Desde 2022, ya no me pregunto realmente si la IA puede programar. La respuesta es sí. Puede incluso sacar mucho código, muy rápido, en direcciones distintas, con una calidad que veo progresar a cada generación de modelos.
Vi de cerca esa subida de potencia. Primero como curiosidad, después como herramienta de trabajo, y después como entorno en el que una parte de mi oficio se desplaza. Prefiero mirarlo a la escala de una jornada de trabajo: las líneas que ya no escribo, los diffs que leo, las decisiones que guardo.
El verdadero tema empieza después: ¿qué hago con esa velocidad? ¿La dejo tomar la reflexión en mi lugar, o la uso para explorar más allá de mis límites humanos? Sigo limitado por mi cuerpo, mi atención, mi fatiga, y el tiempo que realmente puedo darle a este oficio.
Explorar más rápido que mi tiempo humano
Puedo cavar mucho tiempo, pero no puedo explorar todas las pistas a mano. Escribir 500 líneas de código útiles a mano en una jornada ya es bastante, porque esas líneas finales suelen esconder dos o tres veces más de intentos, refactor, eliminaciones y vueltas atrás.
Esa relación con el tiempo cambia. La IA puede producir una primera pista, una variante, un segundo enfoque, después un contraejemplo, mucho más rápido que yo. No vuelve buenas esas pistas por arte de magia. Me da un volumen de exploración que no me hubiera podido pagar solo.
Es en ese sentido que la veo como una herramienta de exploración temporal. No reemplaza la experiencia; me permite recorrer más caminos posibles antes de elegir. Mi trabajo no consiste en aceptar la primera salida. Consiste en leer, comparar, sentir lo que se sostiene, y después llevar el sistema hacia la dirección que tiene más sentido.
Pensar un escalón arriba del código
Ya casi no escribo el código a mano. Si programar quiere decir tipear las líneas, entonces sí, programo mucho menos que antes. Pero si programar quiere decir transformar una intención en un sistema que funciona, sigo programando: escribo la intención, las restricciones, los criterios de fin, y después releo la traducción producida por la máquina.
Visto así, los LLM no salen de la historia del código. Agregan una capa de abstracción más: después de los compiladores, los lenguajes, los IDE y el autocompletado, el lenguaje natural se vuelve una parte de la interfaz de programación.
Hay un peligro evidente: pedirle a la IA que piense en mi lugar. En ese caso, quizás gano tiempo en una tarea, pero pierdo el ejercicio que me vuelve capaz de juzgar la siguiente. No quiero eso.
Lo aprendí dándome contra la pared. Al principio de Claude Code, durante la beta, cuando empezaba a meter la mano en los agentes y la herramienta, vi salir diffs que se sostenían. Empecé a releer menos. Después casi nada. Aceptaba los planes, dejaba a los agentes encadenar, y partía del supuesto de que el resultado iba a ser bueno porque las salidas anteriores parecían buenas. Terminó como tenía que terminar: demasiada complejidad, regresiones, incoherencias, y un sistema que tenía que retomar a mano cuando ya no lo entendía bien yo mismo.
El punto no es leer cada bucle for o cada if en detalle. El punto es entender el sistema: las fronteras entre los módulos, los contratos, las interfaces, los tests que me dicen cuándo se rompe. Cuando esas fronteras están borrosas, el agente puede pasar una responsabilidad al lugar equivocado, conectar dos bloques demasiado rápido, o producir una solución que funciona localmente pero arruina la arquitectura. Lo viví. Mientras entiendo cómo se comunican los bloques entre sí, mientras los tests cuentan una intención legible, sigo haciendo mi oficio. Solo que trabajo a un nivel más alto.
Es ahí donde la expresión “amplificador de pensamiento” tiene sentido para mí. La IA no amplifica un pensamiento ausente. Me ayuda sobre todo cuando ya sé dónde mirar, qué rechazar, y qué verificación encadenar después. Mi expertise sigue ahí, y la IA me da con qué construir alrededor: un prototipo, una interfaz, un script, una documentación, una pista de arquitectura. No reemplaza mi técnica. Me da más agarre.
Orquestar sin soltar el volante
La imagen del director de orquesta todavía me habla, si queda atada al trabajo real. En mi día a día, eso quiere decir: doy la intención, acoto la tarea, a veces elijo un agente o un subagente, releo lo que vuelve, corto cuando el marco se vuelve demasiado pesado.
Pilotear agentes no quiere decir mirar el trabajo de lejos. Al contrario, cuanto más rápido van, más tengo que saber dónde mirar. Una consigna borrosa produce rápido mucho código borroso. Un relevo mal acotado pierde un matiz. Un workflow demasiado ambicioso se vuelve una máquina innecesaria. Mi trabajo, acá, es mantener la señal legible.
Ese desplazamiento me obligó a mirar mis propios métodos. Al principio, pensaba mucho en prompts. Después en contexto. Después en orquestación. Después en barandas. No era un plan trazado de antemano. Era una fase de aprendizaje, como mis primeros años de desarrollador: pruebo, me equivoco, corrijo, entiendo mejor dónde están los verdaderos límites. La diferencia es que esta vez aprendo al inicio de la era de los agentes, mientras los usos, las técnicas y las herramientas todavía se construyen.
Lo que sigue siendo útil
Después de todos esos intentos, no me quedo con las herramientas más impresionantes. Me quedo con lo que reduce realmente el ruido: fronteras visibles, contexto cargado en el momento justo, reglas cortas, y controles automáticos que rechazan lo que sale del marco.
Me quedo con el contexto útil. El contexto máximo termina rápido costando más caro de lo que aporta. Un agente no necesita saberlo todo al arrancar. Necesita entender el marco para actuar sin inventarlo, y después poder cargar el resto cuando la tarea lo pide.
Me quedo con las reglas cortas, cerca del código, acompañadas de su razón. Una regla seca se esquiva rápido. Una regla que explica por qué existe una frontera se sostiene mejor, sobre todo cuando el agente tiene que elegir entre dos soluciones plausibles.
Me quedo con las verificaciones ejecutables: no solo escribir una regla, sino hacer que el sistema pueda controlarla. Cuando una restricción puede convertirse en un test, un lint, un check de arquitectura o una validación CI, prefiero sacarla del prompt y hacerla responder automáticamente.
Corto los escaneos exhaustivos demasiado lentos, los archivos de contexto mantenidos a mano, los workflows de orquestación que cuestan más caro de lo que evitan. Corto también la idea de que un mejor prompt puede compensar una arquitectura borrosa. A partir de cierto punto, más palabras no dan más control. Solo dan más ruido.
No corto para apuntar a algo más chico. Corto para poder seguir entendiendo lo que construyo.
Lo que me hubiera gustado leer antes
Aprendí esto en un momento en que los usos todavía eran inestables. No había autopista limpia, ni buena práctica evidente, ni respuesta simple para copiar.
Algunos errores valen más cuando no se quedan privados. Si una parte de este diario puede evitarle a alguien perder tiempo en los mismos callejones sin salida, ya habrá servido de algo.
Actualización (28 de abril de 2026)
Pronto va a hacer un año que descubrí Claude Code y que lo uso, entre otras herramientas. En este año, pasé más de 2000 horas programando con agentes IA. No sé hacia dónde va todo esto, pero sé que ese tiempo pasado con ellos me cambió la mirada: veo más rápido dónde ayudan, dónde derivan, y dónde el desarrollador tiene que seguir presente.
Si querés hablarlo conmigo, podés escribirme acá: augustin.bengolea@gmail.com.
No salgo de esto con una doctrina. Salgo con un reflejo: mientras siga entendiendo el sistema, puedo delegar. El día que ya no entiendo, la ganancia de velocidad se transforma en deuda.