Javier Guerrero

Friday, May 22, 2026

Lo que diferencia al que programa con IA del que solo pega código de ChatGPT

Los 3 niveles de uso — y por qué casi todos se quedan atascados en el primero.

Hay una escena que se repite todos los días en miles de equipos de desarrollo. Alguien abre ChatGPT, escribe "dame el código para X", copia lo que sale, lo pega en el editor y reza para que funcione. Si funciona, sigue. Si no, vuelve a preguntar.

Eso no es programar con IA. Eso es buscar en Google con pasos extra.

Y el problema no está en la herramienta. Está en el nivel de uso. Porque la IA tiene capas, y la mayoría de los developers viven congelados en la primera. No por falta de inteligencia, sino porque nadie les ha mostrado que hay algo mucho más potente debajo.

En este artículo voy a describir los tres niveles con los que un developer puede relacionarse con la IA. Verás en cuál estás tú ahora mismo. Y lo más importante: verás adónde puedes ir — y cómo llegar.

Primero: ¿qué diferencia a quien programa con IA del que solo pega código?

La respuesta corta es: la dirección del flujo de pensamiento.

El que pega código delega el pensamiento en la IA. El que programa con IA usa la IA para amplificar su propio pensamiento. La diferencia parece sutil, pero produce resultados completamente distintos.

Cuando delegas el pensamiento, obtienes código que responde a tu pregunta literal. Cuando amplificas tu pensamiento, obtienes código que resuelve tu problema real dentro del contexto real de tu sistema.

La IA en ambos casos hace lo mismo. Eres tú quien cambia.

Los 3 niveles de uso

Nivel 1 El buscador glorificado

Este es el nivel en el que está el 80% de las personas que dicen "usar IA en su trabajo". El patrón es siempre el mismo: tienes un problema puntual, escribes una pregunta genérica, obtienes código, lo copias, lo pegas, ves si funciona. No hay contexto. No hay conversación real. Cada prompt es una isla desconectada de la anterior.

La IA no sabe quién eres, qué estás construyendo, cuáles son tus convenciones de código ni cuál es la arquitectura de tu sistema. Es como contratar a un consultor brillante y hablar con él durante dos minutos cada vez, sin contarle nada de tu empresa.

El resultado predecible: código que funciona en el vacío pero que no encaja en tu base de código real. Soluciones que resuelven la pregunta literal pero ignoran el problema de fondo. Una sensación constante de que "la IA a veces acierta y a veces no" — cuando en realidad el problema es que no le estás dando lo que necesita para acertar siempre.

Señales de que estás en el Nivel 1:

Tus prompts casi nunca superan las 2-3 líneas.
Cada conversación empieza desde cero, sin contexto previo.
Copias el código sin entenderlo del todo, a ver si funciona.
Cuando falla, vuelves a preguntar sin analizar por qué falló.
Usas la IA para cosas que ya sabrías hacer tú solo, solo que más rápido.

Nivel 2 El colaborador con contexto

El developer que llega al Nivel 2 entiende algo fundamental: la IA es tan buena como el contexto que le das. No es una máquina de respuestas — es un colaborador que necesita entender el proyecto, las restricciones y el objetivo para ayudarte de verdad.

En este nivel, los prompts cambian de forma. En lugar de "dame un endpoint para crear usuarios", el developer escribe algo como: "Estoy construyendo una API REST en ASP.NET Core con arquitectura limpia. El dominio tiene una entidad User con estas propiedades. Necesito el handler del comando CreateUser siguiendo el patrón que ya uso en otros handlers. El resultado debe ser un Result monad, no excepciones. Aquí está un handler de referencia para que te guíes..."

La diferencia en la calidad de la respuesta es abismal. Y no porque la IA sea mágicamente mejor — sino porque tú le estás hablando como un developer senior le hablaría a un colega junior muy capaz.

Señales de que estás en el Nivel 2:

Das contexto de arquitectura, stack y convenciones antes de pedir código.
Tienes conversaciones largas y continuas, no preguntas sueltas.
Iteras sobre el output: "esto está bien pero ajusta X porque en mi proyecto Y".
Usas la IA para cosas que serían difíciles o lentas para ti solo.
El código que obtienes encaja en tu base de código real sin cirugía mayor.

Nivel 3 El arquitecto que orquesta agentes

En este nivel, la IA deja de ser una herramienta de productividad y se convierte en una palanca de capacidad. El developer no solo usa la IA para generar código — la usa para pensar en sistemas, validar decisiones de arquitectura, ejecutar flujos de trabajo complejos y coordinar agentes que trabajan sobre diferentes partes del proyecto de forma coordinada.

Hablamos de setups donde múltiples agentes especializados colaboran: uno analiza requerimientos, otro implementa, otro hace code review. O de pipelines donde la IA genera escenarios BDD, código de producción y tests de forma encadenada. El developer de Nivel 3 diseña el flujo — y la IA lo ejecuta.

Lo que diferencia a este developer no es el tooling. Es la mentalidad: no le pide a la IA que escriba código. Le pide que razone sobre trade-offs, que proponga estructuras, que identifique inconsistencias en el diseño. La IA no es el que escribe — es el que piensa junto a ti.

Señales de que estás en el Nivel 3:

Diseñas prompts como si fueran especificaciones técnicas.
Tienes flujos de trabajo donde la IA encadena tareas de forma autónoma.
Usas la IA para decisiones de arquitectura, no solo para implementación.
Tienes agentes con roles distintos: analista, coder, reviewer.
Tu velocidad de entrega ha cambiado de forma estructural, no incremental.

Por qué casi todos se quedan en el Nivel 1 — y cómo salir de ahí

No es por falta de ambición. Es porque el Nivel 1 ya se siente como una ganancia. Si antes tardabas 30 minutos buscando en Stack Overflow y ahora tardas 2 minutos pegando en ChatGPT, la mejora es real y visible. El cerebro humano tiende a optimizar lo que ya funciona y a no buscar lo que todavía no conoce.

Además, pasar del Nivel 1 al 2 requiere algo que muchos developers evitan: pensar más antes de escribir el prompt. En el corto plazo, eso parece más lento. No lo es — pero lo parece. Y ese freno psicológico es suficiente para que la mayoría nunca dé el salto.

El Nivel 3 exige algo más profundo todavía: entender lo suficiente tu propia arquitectura y flujos de trabajo como para poder delegarlos en un agente. Sin fundamentos sólidos, la orquestación de agentes produce caos, no productividad.

"La IA amplifica lo que ya sabes. Si tus fundamentos son débiles, te ayuda a cometer errores más rápido. Si tus fundamentos son sólidos, te convierte en un developer diez veces más potente."

Cómo pasar del Nivel 1 al 2: empieza a dar contexto

El primer paso es el más accesible. Antes de escribir cualquier prompt, hazte tres preguntas: ¿Qué sabe la IA sobre mi proyecto? ¿Qué restricciones tiene que respetar? ¿Cuál es el resultado exacto que necesito y en qué formato?

Responder esas tres preguntas antes de escribir transforma la calidad de lo que obtienes. No es magia — es ingeniería de contexto. Y es una habilidad que se entrena.

Cómo pasar del Nivel 2 al 3: aprende a delegar sistemas, no tareas

La diferencia entre el Nivel 2 y el 3 no es solo técnica. En el Nivel 2 piensas en "qué quiero que la IA haga ahora". En el Nivel 3 piensas en "cómo diseño un flujo donde la IA opera de forma autónoma y confiable".

Eso requiere conocer bien tu dominio, tus patrones de código y tus invariantes de calidad. Primero construye ese conocimiento. Después delégalo.

Si llegaste hasta aquí, ya estás pensando de forma diferente al 80% de los developers que usan IA hoy. El siguiente paso es convertir ese pensamiento en práctica — proyecto real, código real, sistema real.

¿En qué nivel estás ahora mismo? ¿Y adónde quieres llegar?

Thursday, May 7, 2026

Ya no programamos. Ahora dirigimos.

Andrej Karpathy, uno de los fundadores de OpenAI y quien hizo funcionar el piloto automático de Tesla, dijo hace unos meses algo que me resultó sorprendente viniendo de él: que nunca se había sentido tan rezagado como programador.

No lo dijo con angustia. Lo dijo con la curiosidad de alguien que acaba de ver algo que cambia las reglas del juego. Y creo que vale la pena detenerse en eso, porque lo que describe no es una anécdota personal. Es una señal de que el paradigma cambió.

Software 1.0, 2.0, 3.0

Durante décadas programamos de la misma manera: le decíamos a la máquina exactamente qué hacer, línea a línea. Eso es el Software 1.0. Instrucciones explícitas, deterministas, sin ambigüedad.

Luego vino el Software 2.0: en lugar de escribir reglas, organizábamos datos y entrenábamos redes neuronales. Ya no programabas la lógica directamente, sino que la aprendías de los ejemplos. El código se volvió implícito.

Ahora estamos en el Software 3.0. Y aquí la palanca de programación es el lenguaje natural. Lo que pones en el contexto de un modelo de lenguaje es tu forma de instruir al intérprete. El LLM es ese intérprete. Y la pregunta ya no es qué función escribo, sino qué texto le doy a mi agente.

"Puedes externalizar tu forma de pensar, pero no puedes externalizar tu comprensión."

Eso no es solo una metáfora. Es un cambio en cómo concebimos la construcción de software. Y la mayoría de nosotros todavía está usando la mentalidad del paradigma anterior.

El momento en que algo hizo click

Karpathy describe que en diciembre pasado, durante sus vacaciones, empezó a notar algo distinto. Los fragmentos de código que pedía simplemente salían bien. Ya no tenía que corregirlos. Y siguió pidiendo más. Y seguían saliendo bien. Hasta que se dio cuenta de que no recordaba la última vez que había tenido que editar algo manualmente.

Lo que vivió no es solo una mejora cuantitativa en las herramientas. Es una transición cualitativa en el flujo de trabajo. Y creo que muchos developers estamos justo en ese borde, sin haberlo atravesado todavía, o habiéndolo cruzado sin nombrarlo.

Hay un agujero de conejo ahí adentro. Una vez que confías en el sistema, tus proyectos personales se multiplican. Las cosas que antes parecían demasiado grandes para empezarlas solas, de repente son abordables. Eso tiene un costo, claro, porque también tienes que aprender a dirigir, no solo a ejecutar.

El problema de la inteligencia irregular

Pero seamos honestos. Estos modelos son notablemente inconsistentes. Karpathy los llama "irregulares". Un modelo puede refactorizar una base de código de 100,000 líneas y encontrar vulnerabilidades de día cero, y en el mismo día decirte que camines 50 metros para lavar tu carro porque está "muy cerca".

Eso no es un error menor. Es una señal de cómo funcionan por dentro. Los modelos son entrenados con aprendizaje por refuerzo sobre dominios donde la verificación es posible: código, matemáticas, lógica formal. En esos dominios, avanzan rápidísimo. En dominios donde no hay señal de recompensa clara, el modelo navega a ciegas.

La conclusión práctica es importante: si tu problema vive dentro de los circuitos que el modelo entrenó bien, vas a volar. Si estás fuera de esos circuitos, vas a pelear. Y la única forma de saber en cuál estás es explorando. No hay manual. Hay que probar.

Vibe coding vs. ingeniería agéntica

Hay una distinción que me parece clave y que a menudo se mezcla: el vibe coding y la ingeniería agéntica no son lo mismo.

El vibe coding sube el piso. Cualquier persona, con conocimiento técnico limitado, puede construir algo funcional. Eso es enorme. Democratiza la creación de software de maneras que hace cinco años eran impensables.

Pero la ingeniería agéntica busca otra cosa: mantener los estándares de calidad del software profesional mientras usas agentes para ir más rápido. No introduces vulnerabilidades porque "el agente lo hizo". Sigues siendo responsable. Lo que cambia es la velocidad a la que puedes operar.

"El ingeniero 10x de antes se magnifica mucho más ahora. Y 10x ya no es la velocidad que se obtiene."

El techo sube, no baja. Y quienes aprenden a coordinar agentes con criterio de ingeniería son los que van a operar en ese techo. Eso requiere algo que ningún modelo tiene todavía de forma confiable: gusto, juicio, diseño.

Qué sigue valiendo la pena

Si los modelos se encargan de los detalles de las APIs, de los parámetros de las funciones, de la sintaxis específica de cada framework, ¿qué queda para nosotros?

Queda lo más difícil: entender qué estamos construyendo y por qué. Saber que hay un tensor subyacente y qué implica manipular su vista. Diseñar que los usuarios tengan un ID único y que todos los sistemas lo usen, en lugar de intentar cruzar correos electrónicos de distintas plataformas. Eso es diseño de sistemas. Eso es criterio. Y ningún modelo lo va a sustituir en el corto plazo, no porque sea imposible, sino porque nadie ha puesto esa señal de recompensa todavía.

La comprensión no se puede externalizar. Puedes delegar el pensamiento, pero no el entendimiento. Y si no entiendes qué le estás pidiendo al agente, estás firmando en blanco.

El momento en que estamos

Estamos en un punto raro. Las herramientas cambiaron de forma suficientemente profunda como para que los flujos de trabajo viejos ya no sean los óptimos, pero la mayoría del ecosistema todavía está organizado para humanos. La documentación está escrita para que la lea una persona. Los procesos de contratación evalúan si resuelves puzzles algorítmicos. Las empresas miden productividad con métricas diseñadas antes de que existieran los agentes.

Todo eso va a cambiar. Ya está cambiando. Y quienes se adapten primero no son los que abandonen el rigor técnico, sino los que aprendan a aplicarlo en este nuevo paradigma: dirigiendo agentes con la misma exigencia con la que antes escribían código.

La pregunta ya no es si sabes programar. Es si sabes dirigir.

Este artículo está basado en ideas expresadas por Andrej Karpathy en una conversación reciente sobre el estado actual del desarrollo de software y la inteligencia artificial.

Fuente: https://x.com/stephzhan/status/2049518659513852109

Friday, May 1, 2026

Lo que Martin Fowler y Kent Beck piensan sobre la IA (y lo que eso significa para ti como desarrollador)

Dos leyendas de la ingeniería de software hablan sin filtros sobre el momento más incierto y emocionante de la historia del desarrollo.

Hace unas semanas, Martin Fowler y Kent Beck —dos de los 17 firmantes del Manifiesto Ágil— se sentaron frente a una sala llena de startups de IA para hablar sobre lo que está pasando en nuestra industria. No como vendedores de tecnología. No como gurús con respuestas prefabricadas. Sino como ingenieros con décadas de experiencia que, por primera vez en mucho tiempo, admiten que tampoco saben qué va a pasar.

Lo que dijeron merece tu atención.

"Nadie tiene las respuestas. Eso es la buena noticia."

Durante 25 años, cuando alguien llegaba con un problema —demasiados bugs, código imposible de mantener, equipos disfuncionales— Kent Beck y Martin Fowler tenían respuestas. Escribe pruebas. Refactoriza. Trabaja en pareja. Itera en ciclos cortos.

Eso se acabó. Y ellos lo dicen sin drama.

"Lo que ha cambiado es que en este momento, nadie sabe las respuestas a nada." — Kent Beck

Pero Beck añade algo importante: la mala noticia es que no hay respuesta. La buena noticia es que nadie más la tiene tampoco. Eso pone a todos —junior, senior, los propios Fowler y Beck— en el mismo punto de partida.

Si llevas tiempo sintiéndote perdido frente a la IA, no es porque te falte experiencia. Es porque estamos todos en territorio desconocido.

La IA como amplificador: por qué este es el mejor momento para ser junior

Kent Beck tiene una opinión que va contra la narrativa del miedo: este es la época dorada para los programadores junior.

Su argumento es directo: la IA es un amplificador. Si aprendes rápido —y los juniors aprenden rápido— la IA multiplica esa capacidad. Si eres curioso y estás dispuesto a explorar, la IA te da superpoderes que antes tomaban años conseguir.

Usa una analogía que vale la pena repetir:

"Esto es como si fueras carpintero y acaban de inventar la sierra circular. No se acabó la carpintería. Ahora tienes herramientas más poderosas."

El riesgo no es que la IA te reemplace. El riesgo es que otro desarrollador —junior o senior— que sepa usarla bien te deje atrás. La diferencia entre los dos grupos va a ser enorme.

TDD en la era de los agentes: por qué los fundamentos importan más que nunca

Aquí hay algo que sorprendió incluso a Kent Beck: alguien le agradeció el impulso del Test-Driven Development (TDD) durante los últimos 20 años. No por razones de calidad de código en abstracto, sino porque resulta que las pruebas son críticas cuando trabajas con agentes de IA.

¿Por qué? Porque cuando tienes un "genio grande y poderoso" generando código, necesitas verificar que está haciendo lo correcto. Necesitas una red de seguridad. Necesitas pruebas.

Martin Fowler también menciona algo revelador: el código bien modularizado —otro fundamento clásico— facilita mucho el trabajo de los agentes. La buena arquitectura no es un lujo del pasado. Es lo que permite que la IA funcione bien.

Los fundamentos no murieron con la IA. Se volvieron más valiosos.

El escepticismo como habilidad: cómo navegar sin perderse

Fowler es brutalmente honesto sobre su propia experiencia inicial con la IA: no le impresionó. Probó Copilot, lo configuró en Emacs, y lo abandonó a los tres o cuatro días porque era inconsistente. Si esa hubiera sido su única experiencia, habría descartado toda la tecnología.

No lo hizo. ¿Por qué? Porque aprendió a no confiar demasiado en sus reacciones iniciales.

Su consejo: busca voces que ofrezcan equilibrio entre lo bueno y lo malo, y que además estén dispuestas a decir "no sé". Eso es una señal de que vale la pena escuchar. Las voces que solo venden o solo critican son ruido.

También advierte sobre el "complejo industrial ágil": igual que surgió una industria entera de charlatanería alrededor del movimiento ágil, lo mismo está pasando con la IA. Ya está pasando. Distinguir entre lo valioso y el ruido es una habilidad que debes desarrollar activamente.

Su regla: sé escéptico. Pero sé escéptico también de tu propio escepticismo.

El futuro de los equipos: ¿una pizza o dos?

Una de las conversaciones más interesantes fue sobre cómo va a cambiar la estructura de los equipos. La pregunta que plantearon: ¿los "equipos de dos pizzas" (el famoso tamaño de equipo de Amazon) se van a convertir en "equipos de una pizza" porque los agentes no comen?

Beck tiene su apuesta: equipos de dos pizzas, pero más efectivos.

No cree que la respuesta correcta sea un programador solo con diez agentes. Cree que la dinámica humana —dos personas con perspectivas diferentes, niveles de energía distintos, capaces de tener conversaciones reales sobre filosofía de diseño— sigue siendo irremplazable.

De hecho, señala algo inesperado: aprecia que los modelos de IA sean lentos. Cuando le das una instrucción a un agente y tarda tres minutos en responder, tienes tiempo para conversar con tu colega sobre convenciones de nombres, sobre la próxima decisión de diseño, sobre lo que deberían hacer después. Si el modelo responde en 15 segundos, esa conversación desaparece.

Lo que más debería preocuparte (y no es lo que crees)

Fowler habla de algo que lo inquieta: empresas —incluso grandes— que están considerando dar a los LLMs control total sobre sus correos electrónicos. Acceso de lectura y escritura. Respuesta automática.

Su reacción: "No. ¿Qué? No."

Hay una prisa ciega por aprovechar lo que parece funcionar, sin dimensionar los riesgos reales de seguridad. Y en sistemas grandes y complejos —con millones de líneas de código, donde un error puede dejar una aerolínea fuera de servicio dos días— el margen de error es cero.

La madurez técnica que le tomó a la industria décadas construir (modularización, pruebas, revisión de código, seguridad) no es opcional cuando introduces agentes. Se vuelve crítica.

Una idea que te cambia la perspectiva

Hubo un momento en la conversación que quedó grabado: alguien mencionó que el diagrama de Venn entre la experiencia del desarrollador y la experiencia del agente es un círculo.

Lo que es bueno para los agentes —código modular, funciones pequeñas, nombres claros, pruebas— también es bueno para los humanos. Y al revés.

Eso significa algo importante: si te enfocas en mejorar como desarrollador —en entender los fundamentos reales, en escribir código limpio, en pensar bien el diseño— estás al mismo tiempo mejorando en trabajar con IA. No son caminos separados.

Para cerrar: lo que estos 25 años enseñan sobre los próximos 25

Martin Fowler terminó diciendo algo que resume bien su postura: dejó de escribir libros para trabajar con personas que sí están en proyectos reales, escribiendo código de verdad, y ayudarlas a compartir lo que aprenden. Porque en este momento, eso es más valioso que cualquier respuesta de un libro.

La industria está en modo exploración. Nadie tiene el manual. Y eso —si lo ves bien— es una oportunidad enorme para los desarrolladores que estén dispuestos a explorar, a aprender en público y a construir criterio propio.

Fowler y Beck llevan 25 años haciéndolo. La diferencia es que ahora no están solos.

Sunday, April 19, 2026

Agentic AI engineer

Agentes para desarrollar software:

https://x.com/unclebobmartin/status/2045477573535142212

Links

Sunday, April 12, 2026

El futuro de la programación es no programar en absoluto

En 2017, el CEO de GitHub dijo que la programación iba a desaparecer. Tenía razón en algo. Se equivocó en lo que importa.

"El futuro de la programación es no programar en absoluto." — Chris Wanstrath, ex-CEO de GitHub, 2017

Business Insider lo publicó en portada. El CEO de GitHub diciendo que la automatización acabaría con la programación tradicional.

En 2017 no existía ChatGPT. No existía Copilot. No existía nada de lo que hoy usamos a diario.

Y aun así, ya lo estaba diciendo.

¿Tenía razón?

Sí y no.

En lo que tenía razón

La forma de programar cambió. Eso es un hecho.

Hoy cualquier persona puede abrir una interfaz, escribir un prompt, y obtener un componente funcional en segundos. Código que hace cinco años habría requerido horas de trabajo aparece en la pantalla antes de que termines el café.

Sobre esto no hay debate. La barrera para generar código se desplomó.

En lo que se equivocó

Programar nunca fue solo escribir código.

Programar es pensar en sistemas. Es decidir qué construir y cómo. Es diseñar soluciones que funcionen hoy y que se puedan modificar mañana sin que todo explote. Es entender por qué una arquitectura aguanta la carga y otra no. Es saber cuándo una abstracción ayuda y cuándo está creando un problema que alguien va a sufrir en seis meses.

Eso no lo hace un prompt.

Un modelo de lenguaje genera código. No razona sobre el sistema. No conoce las restricciones reales del negocio. No tiene que mantener lo que produce ni responder cuando algo falla en producción a las dos de la mañana.

El criterio de ingeniería no se automatiza. Se aplica sobre la automatización.

La ventaja que nadie está viendo del todo

El programador que sabe diseñar software y además sabe usar herramientas de IA como un profesional tiene una ventaja que hoy todavía no está completamente valorada. Pero lo va a estar.

Y acá importa ser preciso, porque hay mucha confusión sobre qué significa "usar IA como profesional".

No hablo de pedirle a ChatGPT que te escriba un componente. Eso ya lo hace cualquiera. Eso es el piso, no el techo.

Hablo de otra cosa. De montar agentes que siguen tus reglas de arquitectura. De encadenar subagentes que manejan partes específicas de un flujo. De definir skills reutilizables y conectar herramientas externas vía MCP. De hacer que la IA trabaje para vos de forma estructurada, con criterio, con guardarraíles de ingeniería reales.

La diferencia entre generar código con un prompt y montar un sistema de IA que hace ingeniería de software es la misma diferencia que hay entre ejecutar un script y diseñar una arquitectura.

Dos caminos

Podés seguir haciendo vibe coding. Generar código, pegarlo, rezar para que funcione, repetir. Muchos lo hacen. El resultado es velocidad aparente y deuda técnica real.

O podés aprender a montar sistemas de IA que apliquen ingeniería de software de verdad. Que sigan principios de diseño. Que generen tests. Que respeten las convenciones del proyecto. Que escalen.

Wanstrath tenía razón en que escribir código manualmente iba a dejar de ser el centro del trabajo. Se equivocó en pensar que eso hacía irrelevante al programador. Lo que hace irrelevante al programador es no entender que su rol cambió.

El rol ahora es dirigir sistemas que producen software. Y para dirigirlos bien, necesitás saber exactamente qué es buen software.

El que no sabe eso, con o sin IA, sigue construyendo lo mismo de siempre.

Solo más rápido.

Tu código limpio ya no te diferencia

Todo lo que aprendiste sigue valiendo. El problema es que ya no es suficiente.

Años aplicando SOLID. Code reviews serias. Tests, refactoring, arquitectura limpia. Has pagado el precio que hay que pagar para escribir software de verdad.

Y ahora hay alguien con menos experiencia que está entregando más rápido que tú.

Antes de que eso te moleste, lee: no es porque sea mejor programador. Probablemente ni sabe por qué funciona la mitad de lo que escribe. Pero aprendió algo que tú todavía no has incorporado.

Aprendió a dirigir agentes.

El código limpio sigue siendo necesario. Ya no es suficiente.

Esto no es un ataque a los fundamentos. El código sostenible, los principios de diseño, la capacidad de detectar un code smell antes de que se convierta en un desastre — todo eso sigue importando. Mucho.

Pero dejó de ser lo que te diferencia.

Antes, ser senior era saber escribir buen código. Conocer los patrones. Hacer buenas abstracciones. Eso era el nivel al que llegabas después de años de trabajo real.

Ahora eso es el piso. El punto de partida. Lo mínimo esperado.

Lo que está cambiando la ecuación no es el conocimiento. Es quién está aplicando ese conocimiento, y a qué velocidad.

Lo que está pasando en los equipos ahora mismo

Hay developers que llevan meses trabajando con agentes. No como juguete. Como parte real de su flujo de trabajo.

Le dan al agente sus reglas de arquitectura. Sus convenciones de naming. Sus criterios de testing. Las mismas reglas que tú aplicas en cada PR. Y el agente las ejecuta de forma consistente, en cada archivo, sin que nadie tenga que repetirlas.

El resultado: resuelven los mismos problemas que tú. En menos tiempo.

No porque tengan mejor criterio. Porque aprendieron a convertir su criterio en instrucciones que escalan.

No va a ser la IA la que te desplace. Va a ser un developer que sabe lo mismo que tú pero que lleva meses haciendo ingeniería con agentes mientras tú segues trabajando igual que hace un año.

Y la distancia se alarga cada semana.

Por qué los seniors tienen la mejor posición para esto

Acá está la parte que la mayoría no está viendo.

Los agentes sin criterio son peligrosos. Un developer que no distingue buen diseño de malo, que no entiende por qué una abstracción existe, que no sabe cuándo un test agrega valor y cuándo solo agrega ruido — ese developer con agentes genera deuda técnica a velocidad industrial.

El criterio que tardaste años en construir es exactamente lo que convierte un agente en una herramienta de ingeniería seria. Sin ese criterio, el agente es solo ruido rápido.

Las convenciones que aplicas en cada code review. Los límites de responsabilidad que defiendes en cada diseño. Los patrones que exiges antes de aprobar un PR. Todo eso, que hoy vive en tu cabeza, puede convertirse en reglas que un agente sigue de forma consistente.

Solo tienes que dar ese paso.

La pregunta que vale la pena hacerse

¿Cuánto de lo que sabes está documentado de una forma que un agente pueda seguir? ¿Cuánto sigue atrapado en tu cabeza, disponible solo cuando tú estás en la conversación?

Eso es lo que hay que cambiar. No el conocimiento. La forma en que ese conocimiento se aplica.

El developer que va a seguir siendo relevante en los próximos años no es el que abandona lo que sabe. Es el que aprende a multiplicarlo.

El que no lo haga se va a quedar atrás. No por falta de talento. Por falta de movimiento.

Y eso sí es una decisión.

Refactorizar sin tests es apostar a ciegas

El código limpio que nadie puede verificar es solo código que todavía no ha roto nada.

El buen código no es opcional. Eso ya lo sabes. Pero hay algo que mucha gente se deja en el camino.

¿Cómo sabes que tu código "limpio" sigue funcionando después de refactorizarlo?

Imagina esto: es un viernes por la tarde. Te sientas a refactorizar un servicio que lleva meses pidiendo a gritos una limpieza. Renombras métodos, los extraes a un nuevo módulo, introduces abstracciones que antes no existían. Cuando terminas, el código brilla. Es una obra de arte.

Y entonces viene la pregunta incómoda.

¿Cómo sabes que no has roto nada? ¿Que el flujo de pedidos sigue funcionando de extremo a extremo? ¿Que la integración de pagos no se ha roto silenciosamente? ¿Que un cliente todavía puede completar una compra?

No lo sabes. No puedes saberlo, a menos que tengas tests que verifiquen el comportamiento del sistema, no la implementación.

El código sostenible necesita una red de seguridad

Los tests unitarios son rápidos. Te dan feedback inmediato y hacen que refactorizar se sienta seguro. Son el pan de cada día de cualquier desarrollador disciplinado.

Pero incluso los mejores tests unitarios tienen un punto ciego enorme.

Verifican piezas en aislamiento. Mockean la base de datos. Stubean la API externa. Se saltan la serialización. Cuando todos los tests pasan, sabes que la lógica de tu unidad funciona correctamente. Pero no sabes si la lógica del sistema funciona.

Los problemas aparecen en los límites. La consulta que devuelve datos con una forma diferente a la que asumías. La capa HTTP que silenciosamente se come un campo. La integración que funcionaba aislada pero se rompe cuando se encuentra con la realidad.

Los tests unitarios no pueden detectar estos problemas, no porque estén mal escritos, sino porque no están diseñados para eso. Nadie les pidió que lo hicieran.

Los tests de aceptación llenan ese hueco

Los tests de aceptación ejercitan el sistema de extremo a extremo, a través de los mismos límites que tocan tus usuarios reales.

La diferencia con los unitarios no es solo técnica, es conceptual:

Un test unitario dice: "Esta función calcula el descuento correctamente."
Un test de aceptación dice: "Cuando un cliente aplica un cupón en el checkout, el precio total se reduce y el pedido se completa."

Uno verifica una pieza. El otro verifica una historia. Uno te dice que la función hace lo que se supone. El otro te dice que el usuario puede hacer lo que necesita.

Ambos son necesarios. Son complementarios, no competidores. Pero el segundo es el que te deja dormir tranquilo después de un viernes de refactoring.

¿Y si tienes un proyecto legacy sin un solo test?

Esta es la pregunta real. La que tienen la mayoría de desarrolladores .NET que trabajan en proyectos con años de historia encima.

Aquí está la trampa en la que caen muchos: intentan escribir tests unitarios primero en código legacy. Es una batalla perdida. El código legacy no fue diseñado para ser testeado en aislamiento. Tiene dependencias estáticas, clases enormes, métodos que hacen diez cosas a la vez.

La estrategia más efectiva es la contraria: empieza por los tests de aceptación.

1. Escribe un test de aceptación que describa un flujo crítico.
2. Hazlo pasar tal cual está el código (sin tocar nada).
3. Ahora tienes una red de seguridad.
4. Refactoriza con confianza.
5. Añade tests unitarios a medida que extraes lógica.

Los tests de aceptación sobre código legacy son feos, lentos, a veces frágiles. No importa. Su trabajo no es ser elegantes. Su trabajo es atrapar regresiones mientras tú limpias el desastre heredado.

Primero pon la red. Luego haz el salto.

La conclusión que no te puedes saltar

Refactorizar código sin cobertura de tests de comportamiento no es "limpiar". Es reorganizar la deuda técnica sin garantías. Puede quedar bonito en el repositorio y estar completamente roto en producción.

El código limpio sin tests es código que todavía no ha fallado en el peor momento. El código con una buena cobertura de aceptación es código que puedes cambiar sin miedo.

Y en este trabajo, cambiar código sin miedo no es un lujo. Es la habilidad que te hace relevante.

Pages