Una publicación del GitHub Blog analiza cinco hipótesis populares sobre el uso de la inteligencia artificial en el desarrollo de software, entre ellas que el código generado no necesita leerse, que RAG ha llegado a su fin y que Skills ha sustituido a Model Context Protocol (MCP). El autor considera que el valor de estas afirmaciones no reside en su veracidad tal como se formulan de manera resumida, sino en descomponer sus condiciones y límites al aplicarlas al trabajo real.
La responsabilidad del código no se transfiere al modelo
La regla fundamental que plantea el artículo es que el desarrollador debe revisar el código hasta el punto en que pueda explicar el resultado y asumir su responsabilidad. Esto no significa examinar cada línea con la misma profundidad; un cambio en un sistema de autenticación de producción merece una revisión diferente de la de un experimento sencillo en CSS.
La revisión puede comenzar antes de que el agente escriba código alguno, mediante la comprensión de la implementación actual, la identificación de las dependencias y los casos límite, y la elaboración de un plan. En otros casos, el código resultante necesita una auditoría directa de la gestión de errores, los permisos, el acceso a los datos, el rendimiento, la accesibilidad y las pruebas. Según el artículo, la inteligencia artificial cambia dónde se concentra el esfuerzo, pero no elimina el trabajo en sí.
La habilidad más importante es el buen criterio
La publicación rechaza la idea de que las empresas no contratarán a quienes no utilicen la inteligencia artificial en absoluto, pero reconoce que un número creciente de equipos pregunta a los candidatos cómo utilizan estas herramientas. La señal más importante, según el planteamiento, no es el entusiasmo por la herramienta en sí, sino la capacidad de explicar cuándo la utiliza el desarrollador y cuándo trabaja manualmente, cómo revisa sus resultados y cómo equilibra la velocidad, la calidad, la seguridad y la mantenibilidad.
Evitar la inteligencia artificial puede convertirse en un obstáculo en una empresa que desarrolla sus productos o depende de ella intensivamente, pero depender completamente de ella no es una solución mejor. Lo necesario es mantener al ser humano dentro del circuito y contar con una explicación clara de aquello en lo que el desarrollador confía y aquello en lo que no.
MCP, Skills y RAG desempeñan funciones complementarias
El artículo establece una distinción entre las tres herramientas. MCP proporciona un método estandarizado para que los agentes accedan a herramientas y datos y los invoquen, mientras que Skills ofrece conocimiento empaquetado sobre la forma de trabajo del equipo, las reglas para modificar el proyecto o las convenciones utilizadas. Como Skills suele escribirse en formato Markdown, su legibilidad para las personas forma parte de su utilidad.
Por su parte, RAG, o generación aumentada mediante recuperación, incorpora al sistema información relevante externa a los datos de entrenamiento del modelo, como documentación, registros de soporte, detalles de productos, conocimiento interno y contexto de la base de código. Una buena recuperación ayuda al modelo a comenzar a trabajar desde un contexto más cercano a la respuesta, reduciendo el espacio de búsqueda y la posibilidad de ofrecer una respuesta incompleta.
Por ello, el autor no considera que Skills haya acabado con MCP ni que RAG haya muerto; el agente puede utilizar MCP para acceder a una herramienta, seguir una Skill para aplicar instrucciones específicas del proyecto y recurrir a la recuperación para obtener el contexto de apoyo. El conflicto entre estos componentes ignora la manera en que pueden integrarse en un único flujo de trabajo.
La mantenibilidad se enfrenta a una nueva prueba
La publicación también analiza la idea de que la necesidad de entrenar el modelo con una base de código concreta significa necesariamente que el código es malo. Existen razones legítimas para el entrenamiento personalizado, pero la incapacidad del modelo para comprender la base de código puede revelar un problema que también enfrentaría un nuevo compañero.
Una arquitectura clara, una nomenclatura coherente, pruebas legibles, abstracciones útiles y documentación actualizada hacen que el código sea más fácil de comprender tanto para los agentes como para las personas. La lectura editorial aquí es que las herramientas de inteligencia artificial no eximen a los equipos de las prácticas de ingeniería de software; más bien, pueden hacer más visibles las deficiencias de mantenibilidad.
Del debate al experimento
El artículo concluye invitando a probar las opiniones en la práctica en lugar de sustituir cada opinión por la contraria. Cita el proyecto Pollinations AI, en el que los colaboradores pueden ganar créditos llamados pollen mediante la mejora del proyecto, y el proyecto Avian Visitors, que documenta una pantalla de tinta electrónica que escucha a los pájaros y convierte sus visitas en paneles cambiantes utilizando un micrófono, una Raspberry Pi, componentes impresos en 3D e imágenes generadas.
Estos proyectos no resuelven todos los debates sobre la inteligencia artificial, pero producen pruebas y ponen de manifiesto las compensaciones. La principal limitación del material es que ofrece un marco orientativo general y ejemplos, no resultados de mediciones comparativas que demuestren la superioridad de un flujo de trabajo concreto. Por ello, sus recomendaciones deben tratarse como puntos de prueba para la práctica, no como reglas definitivas.