Tools such as Anthropic Claude Code or OpenAI Codex have changed the face of software development, and all the signs are that this investment is set to increase further.
Tools such as Anthropic Claude Code or OpenAI Codex have changed the face of software development, and all the signs are that this investment is set to increase further.
That’s a question several economists from the US National Bureau of Economic Research have attempted to answser, at least indirectly. Their paper, snappily entitled The Macroeconomic Effect Of AI: Sizing The Software Engineering Channel, attempts to calculate how much AI has increased the productivity of software engineers in enterprises outside the software and semiconductor industries by looking at their share prices.
“The main idea is that if AI raises the productivity of software engineers, then firms that rely more heavily on them should benefit more. Therefore news about AI generates higher expected profits for these firms. These profits are capitalized into larger stock price responses. Combining these stock price responses with a model, we can pin down the increase in software engineering productivity expected by financial markets,” the researchers wrote.
And the answer? “From November 2022 to December 2025, AI increased the market’s expected present value of software engineering productivity by the equivalent of a permanent 32.6% productivity increase.”
That’s not to say that your software engineers will be that much more productive, but it’s a starting point for allocating budget between AI tool use and payroll.
In context
- Topic: Desarrollo con IA — Copilotos y agentes en el ciclo de desarrollo de software.
- Source: CIO
- Published: 02/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Por qué importa
Lo que está cambiando en ingeniería no es la velocidad de tipeo, es la relación entre el que produce y el que responde por el resultado. Un asistente puede generar en minutos algo que nadie del equipo entiende del todo, y eso tiene un costo que no aparece en ninguna métrica de productividad.
Mi vara es simple: ¿mejoró el tiempo desde que se pide algo hasta que está en producción y funcionando? Si mejoró la velocidad de escribir pero el cambio sigue tardando tres semanas en salir, el cuello de botella estaba en otro lado y la herramienta no lo tocó.
Lo que suele salir mal
El problema aparece cuando alguien acepta código que no entiende del todo pero que pasa las pruebas. Funciona, entra a producción, y seis meses después hay que modificarlo. Ahí se descubre que nadie en el equipo puede explicar por qué está escrito así, y el cambio chico se convierte en una reescritura.
Qué mirar
- Qué pasa con las pruebas — generar código sin generar pruebas solo mueve el problema hacia adelante.
- Dónde viaja el código fuente cuando se usa el asistente, y qué dice el contrato sobre eso.
- El efecto sobre la gente que recién entra al equipo, que es donde más rápido se pierde el criterio.
Cómo leo esta entrada
Lo que yo pediría medir no es líneas ni sugerencias aceptadas, sino defectos que llegan a producción y tiempo de revisión por cambio. Si esas dos bajan, la herramienta sirve. Si suben mientras sube la velocidad, se está acumulando una deuda que se paga con incidentes.
La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.
Comentarios
Todavía no hay comentarios. El primero puede ser el tuyo.
¿Lo estás viviendo en tu equipo?
Abrí el chat y contame cómo lo están manejando. Me interesa comparar notas.
