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: InfoWorld
- 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
Cuando aparece una herramienta que promete acelerar el desarrollo, la pregunta útil no es cuánto código genera sino cuánto trabajo genera aguas abajo. Pruebas, revisión, seguridad, deuda técnica, incidentes: ahí es donde se paga o se cobra la promesa.
Yo lo miro desde la operación, no desde la demo. La pregunta no es si el asistente escribe una función correcta, sino si el equipo puede sostener seis meses después lo que produjo, con otra gente, sin el contexto original. Esa es la prueba real y casi nunca aparece en los anuncios.
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
Yo lo trataría como un cambio de proceso, no de herramienta. El asistente cambia quién hace qué dentro del equipo, y eso hay que conversarlo con la gente antes, no descubrirlo en la retrospectiva cuando alguien ya se sintió reemplazado.
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.
