El hype de codificación de Vibe está terminando, porque hay enormes limitaciones a lo que los grandes modelos de idiomas pueden lograr. A pesar de esto, los agentes de codificación se están volviendo bastante buenos. Pueden girar nuevas páginas frontend, wire up APIs, e incluso construir configuraciones de CI / CD. Pero cualquiera sabe lo inconsistente que son. El mismo prompt puede trabajar una vez y romper la siguiente. Olvidan partes de su base de código, mezclan SDKs deprecados, o simplemente hacen cosas. El problema no es que el modelo sea malo, es que no Aquí está la prueba - Alguien escribió un lenguaje de programación puramente utilizando el agente de codificación. Conozca su contexto https://cursed-lang.org/ Para obtener una salida fiable, no se puede hacer una mejor prompt. el agente trabaja en – moldear sus entradas, darle estructura y establecer los límites correctos. . engineer the environment context engineering Los LLM no piensan como los ingenieros Los LLM no “entenden” el código de la manera que hacemos. predicen tokens basados en patrones en la entrada anterior, no en las construcciones de aplicaciones o la estructura. Así que incluso pequeños cambios en los archivos prompt o circundantes pueden cambiar la salida. Sin estructura, son como los internados que adivinan su pila de la memoria. No puedes arreglar esto gritando al modelo. (Puedo decir, lo intenté) Lo arreglas dándole la derecha - las restricciones y el entorno que lo guían hacia un código válido cada vez. scaffolding Las restricciones hacen que el código sea previsible Si quieres que el agente se comporte de manera coherente, Suelen restringir el espacio de posibles salidas y forzar al modelo a alinearse con su configuración. constraints are your friend Algunas restricciones útiles: Tipos: Si está utilizando esquemas TypeScript o JSON, el agente puede ver exactamente qué formas necesita seguir. Lint + reglas de formato - Prettier, ESLint, o reglas de codegen hacen que la salida sea consistente sin necesidad adicional. Tareas más pequeñas – En lugar de “construirme un backend”, preguntar “Añadir esta ruta a src/api/user.ts”. Configuraciones y plantillas: herramientas como Typeconf y Varlock pueden predefinir variables ambientales, SDK, o cualquier patrón de configuración que el agente debe seguir. El truco es asegurarse de que siempre está escribiendo código con tipos fuertes.No pierde flexibilidad - solo captura errores antes y hace que el comportamiento sea repetible. Construir sistemas como la verdad del suelo Incluso cuando el código se ve bien, a menudo se rompe en el tiempo de construcción porque el agente se equivocó acerca de cómo se conectan las cosas. Por ejemplo: Usted le pide que ejecute pruebas, escribe la prueba npm, pero su repo utiliza pnpm o nx. Trata de construir un Dockerfile que ni siquiera existe en su entorno real. Importa un paquete que ni siquiera está instalado. La fijación es a - dar al agente una imagen clara de cómo se construye, prueba y implementa el código.Piensa en ello como una herramienta de agente adicional para el entorno de tu proyecto. abstract the build system Una vez que el agente sabe lo que significa “construir” en tu mundo, puede usar ese conocimiento en lugar de adivinar. Bazel, Buck, Nx, o incluso un package.json bien estructurado ya son buenos fundamentos. Cuanto más supervisas esta información, menos alucinaciones tratarás. Si quieres ir más lejos puedes escribir tus propios hooks de herramientas para evitar que el agente llame el sistema de construcción incorrecto, consulte la guía Claude Code: . https://docs.claude.com/en/docs/claude-code/hooks-guide El problema de la formación obsoleta La mayoría de los agentes de codificación están capacitados en datos que están un año o dos desactualizados. usarán felices APIs que ya no existen, o patrones de código que todos han abandonado hace siglos. Probablemente hayas visto cosas como: Métodos antiguos del ciclo de vida React Funciones de la biblioteca no existentes Desactivar las APIs de Next.js Comandos NPM para bibliotecas que se han trasladado a nuevas versiones Usted necesita traer su propio contexto: documentos reales, código real, configuraciones reales. Algunas maneras de cerrar la brecha: Alimentación en el documento de la biblioteca, por ejemplo, a través de MCPs como Context7. Deje que el agente lea los archivos de código reales y las dependencias - apunte a leer node_modules, te sorprenderías con qué frecuencia ayudaría a corregir la API. Añade instrucciones personalizadas a AGENTS.md diciendo al modelo para evitar el patrón problemático repetido que está tratando de usar. Cuando el modelo sabe lo que realmente está ahí, deja de alucinar. 5.- Los límites del contexto Un buen agente de codificación no solo lee tu mensaje, sino que lee toda la situación. Puedes pensar en el contexto en tres capas: Static context Estructura del proyecto, diseño de archivos, tipos, configuraciones, comandos de construcción, dependencias. Dynamic context La tarea actual, archivo abierto, mensajes de error, resultados de pruebas, registros de tiempo de ejecución. External context Docs, referencias SDK, changelogs o fragmentos de la web cuando sea necesario. Combine los tres, y el agente comienza a actuar como alguien que está realmente incorporado a su base de código - no un freelancer aleatorio que adivina de la memoria. Ejemplos del mundo real Actualmente estoy construyendo SourceWizard - agente de codificación para la automatización de las integraciones.Cuando empecé a automatizar la integración de WorkOS AuthKit, aquí está la lista no exhaustiva de los problemas que el modelo generó para mí: Comenzó a usar las APIs de deprecado withAuth y getUser; Lógica mixta frontend y backend; (como el uso de useState en componentes del lado del servidor) variables ambientales incorrectas; Instalar el paquete incorrecto. Es obvio que el modelo también golpeó a través de todos los gestores de paquetes, a veces npm, a veces pnpm, lo que era más interesante para el modelo en un momento. Después de haber añadido restricciones, especificado directamente qué debe usar el agente, suministrado con la última API el modelo comenzó a generar el código de integración . consistently La diferencia no está en el modelo, sino en lo que ve. El contexto es la nueva interfaz La mayoría de la gente todavía piensa en los agentes de codificación como los chatbots: da un prompt, obtiene una respuesta. La verdadera magia ocurre en el contexto: los archivos, los tipos, los comandos y los circuitos de retroalimentación a los que el agente puede acceder. En el futuro, no solo “hablaremos” con los agentes de codificación, sino que los conectaremos a nuestros sistemas de construcción.Ellos entenderán nuestro reposo, conocerán nuestras herramientas y seguirán las mismas reglas que cualquier otra parte de la pila. Conclusión Los agentes de codificación fallan no porque sean estúpidos, sino porque estén trabajando ciegamente. Si quieres que sean compañeros de equipo confiables, dales estructura: Limitaciones que definen cómo deben codificarse; Construir abstracciones que muestren cómo funciona su proyecto en realidad; Contexto actualizado para que dejen de usar viejos patrones; Cuanto mejor el contexto, mejor el código. No solo dejas caer a un nuevo ingeniero en tu repo y dices “fijalo”.
