El Framework de los Tres Ejes
Un framework para que la IA no te coma el cerebro mientras shipeás código.
Esta es la versión traducida al español del mismo articulo publicado acá.
El Momento
Me quedé mirando una función que supuestamente había escrito veinte minutos antes.
Compilaba. Los tests pasaban. La lógica era correcta. Y no podía, por más que quisiera, explicar por qué estaba estructurada así.
Soy desarrollador backend con más de seis años de experiencia profesional. Me dedico a construir sistemas. Creo que sé cómo se ve una buena arquitectura y cómo huele una mala.
Y sin embargo ahí estaba, leyendo mi propio código como si fuera la letra de un desconocido.
El código estaba bien. El problema era yo.
El Efecto Lento
Si usaste herramientas de codeo con IA agéntica con cierta regularidad, probablemente esto ya lo sentiste también.
No de golpe. Se filtra. Shipeás un feature más rápido que nunca. Te subís a la ola con un segundo feature, un tercero. La velocidad es embriagante. Tu gráfico de commits parece un electrocardiograma de un tipo re limado con sobredosis de cafeína.
Y un día algo se rompe. Abrís el archivo. El código se ve ajeno. Reconocés los patrones — VOS aprobaste cada uno de ellos — pero la comprensión que debería venir con la autoría no está. Podés ver qué hace el código. No podés sentir por qué.
La intuición está hueca.
No tenía una palabra para esto hasta que leí dos piezas que me pegaron como un tren Sarmiento en plena hora pico.
Anthropic hizo un estudio. Ensayo controlado aleatorizado, 52 ingenieros de software, mitad con IA, mitad sin. El grupo asistido por IA sacó 17% menos en evaluaciones de comprensión — casi dos notas enteras. ¿La brecha más grande? Debugging. Sí, la habilidad que más necesitás cuando todo se va al carajo a las 3 de la mañana y la IA no está en la habitación.
Después Addy Osmani le puso nombre a la cosa: deuda de comprensión. La brecha creciente entre cuánto código existe en tu sistema y cuánto de ese código entiende genuinamente algún ser humano. A diferencia de la deuda técnica, que se anuncia sola haciendo todo más lento, la deuda de comprensión es invisible. El codebase se ve limpio. Los tests están en verde. La velocidad subió. Y nadie puede explicar por qué funciona nada.
¿Te suena?
Pero acá viene la parte que salva a esto de ser otro post de "IA es mala": el estudio de Anthropic también encontró que los desarrolladores que se involucraron cognitivamente — hicieron preguntas de seguimiento, pidieron explicaciones, plantearon dudas conceptuales mientras codeaban por su cuenta — retuvieron conocimiento casi al mismo nivel que los que escribieron todo a mano.
La herramienta no destruye la comprensión. La delegación pasiva sí.
Esa distinción me cambió todo.
La Trampa Binaria
El discurso alrededor de la IA y programación tiene exactamente dos bandos.
Bando uno: la IA es un superpoder, abrazala, dejá que haga el laburo pesado, la resistencia es fútil.
Bando dos: la IA es una muleta, los verdaderos programadores escriben su propio código, andá a cagar.
Los dos se equivocan, y se equivocan de la misma manera. Tratan a la asistencia de IA como un interruptor on/off. Usala o no. Confiá o no. Delegá o no.
Pero así no funciona el laburo, dentro del laburo.
Escribir un script de procesamiento batch en un lenguaje que usás hace seis años no es lo mismo que implementar una máquina de estados en un lenguaje que empezaste a aprender el mes pasado. Shipear un servicio de pagos que maneja guita real no es lo mismo que buildear un juego personal que se te crashea al escritorio. Meter cabeza contra un deadline no es lo mismo que una sesión de fin de semana donde el punto entero del asunto es la lucha, el dársela contra la pared.
No necesitás un interruptor. Necesitás un dial.
En realidad, necesitás tres.
Tres Ejes
Cada tarea que toco con IA se ubica en algún punto de tres ejes independientes. Las reglas que sigo no cambian — pero su intensidad se mueve dependiendo de dónde cae cada tarea.
Dominio — ¿qué tan bien conozco esto?
Cuando el dominio es alto, la IA acelera lo que ya puedo razonar. Puedo revisar código generado críticamente porque tengo los modelos mentales para detectar cuando algo está mal. Cuando el dominio es bajo, la misma aceleración me saltea silenciosamente el aprendizaje que necesito hacer.
El dolor de quedarte trabado — persiguiendo un bug por territorio desconocido, leyendo documentación que no termina de cerrar, mirando un error de tipos que no tiene sentido — ese dolor es la matrícula. Saltealo, salteás la educación.
Este es el eje que el estudio de Anthropic iluminó más claramente. Los ingenieros que delegaron todo no aprendieron nada. Los que lucharon, fallaron, preguntaron, y después usaron la IA para verificar su comprensión? Aprendieron casi tanto como los que no tenían IA.
La lucha no es el obstáculo. La lucha es el plan de estudios.
Consecuencia — ¿qué se rompe si me equivoco?
Un servicio de pagos en producción que calcula mal silenciosamente no es lo mismo que un juego personal que se crashea al escritorio. La consecuencia determina cuánta comprensión tenés que tener antes de shipear — no como un "estaría bueno", sino como una barrera.
Acá es donde el argumento de Osmani pega más fuerte. Cuando código generado por IA corre en producción, "lo escribió la IA y no lo revisamos del todo" no se sostiene en un post-mortem. Cuanto más altas las apuestas, menos te podés dar el lujo de no entender lo que estás shipeando.
Intención — ¿estoy shipeando o aprendiendo?
No siempre se oponen, pero cuando el tiempo aprieta, uno gana. Un feature contra reloj en el laburo demanda output. Una sesión de C++ el fin de semana demanda crecimiento. El peligro es dejar que el modo output se convierta en el default, porque el modo output se siente productivo incluso cuando está erosionando silenciosamente las habilidades que hacen posible el output futuro.
Este es el eje en el que la mayoría nunca piensa explícitamente. Defaulteamos a output. El deadline es real, la tarea está enfrente, la IA está ahí ofreciendo hacerlo rápido.
El modo crecimiento requiere una decisión consciente de frenar. Y frenar, en una cultura que venera la velocidad, se siente como fracaso.
No lo es.
Seis Reglas, Siempre Prendidas
Estos principios gobiernan cada interacción asistida por IA en todos mis proyectos. Ninguno se apaga nunca. Lo que cambia es la intensidad — y los tres ejes me dicen dónde poner cada dial.
1. Yo soy dueño del SDLC. La IA se encarga de la implementación, pero cada decisión arquitectónica pasa por mí. Nada se construye sin que yo entienda qué hace y por qué. Cuando estoy aprendiendo, esto está al máximo. Cuando soy experto pero responsable por producción, sigue al máximo — distinta razón. Cuando estoy scripteando un batch job descartable, el dial se relaja. Pero la conciencia de que lo estoy relajando es el punto.
2. Explicar antes de construir. Para cualquier cambio no trivial, primero el plan. Qué vamos a hacer, por qué, qué alternativas se consideraron. Este es el patrón de interacción exacto que el estudio de Anthropic encontró más protector contra la pérdida de comprensión — preguntar "¿por qué este approach?" fuerza el involucramiento cognitivo que la delegación pasiva saltea.
3. Nada de cajas negras. Si no puedo explicar por qué algo está estructurado de cierta manera, la deuda de comprensión se está acumulando. Este es el canario. El momento en que me encuentro sin poder explicar código que se acaba de escribir "conmigo", esa es la señal de frenar y volver atrás.
4. Cada fase shipea software funcional. Cada incremento termina con algo que compila, corre y funciona. Nada de estados parciales. Esta casi no se mueve. Los estados intermedios rotos crean confusión sin importar el contexto.
5. Dejame espacio para codear. Si una tarea es lo suficientemente educativa como para que yo quiera meterle mano, la IA se corre. Revisa, debuggea, responde preguntas — pero no agarra el teclado. Acá está la pista: cuando siento la urgencia de saltearme esta regla, esa urgencia misma es la señal de respetarla. Si estoy evitando codear algo porque se siente tedioso o difícil, eso es muchas veces exactamente lo que necesito hacer yo mismo.
6. Preferir legible sobre ingenioso. Lo idiomático está bien. Lo oscuro no. Cada línea ingeniosa es un impuesto futuro de comprensión que paga la próxima persona que la lea, y esa persona casi siempre soy el yo del futuro.
Instalando Esto en Tu Cabeza (y en Tus Herramientas)
Esto no es teórico. Lo meto en cada proyecto a través de un documento que cualquier asistente de IA lee antes de escribir una sola línea de código. Incluye los tres ejes, las seis reglas, y señales explícitas de cambio de modo:
"Dejame intentar" → La IA se corre, modo mentor. "Hacelo" → Modo output, sé eficiente. "Explicame esto" → Modo crecimiento, enseñá a fondo. "¿Cuáles son los tradeoffs?" → Presentá alternativas honestamente.
Lo publiqué como un skill instalable — un documento autocontenido que podés meter en Claude Projects, archivos CLAUDE.md, Cursor rules, custom instructions, lo que sea que uses. No es específico de ninguna herramienta ni lenguaje. Simplemente funciona.
Para Claude Code en particular, lo publiqué como un plugin que podés agarrar acá.
Para otras herramientas, sentite libre de adaptar el skill desde el repo del plugin, acá.
La Parte Incómoda
Uso herramientas de coding con IA todos los días. Claude Code, Copilot, todo el stack. Creo que son el multiplicador de fuerza más poderoso que la mayoría de los desarrolladores van a encontrar en su vida.
También creo que te pueden vaciar por dentro si los dejás.
No por maldad. Por comodidad. El camino de menor resistencia es delegar, y delegar sin comprender es simplemente pedirle prestada comprensión a tu yo del futuro a una tasa que no podés ver. Un día la cuenta llega y estás mirando tu propio código como si fuera la letra de un desconocido.
Tres preguntas antes de cada tarea. Dominio, consecuencia, intención. No es un checklist — es un reflejo. Una forma de mantener a la herramienta a tu servicio en vez de al revés.
Creo que voy a seguir preguntando "¿por qué es así?" antes de preguntar "¿me lo podés construir?"
Mi yo del futuro me lo va a agradecer. Probablemente.