{"id":6297,"date":"2026-08-17T14:56:10","date_gmt":"2026-08-17T12:56:10","guid":{"rendered":"http:\/\/blog-david.moreno-morales.com\/?p=6297"},"modified":"2026-08-17T17:05:55","modified_gmt":"2026-08-17T15:05:55","slug":"desarrollo-de-software-con-ia-que-delegar-a-un-asistente-y-que-debe-seguir-revisando-una-persona","status":"publish","type":"post","link":"http:\/\/blog-david.moreno-morales.com\/index.php\/2026\/08\/17\/desarrollo-de-software-con-ia-que-delegar-a-un-asistente-y-que-debe-seguir-revisando-una-persona\/","title":{"rendered":"Desarrollo de software con IA: qu\u00e9 delegar a un asistente y qu\u00e9 debe seguir revisando una persona"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Los asistentes de programaci\u00f3n han cambiado de escala. Ya no se limitan a completar una l\u00ednea de c\u00f3digo: los agentes actuales pueden explorar un repositorio, modificar varios archivos, ejecutar pruebas y preparar cambios para revisi\u00f3n. OpenAI describe flujos donde Codex trabaja sobre tareas de ingenier\u00eda y propone pull requests; GitHub ofrece agentes capaces de investigar el repositorio, planificar una implementaci\u00f3n y efectuar cambios en una rama.<\/p>\n

La pregunta, por tanto, ya no es si una IA puede escribir c\u00f3digo. La pregunta \u00fatil para un equipo t\u00e9cnico es otra: \u00bfqu\u00e9 trabajo podemos delegarle con suficiente autonom\u00eda y qu\u00e9 decisiones deben continuar bajo responsabilidad humana?<\/p>\n

La respuesta no depende \u00fanicamente de la capacidad del modelo. Depende tambi\u00e9n del impacto del cambio, de lo f\u00e1cil que sea detectarlo y revertirlo, de los permisos concedidos al agente y de la calidad de los controles que rodean al proceso.<\/p>\n

Delegar implementaci\u00f3n no significa delegar responsabilidad<\/h2>\n

Un asistente puede producir c\u00f3digo correcto a primera vista y, aun as\u00ed, introducir un problema de seguridad, mantenibilidad o dise\u00f1o. GitHub advierte expresamente que el c\u00f3digo generado por sus agentes puede ser sint\u00e1cticamente correcto sin ser necesariamente seguro y recomienda aplicar pr\u00e1cticas rigurosas de revisi\u00f3n, pruebas y an\u00e1lisis de vulnerabilidades. Sus buenas pr\u00e1cticas tambi\u00e9n aconsejan evaluar funcionalidad, seguridad, legibilidad y mantenibilidad antes de aceptar una sugerencia.<\/p>\n

Eso establece una distinci\u00f3n importante.<\/p>\n

La IA puede encargarse de generar una implementaci\u00f3n. El equipo contin\u00faa siendo responsable de decidir si esa implementaci\u00f3n debe llegar a producci\u00f3n.<\/strong><\/p>\n

Esa separaci\u00f3n permite utilizar los agentes con mucha m\u00e1s intensidad sin convertirlos en una fuente de cambios sin control.<\/p>\n

Qu\u00e9 tareas son buenas candidatas para delegar<\/h2>\n

Las mejores tareas para un asistente de c\u00f3digo suelen compartir tres propiedades: tienen un alcance claro, poseen criterios objetivos de validaci\u00f3n y son relativamente f\u00e1ciles de revertir.<\/p>\n

1. Boilerplate y c\u00f3digo repetitivo<\/h3>\n

Crear estructuras iniciales, modelos, DTO, adaptadores, serializadores o c\u00f3digo semejante es un buen uso de la IA cuando las convenciones del proyecto est\u00e1n bien documentadas.<\/p>\n

El valor aqu\u00ed no est\u00e1 en que la IA tome decisiones arquitect\u00f3nicas, sino en eliminar trabajo mec\u00e1nico.<\/p>\n

2. Tests a partir de comportamiento conocido<\/h3>\n

Un asistente puede resultar especialmente \u00fatil proponiendo casos de prueba, ampliando cobertura o convirtiendo requisitos concretos en tests.<\/p>\n

Eso s\u00ed: generar el test y validar que el test representa correctamente la regla de negocio son dos problemas diferentes. Un conjunto de pruebas generado autom\u00e1ticamente puede reproducir una interpretaci\u00f3n equivocada del requisito.<\/p>\n

3. Documentaci\u00f3n t\u00e9cnica<\/h3>\n

Explicar una funci\u00f3n, resumir un m\u00f3dulo, documentar una API o preparar notas sobre un cambio son tareas de bajo riesgo siempre que una persona compruebe que la explicaci\u00f3n coincide con el comportamiento real.<\/p>\n

4. Refactorizaciones acotadas<\/h3>\n

Renombrados, extracci\u00f3n de funciones, eliminaci\u00f3n de duplicaci\u00f3n o modernizaci\u00f3n de patrones conocidos pueden delegarse con bastante comodidad cuando existe una buena bater\u00eda de tests.<\/p>\n

El criterio importante es mantener el cambio peque\u00f1o. Cuanto mayor sea el radio de impacto, menos conveniente resulta aceptar autom\u00e1ticamente la propuesta del agente.<\/p>\n

5. Investigaci\u00f3n dentro del c\u00f3digo<\/h3>\n

Los agentes tambi\u00e9n son \u00fatiles para localizar d\u00f3nde se implementa determinada l\u00f3gica, seguir dependencias o identificar posibles puntos de modificaci\u00f3n. De hecho, buena parte de su valor actual est\u00e1 en reducir el coste de comprender un c\u00f3digo base antes de tocarlo.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"proceso\t\t\t\t\t\t\t\t\t\t\t
proceso recomendado para trabajar con asistentes de c\u00f3digo o agentes de IA sin perder control ni seguridad<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"herramienta\t\t\t\t\t\t\t\t\t\t\t
herramienta visual pr\u00e1ctica para decidir cu\u00e1nta autonom\u00eda darle a la IA<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Qu\u00e9 deber\u00eda conservar una revisi\u00f3n humana expl\u00edcita<\/h2>\n

Hay categor\u00edas de cambios donde la IA puede ayudar a analizar alternativas o preparar una primera implementaci\u00f3n, pero no deber\u00eda convertirse en la autoridad final.<\/p>\n

Arquitectura<\/h3>\n

Elegir l\u00edmites entre servicios, introducir una nueva dependencia estructural, decidir c\u00f3mo dividir responsabilidades o establecer una estrategia de datos son decisiones cuyo coste aparece durante meses o a\u00f1os.<\/p>\n

Un agente puede proponer opciones. El equipo debe evaluar las consecuencias.<\/p>\n

La arquitectura contiene contexto organizativo que rara vez est\u00e1 completamente expresado en el repositorio: experiencia del equipo, planes del producto, costes operativos, sistemas heredados, obligaciones contractuales y evoluci\u00f3n prevista.<\/p>\n

Autenticaci\u00f3n, autorizaci\u00f3n y secretos<\/h3>\n

Los cambios en permisos son especialmente sensibles porque un error puede funcionar correctamente desde el punto de vista funcional y seguir creando una vulnerabilidad.<\/p>\n

En este \u00e1mbito conviene mantener revisi\u00f3n humana expl\u00edcita y aplicar el principio de m\u00ednimo privilegio tambi\u00e9n al propio agente. Anthropic, por ejemplo, documenta un modelo de permisos restrictivos por defecto para Claude Code antes de ejecutar acciones adicionales.<\/p>\n

Datos sensibles<\/h3>\n

Cambios relacionados con informaci\u00f3n personal, credenciales, informaci\u00f3n financiera o datos regulados requieren saber no solo si el c\u00f3digo funciona, sino tambi\u00e9n qu\u00e9 datos atraviesan cada sistema, d\u00f3nde se almacenan y qui\u00e9n puede acceder a ellos.<\/p>\n

Ese contexto no deber\u00eda darse por supuesto.<\/p>\n

Migraciones dif\u00edciles de revertir<\/h3>\n

Modificar un esquema de producci\u00f3n, transformar grandes cantidades de informaci\u00f3n o eliminar datos merece un nivel de supervisi\u00f3n mayor que a\u00f1adir una funci\u00f3n aislada.<\/p>\n

Una regla pr\u00e1ctica funciona bien:<\/p>\n

cuanto m\u00e1s dif\u00edcil sea revertir un cambio, menos autonom\u00eda deber\u00eda tener el agente.<\/strong><\/p>\n

Reglas cr\u00edticas de negocio<\/h3>\n

Un descuento, un l\u00edmite de cr\u00e9dito, una condici\u00f3n fiscal, el c\u00e1lculo de una factura o la elegibilidad de un usuario pueden parecer simples funciones.<\/p>\n

Pero el peligro no est\u00e1 necesariamente en escribir mal el c\u00f3digo. Est\u00e1 en implementar perfectamente una interpretaci\u00f3n incorrecta del negocio.<\/p>\n

La nueva superficie de riesgo: agentes con herramientas<\/h2>\n

Existe adem\u00e1s una diferencia fundamental entre un chatbot que sugiere c\u00f3digo y un agente autorizado para ejecutar acciones.<\/p>\n

Cuando el asistente puede leer archivos, ejecutar comandos, acceder a servicios o interactuar con herramientas externas, una instrucci\u00f3n equivocada deja de producir \u00fanicamente una respuesta incorrecta: puede provocar una acci\u00f3n.<\/p>\n

OWASP ha destacado entre los riesgos de los sistemas ag\u00e9nticos el abuso de herramientas y privilegios. Tambi\u00e9n documenta el riesgo de prompt injection<\/em> indirecta, donde instrucciones maliciosas pueden esconderse en contenidos que el agente procesa, incluyendo comentarios de c\u00f3digo, documentaci\u00f3n, mensajes de commits, issues o p\u00e1ginas web.<\/p>\n

Esto cambia el modelo de seguridad.<\/p>\n

No basta con preguntarse: \u00ab\u00bfConf\u00edo en la respuesta del modelo?\u00bb.<\/p>\n

Tambi\u00e9n hay que preguntar:<\/p>\n

    \n
  • \u00bfA qu\u00e9 puede acceder?<\/li>\n
  • \u00bfQu\u00e9 comandos puede ejecutar?<\/li>\n
  • \u00bfQu\u00e9 credenciales tiene disponibles?<\/li>\n
  • \u00bfPuede escribir directamente sobre recursos sensibles?<\/li>\n
  • \u00bfExiste una aprobaci\u00f3n antes de una acci\u00f3n irreversible?<\/li>\n<\/ul>\n

    El dise\u00f1o seguro consiste en limitar las consecuencias posibles de un error<\/strong>, no en asumir que el modelo nunca cometer\u00e1 uno.<\/p>\n

    Un flujo pr\u00e1ctico para trabajar con agentes<\/h2>\n

    Una organizaci\u00f3n no necesita elegir entre prohibir la IA o darle acceso ilimitado. Existe una opci\u00f3n mucho m\u00e1s productiva: dise\u00f1ar distintos niveles de autonom\u00eda.<\/p>\n

    Un flujo razonable puede funcionar as\u00ed:<\/p>\n

    1. Definir una tarea acotada.<\/strong>
    Cuanto mejores sean los criterios de aceptaci\u00f3n, menos espacio queda para una interpretaci\u00f3n inesperada.<\/p>\n

    2. Permitir que el agente investigue y proponga un plan.<\/strong>
    Antes de generar grandes cambios conviene comprobar si ha entendido correctamente el problema.<\/p>\n

    3. Ejecutar en un entorno controlado.<\/strong>
    Permisos m\u00ednimos, credenciales limitadas y aislamiento reducen el impacto de una acci\u00f3n incorrecta.<\/p>\n

    4. Exigir tests autom\u00e1ticos.<\/strong>
    El agente deber\u00eda demostrar el comportamiento de su implementaci\u00f3n, no limitarse a producir c\u00f3digo.<\/p>\n

    5. Revisar el diff.<\/strong>
    La revisi\u00f3n debe centrarse especialmente en los l\u00edmites de confianza: autenticaci\u00f3n, permisos, entrada de usuario, datos, dependencias y efectos laterales.<\/p>\n

    6. Utilizar herramientas autom\u00e1ticas adicionales.<\/strong>
    Linters, an\u00e1lisis est\u00e1tico, esc\u00e1neres de dependencias y pruebas de seguridad siguen siendo relevantes aunque el c\u00f3digo haya sido generado o revisado por IA.<\/p>\n

    7. Mantener aprobaci\u00f3n humana antes del merge en cambios de riesgo relevante.<\/strong><\/p>\n

    Los propios flujos modernos de desarrollo con agentes mantienen esa idea de revisi\u00f3n e iteraci\u00f3n. OpenAI ha descrito procesos internos donde los agentes revisan cambios, reciben feedback y vuelven a iterar antes de completar un PR.<\/p>\n

    Una matriz sencilla: impacto y reversibilidad<\/h2>\n

    No todas las empresas necesitan una pol\u00edtica compleja para empezar. Dos preguntas proporcionan un criterio sorprendentemente \u00fatil:<\/p>\n

    \u00bfQu\u00e9 impacto tendr\u00eda un error?<\/strong>
    \u00bfQu\u00e9 tan f\u00e1cil ser\u00eda revertirlo?<\/strong><\/p>\n

    Un cambio de bajo impacto y f\u00e1cilmente reversible puede concederse al agente con bastante autonom\u00eda.<\/p>\n

    Un cambio de alto impacto y dif\u00edcil reversi\u00f3n deber\u00eda exigir planificaci\u00f3n, revisi\u00f3n humana y controles adicionales.<\/p>\n

    Entre ambos extremos existen diferentes niveles de supervisi\u00f3n.<\/p>\n

    Esta matriz evita una pol\u00edtica demasiado simplista de \u00abc\u00f3digo humano\u00bb frente a \u00abc\u00f3digo de IA\u00bb. Lo importante no es qui\u00e9n escribi\u00f3 cada car\u00e1cter, sino qu\u00e9 riesgo introduce el cambio y qu\u00e9 evidencias tenemos de que es correcto.<\/p>\n

    La habilidad que cambia: revisar sistemas, no solo escribir c\u00f3digo<\/h2>\n

    A medida que aumenta la capacidad de los agentes, parte del trabajo del desarrollador pasa de producir cada l\u00ednea manualmente a definir restricciones, proporcionar contexto, revisar propuestas y validar resultados.<\/p>\n

    Eso no elimina la ingenier\u00eda. Cambia d\u00f3nde se concentra.<\/p>\n

    El desarrollador que utiliza bien estos sistemas necesita comprender arquitectura, pruebas, seguridad y dominio precisamente porque debe evaluar una producci\u00f3n de c\u00f3digo cada vez m\u00e1s r\u00e1pida.<\/p>\n

    La productividad real no consiste en generar m\u00e1s l\u00edneas.<\/p>\n

    Consiste en reducir el tiempo necesario para llevar una soluci\u00f3n correcta y mantenible hasta producci\u00f3n sin aumentar el riesgo en la misma proporci\u00f3n<\/strong>.<\/p>\n

    Y ah\u00ed est\u00e1 probablemente la regla m\u00e1s importante del desarrollo de software con IA:<\/p>\n

    delega ejecuci\u00f3n cuando puedas verificarla; conserva el criterio humano all\u00ed donde un error sea costoso, ambiguo o dif\u00edcil de revertir.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

    Buenas pr\u00e1cticas para usar asistentes de c\u00f3digo sin comprometer arquitectura, seguridad ni mantenibilidad.<\/p>\n","protected":false},"author":1,"featured_media":6469,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[38],"tags":[50,47,49,48],"class_list":["post-6297","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software","tag-agentes","tag-desarrollo","tag-ia","tag-software"],"_links":{"self":[{"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6297","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/comments?post=6297"}],"version-history":[{"count":16,"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6297\/revisions"}],"predecessor-version":[{"id":6475,"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6297\/revisions\/6475"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media\/6469"}],"wp:attachment":[{"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media?parent=6297"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/categories?post=6297"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/tags?post=6297"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}