https://www.knightli.com/es/tags/software-engineering/ Recent content in Software Engineering on KnightLi Blog Hugo -- gohugo.io es Fri, 15 May 2026 08:46:23 +0800 https://www.knightli.com/es/2026/05/15/matt-pocock-skills-ai-engineering-workflow/ Fri, 15 May 2026 08:46:23 +0800 https://www.knightli.com/es/2026/05/15/matt-pocock-skills-ai-engineering-workflow/ <p>Cuanto más rápido escribe código la IA, más rápido puede perder el control un proyecto. La cuestión real no es si un modelo puede generar funciones, sino si entiende el requisito, respeta el lenguaje del equipo y avanza con cambios pequeños dentro de la arquitectura existente.</p> <p>El repositorio <code>mattpocock/skills</code> de Matt Pocock apunta en la dirección opuesta al vibe coding: no dejar que la IA tome todo el proceso de desarrollo, sino ponerla dentro de restricciones maduras de ingeniería de software.</p> <p>Proyecto: <a class="link" href="https://github.com/mattpocock/skills" target="_blank" rel="noopener" >https://github.com/mattpocock/skills</a></p> <p>No se trata de un prompt mágico. Es un conjunto de agent skills que convierten aclaración de requisitos, modelado de dominio, TDD, diagnóstico y revisión arquitectónica en workflows adecuados para herramientas de AI Coding.</p> <h2 id="primero-resolver-la-falta-de-alineación">Primero resolver la falta de alineación </h2><p>El fallo más común en AI Coding es creer que el modelo entendió cuando en realidad solo adivinó a partir de una descripción vaga.</p> <p><code>grill-me</code> invierte la interacción. Antes de escribir código, el agente actúa como un revisor exigente y pregunta por ramas, límites y decisiones pendientes.</p> <p>Si pides una página de login, debería preguntar primero:</p> <ul> <li>Cómo funcionará recuperar contraseña.</li> <li>Si habrá login de terceros.</li> <li>Qué error mostrar cuando falle el login.</li> <li>Si bloqueo de cuenta, CAPTCHA o control de riesgo están dentro del alcance.</li> <li>A dónde redirigir tras el éxito.</li> </ul> <p>Parece más lento, pero reduce retrabajo. Cuanto más barato es generar código, más caro se vuelve no haber aclarado el requisito.</p> <h2 id="escribir-el-lenguaje-de-dominio-en-el-contexto">Escribir el lenguaje de dominio en el contexto </h2><p>Otro problema es el vocabulario genérico. El modelo no conoce los términos internos del equipo, así que los nombres de variables, funciones y documentos empiezan a desviarse.</p> <p><code>grill-with-docs</code> pregunta mientras revisa <code>CONTEXT.md</code>, ADRs o documentos de dominio. Los términos y decisiones confirmados pueden volver a esos documentos.</p> <p>Esto se parece al lenguaje ubicuo de DDD. Si el equipo dice customer en lugar de user, o transaction en lugar de order, la IA debe heredar esa terminología.</p> <p>El valor del contexto no está en acumular datos, sino en reducir la necesidad de adivinar.</p> <h2 id="usar-tdd-para-limitar-la-velocidad">Usar TDD para limitar la velocidad </h2><p>La IA es peligrosa porque es rápida. Antes, escribir mucho mal código tomaba tiempo; ahora aparecen cientos de líneas en segundos. El problema no es la velocidad, sino la falta de ciclos de feedback.</p> <p>El skill <code>tdd</code> devuelve el ciclo rojo-verde-refactor:</p> <ol> <li>Escribir un test fallido para un comportamiento.</li> <li>Implementar lo mínimo para pasarlo.</li> <li>Refactorizar.</li> <li>Continuar con el siguiente corte vertical.</li> </ol> <p>La clave es avanzar comportamiento por comportamiento. La IA ejecuta; la persona controla dirección y límites.</p> <h2 id="diagnosticar-con-un-ciclo">Diagnosticar con un ciclo </h2><p>Ante un bug, muchos agentes adivinan y parchean varias veces hasta empeorar el código.</p> <p><code>diagnose</code> exige crear primero un ciclo de feedback:</p> <ul> <li>Reproducir el problema</li> <li>Minimizar el caso</li> <li>Formular una hipótesis</li> <li>Añadir observación o logs</li> <li>Corregir</li> <li>Añadir una prueba de regresión</li> </ul> <p>Es un proceso clásico, pero en AI Coding es aún más importante. La IA prueba rápido; el proceso la mantiene cerca de la causa raíz.</p> <h2 id="revisar-la-arquitectura-con-regularidad">Revisar la arquitectura con regularidad </h2><p>Que una tarea pase no significa que el código esté mejor. Muchas pequeñas modificaciones de IA pueden difuminar límites de módulos, complicar interfaces y hacer más difíciles los tests.</p> <p>Skills como <code>improve-codebase-architecture</code> hacen que el agente mire el código desde más arriba:</p> <ul> <li>Qué módulos mezclan responsabilidades.</li> <li>Qué interfaces son demasiado complejas.</li> <li>Qué rutas son difíciles de probar.</li> <li>Qué nombres no encajan con el lenguaje de dominio.</li> <li>Qué duplicaciones conviene consolidar.</li> </ul> <p>No es una gran refactorización automática. Es observación estructurada y dirección de mejora; la decisión sigue siendo humana.</p> <h2 id="lo-que-hay-que-limitar-es-la-libertad">Lo que hay que limitar es la libertad </h2><p>La idea central es sencilla: programar con IA no consiste en dejar improvisar al modelo, sino en darle objetivos, contexto, tests y condiciones de parada.</p> <p>Las personas definen el problema, los límites de arquitectura, las decisiones de negocio y los criterios de aceptación. La IA genera código, completa tests, repite cambios y hace refactors locales.</p> <p>Los fundamentos de ingeniería de software no quedaron obsoletos porque la IA mejoró. Aclarar requisitos, usar lenguaje de dominio, TDD, diagnóstico y revisión de arquitectura es cada vez más importante.</p> <p>Cada vez más personas podrán escribir código. La diferencia estará en quién puede insertar la IA en un sistema de ingeniería mantenible, verificable y capaz de evolucionar.</p>