La herramienta cambia. La ingeniería que la rodea, no. Construye las seis disciplinas que hacen fiable el desarrollo de software con IA.
Seis disciplinas. Un entorno de trabajo.
Podés usar Cursor, Claude Code, Codex o lo que salga el mes que viene. La herramienta cambia; el trabajo de ingeniería que hay alrededor, no. Estas seis disciplinas cubren las carencias que hacen que trabajar con IA resulte caro, inconsistente y poco fiable.
Cada una de esas seis carencias es una disciplina de ingeniería. No se resuelven con un prompt mejor. Se resuelven armando el entorno.
Marcá las que ya cubrís hoy. Sin trampa: contar “le pego el contexto en el chat” no vale, eso lo hacés vos a mano cada vez.
Tocá cada una para marcarla.
Todavía no marcaste ninguna. Si arrancás de cero, esto es exactamente lo que sentís como “la IA a veces la pega y a veces no”.
Ordenadas por cuánto te cambia el día cubrirlas. Si solo vas a cubrir una, cubrí la primera.
¿Qué sobrevive cuando cerrás la terminal?
Guardar las decisiones que vas tomando —y el porqué de cada una— en algún lugar que siga existiendo mañana, y que cualquier herramienta de IA pueda leer.
Volvés a explicar lo mismo cada mañana, y cada tanto el agente te propone con entusiasmo la alternativa que ya descartaron hace un mes. Nadie se acuerda de por qué la descartaron.
¿Qué sabe de tu mundo, ahora mismo?
Hacer que el agente tenga a mano lo que realmente existe: tu código, quién llama a qué, y la documentación de la versión de la librería que usás vos.
Inventa funciones que suenan perfectamente razonables y no existen. Reescribe cosas que ya estaban hechas. Usa la API de una librería como era hace dos años.
¿Qué significa “bien hecho” en este proyecto?
Escribir una sola vez las reglas, convenciones y procedimientos del proyecto, en un lugar que el agente lee solo, sin que se lo recuerdes.
Cada sesión produce código con un estilo distinto. Repetís “usá pnpm”, “los tests van acá”, “no toques esa carpeta” hasta el cansancio. Y el día que entra alguien nuevo, ese conocimiento no está escrito en ningún lado.
¿Qué puede tocar, y qué no debería poder tocar?
Darle acceso real a lo que necesita —archivos, comandos, servicios externos— y ponerle límites explícitos a lo que no.
Sin acceso, te describe la solución en vez de hacerla, y a veces simula que la hizo. Con acceso ilimitado, un día corre algo destructivo y nadie le dijo que no podía.
¿En qué orden se hace el trabajo, y quién hace cada parte?
Partir el trabajo en fases con entregables entre una y otra, en vez de pedir una tarea grande de una sola vez y esperar a ver qué sale.
Las tareas largas arrancan bien y a la hora empiezan a derrapar. El costo se dispara sin que el resultado mejore. Y cuando algo sale mal, no sabés en qué momento se torció.
¿Cómo sabés que lo que hizo funciona?
Tener algo que asuma que el agente se equivocó y lo compruebe: tests que fallan primero, revisión que no la haga quien escribió, y controles que no se pueden saltear.
Mergeás código que pasa todos los tests y no funciona. Le pedís al agente que revise su propio trabajo y te dice que está muy bien, porque un revisor que trae el mismo razonamiento del autor no está en posición de encontrar lo que ese razonamiento se perdió.
No hace falta cubrir las seis mañana. Estas tres etapas van sumando disciplinas en el orden que da más retorno por hora invertida, que no es el orden de la lista de arriba: el orden de impacto no es el orden de adopción. Esa lista ordena por cuánto te cambia el día cada una; estas etapas arrancan por donde arrancar sale más barato.
Nunca configuraste nada más allá de abrir la herramienta
Escribir las reglas del proyecto y declarar qué se puede tocar. Es la relación esfuerzo/resultado más alta de todo el mapa, y no depende de ninguna herramienta en particular.
Cubre
Esfuerzo
Una tarde, sin instalar nada
Ya tenés reglas escritas y el repositorio te quedó grande
Sumás las dos formas de saber: qué existe ahora mismo en el código y qué decidimos antes. Es la etapa que ataca las alucinaciones en la raíz, y la primera en la que el contexto y la memoria son portables: quedan fuera de la herramienta, y los puede leer la que uses después.
Cubre
Esfuerzo
Un fin de semana, con dos servicios conectados
Un equipo que necesita el mismo resultado en todas las máquinas
Agregás método y control: fases con entregables, revisión que no la hace el autor y con presupuesto, y una configuración que se instala igual en cualquier máquina. Más ceremonia; el retorno aparece cuando hay más de una persona.
Cubre
Esfuerzo
Continuo, con proceso acordado