AMP: El emperador está desnudo – Por qué los agentes de codificación con IA están revolucionando el mercado de herramientas para desarrolladores

Introducción

El panorama de los agentes de codificación con IA está experimentando una disrupción sin precedentes. Lo que era innovador hace seis meses, hoy ya se considera obsoleto. GitHub Copilot, que fue el referente del desarrollo asistido por IA, ha sido superado por herramientas más nuevas. Cursor dominó el mercado como la startup de más rápido crecimiento de la historia, solo para enfrentarse después a soluciones aún más avanzadas. En este ecosistema en rápida evolución, Sourcegraph tomó una decisión estratégica audaz: en vez de mejorar incrementalmente su producto Cody existente, lanzaron AMP, un agente de codificación completamente nuevo construido desde cero para aprovechar la frontera de las capacidades de la IA.

Este artículo explora la filosofía, arquitectura técnica y estrategia empresarial detrás de AMP, extrayendo ideas de conversaciones con el equipo creador de esta herramienta revolucionaria. Analizaremos por qué los enfoques tradicionales de desarrollo de productos fracasan en la era del avance acelerado de la IA, cómo los agentes que llaman herramientas difieren fundamentalmente de los asistentes de codificación con IA anteriores y cómo será el futuro del desarrollo autónomo. Pero lo más importante, entenderemos por qué el “emperador está desnudo”: por qué productos consolidados, con posiciones aparentemente inamovibles en el mercado, pueden volverse irrelevantes de la noche a la mañana cuando la tecnología subyacente cambia.

{{ youtubevideo videoID=“b4rOVZWLW6E” provider=“youtube” title=“AMP: El emperador está desnudo - Por qué los agentes de codificación con IA están revolucionando las herramientas para desarrolladores” class=“rounded-lg shadow-md” }}

¿Qué son los agentes de codificación con IA y cómo funcionan?

La evolución del desarrollo asistido por IA ha seguido una trayectoria clara, donde cada generación se apoya en la anterior, pero cambia fundamentalmente la forma en que los desarrolladores interactúan con la inteligencia artificial. Para entender la importancia de AMP, primero debemos comprender qué distingue a un agente de codificación de las formas anteriores de asistencia con IA. El viaje empezó con GitHub Copilot, que introdujo la autocompletación y sugerencia de código directamente en el editor de los desarrolladores. Copilot fue revolucionario porque integró la IA en el flujo de trabajo de desarrollo de una manera no intrusiva, sugiriendo mientras el programador escribía. Sin embargo, Copilot tenía una limitación fundamental: podía sugerir código, pero no podía ejecutar tareas complejas y de múltiples pasos ni interactuar con un entorno de desarrollo más amplio.

La siguiente generación trajo herramientas como Cursor y Windsurf, que crearon bifurcaciones de IDE integrando la IA más profundamente en el entorno de desarrollo. Estas herramientas demostraron que capacidades parcialmente agénticas —donde la IA podía realizar operaciones más complejas dentro del IDE— podían mejorar notablemente la productividad del desarrollador. Mostraron que los programadores estaban dispuestos a cambiar por completo su entorno de desarrollo si las capacidades de la IA eran suficientemente avanzadas. Sin embargo, incluso estas herramientas operaban con restricciones: eran interactivas, requerían la intervención y aprobación del desarrollador en cada paso, y no podían operar verdaderamente de forma autónoma.

En contraste, un agente de codificación es una arquitectura fundamentalmente diferente. Un agente consta de tres componentes principales: un modelo de lenguaje (normalmente uno de vanguardia como Claude 3.5), una instrucción de sistema que define el comportamiento y restricciones del agente, y un conjunto de herramientas con instrucciones asociadas que describen lo que cada herramienta puede hacer. La diferencia crucial es que los agentes pueden operar con permisos explícitos para interactuar con sistemas externos—sistemas de archivos, editores de código, sistemas de control de versiones y más. Esto significa que un agente puede razonar autónomamente sobre un problema, decidir qué herramientas utilizar, ejecutarlas, observar los resultados e iterar hasta completar la tarea. Esto es mucho más potente que cualquier enfoque anterior, ya que permite un comportamiento verdaderamente autónomo en vez de solo sugerencias mejoradas o asistencia interactiva.

Por qué el desarrollo tradicional de productos fracasa en la era de la disrupción IA

El panorama tecnológico ha entrado en una fase de inestabilidad sin precedentes. Lo que hace dieciocho meses era lo más avanzado, hoy se considera primitivo. GitHub Copilot, lanzado en 2021, fue realmente revolucionario—representó la primera aplicación a gran escala de modelos de lenguaje al desarrollo de software. Pero hoy muchos desarrolladores ni siquiera lo consideran entre las mejores opciones para programar con IA. No es que Copilot haya empeorado; es que la tecnología subyacente avanzó tan rápido que toda la categoría cambió. Esto representa un reto profundo para las empresas consolidadas: ¿cómo mantener un producto exitoso cuando el suelo bajo tus pies cambia constantemente?

El desarrollo tradicional de productos asume una base relativamente estable. Encuentras el product-market fit, escalas el producto, estableces buenas prácticas de ingeniería, añades características empresariales, firmas contratos a largo plazo con clientes. Esta receta ha funcionado durante décadas porque la tecnología solía evolucionar gradualmente. Pero en la era actual de la IA, este enfoque es perjudicial. Si optimizas tu producto para escalar y ser estable, te vuelves lento. Si eres lento, pierdes la siguiente ola de mejoras de capacidad. Cuando terminas de agregar las funciones empresariales y los requisitos de seguridad, ya ha salido un nuevo modelo que vuelve obsoleto tu enfoque.

Sourcegraph enfrentó exactamente este dilema con Cody. Cody era un producto exitoso, con clientes empresariales, contratos extensos e ingresos significativos. Pero Cody estaba estrechamente integrado en la plataforma Sourcegraph, lo que lo ataba a los ciclos de lanzamiento de la plataforma. La plataforma tenía su propia infraestructura, su propio calendario de despliegue y sus propias restricciones. Cuando se lanzó Claude 3.5 Sonnet y el equipo se dio cuenta de que podían construir algo radicalmente distinto—un agente que llamara herramientas y razonara de manera autónoma—tuvieron que elegir: intentar adaptar esas capacidades a Cody, o empezar desde cero con un producto nuevo. Eligieron empezar de cero, y esa decisión revela una idea clave sobre cómo competir en mercados que evolucionan con rapidez.

La clave fue darse cuenta de que no se puede hacer funcionar un modelo de suscripción de 20 $ para un agente que llama herramientas. Los costes computacionales son radicalmente diferentes. Un asistente basado en chat como Cody puede funcionar eficientemente con una infraestructura modesta. Un agente que llama herramientas, que razona sobre el código, ejecuta herramientas y itera autónomamente, requiere mucha más computación. No es solo un problema de precios; es una señal de que el producto es fundamentalmente distinto, requiere un modelo de negocio diferente, otras expectativas de cliente y una estrategia comercial distinta. Al crear AMP como producto y marca independientes, Sourcegraph pudo redefinir por completo estas expectativas. Podían decir a los clientes: “Esto no es Cody 2.0. Es una cosa totalmente diferente. Cuesta más porque hace mucho más. Funciona distinto porque está construido sobre otra arquitectura”.

Comprendiendo los agentes que llaman herramientas y el razonamiento autónomo

Para valorar realmente el cambio de paradigma que supone AMP, debemos entender la arquitectura técnica de los agentes que llaman herramientas. Un agente que llama herramientas no es simplemente un modelo de lenguaje con acceso a funciones. La arquitectura es más sofisticada y poderosa. El sistema parte de un modelo de lenguaje de vanguardia—en el caso de AMP, Claude 3.5 Sonnet—entrenado para comprender y usar herramientas de forma eficaz. El modelo recibe una instrucción de sistema que define su rol, restricciones y objetivos. Esta instrucción no es una indicación casual; es un prompt cuidadosamente diseñado que moldea cómo el modelo razona sobre los problemas y decide qué herramientas usar.

Junto a la instrucción de sistema, cada herramienta tiene su propio prompt, que describe lo que hace, qué parámetros acepta, qué devuelve y cuándo debe usarse. Esto es fundamental porque el modelo de lenguaje necesita entender no solo que existe una herramienta, sino para qué sirve y cuándo es apropiado utilizarla. Por ejemplo, un agente puede tener herramientas para leer archivos, escribir archivos, ejecutar código, correr pruebas y hacer commits. Cada herramienta tiene una descripción detallada que ayuda al modelo a razonar sobre cuál usar en cada situación. El modelo puede decidir de forma autónoma utilizar estas herramientas, observar los resultados e iterar a partir de lo aprendido.

El poder de esta arquitectura se aprecia cuando consideramos lo que un agente puede hacer. Un desarrollador podría pedirle a un agente: “Implementa una nueva función que añada autenticación de usuarios a este repositorio”. El agente puede entonces, de forma autónoma: leer el código existente para entender la arquitectura, identificar dónde integrar la autenticación, escribir el código necesario, ejecutar pruebas para verificar la implementación, corregir errores modificando el código y, finalmente, hacer commit de los cambios. Todo esto ocurre sin intervención humana. El agente razona sobre el problema, decide qué herramientas usar e itera según el feedback de esas herramientas.

Esto es completamente diferente de las herramientas de codificación con IA anteriores. Copilot puede sugerir código, pero no ejecutar un flujo de trabajo de varios pasos. Cursor puede realizar operaciones más complejas, pero requiere aprobación humana en cada paso. Un agente puede operar de forma autónoma con permisos explícitos. Esto crea una nueva categoría de capacidades, mucho más poderosa. Sin embargo, también trae nuevos desafíos. Los agentes autónomos pueden cometer errores a gran escala. Pueden ejecutar operaciones perjudiciales si no están bien restringidos. Requieren una ingeniería cuidadosa de las instrucciones del sistema para asegurar el comportamiento deseado. Por eso la arquitectura y el enfoque de AMP son tan relevantes.

La filosofía AMP: velocidad, iteración y posición en la vanguardia

Cuando el equipo de AMP comenzó a construir, tomó una decisión fundamental: la velocidad y la iteración serían la principal prioridad. Todo lo demás se derivaría de esa premisa. Esto significó abandonar muchas de las prácticas que hicieron exitoso a Sourcegraph con Cody. Sin revisiones formales de código. Sin ciclos extensos de planificación. Sin los checklists de seguridad y cumplimiento que toman nueve meses en completarse. En su lugar, el equipo adoptó una mentalidad de proyecto personal: hacer push a main, desplegar 15 veces al día, probar el producto internamente constantemente e iterar en función del uso real.

Este enfoque suena caótico, y bajo los estándares tradicionales de ingeniería de software, lo es. Pero es precisamente el enfoque correcto para un producto que opera en la frontera de las capacidades de la IA. La razón es simple: la frontera se mueve. Cada pocos meses sale un modelo nuevo. Cada pocas semanas aparecen nuevas capacidades. Cada pocos días se descubren nuevas técnicas de ingeniería de prompts o diseño de herramientas. En este contexto, la capacidad de iterar rápido es más valiosa que la de escalar de forma fiable. Un producto que se despliega 15 veces al día puede incorporar nuevas capacidades en cuestión de horas tras su lanzamiento. Un producto que sigue ciclos tradicionales de lanzamiento irá meses por detrás.

La estructura del equipo refleja esta filosofía. El núcleo de AMP es pequeño, unas ocho personas, comparado con organizaciones de ingeniería más grandes. Este tamaño reducido es intencional: permite una toma de decisiones ágil y elimina la sobrecarga comunicativa que ralentiza a los equipos grandes. Todos en el equipo son experimentados, lo que permite prescindir de exhaustivas revisiones de código. Prueban el producto en uso real constantemente, lo que les permite detectar problemas rápido y comprender de cerca las necesidades de los usuarios. No intentan construir un producto para todos los desarrolladores; construyen para quienes desean moverse tan rápido como ellos, permanecer en la vanguardia de la IA y están dispuestos a adoptar nuevos enfoques de desarrollo.

Este posicionamiento es clave. AMP no intenta ser el Copilot de GitHub para todos. No busca ser la herramienta predeterminada de IA para todos los desarrolladores. Se posiciona como la herramienta para quienes quieren ir rápido y estar en la frontera. Es un mercado mucho más pequeño que “todos los desarrolladores”, pero dispuesto a pagar mucho más por capacidades superiores. El modelo de negocio lo refleja: en vez de una suscripción de 20 $ al mes, los clientes de AMP pagan cientos de dólares mensuales. Algunos equipos tienen cifras anuales de cientos de miles de dólares. Esto es posible porque la propuesta de valor es muy fuerte para el mercado objetivo.

FlowHunt y el futuro de los flujos de trabajo autónomos

Los principios que guían el desarrollo de AMP—iteración rápida, posicionamiento en la frontera y razonamiento autónomo—son directamente aplicables a la automatización de flujos de trabajo en general. FlowHunt, como plataforma para construir y automatizar flujos complejos, enfrenta retos y oportunidades similares. Así como AMP se posiciona para manejar la próxima generación de capacidades de IA, FlowHunt puede ayudar a las organizaciones a construir flujos resilientes al cambio tecnológico acelerado. Al centrarse en la flexibilidad, la iteración rápida y la capacidad de incorporar nuevas herramientas y capacidades rápidamente, FlowHunt permite a los equipos mantenerse a la vanguardia.

La clave es que, en un entorno tecnológico que cambia rápido, la capacidad de adaptarse es más valiosa que la de optimizar para las condiciones actuales. Esto aplica tanto si construyes un agente de codificación con IA como si automatizas procesos de negocio. El enfoque de FlowHunt, permitiendo crear, probar e iterar flujos rápidamente, encaja perfectamente con esta filosofía. Los equipos pueden crear flujos que integren las últimas capacidades de IA, probarlos rápidamente e iterar en función de los resultados. A medida que surgen nuevos modelos y herramientas, los flujos pueden actualizarse sin necesidad de rediseñar todo. Este es el futuro de la automatización: no procesos estáticos y optimizados, sino flujos dinámicos y adaptativos que evolucionan con la tecnología.

Dinámica de mercado: por qué los productos establecidos quedan obsoletos

El mercado de agentes de codificación con IA es un caso fascinante de cómo el liderazgo puede cambiar rápidamente. A comienzos de 2024, Cursor era considerado el rey de las herramientas de codificación con IA. Era la startup de más rápido crecimiento de la historia. Muchos desarrolladores cambiaron de otras herramientas a Cursor. El mercado parecía asentado. Luego, en cuestión de meses, la conversación cambió. Surgieron nuevas herramientas. Mejoraron las capacidades. Los desarrolladores empezaron a hacerse otras preguntas. A mediados de 2024, si preguntabas cuál era la mejor herramienta de codificación con IA, muchos ya no nombraban primero a Cursor. El liderazgo del mercado había cambiado tan rápido que el líder anterior ya no era dominante.

Este patrón no es único para los agentes de codificación. Es una característica fundamental de los mercados donde la tecnología subyacente avanza rápidamente. En estos mercados, la capacidad de moverse rápido y adaptarse es más importante que la cuota de mercado actual. Una empresa con 30% de cuota que itera rápido y añade capacidades nuevas acabará superando a una con 50% que se mueve lento. Por eso la decisión de Sourcegraph de crear AMP como producto separado fue tan acertada. Al separar AMP de Cody, se liberaron de las restricciones que los habrían ralentizado. Pudieron moverse rápido, iterar y posicionarse en la vanguardia.

La lección más amplia es que, en mercados que evolucionan rápido, el emperador suele estar desnudo. Productos dominantes pueden quedarse obsoletos sorprendentemente rápido. No es porque empeoren, sino porque la tecnología cambia y no pueden adaptarse lo suficientemente rápido. Las empresas que tienen éxito son las que entienden esta dinámica y se posicionan en consecuencia. No optimizan para las condiciones actuales, sino para la capacidad de adaptarse a futuras condiciones. No intentan servir a todos los clientes, sino a los que valoran la velocidad y la innovación. No siguen los procesos tradicionales, sino que adoptan prácticas que permiten iterar y aprender rápido.

Agentes asíncronos y la próxima frontera

La conversación sobre AMP revela un punto clave sobre el futuro de los agentes IA: el próximo gran cambio será de agentes interactivos a agentes asíncronos. Actualmente, la mayoría de los agentes de codificación funcionan de manera interactiva. Un desarrollador ejecuta un agente en su editor o CLI, el agente realiza operaciones y el desarrollador ve los resultados. Normalmente hay un agente ejecutándose a la vez, y es síncrono: el desarrollador espera a que termine. Esto es un gran avance sobre la programación manual, pero no es la forma definitiva del desarrollo asistido por agentes.

La siguiente frontera son los agentes asíncronos, que corren 24/7 en segundo plano y de manera concurrente. En vez de un solo agente, puedes tener 10, 50 o 100 agentes trabajando simultáneamente en diferentes tareas. Uno podría estar refactorizando código en una parte del repositorio, otro escribiendo tests para un componente distinto y un tercero analizando el rendimiento y sugiriendo optimizaciones. Todo esto ocurre sin intervención humana y de forma concurrente. Las implicaciones son enormes: una mejora de 10x a 100x en el volumen de trabajo realizado, un cambio fundamental en la organización de los equipos y una reinvención total de lo que es posible con el desarrollo asistido por IA.

Este cambio tendrá un gran impacto en los costes de inferencia, en cómo los equipos organizan su trabajo y en lo que significa ser desarrollador. También creará nuevos retos en aseguramiento de calidad, seguridad y control de que los agentes autónomos no introduzcan errores o vulnerabilidades a gran escala. Pero el potencial es enorme. Los equipos que sepan aprovechar agentes asíncronos podrán lograr en días lo que hoy toma semanas. Por eso es tan crítico posicionarse para moverse rápido y adaptarse. Las empresas que logren construir agentes asíncronos eficaces primero tendrán una ventaja competitiva masiva.

Construyendo para la incertidumbre: el principio central

El principio fundamental detrás del enfoque de AMP es construir para la incertidumbre. El equipo no sabe exactamente hacia dónde irá la tecnología, pero sabe que cambiará. No sabe qué capacidades serán las más importantes, pero sabe que surgirán nuevas. No sabe cómo será el mercado en seis meses, pero sabe que será distinto. Ante esta incertidumbre, el enfoque racional es optimizar para la adaptabilidad, no para la optimización. Esto implica mantener el código flexible, la capacidad de desplegar rápido, estar cerca de la frontera de la IA y estar dispuestos a descartar enfoques que ya no funcionen.

Este principio se extiende a la estructura del equipo, el modelo de negocio y la estrategia de clientes. El equipo es pequeño y experimentado, lo que permite tomar decisiones rápidamente. El modelo de negocio es flexible, sin precios ni modelos de usuario fijos, permitiendo ajustes rápidos según evolucione el mercado. La estrategia de clientes se centra en desarrolladores que quieren moverse rápido, creando una alineación natural entre capacidades de la empresa y necesidades del cliente. Todo fluye desde el principio de construir para la incertidumbre y optimizar la adaptabilidad.

Esto es radicalmente diferente al desarrollo tradicional, donde se intenta predecir el futuro, construir para escalar y optimizar la estabilidad. Pero en un mercado donde la tecnología subyacente avanza rápidamente, los enfoques tradicionales son perjudiciales. Te ralentizan, te atan a decisiones que luego quedan obsoletas y te impiden adaptarte a nuevas realidades. Las empresas que triunfan en estos mercados son las que abrazan la incertidumbre, optimizan la adaptabilidad y se mueven lo suficientemente rápido para no quedarse atrás.

{{ cta-dark-panel heading=“Impulsa tu flujo de trabajo con FlowHunt” description=“Descubre cómo FlowHunt automatiza tus flujos de contenido y SEO con IA — desde la investigación y generación de contenido hasta la publicación y analítica — todo en un solo lugar.” ctaPrimaryText=“Solicita una demo” ctaPrimaryURL=“https://calendly.com/liveagentsession/flowhunt-chatbot-demo" ctaSecondaryText=“Prueba FlowHunt Gratis” ctaSecondaryURL=“https://app.flowhunt.io/sign-in" gradientStartColor="#123456” gradientEndColor="#654321” gradientId=“827591b1-ce8c-4110-b064-7cb85a0b1217” }}

Arquitectura técnica: cómo AMP logra 15 despliegues diarios

La capacidad de desplegar 15 veces al día no es casual; es el resultado de elecciones arquitectónicas deliberadas. La primera decisión clave fue desacoplar por completo AMP de la plataforma Sourcegraph. Cody estaba integrado a la plataforma, lo que lo ataba a sus ciclos de lanzamiento y restricciones de infraestructura. AMP se construyó como un producto independiente, con su propia infraestructura, pipeline de despliegue y calendario de lanzamientos. Este desacoplamiento es crucial porque elimina la coordinación que ralentiza sistemas grandes. Los cambios en AMP no requieren coordinar con la plataforma. Los despliegues no dependen de lanzamientos de la plataforma.

La segunda decisión fue adoptar un proceso mínimo de revisión de código. El equipo hace push a main y despliega frecuentemente. Si algo falla, lo arreglan rápido. Suena arriesgado, pero funciona porque el equipo es pequeño, experimentado y usa el producto constantemente. Detectan problemas rápido porque lo usan ellos mismos. Pueden corregir rápido porque el código está fresco en su memoria. Pueden iterar rápido porque no esperan aprobaciones de revisión. Este enfoque sería peligroso en una organización grande, pero en un equipo pequeño y experimentado, es sumamente eficaz.

La tercera decisión fue utilizar agresivamente su propio producto (“dogfooding”). El equipo usa AMP para construir AMP. Esto genera un ciclo de feedback directo donde experimentan inmediatamente cualquier problema o limitación. También descubren continuamente nuevos casos de uso y capacidades. Cuando usas tu propio producto para construirlo, rápidamente aprendes lo que funciona y lo que no. Descubres casos límite que no saldrían en pruebas tradicionales. Desarrollas intuición sobre qué características importan más. Por eso el dogfooding es tan potente para iterar rápido.

La cuarta decisión fue mantener el código simple y flexible. En vez de construir un sistema complejo y optimizado, el equipo creó algo fácil de modificar y extender. Así pueden incorporar nuevas capacidades rápido. Cuando sale un nuevo modelo, lo integran sin demora. Cuando aparece una técnica nueva de ingeniería de prompts, pueden probarla rápidamente. Si descubren un mejor enfoque para un problema, pueden refactorizar sin miedo a romper dependencias complejas. Esta simplicidad y flexibilidad valen más que la optimización en un mercado que cambia rápido.

Modelo de negocio: por qué tiene sentido cobrar cientos de dólares al mes

El modelo de precios de AMP revela ideas importantes sobre la creación de valor en el desarrollo asistido por IA. Pronto el equipo se dio cuenta de que no podían conseguir un negocio viable con suscripciones de 20 $ al mes para un agente que llama herramientas. No era solo un problema de precios, sino una señal de que el producto es fundamentalmente diferente y necesita otro modelo de negocio. Un asistente basado en chat como Cody funciona bien con infraestructura modesta. Un agente que llama herramientas, razona sobre código, ejecuta herramientas e itera autónomamente, necesita mucha más computación. Solo los costes de infraestructura justifican precios más altos.

Pero el precio también refleja la propuesta de valor. Para un desarrollador o equipo que aprovecha bien AMP, las ganancias de productividad son enormes. Un agente que puede implementar funciones, escribir tests y refactorizar código autónomamente puede ahorrar horas o días de trabajo cada semana. Para un equipo, esto se traduce en mucho valor. Si AMP ahorra a un equipo 10 horas semanales y el tiempo del desarrollador cuesta 100 $ la hora, AMP genera 1.000 $ de valor semanal. Cobrar cientos de dólares al mes es solo una fracción de ese valor. Por eso algunos equipos llegan a cifras anuales de cientos de miles de dólares: la propuesta de valor es tan fuerte que el precio es en realidad una ganga.

El modelo de negocio también refleja el posicionamiento estratégico. Al cobrar mucho más que las herramientas tradicionales, AMP deja claro que es una categoría diferente. No compite en precio, sino en capacidad y valor. Esto atrae a clientes que valoran capacidad y valor, y aleja a los sensibles al precio. Es exactamente la segmentación adecuada para un producto en la vanguardia de la IA. Quieres clientes que comprendan y estén dispuestos a pagar por capacidades frontera. No quieres a quienes solo buscan lo más barato, porque cambiarán apenas aparezca otra opción más barata.

El reto organizacional: equilibrando innovación y estabilidad

Uno de los aspectos más interesantes del enfoque de Sourcegraph es cómo gestionan la tensión entre innovación y estabilidad. Sourcegraph tiene un negocio rentable y consolidado con Cody y la plataforma en general. Ese negocio genera ingresos que financian la experimentación audaz con AMP. Pero esto también crea tensión organizativa. ¿Cómo mantener un negocio estable y rentable y, al mismo tiempo, perseguir la innovación radical? ¿Cómo motivar a ingenieros experimentados a centrarse en el nuevo producto cuando tienen experiencia profunda en el anterior?

La respuesta implica varias decisiones clave. Primero, Sourcegraph decidió explícitamente no intentar convertir clientes de Cody a AMP. Usan la confianza y los ingresos de Cody para financiar el desarrollo de AMP. Es una distinción crucial. Si intentaran migrar clientes de Cody a AMP, encontrarían resistencia porque AMP es diferente y requiere otros patrones de uso. Manteniendo separados Cody y AMP, pueden atender segmentos de clientes distintos y evitar la disrupción de migrar entre productos radicalmente diferentes.

Segundo, Sourcegraph formó un equipo para AMP que incluye personas sin ideas preconcebidas sobre cómo construir software. Algunos de los miembros más efectivos solo han trabajado en empresas unipersonales. No tienen años de experiencia en prácticas tradicionales de ingeniería. No tienen hábitos arraigados sobre revisiones de código, ciclos de planificación u optimización. Esa falta de “bagaje” es una ventaja: pueden adoptar prácticas que parecerían radicales a alguien con experiencia tradicional, y hacerlo sin el conflicto interno de abandonar viejas creencias.

Tercero, Sourcegraph ha sido explícito sobre las reglas diferentes para AMP. El equipo no sigue los mismos procesos que el resto de la empresa. No hacen revisiones formales de código. No marcan casillas de seguridad y cumplimiento. No siguen los mismos ciclos de planificación. Esto es posible porque tienen la confianza de sus clientes. Saben que AMP es un producto de frontera y aceptan otras prioridades. Esta separación explícita de reglas y procesos es crucial. Si AMP tuviera que seguir los procesos del resto de Sourcegraph, sería lento. Al separar las reglas, han creado espacio para la innovación radical.

Lecciones para otras organizaciones

La historia de AMP ofrece varias lecciones para organizaciones en mercados que evolucionan rápido. La primera lección es que el éxito previo puede convertirse en un lastre. El éxito de Sourcegraph con Cody y su plataforma podría haberlos atado a un enfoque lento e incremental. En lugar de eso, reconocieron que la tecnología cambiaba y tomaron la decisión audaz de empezar de cero. Eso requirió confianza para canibalizar su propio negocio, visión para ver que el enfoque anterior no serviría y valentía para apostar por una estrategia radicalmente distinta.

La segunda lección es que, en mercados que evolucionan rápido, la velocidad y la adaptabilidad valen más que la optimización y la escala. El equipo no intenta construir un sistema perfectamente optimizado. Construyen algo suficientemente bueno y que pueda iterarse rápido. No buscan atender a todos los clientes. Se enfocan en quienes valoran la velocidad y la innovación. No siguen procesos tradicionales. Adoptan los que permiten iterar rápido. Esta preferencia por la adaptabilidad sobre la optimización es contraintuitiva, pero es la correcta cuando la tecnología subyacente avanza rápido.

La tercera lección es que equipos pequeños y experimentados pueden superar a organizaciones grandes. El equipo de AMP tiene unas ocho personas, todos ingenieros experimentados. Trabajan sin revisiones formales de código ni planificación extensiva. Despliegan 15 veces al día. Usan el producto todo el tiempo. Este equipo pequeño puede moverse más rápido e innovar más que equipos mucho más grandes de otras empresas, porque han eliminado la sobrecarga comunicativa y de procesos que ralentiza a los grandes. Han creado un entorno donde la iteración rápida es posible.

La cuarta lección es que hay que redefinir expectativas cuando el producto cambia radicalmente. Los clientes de Cody tenían expectativas sobre precios, funciones y funcionamiento. Esas expectativas no habrían funcionado para AMP. Al crear AMP como producto y marca independientes, Sourcegraph pudo redefinirlas por completo. Es una estrategia poderosa cuando tu producto es fundamentalmente distinto del anterior. En vez de intentar adaptar nuevas capacidades a un producto viejo, crea uno nuevo y redefine las expectativas.

El panorama competitivo y la dinámica del mercado

El mercado de agentes de codificación con IA se caracteriza por el cambio rápido y el liderazgo inestable. En cada momento hay una herramienta “mejor”, pero esa posición es volátil. Copilot lideró un tiempo. Luego, Cursor tomó la delantera. Ahora hay varios competidores fuertes y la posición está en disputa. Esta inestabilidad la provoca el rápido avance de modelos y técnicas subyacentes. Cuando salió Claude 3.5 Sonnet, habilitó capacidades antes imposibles. Cuando se descubren nuevas técnicas de ingeniería de prompts, pueden incorporarse rápido. Cuando salen modelos nuevos, el panorama competitivo cambia.

En este contexto, triunfan las empresas que se mueven y adaptan rápido. Una empresa optimizada para estabilidad y escala será lenta en incorporar capacidades nuevas. Una empresa optimizada para velocidad e iteración podrá hacerlo rápidamente. Con el tiempo, la empresa rápida se impondrá. Por eso es tan estratégico el enfoque de AMP en la velocidad y la iteración. Al optimizar para la velocidad, AMP se posiciona para seguir en la vanguardia a medida que evoluciona la tecnología.

El mercado también se está especializando cada vez más. En vez de intentar ser la mejor herramienta para todos los desarrolladores, los productos exitosos se enfocan en segmentos específicos. AMP se dirige a quienes quieren moverse rápido y estar en la frontera. Otros productos pueden enfocarse en clientes empresariales que valoran estabilidad y soporte. Otros pueden dirigirse a principiantes que buscan guía y formación. Esta especialización es saludable porque permite a los productos optimizar para su segmento objetivo, en vez de intentar ser todo para todos.

Conclusión

La historia de AMP revela verdades fundamentales sobre cómo competir en mercados que evolucionan rápido. Productos consolidados, aparentemente inamovibles, pueden volverse obsoletos sorprendentemente rápido cuando la tecnología cambia. Las empresas que optimizan para la estabilidad y la escala se vuelven lentas y vulnerables. Las que optimizan para la velocidad y la adaptabilidad pueden moverse lo suficientemente rápido para seguir en la vanguardia. El emperador suele estar desnudo: el producto dominante de hoy puede ser irrelevante mañana si no puede adaptarse al cambio tecnológico. La decisión de Sourcegraph de crear AMP como producto independiente, adoptar prácticas radicales como hacer push a main sin revisiones de código, priorizar la velocidad y la iteración sobre la optimización y la escala, y posicionar el producto en la frontera de la IA, demuestra una comprensión sofisticada de cómo competir en estos mercados. Las lecciones de AMP van mucho más allá de los agentes de codificación: cualquier organización en un mercado de avance tecnológico acelerado debería preguntarse si está optimizando para lo correcto. ¿Optimizas para la estabilidad cuando deberías hacerlo para la adaptabilidad? ¿Intentas servir a todos cuando deberías enfocarte en un segmento específico? ¿Sigues procesos tradicionales cuando deberías adoptar prácticas que permitan iterar rápido? Las respuestas a estas preguntas determinarán si tu organización prospera o queda obsoleta ante el cambio tecnológico.