Picón: la IA escribe 30% más código, no más software

La IA escribe más código, pero el sistema sigue siendo tu responsabilidad

Los agentes de IA que escriben código elevan las líneas producidas un 30%, los commits un 20% y los pull requests un 23% en las empresas que los adoptan. Lo midió un estudio de los investigadores de Harvard Fiona Chen y James Stratton sobre 300 millones de eventos de trabajo en más de 700 compañías, y lo reportó Ars Technica: la tasa de resolución de issues y epics no cambió de forma estadísticamente significativa. Más código, no necesariamente más software.

Esa brecha es el punto de partida del ensayo que Armando Picón publicó en su sitio. Su tesis incomoda a las dos tribunas del debate: los agentes pueden asumir más trabajo de implementación y asistir en análisis, diseño y pruebas, pero el ingeniero sigue siendo responsable de decidir qué construir y qué evidencia basta para aceptarlo. "Eso cambia el trabajo. No hace desaparecer las responsabilidades", escribe.

¿Qué parte del desarrollo de software automatiza realmente un agente?

Picón desarma la pregunta mal planteada. Producir una implementación, explorar un diseño y decidir si un sistema resuelve el problema correcto son actividades conectadas, pero automatizar una no resuelve las otras. Y advierte contra la versión fácil del relato: describir el cambio como reemplazar al que teclea código reduce al desarrollador a mecanografía, subestima lo que el agente puede asistir y convierte una automatización de tareas en una afirmación sobre empleos. Las afirmaciones sobre reemplazo de fuerza laboral, dice, requieren evidencia más allá de una demostración impresionante.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

La pregunta que le interesa es operativa: cómo usar estas herramientas manteniendo las decisiones visibles y el feedback útil.

El cuello de botella se movió a la revisión

Los datos del estudio de Harvard apuntan al mismo lugar. La eficiencia ganada en la fase de codificación se absorbe en restricciones posteriores del proceso: la revisión de código se alarga, los pull requests requieren más revisiones y los revisores dejan más comentarios. El ahorro en generación se paga en revisión.

Una encuesta informal de SD Times a 103 desarrolladores dibuja el mismo desajuste desde el lado humano: el 87% ya usa herramientas de IA o planea adoptarlas, pero solo el 31% confía en la exactitud de lo que producen y apenas el 4% declara confianza alta. El 56% dice que la IA mejoró su productividad individual; solo el 13% cree que los agentes mejoraron la colaboración del equipo. Y la opinión favorable bajó al 58%, desde el 70% y pico de años anteriores.

Traducción para un founder: la adopción ya no es la pregunta. La pregunta es qué haces con la revisión.

Decisiones que sobreviven a la conversación

Una conversación es cómoda para explorar opciones y frágil para guardar la única copia de una decisión de arquitectura. El contexto del modelo es acotado: una sesión larga puede resumirse o compactarse, y el resumen puede conservar la conclusión y perder la condición que la hacía razonable. "Usar caché local" no es lo mismo que "usar caché local porque esta pantalla debe seguir siendo usable sin conectividad".

Picón cita el reporte de ingeniería de Anthropic sobre agentes de larga duración, que describe problemas de continuidad entre ventanas de contexto y una aproximación basada en trabajo incremental y artefactos de progreso persistentes, además de señalar que la compactación puede dejar instrucciones poco claras. Él mismo aclara que se trata de un reporte de proveedor sobre una configuración particular, no de una comparación universal.

Su propuesta es modesta y concreta: darle a las decisiones durables un hogar chico y revisable. Un archivo PROJECT_GUIDE.md con el propósito y el alcance actual del producto —incluyendo exclusiones explícitas—, los límites importantes del sistema y las razones detrás de las decisiones de arquitectura, las expectativas de calidad con los comandos para verificarlas, y enlaces a decisiones más profundas. El nombre del archivo no tiene poder mágico: hay que conectarlo a las instrucciones de proyecto que soporte la herramienta o incluirlo explícitamente en la tarea, y después revisar cómo lo interpretó el agente.

El marco viene de la discusión de Simon Willison sobre context engineering de junio de 2025. La recomendación de Picón es más acotada: que la selección de información sea deliberada y que inspecciones sus consecuencias. Markdown no garantiza ni recuperación ni obediencia, y mandar todos los documentos en cada tarea sube el contexto y el costo.

Criterios de aceptación: define el comportamiento antes de generar

Picón usa un ejemplo hipotético —una pantalla de búsqueda en una app móvil— para mostrar el método. Antes de implementar, los casos de aceptación quedan explícitos: una consulta con coincidencias muestra los ítems esperados; una sin coincidencias muestra un estado vacío; limpiar la consulta restaura la colección completa; y si el filtrado es asíncrono, un resultado viejo no puede sobrescribir el de una consulta más nueva.

Ese último caso abre una pregunta técnica real: ¿hace falta trabajo asíncrono? La respuesta se resuelve contra el tamaño de datos esperado y los requisitos de respuesta, no porque una plantilla lo espere.

Verificación: por qué un test en verde no prueba nada

La salida de un agente es probabilística, así que la aceptación tiene que depender de evidencia inspeccionable y, cuando sea posible, reproducible. Un comando local puede correr formato, análisis estático, compilación y tests focalizados, pero cada chequeo responde una pregunta distinta: el formateador revisa convenciones, el compilador revisa reglas de lenguaje y tipos, los tests evalúan comportamiento seleccionado bajo condiciones seleccionadas. Ninguno establece que elegiste el comportamiento de producto correcto.

Peor: un test generado puede codificar fielmente el mismo malentendido que la implementación generada. Un test de búsqueda puede afirmar que aparece algún resultado sin verificar cuál. Por eso hay que revisar la aserción contra el caso de aceptación y usar ejemplos elegidos a mano, incluido un caso de fallo. Y si el rendimiento importa, define la medición antes de declarar éxito: dispositivo, dataset, escenario y umbral.

Los hooks locales ayudan a atrapar errores antes, pero su cobertura depende de qué los dispara y de si se pueden saltar. Donde el equipo necesita cumplimiento obligatorio, hacen falta chequeos del lado del servidor y protecciones del repositorio.

¿Cuánta documentación se justifica?

Picón desconfía de la cadena larga de documentos generados antes de ver comportamiento funcionando: producir texto es barato, entenderlo no. Cita la distinción de Birgitta Böckeler —reseñada por InfoWorld— entre tres niveles: spec-first, donde la especificación se escribe primero y se usa en la tarea; spec-anchored, donde se conserva después para evolución y mantenimiento; y spec-as-source, donde solo se edita la especificación y el humano nunca toca el código. Los tres tienen costos y niveles de control distintos.

Su test para un documento es práctico: qué decisión, implementación o verificación sostiene, y quién lo va a mantener. Mantendría la explicación de una restricción de compatibilidad aunque ocupe varias páginas, y borraría la prosa repetida que no cambia ninguna decisión.

Qué significa esto para tu startup

El valor del enfoque no está en la herramienta, está en el bucle: definir el siguiente comportamiento, darle el contexto que necesita, revisar la interpretación, inspeccionar el cambio, juntar evidencia y decidir si se acepta. Acciones concretas:

Escribe un PROJECT_GUIDE.md de una página con propósito, alcance, exclusiones explícitas, límites del sistema, expectativas de calidad y los comandos que las verifican. Conéctalo a las instrucciones de proyecto del agente y comprueba que lo interpretó como esperabas.
Pide un resumen antes del código. Para cada incremento, entrega los archivos relevantes y pide un relato breve del cambio previsto, las restricciones y los casos de aceptación. Es la oportunidad más barata de detectar un malentendido.
Mide el ciclo completo, no la generación. El estudio de Harvard muestra que el ahorro al escribir código se puede absorber en revisión. Si vas a justificar la inversión, cuenta revisión, retrabajo, defectos y mantenimiento.
Si la revisión se vuelve inmanejable, reduce el incremento antes de pedirle más código al agente.

Conclusión

Picón es explícito sobre los límites de su propio texto: presenta una posición de trabajo, no un estudio controlado ni una ganancia de productividad demostrada. Establecer esa ganancia requeriría tareas comparables y contabilizar revisión, retrabajo, defectos y mantenimiento, no solo el tiempo de generación.

Aun así, la posición es sólida y barata de adoptar. La pregunta con la que cierra vale como diagnóstico para cualquier equipo: qué decisiones de tu flujo de trabajo siguen visibles después de que termina la conversación, y qué evidencia te dice que el agente las respetó.