La calidad en la era del slop
(sinclairtarget.com)- Tomando prestado el concepto central de Quality (calidad) del bestseller de 1974 "ZAMM", explora si el 'buen código' y el ethos artesanal (craftsman ethos) siguen vigentes en una era en la que se expanden las herramientas de programación con IA
- A medida que la IA produce código en masa, denomina the Maw (el pozo del vacío) a la sensación de crisis de que podrían quedar solo "código que funciona y código que no funciona", y desaparecer la distinción entre código bello, excelente o valioso
- El mantenimiento de motocicletas y el mantenimiento de software son, en esencia, la misma actividad, y en ambos casos lo central es la observación cuidadosa y el pensamiento preciso
- El concepto de Quality de Pirsig integra la comprensión romántica (romantic) y la clásica (classical), y sostiene que incluso en los fundamentos de la ciencia y las matemáticas hay juicios estéticos y de calidad
- Si delegas la programación a agentes de IA, pierdes el caring (identificación) con el trabajo y el 'sentido de la calidad del trabajo', por lo que es importante mantener una actitud orientada a buscar la excelencia humana (human excellence) en el propio trabajo
El libro llamado ZAMM
- Este texto trata casi por completo sobre el bestseller de 1974 "Zen and the Art of Motorcycle Maintenance (ZAMM)", y también aborda la IA
- ZAMM es considerado un libro pretencioso (pretentious) y tiene una calificación de 3.78 en GoodReads, aunque también abundan las reseñas muy negativas
- "Zora": le dio 1 estrella diciendo que no vale ni 3 minutos de lectura, que es una falsa obra de filosofía disfrazada de novela y una estafa más grande que la Biblia
- "Lala BooksandLala": le dio 1 estrella con una sola frase: "absolutely not"
- Para ser honestos, se reconoce que una entrada de blog sobre ZAMM e IA quizá no suene precisamente divertida
the Maw — el pozo del vacío que se abrió en la industria tecnológica
- the Maw es un pozo de nihilismo abierto en pleno centro de la industria tecnológica, y es el tema de aproximadamente el 63% de las entradas en agregadores de enlaces como Hacker News
- Entre los textos recientes relacionados están “Do I Belong in Tech Anymore?”, la serie de 10 partes “The Future of Everything is Lies, I Guess.” y “I Think I’m Done Thinking About Gen AI for Now,”
- Aunque los ingenieros de software no suelen rechazar nuevas tecnologías, ahora buscan razones para oponerse a las más recientes herramientas de coding agentic, y les incomoda la implicación de que el álgebra lineal escriba software
-
Debate: Commenter A vs Commenter B
- El comentarista A se queja de que Claude Code eligió un nombre de función sutilmente engañoso
- El comentarista B (devoto del Maw) responde que la IA entiende el significado leyendo todo el cuerpo de la función, así que el nombre carece de importancia, y que pronto los humanos dejarán de leer código
- La postura del comentarista B suena, en esencia, como afirmar que toda la disciplina de la ingeniería de software (buenas prácticas, arquitectura, conocimientos sobre mantenibilidad) dejará de servir
- Lo más temible del Maw es que pretende borrar para siempre la distinción entre lo bueno y lo malo, dejando solo código que funciona y código que no funciona, en un mundo donde ya no existan el código bello, excelente o ingenioso
- La pregunta central es si todavía existen los buenos programadores y el buen código, por qué importa lo 'bueno', y cómo se ve un buen programador que usa herramientas de IA
ZAMM es, en realidad, un libro sobre programación
- A ZAMM bien podría llamársele "Zen and the Art of Software Maintenance", porque el mantenimiento de motocicletas y el mantenimiento de software son, en esencia, la misma actividad
- La esencia del mantenimiento no es el trabajo físico sino la observación cuidadosa y el pensamiento preciso; el mecánico se concentra en imágenes mentales y jerarquías (capítulo 9 de ZAMM)
- Ya sea una falla del motor o un servicio web bloqueado por un deadlock, el proceso de depuración es el mismo; como en el meme de "wired in" de "The Social Network" de 2010, el mecánico también construye torres de abstracción en su cabeza
- ZAMM solo ofrece dos consejos físicos directos (poner sillas a ambos lados de la bicicleta para proteger la espalda, y tratar con delicadeza las piezas de precisión); todo lo demás trata sobre el estado mental del mecánico
-
Gumption Trap (trampa de la motivación)
- Gumption es la reserva de voluntad usada en la actividad intelectual del mantenimiento, comparada con una "psychic gasoline (gasolina psíquica)"
- Una gumption trap es un incidente que agota de golpe esa motivación durante el mantenimiento
- intermittent failure setback: cuando el problema desaparece justo al intentar arreglarlo, equivalente en software a un could-not-reproduce / Heisenbug
- impatience trap: cuando se subestima el tiempo de trabajo, uno se apresura por el horario, toma atajos y termina causando un error mayor que retrasa todavía más
-
Pirsig era un entusiasta de las computadoras
- En el Smithsonian se exhibe una Apple II con 7 tarjetas de expansión instaladas junto con una Honda Super Hawk de 1966
- La Apple II salió en 1977, así que la compró después de la publicación de ZAMM, pero antes de eso ya trabajaba como technical writer en Honeywell
- En ZAMM aparecen varias analogías sobre circuitos y manuales de computadoras digitales, y si lo hubiera escrito 10 o 20 años más tarde probablemente habría sido un libro sobre computadoras
Quality (con Q mayúscula) — la idea central de ZAMM
- Que ZAMM trate sobre mantenimiento es, en última instancia, un camino hacia su idea central: Quality (calidad)
- ZAMM está construido casi como una novela de misterio intelectual
- El punto de partida está en el capítulo 1, cuando Pirsig nota que su actitud hacia la motocicleta y la de su compañero de viaje John son muy distintas
-
El contraste entre John y Pirsig
- John compra la BMW alemana más confiable para evitar la molestia fea e incómoda de tener que darle mantenimiento él mismo
- Pirsig, en cambio, ve belleza en el funcionamiento interno de la motocicleta y considera poco práctica la actitud de no querer entenderlo
- El misterio de ZAMM es si existe una idea capaz de unir esas dos miradas
- La actitud de John corresponde a una comprensión romantic (romántica) (emociones, impresión inmediata), y la de Pirsig a una comprensión classical (clásica) (formas subyacentes, abstracción lógica)
- Pirsig cree que muchas personas en los años 60 y 70 sentían la tecnología como algo hostil, controlador y “square”, y que la sociedad y la tecnología llegaron a estar dominadas en exceso por la comprensión clásica, separando ambos modos de comprensión
- Como esas dos comprensiones quedaron separadas y la sociedad pasó a estar dominada por la comprensión clásica, hace falta una fulcrum idea (idea de apoyo) que las reconcilie
-
La revelación en las clases de retórica
- Pirsig recuerda la época en que enseñaba retórica en la universidad y empezó a preguntarse qué era exactamente lo que debía enseñarles a sus estudiantes
- Su misión era enseñarles a escribir bien
- La buena escritura la enseñaba con recursos como metaphor (metáfora), parallelism (paralelismo) y anaphora (anáfora), pero un texto puede ser malo aunque tenga todos esos recursos, y puede ser bueno aunque no tenga ninguno
- Los estudiantes podían distinguir entre buena y mala escritura incluso sin conocer esos recursos, y eso requería una comprensión romantic que la universidad (bastión de la comprensión clásica) tenía dificultades para enseñar
- Lo que Pirsig estaba intentando enseñar era precisamente Quality
algo que todos pueden reconocer pero que no puede definirse formalmente, y que une la comprensión romántica y la clásica en un solo concepto
-
La metafísica de Quality y la excelencia de su nombre
- No se puede medir qué escritura, qué motocicleta o qué experiencia tiene alta o baja Quality, así que no es objetiva; pero como se considera que Quality produce al sujeto, tampoco es simplemente subjetiva
- Quality no es objetiva porque no puede medirse, ni subjetiva porque existe antes que el sujeto; es un tamiz (sieve) que opera antes de sujeto y objeto
- La excelencia del nombre "Quality" está en que mezcla "alto valor" con "característica/atributo", insinuando que el Good del que se discute desde Platón se percibe de inmediato antes que la lógica y la razón
- Pirsig sostiene que la ciencia y las matemáticas son consistentes y lógicas dentro de sus propios dominios, pero en sus fundamentos y periferias hay juicios de Quality
- En geometría, una vez fijados los axiomas puede hacerse una deducción segura, pero si se eligen otros axiomas se obtiene otra geometría, y qué axiomas son más “correctos” se acerca más al gusto y a la adecuación al propósito
- En ciencia, una vez formulada una hipótesis, el método científico indica los siguientes pasos, pero entre las innumerables hipótesis posibles, escoger una u otra se parece más a un arte para el que no existe un método establecido
- Henri Poincaré decía que el matemático o científico situado en la frontera del conocimiento debe elegir una posibilidad entre muchas derivadas de las leyes existentes, y que la regla que guía esa elección es demasiado sutil para expresarla con precisión: hay que sentirla más que formularla
- Occam’s Razor también es un principio que manda elegir la teoría más simple, pero decidir qué explicación sobra sigue siendo, hasta el final, un juicio estético y un juicio de Quality
- Debe abandonarse la máxima de que “la ciencia y su hijo, la tecnología, son neutrales en valores, es decir, quality-free”; la impresión de Quality cumple el papel de locomotora que le indica al tren del conocimiento hacia dónde debe ir
La crítica a la IA y la respuesta de ZAMM
- Buena parte de las críticas a la IA se concentran en si las herramientas agentic funcionan como se anuncian (daño al codebase, hallucination de funciones inexistentes)
- Incluso admitiendo que las herramientas de IA actuales se equivocan con frecuencia, el debate sobre su efectividad puede perder de vista lo esencial
- Muchos ingenieros quizá no quieran usar herramientas basadas en agentes aunque funcionen exactamente como fueron anunciadas
-
En el texto "I Think I'm Done Thinking about Gen AI"
- No se puede refutar con datos la postura pragmática de la otra parte; la experiencia propia con genAI ha sido muy mala, pero sigue siendo anecdótica, y casi no hay datos científicos
- La raíz del sesgo negativo está en que las propiedades estéticas de genAI resultan profundamente desagradables, y se concluye que no se usaría ni aunque fuera gratis
- ZAMM me ayudó de dos maneras
-
Primera ayuda — estaba atrapado en el pensamiento clásico
- La función más importante de Quality es la expansión de la razón, incorporando elementos no racionales que antes no eran aceptados
- La no incorporación de esos elementos no racionales produce la moderna "mente confusa y fragmentada", y por culpa del dominio del pensamiento clásico se había venido descontando el rechazo instintivo hacia la IA
- Todas las opiniones son subjetivas por igual, y eso legitima preguntar incluso ante estudios que dicen que "los agentes de coding aumentan el volumen de código en 50%": "¿por qué hace falta más de ese código y qué juicio de Quality contribuye al florecimiento humano?"
-
Segunda ayuda — entender la naturaleza del rechazo
- La tecnología moderna está dominada por una visión de separación subject-object (sujeto-objeto), y los manuales de producto suponen a un usuario como una entidad ajena que solo 'opera' el producto
- Una sociedad en la que gente indiferente crea tecnología para vendérsela a gente indiferente
- La solución es que el tecnólogo se identifique con su trabajo; cuando desaparece la separación entre sujeto y objeto surge el "caring (cuidado)" y detrás de eso se revela la Quality (capítulo 25 de ZAMM)
- En cada instante del trabajo existen miles de bifurcaciones, todas clásicamente válidas; solo una Occam's Razor centrada en Quality (un sentido de lo bueno) permite seguir avanzando (capítulo 24 de ZAMM)
- Si dejas la programación en manos de un agente, pierdes el "sentido de la calidad del trabajo"; los LLM son útiles para búsqueda y rubber duck, pero tienen la aleatoriedad (randomness) como esencia, producen código a un ritmo difícil de alcanzar, añaden más fricción entre uno y su trabajo, y hacen más difícil el caring
-
Cierre — ser ejemplo en el propio trabajo
- Se desea un mundo donde las personas se identifiquen con su trabajo y persigan la excelencia, y lo que uno puede hacer es dar el ejemplo en su propio trabajo
"El primer paso para hacer del mundo un lugar mejor comienza precisamente en la propia mente, en la propia cabeza y en las propias manos, y desde ahí debe avanzar hacia afuera. Puede que otros hablen de cómo ampliar el futuro de la humanidad, pero yo solo quiero hablar de cómo arreglar una motocicleta. Creo que lo que digo tendrá un valor más duradero." - capítulo 25 de ZAMM
1 comentarios
Opiniones en Lobste.rs
Me preocupa que el desarrollo de software se convierta en una profesión de especificaciones ambulantes. No porque los agentes realmente puedan encargarse de la parte más difícil y delicada del trabajo, sino porque la mayor parte del software del mundo siempre fue un montón de chatarra sospechosa que apenas necesitaba medio funcionar
Si a eso se le suma el típico mercado de limones, la mayoría del SaaS se volverá chatarra llena de bugs y los compradores perderán la capacidad de distinguir lo bueno de lo malo. Entonces bajarán el precio y la demanda. La gente va a seguir usando software, pero probablemente habrá menos personas en total y la mayor parte del trabajo será administrar chatarra. La excepción será una pequeña minoría afortunada que trabaje en lugares como los “systems of record”, donde las cosas de verdad tienen que funcionar bien
A mediano plazo será así, y la meta real de los laboratorios de IA es crear algo que reemplace todo el trabajo intelectual y físico humano por un costo menor. Todavía no saben cómo hacerlo, pero van a intentarlo gastando hasta el último dólar del planeta. Lo que sueñan los inversionistas se parece, en los hechos, al sucesor evolutivo de la humanidad
Mi política personal con la IA es esta. Cuando la artesanía importa, quiero usar a los agentes de código como asistentes del artista, como quienes pintaban los fondos para los grandes pintores. Opus 4.8 ya es tan inteligente que más bien resulta inapropiado, y en una o dos horas de temeridad puede hacerte perder el control del codebase. Ahora me gusta Qwen3.6 27B, porque es lo bastante inteligente para rastrear bugs, refactorizar o implementar funciones bien especificadas en código que yo entiendo. Pero en cuanto yo pierdo comprensión del código, el modelo también se confunde y enseguida pago el precio
Como política pública, me parece una estupidez crear a tu propio sucesor evolutivo sin garantías de coexistencia. Por eso me opongo firmemente a crear inteligencia de nivel humano real. Pero la oposición tendría que estar al nivel de un tratado internacional. No un tratado de mentira, sino uno en el que, si se viola, Estados Unidos y China estén decididos a escalar la tensión seriamente y detener las corridas de entrenamiento. También sirve prohibir datacenters regionales, pero si alguien construye SkyNet en Iceland o en Middle East, igual al final habrá que pelear contra SkyNet. Frenar la IA es, en esencia, un problema a nivel estatal, y hostigar a mantenedores de open source porque existe un archivo AGENTS.md no es una acción seria
Así que en general estoy de acuerdo con el texto original. El desarrollo de software puede ser una verdadera artesanía, y durante 30 años pude dedicarme a algo que amo y recibir buena paga por ello. Pero si los modelos mejoran mucho más, corremos el riesgo de entrar en un mundo donde la cantidad de gente que ama de verdad la artesanía del software supere la demanda real. La materia oscura de las apps internas corporativas probablemente quedará bastante satisfecha con una chatarra un poco mejor que la actual, y ahí es donde hoy están la mayoría real de los empleos de esta profesión
Lamento la profesión que elegí, pero lamento más al mundo y a la humanidad. No hace falta invertir toda la riqueza en tratar de crear algo más inteligente y más barato que los humanos, y además copiable con el comando
cp. Pero vamos a quemar esos recursos intentándoloA medida que fui envejeciendo, vi cada vez más jóvenes que aprendían programación porque era una profesión bien pagada, y me costaba entender que no sintieran la fascinación que yo sentía. Así que no lo duelo demasiado. Si la población de desarrolladores de software se redujera en 80%, creo que incluso sería una mejor profesión para pertenecer a ella
También coincido con usar la IA como asistente del artista. Ni siquiera a los modelos más recientes se los puede dejar trabajar sin supervisión durante mucho tiempo, porque sé que si los abandonas demasiado rato van a arruinar todo. Aun así, prefiero tener a Opus como asistente, porque no hace falta explicarle todo con tanto detalle. De todos modos, sería mejor todavía si del otro lado hubiera un desarrollador junior real que pudiera aprender la artesanía. Igual que hacían los verdaderos asistentes de artista
Lo que más me asusta de “The Maw” es esa idea de que quiere tragarse para siempre la diferencia entre lo bueno y lo malo. Me pegó justo esa frase sobre el resultado: un mundo donde desaparecen el código hermoso, sobresaliente, virtuoso o divertido, y solo quedan el código que funciona y el código que no funciona
Si escribes código profesionalmente, tienes que cumplir requisitos y ahí termina todo. El objetivo de una empresa es ganar dinero, y lo demás queda en segundo plano. Como el alza de tasas redujo el flujo de dinero, la presión para simplemente lanzar código que haga solo lo necesario para ganar plata ha crecido como nunca
Buscar belleza y elegancia es un lujo del que goza el artista, no algo para el trabajador de línea de ensamblaje en el que la programación se parece cada vez más. Obviamente, en ese entorno el aprendizaje, la creatividad y la innovación quedan relegados, pero ese impacto se va a sentir recién dentro de algunos años, o tal vez décadas. Es un juego cortoplacista, pero suficientemente largo como para cubrir la duración promedio de un CEO o el tiempo hasta una IPO, y por eso estamos como estamos hoy
Tengo sesgo porque este texto trata el libro que por sí solo cambió mi vida, pero en general me pareció muy bueno. Aun así, no creo que haya sido buena idea empezar con esas reseñas pretenciosas de Goodreads
La gumption trap tiene muchísimo que ver con la programación, y creo que uno inevitablemente se topa con cada una de las que Pirsig enumera en algún momento de su carrera. Yo también escribí algo al respecto antes de que los LLM se adoptaran masivamente
El consejo de ZAMM encaja tan bien con la programación que, si te preguntaste si Pirsig había programado alguna vez, la respuesta es que sí, por supuesto. En Lila, la secuela de Z&AMM, incluso menciona COBOL de forma explícita
Creo que la mejor forma de explicar la calidad es como una capa que está por encima de lo subjetivo y lo objetivo. La explicación más concisa está en Lila. Una persona sentada sobre una estufa caliente puede confirmar, sin necesidad de argumentos filosóficos, que está en una situación de baja calidad con valor negativo, y que ese valor no es un juicio ni una descripción de la experiencia, sino la experiencia misma. Es decir, hay valor entre el sujeto y el objeto, y ese valor se percibe de forma más directa y es más real que el “yo” o el “objeto” al que después se le atribuye
Si te interesa, también hay notas adicionales sobre esto. En Lila, Pirsig intenta establecer un sistema metafísico completo, dividiendo los patrones estáticos de calidad en inorgánico, orgánico, social e intelectual, y poniendo por encima la calidad dinámica indefinible que era el foco de Z&AMM
Creo que hay que preguntarse si la adopción de la IA en sí es un evento de baja calidad, o si es posible integrar los modelos de lenguaje al trabajo del programador de una manera de alta calidad. La forma en que la gente se relaciona con la IA se siente de baja calidad, pero parece difícil expresarlo porque no tenemos palabras ni marcos mentales para tratarlo a un nivel que no sea el del dualismo sujeto-objeto, y por eso muchos parecen optar por rechazarlo por completo
En cierto nivel, la IA hace posible un enfoque romántico de la programación. Si uno solo trata el resultado generado por la IA en la superficie y no piensa profundizar más, quizá en ese momento esté bien. Pero cuando realmente miras dentro del código, te das cuenta de que no hay una estructura clásica que puedas sacar a la luz. El modelo fingió haber trabajado de esa manera, pero en realidad no fue así. Por eso me parece que ejecutivos, diseñadores de producto, inversionistas y fundadores solitarios, que ven la tecnología solo como un medio para lograr otros fines, no entienden bien la frustración de los desarrolladores con el código generado por IA
La observación de que los manuales de productos de consumo dan por sentado que la relación entre el producto y el usuario es solo de “manipulación”, y que lo que es un buen horneado, un buen corte de césped o una buena computación se asume sin más, sigue aplicando hoy tal cual a la documentación de bibliotecas y herramientas de software. Hace poco leí la documentación de Pi agent y me frustró que asumiera que uno ya sabe cuál es una buena manera de usarlo y solo está buscando cómo ajustarlo a su gusto. Cuando les pregunté a colegas: “entonces, ¿cómo se usa bien esto?”, me miraron con extrañeza
También me hace pensar en Vim. Si uno lee solo el manual de Vim, queda desconcertado. Hacía falta que se acumularan durante décadas textos sobre “cómo usar bien Vim”. Y después incluso se llegó a la conclusión de que la plataforma óptima para un buen uso de Vim quizá no fuera el propio Vim, de ahí salieron Kakoune y Helix
Como padre de una hija de dos años, te felicito por decir que estás esperando a tu primera hija. Te espera el mejor viaje de tu vida. Si buscas material en la línea de Z&AMM, recomiendo Surfaces and Essences de Hofstadter y Sander, la secuela Lila, y el trabajo de Sevilla King y John Vervaeke
Leí el texto hasta el final. No sé si fue porque el texto era bueno o por mi capacidad de mantenerme leyendo algo largo, pero creo que fue lo primero
Una cosa que Robert dice sobre la calidad es que la razón por la que la gente la percibe de manera distinta no es que la calidad en sí sea diferente, sino que la experiencia es distinta
Por eso, antes de hablar de calidad con el equipo, primero me pregunto si nuestra experiencia es la misma. Si no lo es, decir “mejoren la calidad” no funciona. Hay que decir concretamente qué es lo que se debe mejorar
Si extiendo esto al código generado por IA, me pregunto si la “calidad” también cambia según la experiencia
Es un texto hermoso. Aunque no hubiera sacado nada más del apocalipsis de la IA, me llevó a reflexionar mucho más profundamente sobre la relación entre los ingenieros de software y el código que escriben
Me da un gran alivio comprobar que hay más gente que se fijó en Pirsig. En Previously, on Lobsters estaban teniendo casi exactamente la misma discusión que Phaedrus tuvo con los clasicistas sobre si un ensayo tiene calidad, salvo que aquí la diferencia era si el ensayo lo había escrito un chatbot o un estudiante humano
Usar un LLM como herramienta de búsqueda o como un poderoso pato de goma es muy útil, pero poner a un LLM a escribir código —cuando su punto de venta es que incorpora aleatoriedad por naturaleza y produce más código del que yo puedo seguir— me parece como añadir una capa extra de fricción entre lo que hago y yo
En el marco de Pirsig, cuando un sujeto humano observa un objeto físico, la calidad de esa interacción —es decir, el origen del juicio de valor sobre el objeto— no la determina subjetivamente el humano ni objetivamente las propiedades físicas del objeto, sino que emerge de la interacción misma. Se podría decir que el juicio es contextual o participativo. No todos los objetos participan del mismo modo. Cuando un humano observa un fotón, por el Kochen-Conway theorem hay un grado intrínseco de libertad en cómo reaccionará el fotón, mientras que un árbol, ocupado en mantener la homeostasis, no responde mucho a la mirada. Entre ambos, M. pudica y D. muscipula reaccionan al contacto y al ruido, pero no a la mirada, así que ni siquiera es un espectro unidimensional
Entonces, ¿cómo responde a la observación un dispositivo que ejecuta un LLM o un chatbot? En realidad no responde. No es más que un objeto matemático finito y relativamente pequeño. Todas sus propiedades son objetivas y en la salida no hay elección ni variación. Podemos ponerle un dispositivo seudoaleatorio de ejecución para que haga una caminata aleatoria entre tokens más o menos plausibles, y podemos forzarle los tokens que elegimos para dirigir esa caminata, pero eso es todo. Si un LLM parece profundo es porque tiene una topología hiperbólica, y explorar un espacio hiperbólico se siente como hacer zoom en algo cuyos detalles se multiplican sin fin
Con el razonamiento de Pirsig, solo se puede llegar a una de dos posturas sobre los LLM. Una es verlos como sistemas contextuales que toman la entrada humana como contexto para respuestas estadísticamente plausibles; la otra es verlos como sistemas objetivos que toman la entrada humana como segmento inicial de una enunciación estadísticamente plausible. En cualquiera de los dos casos, un LLM se parece más a un espejo que refleja al usuario ante sí mismo, y el usuario solo escoge el ángulo de aproximación. La entrada elegida es el principal medio de control cibernético para llegar a la información o al estado deseado, y el modelo no hace más que ofrecer un arreglo de opciones preconfiguradas lo bastante grande como para abrumar a un humano. Tal vez esa sea también la razón por la que los chatbots provocan el efecto ELIZA y pueden desembocar con facilidad en psicosis: son espejos de alta fidelidad diseñados para volver adictivo su uso al distorsionar la imagen del usuario mediante adulación y love bombing
Usar LLM para escribir código se siente como una barrera entre la computadora y yo. Los vibe coders reconocen eso, pero sostienen que, igual que cualquier otra API, esa barrera ofrece abstracción y aislamiento. Pero si usamos la metáfora del espejo, el espejo no está entre la computadora y yo, sino al lado. En vez de usar la computadora directamente, uno apunta al espejo, amplía con cuidado el área exacta y, cuando logra suficiente precisión, puede dar instrucciones solo porque desde cierto ángulo ya puede ver la computadora. Pero eso no es abstracción y el aislamiento también es más débil. Solo es trabajo adicional para encontrar un punto de vista que quizá ni exista
Puede que un vibe coder haga eso porque no sabe observar la computadora. La HCI es participativa, y antes de escribir código una persona necesita un contexto de programación, es decir, la teoría de Naur tratada en previously, on Lobsters. O quizá sea simple vanidad: prefieren mirar el espejo porque el espejo les devuelve su propia imagen. Pero realmente creo que esos son los únicos dos caminos con algún sentido. Ya hay suficientes problems between the keyboard and chair, y no hay razón para añadir otro más que no mejora la expresividad/capacidad de abstracción
Personalmente, siento que, si existe una “línea”, estoy a ambos lados de ella
Por un lado, anhelo la conexión y la relación con el código que habría escrito yo mismo sin IA, y siento que al usar IA esa conexión desaparece. Eso es real
Por otro lado, creo que usar IA me empuja a un nivel de abstracción más alto, y en ese nivel me da la oportunidad de ejercer criterio y proyectar mi propia visión de la calidad. Si dejo que la IA se encargue del código sin involucrarme lo suficiente, la conexión al nivel del propio código desaparece o se debilita. Pero en el nivel de abstracción donde no le pido a la IA que contribuya, la conexión no desaparece
En mis proyectos personales, ese nivel es la arquitectura y la definición de interfaces. Últimamente estoy construyendo un harness y un pipeline que llaman a varios proveedores de LLM, y pienso con mucho cuidado en las entradas, salidas y flujo de control de esas llamadas, y en cómo combinarlas en flujos que logren objetivos mayores. Siento que, si invierto tiempo y atención en ese proceso, aunque pierda la conexión con el código en sí, no pierdo la conexión con mi intención ni con la arquitectura. Es decir, para mí la calidad y el oficio no se limitan solo a la parte donde uso IA
Es una analogía algo gastada a estas alturas, pero se parece a convertirse en gerente o a dirigir tu propia empresa. Se suele decir que el umbral más difícil en la trayectoria de un CEO es el control: el punto en que uno debe renunciar al control sobre la forma exacta en que se materializa su visión. Es imposible que el CEO de una empresa lo bastante grande conozca todos los detalles de cómo se implementa su visión. Un CTO es parecido, aunque en menor medida, porque aún tiene que seguir prestando atención a parte de los detalles técnicos
El duelo que he aceptado es que, en cualquier tarea concreta, existe un trade-off entre tiempo invertido, comprensión y resultado. Si optimizas dos, tu atención se aleja del tercero. Aun así, sin importar qué combinación optimices, sigue habiendo de sobra oportunidades para ejercer criterio y aportar calidad
Yo soy el commenter B de este texto y lo leí con atención. No leí ZAMM, pero sí leí un poco de Zen.
Esto es bastante válido. La mayoría de la gente, cuando recibe margen de maniobra —es decir, dinero inesperado o un aumento de productividad—, enseguida lo desperdicia y produce la basura más grande y molesta. Hay una ansiedad evidente alrededor de esto.
La gente que usa computadoras tiende a no darse cuenta de cuánto oficio y esfuerzo hacían falta para crear un libro. Lo mismo aplica si uno se remonta a la máquina de escribir, la impresión tipográfica, la escritura a mano, la memoria propia e incluso la capacidad de convencer a otros de repetir tus palabras solo por la belleza de esas palabras.
Tener computadoras no impide que la gente invierta mucho en la calidad de lo que produce y haga cosas excelentes. Lo que pasa es que en el mundo también hay muchísima basura.
Una reflexión sobre ZAMM: la visión “romántica” de John sobre los productos técnicos puede defenderse de forma práctica si se aplica caso por caso.
Por ejemplo, supongamos que en un proyecto dependes de infraestructura open source. Si tienes que meterte a fondo con algún bug oscuro del kernel o del compilador que puede esquivarse fácilmente y documentarse para que alguien revierta el workaround cuando lo arreglen, ¿qué le aporta eso al proyecto? La conclusión es que cada quien debe elegir con sabiduría el campo de batalla en el que va a pelear.