Prompting es programar: 65% de devs corrige la salida de IA

Por qué la IA acelera el código y se estanca en el resto de la empresa

El 65% de los desarrolladores dedica tiempo cada semana a corregir trabajo generado por IA que no cumplió con la intención original, según el State of Developer Experience 2026 de Atlassian, recogido por i-SCOOP. Y aun así, el 87% de esos mismos desarrolladores afirma que la IA le ayuda a entregar más rápido. Más velocidad en la tarea, más trabajo de limpieza después: esa contradicción es el punto de partida de un ensayo publicado en el blog brethorsting.com que propone una explicación incómoda y bastante convincente.

El texto arranca con una escena doméstica. El autor observa a un amigo suyo, profesor de humanidades formado en una universidad de la Ivy League, trabajando con Claude. La conversación da vueltas, nunca se articula el objetivo, y cada respuesta del modelo es razonable pero un poco desviada. El amigo empuja, el modelo se corre a otro lado. "Es una de las personas más inteligentes que conozco", escribe el autor, "y lo vi peleando con una herramienta que reconfiguró por completo la forma en que construyo software".

La escena le sirve para conectar con un fenómeno más grande: fuera del software, las industrias no están viendo las ganancias de productividad que se prometieron. Marketing, análisis, management y operaciones sacan algo de ayuda redactando correos y resumiendo reuniones, y después gastan el tiempo ahorrado limpiando resultados que parecen plausibles pero no hacen lo que se necesitaba.

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 tesis: prompting bien es programar

La explicación habitual es que los modelos se entrenaron con montañas de código, que el código es verificable (compila o no compila) y que los laboratorios volcaron su mejor tooling en agentes de programación porque sus propios empleados son ingenieros. Todo eso es cierto, dice el autor, pero no alcanza: también hay ingenieros obteniendo resultados excelentes en tareas que no tienen nada que ver con código, como planificar un viaje o reestructurar un presupuesto.

Su teoría es más simple: promptear bien es programar. El trabajo mental es el mismo; solo cambió la sintaxis.

Piensa en lo que pasa por tu cabeza cuando escribes una función. Decides qué entra y de dónde viene. Decides exactamente cómo debe verse la salida. Rompes el problema en pasos lo bastante pequeños como para que cada uno sea obviamente correcto. Piensas en los casos borde: la lista vacía, el campo que falta, el usuario que hace algo inesperado. Y decides cómo vas a saber que funciona. Nada de eso es escribir puntos y comas, y todo eso es lo que separa un buen prompt de uno malo.

Un no programador le pide al agente "un informe de ventas del Q3". Un ingeniero, casi sin pensarlo, pregunta otra cosa: qué datos, en qué archivo, desglosado por qué, comparado contra qué base, en qué formato, y qué debería pasar con las dos regiones que se reorganizaron a mitad de trimestre. No es más inteligente. Tiene la precisión grabada a golpes por un compilador.

El compilador como maestro: por qué el modelo no te corrige

Todo programador pasó años recibiendo, de forma instantánea y sin piedad, el mensaje de que la computadora hace lo que dijiste, no lo que querías decir. Los no programadores se pasaron la carrera comunicándose con humanos, que rellenan los huecos con contexto compartido y vuelven con una pregunta aclaratoria cuando algo no cierra.

Un LLM también rellena los huecos, pero con la conjetura más plausible, y casi nunca pregunta. Un prompt vago no lanza un error: el modelo alucina lo que quisiste decir, devuelve algo que parece correcto y te deja descubrir dónde no lo es. El instinto del ingeniero es desconfiar de la salida que "parece bien". El instinto de la mayoría es aceptarla.

La brecha se agranda cuando el resultado está mal. Un ingeniero depura: forma una hipótesis sobre qué parte de sus instrucciones desvió al modelo, cambia esa sola cosa y vuelve a correr. Un no programador tiende a repetir el mismo prompt, agregar "por favor sé preciso" o concluir que la herramienta no sirve. Nunca desarrolló el hábito de tratar un mal resultado como información sobre su propio input.

El dato: la productividad prometida no llega a toda la organización

Los números acompañan la tesis. Una investigación de Karat realizada por The Harris Poll, difundida por Business Wire y recogida por Yahoo Finance, encontró que el 90% de los líderes tecnológicos en Estados Unidos usa IA para producir más sin reducir su plantilla de ingeniería; apenas el 10% mantiene la producción con menos ingenieros. El 82% reporta más volumen de producto y funcionalidades.

Pero más output no significa entrega más rápida: el 67% reporta un aumento en el tiempo necesario para llevar nuevas funcionalidades al mercado y el 44% reporta más errores de código. Es el patrón que la propia investigación asocia a la paradoja de Jevons: si producir código se abarata, las organizaciones producen más software en lugar de recortar recursos.

El State of Developer Experience 2026 de Atlassian (1.155 desarrolladores y 405 líderes encuestados) muestra la misma tensión desde otro ángulo. El 80% entrega más sin trabajar más horas, pero solo el 28% reporta menos fricción que antes de la IA. La mayor pérdida de tiempo sigue siendo encontrar información (51%), seguida de reuniones (50%). Y el 65% gasta tiempo arreglando trabajo de IA que no captó la intención original.

Otras mediciones apuntan en la misma dirección. Faros AI siguió a más de 10.000 desarrolladores en 1.255 equipos y encontró que los equipos con alta adopción de IA fusionaron 98% más pull requests, pero el tiempo de revisión subió 91%. LinearB, sobre más de 8 millones de pull requests, calcula que los PR generados por IA esperan 4,6 veces más antes de que alguien los tome, y solo el 32,7% se acepta, contra el 84,4% de los manuales. Sonar, en su encuesta State of Code publicada en enero de 2026 con más de 1.100 desarrolladores, encontró que el 96% no confía del todo en el código generado por IA, pero solo el 48% lo revisa siempre antes de hacer commit.

Y el ensayo controlado de METR de 2025 —16 desarrolladores open source experimentados, 246 tareas reales— encontró que con IA tardaron 19% más, aunque antes esperaban ser 24% más rápidos y después seguían creyendo que habían ganado 20%.

En el otro extremo está el caso que se cita como prueba del potencial: Salesforce no sumará más ingenieros de software el próximo año, según declaraciones de Marc Benioff recogidas por TechTimes, porque la IA ya elevó la productividad de ingeniería más de 30%. La compañía atribuye a Claude Code haber comprimido una migración que había sido estimada en 231 días a 13 días, migrando 33 endpoints de API con un framework basado en reglas y revisión humana.

¿Qué significa esto para tu startup?

La lectura útil no es "contrata ingenieros para usar IA". Es que la habilidad que falta en tu equipo probablemente no sea técnica, sino de especificación.

Escribe el estado final antes de empezar. Antes de abrir el chat, define en dos líneas qué tiene que existir cuando el trabajo esté hecho: qué datos, en qué formato, contra qué referencia y qué harás con los casos raros. Es el hábito que el ensayo identifica como el que faltaba en la sesión del profesor.
Trata un mal resultado como información sobre tu input. Cuando la salida no sirve, no repitas el mismo prompt ni agregues "sé preciso". Identifica qué instrucción desvió al modelo, cambia esa sola variable y vuelve a correr. Es depuración, no suerte.
Invierte en contexto compartido, no en más herramientas. El mayor drenaje de tiempo en el reporte de Atlassian es encontrar información (51%). Documentación, decisiones y criterios accesibles para personas y agentes valen más que otra suscripción.
Planifica la capacidad de revisión. Si tu equipo produce PRs más rápido de lo que puede revisarlos, el cuello de botella se muda a la cola de revisión. Mantén los cambios pequeños y pide evidencia: qué se probó y qué no.
Mide resultados, no uso. Los tokens y las horas de uso de IA son un diagnóstico, no una meta. Lead time, estabilidad, calidad y satisfacción dicen si el esfuerzo está pagando.

La trampa de la "programación en lenguaje natural"

La programación en lenguaje natural se vendió como la forma de que todos pudieran programar. Hasta ahora, escribe el autor, sirve sobre todo para que quienes ya piensan como programadores lo hagan más rápido, y en inglés.

Su observación más filosa es sobre quiénes sí obtienen valor fuera del software: el financiero que arma planillas con tablas de búsqueda, el responsable de operaciones que escribe sus propios flujos de Zapier, el investigador que pelea con datos en R porque nadie más quería hacerlo. Ya estaban programando. Solo no lo llamaban así.

El mercado laboral lo reflejó durante un tiempo: en 2024, la consultora Lightcast reportó que la demanda de puestos con el título "prompt engineer" se multiplicó por cinco en un año, según SHRM. Hay quien sostiene lo contrario, que a medida que los modelos se vuelvan más intuitivos la necesidad de prompts muy elaborados caerá y el foco se moverá a verificar resultados, como recoge engineering.com.

Mientras tanto, hay una consecuencia silenciosa: el 37% de los líderes de ingeniería contrató menos desarrolladores junior en el último año, según el reporte de Atlassian. Si la especificación y la revisión se vuelven el trabajo central, la pregunta de dónde se aprenden esas habilidades queda abierta.

Conclusión

La tesis del ensayo no es que la IA no sirva fuera del código, sino que la parte difícil nunca fue la sintaxis. Especificar un estado final, romper el trabajo en piezas verificables y leer un error como señal sobre las propias instrucciones son hábitos que la ingeniería de software entrena a diario y que el resto de las áreas casi nunca practicó.

Para un founder, eso tiene una implicación concreta: antes de comprar otra herramienta de IA, vale más invertir en que tu equipo aprenda a definir qué significa "terminado". La IA no reemplaza esa conversación. La expone.