Más allá de la programación basada en la intuición: mejores prácticas en 2026

En esta entrada, descubrirás las mejores prácticas de programación de IA, los flujos de trabajo y los patrones de ingeniería de agentes que están utilizando equipos reales en 2026.

Introducción

En los últimos ocho meses, me he ido trasladando poco a poco de Tel Aviv a Nueva York. La transición ha merecido la pena, pero no he podido seguir el ritmo frenético de las tendencias semanales en programación de IA.

Y en el mundo de la programación de IA, ocho meses parecen una década.

La última vez que actualicé en serio mi flujo de trabajo fue más o menos en diciembre de 2025. Utilizaba Windsurf con Cascade (que ahora se llama Devin), y me pasé a los los modelos de Claude, y la conclusión clave en aquel momento fue implementar un archivo CLAUDE.md muy concreto: planificar primero, mantener los cambios sencillos, escribir pruebas, ejecutar pruebas y no saltarse el análisis de la causa raíz.

La regla más útil era también la menos glamurosa:

Primero, analiza bien el problema, lee los archivos pertinentes y elabora una lista de comprobación con el plan para tasks/todo.md antes de empezar a programar.

Ese único cambio impulsó enormemente mi desarrollo. Mis sesiones se mantuvieron centradas, las «alucinaciones» con los agentes se redujeron considerablemente y resolví las incidencias mucho más rápido.

Así que quería saber: «¿Qué nuevos superpoderes han surgido en los últimos seis meses?»

Me pasé un día haciendo lo que probablemente hacen ahora la mayoría de los desarrolladores cuando necesitan ponerse al día rápidamente: les pedí a Claude, Grok y ChatGPT que investigaran las últimas tendencias en programación con IA y, a continuación, les hice debatir entre ellos. Pero no buscaba la demostración más reciente. Quería saber qué es lo que realmente se ha consolidado.

A continuación, contrasté los resultados con unas 15 personas en cuyo criterio confío: directores técnicos, fundadores de startups, investigadores en IA, responsables de backend, jefes de equipo e ingenieros sénior que utilizan estas herramientas en bases de código reales.

Esto es lo que he encontrado.

Share the AI coding workflows and practices that have proven useful in production.Me encantaría que me contaras cómo es tu proceso de programación. Por favor, responde en esta publicación de LinkedIn publicación de LinkedIn.

Del «Vibe Coding» a la «ingeniería agentiva»

Cada día aparecen nuevas demostraciones muy llamativas en las redes sociales. «¡Este marco de trabajo multiplicará por diez el rendimiento de tu agente!». «¡Si no estás utilizando esta nueva herramienta, ya te has quedado atrás!». Pero es difícil distinguir lo que es real de lo que es solo publicidad.

«Vibe coding», la expresión Andrej Karpathy popularizó a principios de 2025, ha revolucionado el desarrollo de software: programar describiendo la intención, aceptando los cambios generados y ajustando el modelo hasta que la aplicación funcione. Cuesta creer que alguna vez hiciéramos las cosas de otra manera. El Diccionario Collins la nombró «Palabra del Año 2025». Sin embargo, los equipos de producción serios han separado dos ideas que solían ir de la mano: el uso de la IA para generar código y la aceptación de código generado por la IA sin la estructura ni la verificación suficientes.

Lo primero ha llegado para quedarse. Lo segundo es el problema. Un análisis de CodeRabbit de 470 pull requests reales de GitHub reveló que el código coescrito por IA contenía aproximadamente 1,7 veces más errores que el código escrito por humanos, con vulnerabilidades de seguridad hasta 2,7 veces mayores. El código funciona. Pero requiere un escrutinio mayor que nunca.

Ese es el paso de la programación basada en la intuición a lo que podría denominarse ingeniería agénica. El agente puede inspeccionar archivos, escribir código, ejecutar comandos, generar pruebas, depurar errores y evaluar críticamente su propio resultado. Pero sigue siendo necesario contar con un proceso de ingeniería que lo respalde. Especialmente si te importa la producción.

Lo que hacen realmente los equipos auténticos

El ciclo de expectación de las redes sociales da la impresión de que todo el mundo está actualizando constantemente su flujo de trabajo: procesos basados en especificaciones, con múltiples agentes, orquestados en la nube, conectados a MCP y totalmente autónomos.

Así que pregunté a un grupo reducido pero sólido de amigos con grandes responsabilidades qué estaban haciendo. En su mayoría, hacían algo más sencillo de lo que internet te haría creer: un agente de codificación potente, una fase de planificación, un archivo de instrucciones para el repositorio, pruebas, revisión manual, cambios ocasionales de modelo y, a veces, un segundo modelo para simulacros de ataque.

Un director técnico lo expresó así:

«Planifica siempre primero. Nunca te limites a decir “haz esto”, ni siquiera en el caso de tareas pequeñas, o se les pasarán cosas por alto».

Un jefe de equipo dijo:

«Planifica hasta que todo te parezca perfecto y, después, ponte manos a la obra. Nada de complicaciones».

Además, una ingeniera sénior full-stack describió su enfoque de «confianza cero»:

«Hago que el sistema elabore pruebas y, a continuación, que compruebe sus propias pruebas. Después, recurro a otro agente del equipo rojo. Y, por último, realizo pruebas manuales. Si tiene que ver con el dinero o el ciclo de vida, siempre se hace de forma manual».

Tu tarea principal ahora es planificar

Ha quedado bastante claro que la mayor parte de la responsabilidad del humano consiste ahora en colaborar con el agente para elaborar un plan perfecto. Mi manual tasks/todo.md ahora tiene nombres más sofisticados.

El desarrollo basado en especificaciones es la versión «limpia»: se parte de una intención, se convierte en una especificación, se elabora un plan de implementación, se divide en tareas y, solo entonces, se deja que el agente escriba el código. El Spec Kit de GitHub formalizó este enfoque como spec.md, plan.mdy tasks.md. AWS Kiro utiliza especificaciones como artefactos estructurados para el seguimiento y la rendición de cuentas.

La misma idea se está aplicando en las herramientas. Claude Code cuenta con /goal, que le indicó a Claude que siguiera trabajando hasta que se cumpliera una condición de finalización verificable: que todas las pruebas se superaran, que se resolvieran todos los errores de TypeScript y que la migración estuviera completa. En segundo plano, un modelo evaluador ligero comprueba tras cada iteración si el objetivo se había cumplido objetivamente, de modo que el agente realizaba bucles de forma autónoma hasta que convergiera o alcanzara un límite de presupuesto. Codex incorporó el mismo concepto, con estados como «pursuing», «en pausa», logradoy con un presupuesto limitado que persisten tras reiniciar la sesión.

Esa es la versión comercializada de un tasks/todo.md: un objetivo duradero al que el agente puede volver, ahora con mayor autonomía en torno a él.

También es el lugar donde la autonomía sale cara. Si la condición de finalización es imprecisa, el agente puede permanecer en bucle durante mucho tiempo y seguir sin hacer lo correcto. La autonomía sin medidas de seguridad no es más que una forma más rápida de malgastar dinero.

En el caso de tareas complejas, el agente debe responder a tres preguntas antes de editar el código: ¿Qué estamos cambiando? ¿Qué archivos y comportamientos se ven afectados? ¿Cómo sabremos si ha funcionado?

El desarrollo basado en pruebas (TDD) siempre se ha predicado como si fuera una verdad absoluta, pero se ha puesto en práctica con mucha menos frecuencia. Ahora, con la programación agentica, invertir en pruebas es una de las tareas principales del desarrollador. Un director técnico que fue uno de los primeros en adoptar esta metodología me dijo: «Me paso un buen rato dando vueltas solo para formular el plan. Cada vez que desarrollo una funcionalidad, hago que se escriban pruebas muy exhaustivas. Así sé que funcionará cuando esté terminada».

Si el agente no puede anotarlo, significa que aún no está listo para codificarlo.

AGENTS.md, habilidades y rotación de contexto

Mi antiguo flujo de trabajo se basaba en un gran archivo CLAUDE.md . Lo llené de reglas y frases para dar énfasis: NO SEAS PEREZOSO. NUNCA TE SALTES LAS PRUEBAS. HAZ TODO LO MÁS SENCILLO POSIBLE. La intención era asegurarme de que el agente se mantuviera disciplinado y no tomara atajos.

Y este tipo de orientación dio sus frutos. En 2025, todos los proveedores de agentes contaban con alguna versión de instrucciones a nivel de repositorio: Claude Code, Codex, Cursor, Copilot, Windsurf. El sector comenzó a estandarizarse en torno a AGENTS.md: una guía a nivel de repositorio que indica al agente las reglas básicas del proyecto.

Pero la gente empezó a llenar sus archivos de Claude, y eso tuvo sus consecuencias. Un estudio de la ETH de Zúrich de febrero de 2026 comparó los archivos de instrucciones de los repositorios con incidencias reales de GitHub y descubrió que los archivos de contexto sobrecargados a menudo no mejoraban el éxito de las tareas y podían aumentar el coste de la inferencia en más de un 20 %.

Resulta que el agente no se vuelve más disciplinado por el hecho de que le grites la misma instrucción tres veces. Lo único que consigues, en su mayor parte, es malgastar fichas y ocultar las reglas que realmente importan.

El nuevo modo de fallo es la «rotación de contexto». Un mal AGENTS.md es peor que no tener ningún AGENTS.md , ya que el agente obedecerá con total confianza instrucciones obsoletas.

Así pues, el sector dividió el concepto en dos. AGENTS.md debe mantenerse sencillo. Responde a la pregunta: ¿cuáles son las reglas y convenciones específicas de este proyecto?

Para todo lo demás, están las «Skills». Una «Skill» es una referencia que se carga bajo demanda para una tarea concreta: cómo añadir un nuevo punto final de API, cómo realizar una migración de base de datos o cómo redactar una lista de comprobación para el lanzamiento. La «Skill» solo se carga cuando el agente reconoce el patrón y la necesita.

En la práctica, queda así:

Tu AGENTS.md dice:

Ejecuta las pruebas con npm test. Revisa siempre el código antes de fusionarlo. Utiliza la función «webhook» al añadir nuevas integraciones.

La Skill de webhook dice:

Crea la ruta, añade tipos, escribe el controlador, trata los casos de éxito y de error, y actualiza la documentación.

El agente no tiene por qué ejecutar todos los procedimientos en un contexto de funcionamiento continuo. Estos permanecen en la Skill. Tu AGENTS.md se mantiene breve. Y si cambia el procedimiento del webhook, solo tienes que actualizar la Skill una vez.

La regla general: mantén AGENTS.md breve y sin complicaciones. Crea una Skill cuando tengas un procedimiento repetitivo que te veas obligado a explicar una y otra vez. Y trata las instrucciones del repositorio como si fueran código: revísalas, elimina las reglas obsoletas y no dejes que se echen a perder.

MCP y la CLI

El Protocolo de Contexto de Modelos (MCP) fue probablemente el término que más se puso de moda en el mundo de los desarrolladores en 2025. La idea era sólida: una forma estandarizada de incorporar integraciones en lugar de código de enlace personalizado para cada herramienta.

Así que, por supuesto, en 2026, «el MCP ha muerto». No es cierto. Pero el uso del MCP se ha vuelto más matizado.

Un director técnico al que entrevisté lo expresó sin rodeos:

«Las modelos ya casi no recurren al MCP. Se han vuelto increíblemente buenas utilizando únicamente la CLI».

La cuestión fundamental son los gastos generales. Un servidor MCP estándar puede volcar una gran cantidad de esquemas de herramientas en el contexto antes de que el agente haga nada útil. Las herramientas de la interfaz de línea de comandos (CLI) son locales y combinables, y los modelos ya se adaptan muy bien a los flujos de trabajo al estilo Unix: comandos, opciones, tuberías, salida JSON y registros.

Pero los agentes no descubren las CLI por arte de magia. Necesitan formación, aunque sea más básica.

Si se trata de una CLI conocida como aws, gh, gcloud, o docker, es probable que el agente ya lo sepa gracias al entrenamiento. Puedes indicarle: «Este proyecto utiliza la CLI de AWS. Tienes credenciales. Úsalas para la infraestructura». Y el agente suele encargarse del resto.

Si se trata de una CLI personalizada o interna, crea una Skill. Suele bastar con un párrafo en el que se explique el comando, los parámetros y el formato de la salida.

El debate maduro sobre MCP no es «¿ha muerto MCP?», sino «¿qué permisos acabas de conceder a una herramienta que realiza llamadas probabilísticas?».

El MCP tiene sentido cuando el agente necesita un acceso controlado a sistemas externos: documentos, tickets, observabilidad, bases de datos, API. Pero si una CLI permite realizar la tarea de forma segura, empieza por ahí. Si el mismo procedimiento de CLI se repite, conviértelo en una «Skill». Recurre a MCP cuando ninguna de las dos opciones sea suficiente, y trata cada servidor MCP como si fuera infraestructura de producción: privilegios mínimos, autorizaciones, registro de eventos y revisión de seguridad.

A popular meme highlighting how AI agents have changed the day-to-day experience of software engineering, often shifting the role from implementation toward orchestration and oversight.

Los agentes se están convirtiendo en aviones de control

El cambio más importante que se producirá en 2026 es que los agentes de programación ya no serán simplemente ventanas de chat vinculadas a un editor. Se están convirtiendo en planos de control.

Claude Code tiene /objetivo, hooks, subagentes, sesiones en segundo plano y vistas de agente. Codex cuenta con CLI, nube, aplicación, árboles de trabajo, revisión de código y supervisión móvil. GitHub Copilot puede convertir incidencias en PR y revisar código. Google Antigravity se basa en la gestión de agentes en distintos espacios de trabajo.

La interfaz está pasando de ser un «chat con una modelo» a una «gestión de una cola de trabajadores de confianza relativa».

Suena a ciencia ficción, pero la lección práctica es aburrida: cada agente necesita una tarea clara, un radio de acción reducido, una forma de demostrar que ha funcionado y una persona responsable de la integración.

Aquí es donde los agentes de larga duración resultan útiles.

Imagina que tienes una lista de 30 dependencias que hay que actualizar. Normalmente, tendrías que sentarte con el agente, pedirle información sobre cada una de ellas, revisar cada cambio y aprobar cada fusión. Eso lleva horas y te deja sin tiempo para otras cosas.

Un agente de ejecución prolongada puede ir avanzando por la lista: actualizar una dependencia, ejecutar pruebas, corregir los errores, pasar a la siguiente y detenerse cuando todas las pruebas hayan superado con éxito.

Ese es un buen caso de uso porque «hecho» es objetivamente comprobable.

Ejemplos en los que los agentes de larga duración funcionan realmente: actualizaciones de dependencias, limpieza de pruebas, generación de documentación, ejemplos de SDK, tareas de investigación o elementos del backlog con criterios de aceptación muy claros, como «todas las pruebas superadas», «lint limpio» o «migración completada».

Cuando fallan estrepitosamente: facturación, autenticación, permisos, migraciones, eliminación, cumplimiento normativo o cualquier aspecto relacionado con los datos de los clientes o su ciclo de vida. Estas situaciones requieren tomar decisiones basadas en el criterio propio. «¿Es segura esta migración?» no es una pregunta de sí o no. Tampoco lo es «¿deberíamos eliminar esto?».

La regla: utiliza agentes de ejecución prolongada únicamente para tareas en las que se pueda comprobar objetivamente cuándo están «terminadas» y en las que el alcance de los daños, en caso de fallo, sea reducido. Todo lo demás debe realizarse al ritmo humano.

Si estás ejecutando agentes por tu cuenta, tmux sigue siendo ese truco sencillo que te salva. Los agentes que se ejecutan durante mucho tiempo se cierran cuando se interrumpe la conexión SSH. Un multiplexor de terminales mantiene viva la sesión, resiste las desconexiones y te permite revisar lo que ha ocurrido.

Pero tmux es la solución alternativa «hazlo tú mismo», no la noticia principal. La tendencia real es que las herramientas están convirtiendo este patrón en un producto: sesiones en segundo plano, paneles de control de agentes, árboles de trabajo aislados, aprobaciones remotas y colas de revisión.

Los agentes persistentes que carecen de criterios de éxito verificables no son más que alucinaciones más largas y costosas.

También existe una categoría paralela de entornos de ejecución de agentes personales siempre activos, como OpenClaw y Hermes. Resultan interesantes como planos de control en torno al trabajo de programación: enrutamiento de mensajes, supervisión de sesiones, envío de alertas y, quizá, distribución de tareas. Pero aún no constituyen el núcleo del flujo de trabajo de programación. Merece la pena seguirlos de cerca y experimentar con ellos, pero no hay que pensar que todo el mundo tiene su propio agente OpenClaw. Ninguno de los 15 pioneros a los que pregunté lo había configurado.

La elección del modelo es menos importante

La primera pregunta que me hizo un director de investigación en IA cuando le hablé de mi flujo de trabajo no tuvo que ver con herramientas ni marcos de trabajo. Fue:

«¿Cuál es tu presupuesto para fichas?»

Esto es lo que diferencia la ingeniería de la programación. Es cierto que, con los agentes de IA, si se invierte suficiente dinero y tiempo en un problema, probablemente se pueda resolver. Así que ahora, todas las decisiones sobre los flujos de trabajo dependen en gran medida del presupuesto. Y los distintos agentes influyen en el presupuesto.

Algunas de las personas con las que he hablado apuestan por Codex sin reservas. Otras prefieren Claude. A los usuarios de Cursor les gusta poder cambiar de modelo. Hay quien utiliza Copilot simplemente porque es lo que les proporciona su empresa.

Uno de los fundadores me dijo que con Codex estaba «creando funciones a toda velocidad, como un animal». Otro tenía una opinión más matizada:

«Codex es increíblemente bueno en todo lo relacionado con la informática. Claude sigue teniendo más buen gusto».

Pero el consejo más sensato de un director técnico resultó más útil:

«No te quedes anclado en un modelo. Cada dos semanas, uno se queda obsoleto y otro es mejor».

El patrón duradero es la «higiene de modelos»: utiliza un modelo sólido para la planificación y el razonamiento riguroso, modelos más sencillos para modificaciones directas, un segundo modelo para revisiones de alto riesgo e instrucciones transferibles para que otro modelo u otra sesión pueda retomar el trabajo.

Esto cobra aún más importancia a medida que la tarificación evoluciona hacia la facturación basada en el uso. La estrategia más eficaz no consiste en «utilizar el modelo más sofisticado para todo», sino en saber cuándo merece la pena recurrir a un razonamiento costoso.

La verificación es ahora tu otra tarea principal

Cuando el código se vuelve barato, comprobar que funciona y que es de buena calidad resulta caro. Eso no es un argumento en contra de utilizar la IA para programar. Es un argumento en contra de lanzar código que no se pueda explicar.

Por suerte, las herramientas se están poniendo al día. Los «hooks» son scripts deterministas que se activan ante eventos de los agentes. Permiten a los equipos hacer que una verificación específica no sea opcional. Un PostToolUse puede ejecutar automáticamente un lint o una comprobación de tipos tras cada edición de un archivo, detectando los problemas sobre la marcha en lugar de al final. Un gancho «Stop» puede impedir que el agente declare la victoria prematuramente. Se trata de medidas de seguridad que no dependen del criterio del modelo y, en el caso de trabajos de larga duración o autónomos, esa distinción es importante.

Un buen ciclo de revisión podría ser algo así como:

1. Pide al agente que redacte o actualice las pruebas.

2. Pide al agente que ejecute el conjunto de pruebas correspondiente.

3. Utiliza un segundo modelo para realizar pruebas de ataque (red team) en los cambios importantes.

4. Comprueba manualmente las rutas de alto riesgo.

Una sugerencia útil antes de la revisión humana:

Revisa los cambios que hayas realizado.
Busca posibles errores, pruebas que falten, casos extremos, problemas de seguridad o complejidad innecesaria.
No modifiques los archivos todavía. Informa primero de lo que hayas encontrado.

La versión de seguridad de esto es aún más importante. En cuanto los agentes puedan comentar en las solicitudes de incorporación de cambios (PR), ejecutar flujos de trabajo, utilizar herramientas y acceder a credenciales, la inyección de comandos deja de ser un problema de los chatbots y pasa a ser un problema de CI/CD.

Esa es la parte que, en mi opinión, muchos equipos siguen subestimando. Si el agente lee un problema, la descripción de una solicitud de incorporación de cambios, un comentario en el código o el registro de cambios de una dependencia, está leyendo información no fiable. Si además tiene permiso para ejecutar comandos o acceder a secretos, ya tienes una superficie de ataque.

Por eso, las normas «aburridas» cobran aún más importancia: principio del privilegio mínimo, entornos aislados, autorizaciones, cambios mínimos, comprobaciones determinísticas, registros de Audit y responsabilidad humana.

Si hoy tuviera que crear un nuevo repositorio

1. Crear un AGENTS.md con comandos de instalación, prueba y comprobación de tipos, reglas de flujo de trabajo y una definición de «hecho». Que sea breve. Añade reglas solo cuando el agente falle realmente en algo, no de forma preventiva.

   • El trabajo que no sea trivial requiere una planificación minuciosa. Antes de empezar a programar, el agente elabora una lista de comprobación con el plan para tasks/todo.md con el objetivo, los archivos relevantes, los pasos y los riesgos.

   • Archiva los planos finalizados en tareas/archivo/. Estos planes constituyen el historial de lo que el agente creía que estaba haciendo y por qué.

   • Una tarea por solicitud, una cuestión por cambio. Los cambios pequeños se pueden revisar. Los cambios grandes ocultan errores.

   • No se aprueba ningún cambio de comportamiento sin una prueba. Si el agente dice que «no hace falta ninguna prueba», insístele.

2. Escribe una «Skill» la tercera vez que expliques algo. La primera vez que guíes al agente a través de un procedimiento, limítate a explicárselo. La segunda vez, fíjate en la repetición. La tercera vez, escribe un archivo SKILL.md.

3. Utilizar la CLI de forma predeterminada. Añadir MCP únicamente cuando el agente necesite acceso controlado a un sistema externo y la ruta de la CLI no sea suficiente.

4. Utiliza agentes de ejecución prolongada únicamente para tareas en las que se pueda comprobar objetivamente cuándo están «terminadas». ¿Actualizaciones de dependencias, limpieza de pruebas, documentación, correcciones de lint? Por supuesto. ¿Facturación, autenticación, migraciones, eliminación de datos? No.

5. Analiza las diferencias de alto riesgo del equipo rojo con un segundo modelo. Antes de fusionar cualquier cambio que afecte a la seguridad, los pagos, los permisos o el ciclo de vida de los datos, pide a otro modelo que detecte posibles problemas.

6. Haz lo que te corresponde. Revisa tú mismo los cambios. Ejecuta la aplicación. Prueba manualmente las rutas de riesgo. El agente te propone opciones. Tú decides.

Conclusión

Llevar a cabo esta investigación me tranquilizó. Las mejores prácticas no son más que diferentes versiones de lo que siempre ha sido cierto: seguir los principios SOLID, apostar por el TDD y redactar especificaciones detalladas antes de empezar a desarrollar.

El mejor flujo de trabajo de programación con IA no sustituye a la ingeniería de software. Es ingeniería de software con un desarrollador novato mucho más rápido que nunca se cansa, a veces tiene alucinaciones, de vez en cuando lo estropea todo y necesita instrucciones muy claras.

Si lo tratas así, las herramientas son increíbles. Si lo tratas como si fuera magia, al final tendrás que depurar esa magia.

¿Qué estás usando?

Este es mi primer intento de ponerme al día. Ahora me gustaría saber qué opinan quienes realmente están desarrollando con estas herramientas. ¿Cómo es vuestro flujo de trabajo de programación de IA en este momento?

¿Utilizas Cursor, Claude Code, Codex, Copilot o alguna otra herramienta? ¿Has probado Skills, MCP, subagentes, árboles de trabajo, /goal, hooks o agentes de ejecución prolongada? ¿Qué te ha quedado atascado? ¿Qué has descartado?

Por favor, házmelo saber en esta publicación de LinkedIn.

A LinkedIn post asking developers how their AI coding workflows have evolved in 2026, including questions about planning, guardrails, and emerging agentic practices.Voy a utilizar las mejores respuestas para elaborar una entrada de seguimiento en la que pondré a prueba los flujos de trabajo más importantes en proyectos reales con la API de Vonage: agentes en paralelo, planificación basada en especificaciones y lean AGENTS.md más Skills, MCP frente a CLI y bucles de verificación que detectan errores reales.

Compartiré los resultados en la siguiente entrada.