Programar con AI no te vuelve automáticamente más rápido; te vuelve más expuesto a tus malos hábitos. Si tu forma de trabajar es confusa, la AI amplifica esa confusión con una velocidad impresionante. Y si tenés criterio, contexto y una buena disciplina de revisión, se convierte en una ventaja difícil de igualar.
Llevo tiempo usando AI como parte central del desarrollo en los proyectos que construyo bajo solu30. Lo que describí acá son las cosas que no encontré escritas juntas en ningún lado.
El 73 por ciento de los equipos de ingeniería usa herramientas de IA a diario en 2026. Claude Code escribe el 4 por ciento de todos los commits públicos en GitHub. En mis proyectos personales, el uso de AI redujo el tiempo de tareas bien delimitadas en 3 veces — pero aumentó el tiempo de debugging cuando el código generado tenía suposiciones incorrectas sobre el contexto.
Programar con AI cambia el rol del desarrollador
Tres cambios reales que noté después de 12 meses programando con AI todos los días:
- El tiempo por tarea bajó 3 veces en tareas bien delimitadas — scaffolding, boilerplate, implementaciones repetitivas.
- El tiempo en debugging subió cuando el código generado tenía suposiciones incorrectas sobre el contexto del sistema.
- La calidad del brief se volvió la skill más importante — más que la velocidad de escritura o el conocimiento del framework.
La primera trampa es pensar que la AI viene a escribir código por vos. En la práctica, lo más valioso no es que genere líneas, sino que te obliga a explicar mejor lo que querés construir. Cuando el prompt es flojo, el resultado suele ser un espejo bastante cruel del pensamiento incompleto.
Programar con AI todos los días te mueve de "tipear implementación" a "dirigir decisiones técnicas". Tenés que partir problemas, marcar límites, detectar suposiciones falsas y revisar el impacto de cada cambio. Eso se parece más a liderar a un dev junior muy rápido que a usar un autocompletado elegante.
El cambio real aparece cuando dejás de pedirle "haceme esto" y empezás a trabajar con contexto: archivos relevantes, criterios de aceptación, restricciones del sistema y ejemplos de comportamiento esperado. Ahí la AI deja de improvisar y empieza a operar dentro de un marco.
La productividad sube, pero la deuda también
| Tipo de tarea | Impacto de la AI | Cuándo ayuda más |
|---|---|---|
| Scaffolding y boilerplate | 3-5 veces más rápido | Siempre |
| Implementaciones repetitivas | 2-3 veces más rápido | Con contexto claro |
| Debugging de lógica compleja | Neutral a negativo | Solo si el contexto está bien documentado |
| Decisiones de arquitectura | Útil como segundo opinión | Como exploración, no como oráculo |
| Code review | Bueno para patrones conocidos | Menos útil para decisiones de producto |
La AI baja muchísimo el costo de producir código. Eso suena perfecto hasta que recordás que el costo de mantenerlo no baja en la misma proporción. Si aceptás cambios sin revisar arquitectura, naming, tests o efectos colaterales, podés generar una deuda técnica enorme en una tarde.
El síntoma más común es sentir que avanzaste mucho porque el diff es grande. Pero un diff grande no es progreso; progreso es comportamiento correcto, simple de entender y fácil de cambiar después.
Un ejemplo típico: pedís una integración, la AI resuelve el caso feliz, agrega helpers nuevos, duplica una lógica que ya existía y deja errores silenciosos en los bordes. La demo funciona, pero el sistema quedó más frágil. Por eso necesitás tratar cada salida como una propuesta, no como una verdad.
El hábito más importante es revisar intención, no sintaxis
Revisar sintaxis alcanza para detectar errores obvios. Revisar intención significa preguntarte si el flujo respeta el modelo de datos, si el usuario correcto puede ejecutar la acción, si el estado queda consistente y si el comportamiento encaja con el resto del sistema.
Una práctica concreta: después de cada cambio generado con AI, describí en una frase qué comportamiento nuevo debería existir. Si no podés decirlo simple, todavía no entendiste el cambio. Y si no entendiste el cambio, no deberías mergearlo.
Los anti-patrones de agentes IA en producción son la consecuencia directa de no tener esa disciplina: código que parece funcionar pero que opera sobre suposiciones que nadie validó.
La AI premia a quienes conocen su sistema
Cuanto más conocés tu sistema, mejores instrucciones das. Sabés qué archivos importan, qué patrones respetar, qué abstracciones no tocar y qué pruebas correr. La AI puede acelerar mucho, pero necesita un mapa; si no se lo das, inventa caminos.
Esto es especialmente importante para founders técnicos. La ventaja no está en reemplazar criterio, sino en multiplicarlo.
También hay una ventaja emocional que se menciona poco. Programar con AI reduce la fricción inicial de tareas molestas: migraciones, tests repetitivos, adaptación de componentes, documentación interna. Eso libera energía para decisiones más difíciles, siempre que no uses esa comodidad para evitar pensar.
Cómo usar AI sin perder control
Mi regla práctica es simple: darle a la AI tareas con bordes claros. Cuanto más ambigua la tarea, más chico debería ser el paso. "Refactorizá el módulo de billing" es una invitación al caos; "extraé la validación de impuestos a una función pura y agregá tests para estos tres casos" es trabajo manejable.
También conviene separar generación de verificación. Podés pedir una implementación, pero después pedí una revisión crítica del mismo cambio con foco en riesgos, casos borde y compatibilidad.
Para la parte de revisión sistemática, el artículo sobre IA como compañero de arquitectura cubre el enfoque correcto para usar IA sin entregarle el criterio.
El contexto es el insumo más escaso
Una cosa que aprendí tarde: el costo de programar con AI no está en el tiempo que tarda en generar código. Está en el tiempo que tardás en darle suficiente contexto para que genere el código correcto.
Sin contexto, la AI produce código que compila pero que no respeta los patrones del sistema, duplica abstracciones que ya existen, o resuelve el problema superficial sin entender la restricción real. Con contexto, el resultado suele ser usable con revisión mínima.
El contexto útil no es un párrafo largo explicando el proyecto. Es específico: el archivo que hay que modificar, los tipos involucrados, la restricción que no debe romperse, el ejemplo de comportamiento esperado. Cuanto más concreto, mejor el resultado.
Esto se vuelve especialmente importante cuando trabajás con sistemas con múltiples módulos interrelacionados. Si el cambio que pedís toca tres módulos, hay que decirle cuáles son los tres módulos, qué hace cada uno y cuál es la frontera que no debe cruzarse. Sin eso, la AI va a inventar esa frontera, y casi siempre la va a inventar mal.
Cuándo no usar AI para escribir código
Hay situaciones donde delegar la escritura de código a la AI genera más costo que valor. Las más comunes:
Código de seguridad o autenticación. No porque la AI no sepa hacerlo, sino porque estos módulos requieren revisión exhaustiva que después igual hay que hacer. Si vas a revisar línea por línea de todas formas, conviene entender bien el problema antes de generar.
Cambios estructurales grandes. Pedirle a la AI que "refactorice la arquitectura" produce cambios grandes que son difíciles de revisar. Para cambios estructurales, conviene dividir el trabajo en pasos verificables y usar la AI para cada paso por separado.
Contexto que la AI no puede tener. Si una decisión depende de conocimiento que no está en código —una restricción de negocio, un acuerdo con un cliente, una limitación operativa— la AI no puede saberlo a menos que se lo expliques. Ese tipo de decisiones sigue siendo tuyo.
Programar con AI es una ventaja enorme si seguís siendo responsable del diseño, la revisión y el resultado. No te reemplaza el criterio; te cobra más caro no tenerlo.
Preguntas frecuentes
¿Programar con AI sirve para proyectos grandes? Sí, pero solo si trabajás con contexto y cambios chicos. En proyectos grandes, el valor está en acelerar tareas acotadas sin romper patrones existentes.
¿La AI puede reemplazar tests? No. Puede ayudarte a escribirlos y detectar casos borde, pero los tests siguen siendo tu red objetiva contra regresiones.
¿Qué tipo de tareas conviene delegar primero? Refactors pequeños, generación de tests, adaptaciones repetitivas, documentación técnica y exploración de alternativas.
¿Cómo sé si estoy abusando de la AI? Si aprobás código que no podés explicar, estás abusando. La velocidad no compensa perder entendimiento del sistema.
¿Vale la pena para founders no técnicos? Puede servir para prototipos y validación, pero para producto en producción necesitás revisión técnica seria. La AI ayuda, no elimina la responsabilidad.