Por qué el código escrito por IA frustra a los equipos — y qué hacer al respecto

Con la mayoría de las tecnologías, cuanto más tiempo las utilizas, más calmadamente llegas a confiar en ellas. Con las herramientas de IA, lo contrario ha sido cierto: en su encuesta anual de más de 49,000 desarrolladores, Stack Overflow registró un aumento en el uso hasta el 84% al mismo tiempo que la confianza en la precisión de estas herramientas disminuyó del 40% al 29% en el transcurso de un solo año.

Ese efecto me es familiar. Nuestra primera experiencia con herramientas de IA en el desarrollo tuvo poco en común con el efecto wow de un trabajo más rápido y menos tedioso que la prensa tecnológica seguía escribiendo. Nuestros desarrolladores se sintieron defraudados: la IA produjo un código mediocre que tomó mucho tiempo revisar y, al final, tuvo que ser reescrito. El equipo esperaba que la IA ahorrara tiempo y, en cambio, obtuvo trabajo extra. Así que no mucho después de esos primeros intentos de integrar las herramientas de IA en el flujo de trabajo diario, el equipo regresó a trabajar como siempre había hecho.

Hoy en día, esas mismas herramientas aceleran tanto la escritura de código como su revisión para nuestros desarrolladores — no porque hayamos encontrado un modelo mejor, sino porque cambiamos la forma en que trabajamos con él. Aquí está lo que nos ayudó a llegar allí.

Por qué el código escrito por IA frustra a los desarrolladores

La IA se apoya en una enorme masa de código público de todo Internet, y ese código rara vez es ejemplar: su calidad es promedio, y el modelo reproduce ese promedio.

Pero “promedio” no es el límite de lo que es posible — es simplemente lo que el modelo produce hasta que conoce tu proyecto: sus convenciones, su estructura de código, sus decisiones arquitectónicas. En una encuesta de 600 desarrolladores, Qodo encontró que entre los que no estaban satisfechos con la calidad del código de IA, el 44% lo atribuía precisamente a la falta de contexto. Eso es lo que mantiene la salida en un nivel mediocre.

La buena noticia es que el contexto que la IA recibe es justamente la única variable que un equipo controla completamente. Cómo bien la herramienta entiende el proyecto depende no del modelo, sino de lo que se le alimenta.

La segunda razón es mental — la naturaleza misma del trabajo cambia. Cuando la IA escribe la mayoría del código, el acto principal del desarrollador ya no es escribir, sino verificar lo que se ha generado: leer la solución de alguien más, sopesar las alternativas, decidir qué está listo para ser enviado. Esa es una habilidad diferente a la de escribir código uno mismo, y para cualquiera que amara la parte de escritura, no viene fácilmente.

En su informe Octoverse de 2025, GitHub describe exactamente este cambio: los desarrolladores que han avanzado más con la IA ya no se llaman a sí mismos “autores de código” y se convierten en algo más cercano a sus “directores creativos”, donde la habilidad clave es dirigir y verificar. Pero el camino a ese rol pasa por errores y frustración, hasta que una persona ve el beneficio en su propio trabajo.

Qué convierte a la IA de una fuente de frustración en una herramienta de trabajo

Cuando nuestro equipo comenzó a usar la IA, algunos desarrolladores trabajaron con Claude Code, otros probaron OpenAI Codex, GitHub Copilot o Gemini CLI, y cada herramienta dio un resultado diferente. Así que cuando nos dispusimos a ordenar la forma en que el equipo trabajaba con la IA, lo primero que hicimos fue decidirnos por una sola herramienta.

Esta no es solo nuestra práctica. Toma la historia del equipo en Linear: hasta principios de 2026, funcionaban con un principio de “dejar que todos trabajen como les parezca”, y en enero, la dirección abandonó ese enfoque y trasladó a todos a una sola forma de trabajar — limitando la elección a dos herramientas de IA y pidiendo a los desarrolladores que escribieran código solo con ellas, en lugar de a mano. Según la empresa, la productividad promedio aumentó al mes siguiente en un 30% en las solicitudes de fusión y en un 33% en las tareas cerradas por ingeniero.

Esto dicho, una herramienta compartida por sí sola no mejora el código — tiene que estar configurada: establecer reglas, algo como un archivo de reglas, que especifiquen cómo escribir código — qué enfoques seguir, qué evitar. Luego vienen habilidades personalizadas para las tareas típicas de tu proyecto, para que no tengas que explicar lo mismo una y otra vez. Y finalmente, vale la pena apuntar al agente hacia tu base de código existente: analiza cómo se escribe el proyecto y produce nuevo código en ese mismo estilo en lugar de uno genérico. Cuanto más contexto reciba la herramienta, menos tendrás que reescribir a mano después.

Pero la parte más difícil no es técnica. El cambio de autor del código a su evaluador no sucede por sí solo — esa transición necesita ayuda. La ruta más directa es la capacitación y la certificación. En nuestro caso, por ejemplo, diez desarrolladores están pasando por un programa de socios con el proveedor de la herramienta, mientras que junto a ellos trabaja una persona responsable de la adopción, que explica por qué la herramienta produjo un resultado determinado y cómo solucionarlo.

Una vez que el equipo trabaja de manera coordinada, queda una sola barrera — la revisión — y vale la pena reforzarla con la IA. El agente pasa por cada solicitud de extracción primero y se encarga de lo obvio: errores rutinarios, estilo, repetición, brechas de seguridad. El revisor humano ya no mira todo indiscriminadamente, solo la arquitectura y las decisiones críticas. El efecto es notable incluso dentro de las empresas que construyen estas herramientas: en Anthropic, después de introducir dicho agente, la participación de solicitudes de revisión aumentó del 16% al 54%, y los ingenieros estuvieron en desacuerdo con menos del 1% de sus comentarios.

Para nosotros, esto acortó un ciclo de revisión que antes se extendía a lo largo de dos o tres días en varias rondas, y levantó la carga de trabajo rutinario de nuestros ingenieros senior, dejándoles solo los puntos realmente difíciles. Una vez que la herramienta finalmente comenzó a producir resultados que no necesitaban reescritura, la confianza en ella también apareció.

Dónde la confianza en las herramientas de IA se traduce en beneficios

Primero y principalmente — en la escritura de código: cuando la herramienta conoce el proyecto y el agente maneja la primera revisión, el equipo escribe más y mejor en el mismo tiempo. En nuestro caso, las herramientas de IA aceleraron el trabajo en aproximadamente un 30-40%.

Más allá de eso, la IA ha facilitado la incorporación de nuevos miembros. Cuando una persona nueva se une a un proyecto, alguien experimentado generalmente tiene que responder a docenas de preguntas sobre cómo se estructura el código del proyecto. Ahora el agente asume ese rol: si el proyecto está bien documentado, el recién llegado dirige hasta el 95% de esas preguntas al agente en lugar de a los colegas.

Es una historia similar con la documentación: un borrador arquitectónico aproximado que antes consumía horas ahora es, en gran medida, escrito por el agente mismo — según nuestras estimaciones, alrededor del 80% del borrador, si se le da suficiente contexto. Lo que queda para el ser humano es lo que no está en el repositorio — las decisiones, las compensaciones, la experiencia.

Tan importante como ser honesto sobre los límites de lo que la IA puede hacer, porque son las expectativas infladas las que generan la decepción en primer lugar. La IA no asume la responsabilidad de la cumplimentación — un ser humano firma la información médica o financiera, y la empresa, no el modelo, es responsable de una filtración. No acelera las integraciones con socios, donde docenas de horas se invierten en llamadas y coordinación.

La IA fuera de la caja realmente es irritante — pero solo cuando se utiliza como una solución terminada. La diferencia entre la frustración y el beneficio radica en lo que se construye alrededor de ella: un estándar compartido, el contexto del proyecto y el nuevo rol del desarrollador.