Seis meses de programar solo con agentes de IA: lo que aprendí

> El mayor costo fue la escritura. Cada vez que quería construir algo, podía ver el código en mi cabeza. Simplemente no podía teclearlo lo suficientemente rápido.

Hechos. Para mí, cuanto mayor era la brecha entre lo que veía en mi cabeza y la velocidad con la que mis dedos podían físicamente hacerlo realidad, más estrés sentía, y algunas sesiones de codificación maratónicas terminaban con mi espalda destrozada solo por la tensión.

Y antes de los LLMs, habría improvisado un script bash de veinte líneas y un cron job durante el almuerzo, y habría pasado seis meses trabajando en otra cosa.

¿Cómo lee la gente este tipo de publicaciones con este estilo de IA? No pude leer más de un par de frases.

Varios comentarios aquí tocan el problema central: los agentes están escribiendo más código del que podemos revisar. Los seniors nunca han tenido suficiente tiempo para revisar, y la prolífica producción de los agentes de codificación lo está empeorando. Además, el código es casi siempre bueno. Así que estás revisando un tsunami de código bastante bueno, lo que significa que te fatigas de revisar y todo se convierte en teatro.

Para mí, esto significa que las comprobaciones tienen que ser más que simplemente "lo he mirado". Hay dos cosas que suceden antes de que yo lo vea: primero, como otros han mencionado, tengo un modelo de una familia diferente que lo revisa con criterios bien definidos. Los revisores de la misma familia comparten sesgos, así que debe ser uno diferente. Segundo, tengo un conjunto central de compuertas deterministas (como lint, pero también pruebas unitarias) que deben ejecutarse. En cualquier caso, los fallos vuelven al agente de codificación.

Y solo entonces me molesto. Pero realmente no leo todo. Si es CRUD estándar, los agentes son bastante buenos en eso, especialmente si usan paquetes maduros. Me concentro en cosas críticas, como cómo se aplican los permisos.

Esto funciona bien para mí, aunque deja un problema importante sin tocar: si vale la pena construir esto. Los agentes tienden a ser un poco demasiado entusiastas, así que tengo que hacer mucho trabajo por adelantado para asegurarme de que la salida agregue valor. Las compuertas solo pueden verificar el artefacto, no mi intención.

Escribir código con LLMs requiere disciplina y es difícil. Necesitas aprender a hacerlo y cómo sacarle el máximo provecho.

¡La ingeniería de software ha muerto, larga vida a la ingeniería de software!

Siento una disonancia realmente extraña con todos estos relatos. Tengo acceso a los mejores modelos a través de Cursor en el trabajo. Cada vez que pienso para mí mismo: aquí hay una tarea tediosa pero bien definida, con criterios de éxito claros, donde puedes lograr mucho con iteraciones persistentes. Se la daré a Claude para que la haga.

Primero, me lleva mucho tiempo describir la tarea correctamente. Todos estos criterios de éxito claros, bueno, en lugar de escribir código a partir de una especificación clara en mi cabeza, estoy escribiendo toneladas de prosa, tratando de que sea inequívoca. Estoy programando en inglés++.

Pero luego, una de cada cinco veces, produce algo que más o menos funciona. Quizás no perfecto, pero suficientemente bueno. Dos de cada cinco veces parece más o menos correcto, pero en realidad ignora el 80% de la especificación, o le presta un servicio mínimo en los comentarios.

Y a veces, quizás un poco menos de 2/5, simplemente se desvía por completo hacia una mierda total. Empieza a escribir scripts que cargan el ast del script principal y lo encurten y luego lo serializan a base64 sin ninguna buena razón. Codifican algunas cosas en cadenas y luego comprueban ord(string[i]) repetidamente para comparar cadenas. Eventualmente se queda sin contexto y desarrolla el equivalente LLM de demencia severa.

Realmente no puedo reconciliar mi experiencia con personas que parecen decir "oye, computadora, escribe esto" y es un buen uso de su tiempo.

Es una pena ver un artículo que por lo demás es bueno, inflado con AI-ismos ("Pero aquí está el giro: esa búsqueda que describí antes nunca se envió a botd. Todo el historial estaba en SQLite, así que apunté otro agente hacia él y obtuve el análisis de todos modos. La herramienta murió; los datos no.", entre otros ejemplos).

Maisem Ali escribe sobre cómo no han dejado de hacer ingeniería a pesar de haber entregado la producción de código a la IA. Creo que es una perspectiva interesante por varias razones, pero sobre todo, no estoy seguro de estar de acuerdo.

Primero, vemos un ejemplo primordial de cómo eso puede explotar. "botd murió este mes. Se derrumbó bajo su propio peso". Es difícil imaginar cómo un arnés de agente (¿o es una superposición sobre otros arneses?) podría derrumbarse bajo su propio peso por pura complejidad técnica. ¿Qué hace que una herramienta así se "derrumbé"? Si está correctamente arquitecturada, parece que cualquier cambio externo podría ser adaptable. Las pruebas que fallan podrían arreglarse.

Esta evolución de la codificación con IA nos ha dado la capacidad de crear prototipos de cuyos funcionamientos internos no entendemos, pero creo que para cualquier cosa de valor (y, argumentaría, botd parecía tener valor para Maisem) deberíamos al menos entender e influir en la arquitectura y la ingeniería de lo que estamos construyendo. Si Maisem hubiera hecho eso con botd, no se habría "derrumbado bajo su propio peso" y _no podría_ haberlo hecho. Cualquier influencia externa que requiriera cambios dentro de botd habría sido manejable.

Segundo, la externalización de la producción de este artículo indica que m […]