Los cuatro jinetes de la programación con agentes

Es muy posible usar estas herramientas de forma incorrecta. Las empresas que entienden cómo usar la IA lo harán mejor, las que tengan estos 4 problemas no.

- La IA debería acelerar tu comprensión del código base y de los conceptos técnicos.

- Las habilidades deberían garantizar una calidad de código superior a la que podrías crear sin IA.

- Los ingenieros deberían seguir siendo responsables del código que producen.

- El tiempo disponible liberado debería usarse para comunicación, investigación de producto y marketing. La definición de un ingeniero que solo escribe código es algo que está desapareciendo.

A menos que algo sea tan simple que la IA pueda ejecutarlo de forma autónoma. De hecho, hoy en día hay muchos proyectos así. Y en esos casos, no mirar el código como hace DHH también es una estrategia viable.

Siento que estoy viviendo en un universo alternativo: mi empresa ha adoptado por completo la programación agéntica, estamos trabajando con:

- bases de código grandes

- software crítico para el negocio de clientes que no toleran caídas

- características agénticas y clásicas

Seguimos colaborando bien, seguimos preocupándonos por la calidad, seguimos teniendo buen conocimiento del código base, pero no he escrito una sola línea de código yo mismo en más de un año.

No hemos tenido ni un solo incidente que yo sepa en el que hayamos enviado un slop y haya creado una caída.

Estamos construyendo una "fábrica de software" que actualmente se encarga de tickets de tareas de bajo nivel y fusiona aproximadamente 1/3 de nuestras PRs. Dentro de un año imagino que hará bastante más, y no creo que nadie vaya a ser despedido por ello (si acaso, seguiremos contratando más).

No veo esto como algo de o todo o nada. Si hay algún océano oculto de slop en el que estamos destinados a caer, no lo veo por ningún lado. ¿Dónde está la disparidad?

Mis canales de Slack del trabajo son pueblos fantasma. La gente está conectada, pero nunca dice nada. A menudo me pregunto si alguien está siquiera trabajando. Las PRs llevan sus nombres, incluso los comentarios de revisión se publican desde _sus_ cuentas, pero es obvio que Claude escribió todo, desde el código, el resumen de cambios innecesariamente verboso, hasta sus comentarios. Incluso sus respuestas a mis solicitudes de cambios empiezan con "Tienes razón — …".

Echo de menos los días en que los canales de Slack de ingeniería tenían largos hilos de formas nuevas e interesantes de hacer las cosas, discusiones sobre algo que podríamos hacer a continuación para facilitar el trabajo o arreglar problemas de larga data. Solíamos construir nuestro propio conocimiento sobre quién era bueno en cosas específicas, en qué les interesaría trabajar. Ahora todos simplemente dejan que su máquina de slop escupa cada pieza de un cambio para todo el stack sin prestar atención a los detalles.

Estoy de acuerdo con todo en este artículo (aunque sigo siendo optimista de que los LLMs ayudarán a personas sin habilidades a escribir software personal), pero a menos que el trabajo empiece a organizarse de manera significativa y a presionar contra el poder corporativo que causa estos resultados, las cosas solo empeorarán.

Como que podemos decir "esto apesta" veinte mil veces, pero ¿cuál es el plan? Quizás algunos de los seniors que pueden ser productivos gracias a nuestro conocimiento, que pueden dejar de existir como clase, lo que resultaría en un siglo de slop, deberían reunirse y hablar de praxis. De lo contrario, todos estos artículos son solo datos de entrenamiento.