Desarrollar software con IA es rápido. Llegar a producción, no tanto.

Entre fines del año pasado y este año, programar con agentes dejó de ser un experimento y pasó a ser la práctica habitual. Nueve de cada diez desarrolladores ya los usan en el trabajo al menos una vez a la semana [18], y dos de cada tres de quienes usan IA trabajan directamente con agentes de código [19]. Andrej Karpathy, que acuñó el término «vibe coding», lo resumió en febrero con una frase que comparto.

Los agentes de código básicamente no funcionaban antes de diciembre y básicamente funcionan desde entonces [21].

Lo veo en nuestros proyectos, donde Un agente de código toma un requerimiento, lo construye, lo prueba y lo deja listo para revisar, en horas. Eso ya no se discute. Lo que me quedó dando vueltas es otra cosa. Si construir es tan rápido, ¿por qué llegar a producción sigue costando lo mismo en tantas empresas?

Yo llegué a esta pregunta con una lista en la cabeza. Cuatro frenos que veo repetirse en los proyectos, y una idea de fondo, que las empresas chicas aprovechan la velocidad y las grandes la pierden en el camino. Como no quería quedarme con mi impresión, me puse a leer lo que se había publicado sobre adopción de IA. Los cuatro frenos eran reales. Pero la lista estaba incompleta, y uno de los que faltaban es el que más pesa.

Las cifras que menciono salen de unos artículos y dejo sus fuentes, para quien quiera ir a leerlas.

Los seis frenos empresas pequeñas v/s empresas grandes.

1. Requerimientos: En una empresa pequeña, el requerimiento vive en dos o tres cabezas. Lo conversan un rato y ya está. En una grande está repartido entre áreas que no siempre se hablan, y juntarlo podría ser un proyecto en sí mismo para organizar las prioridades. En una encuesta reciente, el 62 % de las empresas nombra la mala coordinación entre áreas como una de sus principales barreras para adoptar IA, y el 63 % dice que necesita ajustar primero sus flujos de trabajo [1]. Si el requerimiento no está claro, la IA no aporta. Acelera la confusión. Y las grandes suman un segundo problema que las chicas no tienen. La IA suele quedar a cargo del área de tecnología o de innovación, mas retirado de quien responde por el resultado del negocio [2].

2. Integraciones: Las pequeñas tiene pocos sistemas que tocar. La grande, al hacer un cambio, toca el sistema central, la conciliación, el CRM y ese sistema que nadie quiere abrir. Y detrás de cada sistema hay datos que no conversan entre sí. Un estudio que siguió a 30 empresas durante un tiempo llegó a una conclusión simple. El mayor obstáculo para escalar la IA es conseguir, limpiar e integrar los datos correctos [3]. El costo de eso tiene cifra. El 46 % de las pruebas de concepto se descarta antes de llegar a producción, y el 42 % de las empresas abandonó la mayoría de sus iniciativas de IA en 2025 [1].

3. Normativa: Las pequeñas no tiene áreas que vigilen qué arquitectura se usa. La grande sí, y antes de quejarse conviene entender por qué. Quien pone una IA a funcionar responde si falla, aunque la haya comprado a un tercero. En Estados Unidos, cuando un sistema de selección de personal discriminó por edad, la demanda fue contra la empresa que lo usaba, no contra el proveedor del software [4]. Las áreas de arquitectura y cumplimiento existen para que eso no le pase a la empresa donde ustedes trabajan.

   Dicho eso, la normativa tiene un lado que también he visto de cerca. En un proyecto, el desarrollo se complicó mucho más de lo esperado por decisiones de hacerlo más escalable, que el cliente nunca pidió y que no le aportaban nada directo. Podría ser discutible si esto es normativa o sobreingeniería y hacerse la pregunta ¿Esto existe para proteger al cliente ó es un freno disfrazado de buena práctica?.

4. Clientes: La pequeña suele tener menos clientes y, si algo sale mal, podría arreglarlo hablando con ellos. No siempre es así, pero el impacto de un error tiende a ser más acotado. Las grandes cuida una reputación que tardó años en construir y se puede perder en una tarde. El 93 % de los gerentes de tecnología ya usa o planea usar IA, pero solo el 23 % de los consumidores confía en las empresas que la usan [5]. Y el 80 % de las organizaciones que ya tienen agentes de IA funcionando reconoce que alguno se comportó mal frente a un cliente [5]. La grande no es lenta por capricho, es lenta porque tiene más que perder.

5. Personas: Este es el que me faltaba. Venía pensando en sistemas, en áreas, en normas, y el freno que más pesa en lo que leí es el más humano de todos, la gente. El 65 % de los empleados teme ser reemplazado por alguien que use mejor la IA [6]. El 59 % de las grandes empresas dice usar agentes de IA, pero solo el 9 % logró que funcionen solos en algún proceso, y la razón principal no es técnica. Es que la gente no confía en dejarlos actuar [7]. Y los que deberían acompañar el cambio no dan más. El compromiso de los jefes de área cayó de 30 % en 2023 a 22 % en 2025 [8]. Una empresa grande tiene más gente con miedo y más jefes sin tiempo. Las pequeñas tiene menos de ambos, y eso también es velocidad.

6. Procesos sin rediseñar: Este también faltaba en mi lista, y se parece a una deuda. Si se le pone IA a un proceso que ya era malo, el proceso sigue siendo malo, solo que más rápido, y cada automatización encima de lo viejo suma una capa más que después nadie quiere tocar [15]. Los números dicen que es lo común. Solo el 30 % de las organizaciones ha rediseñado algún proceso clave en torno a la IA [14], y el 84 % de los ejecutivos reconoce que le cuesta sacarle valor medible a la tecnología nueva [15]. En una empresa grande hay más procesos acumulados por más años. En una chica hay menos, pero también se acumulan, y más rápido de lo que uno cree.

La ventaja de la pequeña, y cómo no desperdiciarla

La empresa pequeña tiene una ventaja estructural. Pocas personas deciden, pocos sistemas que integrar, pocos controles que esperar, poca gente con miedo. Pero esa ventaja no se cobra sola, y lo que leí lo confirma. Pocas empresas chicas pueden armar por sí solas una arquitectura flexible para la IA, y por eso casi siempre se apoyan en alguien de afuera [3]. De las empresas a las que les va bien con IA, casi todas trabajan con su propia gente y dos de cada tres además se apoyan en externos [13].

Hoy en Apside estamos acompañando a una pyme que no tiene experiencia en IA. No la necesita para partir. Lo que tiene es tamaño para moverse, y con ayuda va a llegar a producción antes que empresas con diez veces su gente. Nuestro papel ahí no es construirle todo, es acelerarle las iniciativas que ya tiene, cuidando tres cosas al mismo tiempo. Ordenar y priorizar su lista de pendientes por impacto, para que la velocidad no se gaste en lo que nadie va a notar y se pueda medir el retorno antes de construir [2]. Darle reglas a sus desarrollos a medida que crecen (ambientes separados, revisión humana antes de producción, respaldos), porque la normativa que hoy no necesita la va a necesitar, y conviene que crezca con ella y no después de un incidente. Y no soltar la calidad ni la seguridad por ir rápido. Hay casos públicos de este año de lo que pasa cuando se suelta. Un agente de código borró la base de datos de producción de una empresa ignorando la orden de no tocarla, y una aplicación expuso 72.000 fotos de sus usuarios porque dejó un almacenamiento en la nube sin clave [9]. Recuperarse de un ataque informático le cuesta a una pyme, en promedio, 375.000 dólares [10]. Y se lleva la confianza que costó años.

Lo que cada empresa tiene que mirar, sea del tamaño que sea

Mi tentación al llegar acá era cerrar con una lista de consejos. Hay pero asociados a tamaños y necesidades de empresas distintas donde por ejemplo no veo por qué le funcionaría igual a una aseguradora en Chile o a una pyme.

El uso de la IA, es nuevo para todos. No hay todavía una receta probada, y desconfío de quien diga que la tiene. Lo que sí veo, es que el problema casi nunca es técnico, es organizacional. Nadie es dueño del resultado, cada área ejecuta su pedazo, y los pilotos mueren en el espacio que queda entre un equipo y otro [11]. Hay un caso que me quedó grabado. Una firma de 2.200 desarrolladores midió que cada persona producía entre 30 % y 40 % más con IA, y el desempeño global de la empresa se mantuvo plano. Recién cuando rediseñaron competencias, incentivos y procesos subió un 22 % [12]. El freno no estaba donde lo buscaban. En otra empresa, el software salió más rápido y el cuello de botella se corrió a la fabricación del hardware [12]. El freno se mueve, y es de cada uno.

Por eso lo correcto, para la grande y para la pequeña, es hacer la revisión propia antes de copiar nada. Tres preguntas que sirven para empezar.

1. ¿Dónde se va el tiempo entre «está listo» y «está en producción»? No en promedio, el último proyecto, con fechas.
2. ¿Cuál de los seis frenos pesa más en su empresa, y quién lo sostiene? A veces es un sistema, otras es una persona con razones que nadie le ha preguntado.
3. ¿Con quién lo han conversado fuera de la empresa? Muchas veces la idea que destraba no sale de un informe, sale de hablar con un par que ya pasó o esta viviendo lo mismo.

Una advertencia sobre la palabra «rápido»

En 2025 un estudio midió a desarrolladores con experiencia trabajando con herramientas de IA. Ellos creían ir un 20 % más rápido y en realidad fueron un 19 % más lentos [9]. El mismo equipo repitió la medición a comienzos de 2026 y ya no encontró evidencia clara en ninguna dirección [20]. Lo que sí cambió, y mucho, es la adopción [18][19], y el costo y el tiempo de construir un prototipo bajaron de una forma que hace un año no se veía [17]. Pero la lección sigue vigente. La velocidad de escribir código no es productividad. Hoy la IA escribe cerca del 42 % del código que se sube a los repositorios, pero el 96 % de los desarrolladores dice que no confía del todo en ese código y menos de la mitad lo verifica siempre [22]. El cuello de botella se movió a verificar, integrar y desplegar con seguridad. Ahí es donde los seis frenos pesan, en la grande y en la pequeña.

Si quieren revisar dónde está el freno en su empresa, conversemos.

Fuentes

1. Bouquet, Wright y Nolan, «Match Your AI Strategy to Your Organization’s Reality», HBR, ene-2026. https://hbr.org/2026/01/match-your-ai-strategy-to-your-organizations-reality
2. Rogers y Sankaranarayanan, «Closing the Gap Between AI Investment and Financial Return», HBR, sep-2026. https://hbr.org/2026/09/closing-the-gap-between-ai-investment-and-financial-return
3. Davenport y Mittal, «Stop Tinkering with AI», HBR, ene-feb 2023. https://hbr.org/2023/01/stop-tinkering-with-ai
4. Parra-Orlandoni y Carvão, «You Outsourced the AI, but You Still Own the Risk», HBR, jul-2026. https://hbr.org/2026/07/you-outsourced-the-ai-but-you-still-own-the-risk
5. Wade y Wirtz, «Responsible AI Is Becoming a Growth Strategy», HBR, jul-2026. https://hbr.org/2026/07/responsible-ai-is-becoming-a-growth-strategy
6. Eatough, Ferrazzi, Smith y Waters, «Why AI Adoption Stalls, According to Industry Data», HBR, feb-2026. https://hbr.org/2026/02/why-ai-adoption-stalls-according-to-industry-data
7. McKinlay, Puntoni y Saka, «To Adopt AI at Scale, Employees Need to Trust Agents», HBR, sep-2026. https://hbr.org/2026/09/to-adopt-ai-at-scale-employees-need-to-trust-agents
8. Shin y Sucher, «AI Adoption Is Overloading Your Middle Managers», HBR, jun-2026. https://hbr.org/2026/06/ai-adoption-is-overloading-your-middle-managers
9. Li, «AI Tools Make Coders More Important, Not Less», HBR, dic-2025. https://hbr.org/2025/12/ai-tools-make-coders-more-important-not-less
10. Dobrygowski, «How AI Is Changing Cyber Threats, and Cybersecurity, for SMBs», HBR, oct-2026. https://hbr.org/2026/10/how-ai-is-changing-cyber-threats-and-cybersecurity-for-smbs
11. Israeli y Ascarza, «Most AI Initiatives Fail. This 5-Part Framework Can Help.», HBR, nov-2025. https://hbr.org/2025/11/most-ai-initiatives-fail-this-5-part-framework-can-help
12. Li, Zhu y Hua, «Overcoming the Organizational Barriers to AI Adoption», HBR, nov-2025. https://hbr.org/2025/11/overcoming-the-organizational-barriers-to-ai-adoption
13. Lawler, D’Silva y Arora, «What Companies Succeeding with AI Do Differently», HBR, ene-2025. https://hbr.org/2025/01/what-companies-succeeding-with-ai-do-differently
14. Balasubramanian, Asaba, Bala y Joshi, «U.S. and Japanese Companies Struggle with Different Parts of AI Adoption», HBR, jul-2026. https://hbr.org/2026/07/u-s-and-japanese-companies-struggle-with-different-parts-of-ai-adoption-and-offer-different-lessons-for-making-it-work
15. Subramanian y Yousufani, «AI Success Depends on Tackling “Process Debt”», HBR, jun-2024. https://hbr.org/2024/06/ai-success-depends-on-tackling-process-debt
16. Ignatius, «Speed Is a Leadership Decision», entrevista a Andy Jassy, HBR, jul-ago 2025. https://hbr.org/2025/07/speed-is-a-leadership-decision
17. Lee, Mantia y McNeill, «How Agentic AI Supercharges Startups and Threatens Incumbents», HBR, jul-ago 2026. https://hbr.org/2026/07/how-agentic-ai-supercharges-startups-and-threatens-incumbents
18. JetBrains, «Developer Ecosystem 2026», ago-2026 (más de 15.000 desarrolladores encuestados entre mayo y julio de 2026). https://blog.jetbrains.com/research/2026/08/ai-coding-agent-adoption-2026/
19. Stack Overflow, «Developer Survey 2026», oct-2026 (más de 30.000 desarrolladores). https://stackoverflow.blog/2026/10/06/the-results-of-the-2026-developer-survey-are-here
20. METR, «Uplift update», feb-2026 (actualización del estudio de 2025). https://metr.org/blog/2026-02-24-uplift-update/
21. Andrej Karpathy, publicación en X, 25-feb-2026. https://x.com/karpathy/status/2026731645169185220
22. Sonar, «State of Code Developer Survey», ene-2026 (1.149 desarrolladores). https://www.sonarsource.com/blog/state-of-code-developer-survey-report-the-current-reality-of-ai-coding/