{"content_id":"zuag1vtnf2","slug":"ai-native-developer-definition-and-practices","locale":"es","schema_type":"TechArticle","category":"ai_data","category_name":"Datos de IA","title":"Qué es un desarrollador nativo de IA: rol, capacidades y estructura operativa de agentes","summary":"Un desarrollador nativo de IA diseña sistemas para que la IA realice tareas de implementación, mientras se encarga de definir los problemas, establecer restricciones, verificar la calidad y asumir la responsabilidad final. Este artículo explica, desde una perspectiva práctica, la documentación, el arnés de agentes, el proceso de adopción en equipos, las métricas de rendimiento y los principios de seguridad.","author":{"name":"Equipo editorial de Injoys","url":"https://injoys.com/ko/about"},"key_points":["La clave del desarrollo nativo de IA no está en la habilidad para crear prompts, sino en diseñar sistemas capaces de delegar tareas y verificar los resultados.","Aunque la IA genere código rápidamente, la definición de problemas, el criterio de producto, las decisiones de arquitectura, la revisión de seguridad y la responsabilidad no se resuelven automáticamente.","Proporcionar especificaciones, restricciones, esquemas y registros de decisiones como documentación gestionada facilita que los agentes trabajen en un contexto coherente.","Las etapas Plan, Draft y Review pueden implementarse incluso con un solo agente; se debe optar por múltiples agentes cuando las ventajas de la separación superen los costes y la complejidad.","El éxito de la adopción en equipos debe evaluarse mediante el tiempo de finalización de las tareas, la tasa de defectos, la tasa de retrabajo, los costes y la carga de revisión humana, no por la cantidad de código generado."],"content_markdown":"Un desarrollador nativo de IA no es simplemente alguien que utiliza con destreza herramientas como ChatGPT, Claude Code o GitHub Copilot. Con mayor precisión, puede definirse como **un desarrollador que diseña el contexto, las herramientas, los permisos y los criterios de evaluación para que la IA realice tareas ejecutables, mientras la persona se encarga de establecer los objetivos, verificar, aprobar y asumir la responsabilidad**.\n\nSin embargo, «desarrollador nativo de IA» no es una certificación oficial ni un cargo profesional estandarizado sobre el que exista consenso en todo el sector. Dado que el alcance de la automatización también varía según el nivel de riesgo de la organización y del producto, no debe equipararse con una situación en la que todas las decisiones se delegan en la IA.\n\n## Definición de desarrollador nativo de IA\n\nEl desarrollo nativo de IA consiste en tratar la IA no como una herramienta complementaria de autocompletado de código, sino como una **capa de ejecución del desarrollo**. La persona estructura lo que debe hacerse y establece las condiciones de éxito y las prohibiciones, mientras que la IA realiza tareas de exploración, redacción, ejecución y modificación dentro del ámbito permitido.\n\nLas funciones principales se dividen de la siguiente manera.\n\n- **Persona:** definición del problema, prioridades, restricciones, clasificación del riesgo, criterios de aprobación y responsabilidad final\n- **Agente de IA:** búsqueda de información, borrador del plan, creación de código y pruebas, análisis estático y modificaciones iterativas\n- **Arnés:** documentación, herramientas, permisos, gestión del estado, pruebas, registros, límite de costes y condiciones de interrupción\n\nPor agente de IA se entiende generalmente un sistema en el que un modelo de lenguaje utiliza herramientas y elige la siguiente acción en función de los resultados intermedios. A diferencia de un flujo de trabajo que sigue procedimientos predefinidos, un agente puede decidir dinámicamente el orden de las tareas dentro del ámbito permitido.\n\n| Categoría | Desarrollo asistido por IA | Desarrollo nativo de IA |\n|---|---|---|\n| Posición de la IA | Herramienta de autocompletado de código o de preguntas y respuestas | Parte de la capa de ejecución del trabajo |\n| Entrada | Centrada en prompts breves | Especificaciones, contexto del repositorio, restricciones y criterios de evaluación |\n| Función de la persona | Implementación directa con ayuda posterior de la IA | Diseño del problema, juicio sobre excepciones, verificación y aprobación |\n| Control de calidad | Depende de la comprobación manual del desarrollador | Incluye pruebas, evaluadores y reglas de revisión en el arnés |\n| Forma de operación | Depende de la manera de trabajar de cada persona | Se gestiona mediante procesos y políticas de equipo reproducibles |\n\nUn principio importante es que **las tareas pueden delegarse, pero la responsabilidad no**. La IA puede tomar decisiones operativas de bajo riesgo, pero las decisiones de gran impacto relacionadas con la seguridad, los datos personales, los pagos, la medicina, el ámbito jurídico o los cambios en producción requieren una aprobación humana más estricta.\n\n## Nivelación de la programación y nuevos factores de diferenciación de los desarrolladores\n\nLa IA generativa reduce las barreras de entrada a implementaciones repetitivas, como escribir código repetitivo, buscar ejemplos de uso de API, crear borradores de pruebas o proponer refactorizaciones. Produce cierto efecto de nivelación, ya que incluso los desarrolladores con poca experiencia pueden crear borradores funcionales con mayor rapidez que antes.\n\nSin embargo, no es correcto afirmar categóricamente que «la brecha de habilidades de programación ha desaparecido». Para evaluar los resultados creados por la IA, siguen siendo necesarios los siguientes conocimientos.\n\n1. Capacidad para detectar si los requisitos son contradictorios o están incompletos\n2. Capacidad para diseñar los límites del sistema y los flujos de datos\n3. Capacidad para valorar los compromisos entre rendimiento, seguridad, costes y mantenibilidad\n4. Capacidad para identificar implementaciones plausibles pero incorrectas\n5. Capacidad para rastrear la causa y recuperarse cuando se produce un fallo\n\nLas competencias que marcan una mayor diferencia en la era de la IA son las siguientes.\n\n- **Definición del problema:** concretar el problema que experimenta realmente el usuario y las condiciones de éxito.\n- **Criterio de producto y UX:** valorar el flujo de uso, la comprensibilidad, la accesibilidad y la confianza, más allá de la mera existencia de una función.\n- **Capacidad de descomposición:** dividir un objetivo grande en tareas pequeñas y verificables.\n- **Diseño de la evaluación:** crear primero las pruebas, listas de comprobación, tablas de puntuación y criterios de aprobación.\n- **Diseño del contexto:** organizar la documentación y el repositorio para que la IA encuentre con precisión solo la información necesaria.\n- **Evaluación del riesgo:** distinguir entre las tareas que pueden automatizarse y las que requieren aprobación humana.\n\nEn definitiva, cuanto mayor sea la velocidad de implementación, más valiosa será la capacidad de decidir «qué crear y por qué» y «si el resultado es suficientemente bueno».\n\n## Diseño de documentos Markdown y documentos de referencia\n\nLos agentes no conocen automáticamente el conocimiento implícito de una organización. Si los requisitos y las restricciones están dispersos entre conversaciones, reuniones, comentarios del código y recuerdos individuales, aumenta la probabilidad de que repitan las mismas preguntas o trabajen con supuestos diferentes.\n\nMarkdown es útil como formato de documentación práctica porque permite gestionar fácilmente el historial de cambios en Git y es relativamente sencillo tanto para la lectura humana como para el procesamiento por parte de la IA. Sin embargo, más importante que el propio formato del archivo es **establecer con claridad qué documento constituye la referencia más reciente**.\n\n### Información que debe incluirse en la referencia\n\n- Objetivos del producto, objetivos excluidos y escenarios de usuario\n- Requisitos funcionales y criterios de aceptación verificables\n- Estructura del repositorio y responsabilidades de cada módulo\n- Contratos de API, modelos de datos y reglas de migración\n- Reglas de programación, comandos de prueba y procedimiento de despliegue\n- Registro de decisiones arquitectónicas y motivos de los cambios\n- Permisos de acceso, acciones prohibidas y condiciones de aprobación humana\n- Limitaciones conocidas, procedimientos de respuesta ante fallos y responsables\n\nEn una GitHub Issue se pueden registrar el contexto de la tarea, el alcance, los criterios de aceptación, los documentos relacionados y la definición de finalización. Resulta adecuado mantener la arquitectura a largo plazo y las reglas operativas en documentos con control de versiones, como un directorio `docs`, y hacer referencia a esos documentos desde la Issue.\n\n### Ejemplo de especificación de una tarea\n\n```markdown\n# Objetivo\nMejorar el mensaje de error de inicio de sesión para que el usuario pueda saber cómo recuperarse.\n\n# Alcance\n- Pantalla web de inicio de sesión\n- Mensajes en coreano e inglés\n\n# Fuera del alcance\n- Cambios en el método de autenticación\n- Cambios en la política de contraseñas\n\n# Criterios de aceptación\n- No se revela externamente si una cuenta existe o no.\n- Supera la comprobación de accesibilidad y las pruebas de autenticación existentes.\n- En caso de fallo, es posible volver al comportamiento original.\n\n# Comandos de verificación\n- npm test\n- npm run lint\n```\n\nUna documentación bien organizada puede reducir la necesidad de que el agente lea toda la base de código cada vez. No obstante, esto no implica necesariamente una reducción de tokens o costes. Si la documentación está duplicada o desactualizada, puede provocar aún más búsquedas y modificaciones incorrectas. También deben establecerse responsables de la documentación, momentos de actualización y reglas de verificación automática.\n\nLas contraseñas, las claves de API, los datos reales de clientes y los permisos excesivos de bases de datos no deben registrarse en la documentación. Los ejemplos de esquemas deben anonimizarse y la información secreta debe gestionarse en un almacén seguro independiente.\n\n## Estructura mínima de un arnés para agentes de IA\n\nLa ingeniería de arneses consiste en diseñar los mecanismos de ejecución que rodean al modelo. Esto incluye instrucciones del sistema, conexión de herramientas, búsqueda de contexto, permisos, memoria, pruebas, observabilidad, reintentos y condiciones de interrupción.\n\nEl bucle mínimo de ejecución puede constar de Plan, Draft y Review.\n\n| Etapa | Pregunta principal | Resultado | Tratamiento en caso de fallo |\n|---|---|---|---|\n| Plan | ¿Es necesaria esta tarea y cuáles son su alcance y sus riesgos? | Plan, elementos que cambiar y método de verificación | Solicitud de información adicional o interrupción de la tarea |\n| Draft | ¿Se ha implementado el plan en la unidad segura más pequeña posible? | Código, pruebas y cambios en la documentación | Modificación durante un número limitado de intentos |\n| Review | ¿Cumple los requisitos y los criterios de calidad? | Resultados de la evaluación, lista de defectos y propuesta de aprobación | Reelaboración o derivación a una persona |\n\nUn arnés real necesita los siguientes mecanismos de control.\n\n- Archivos, comandos, redes y ámbitos de datos permitidos\n- Tiempo máximo de ejecución, número de llamadas a herramientas y límite de costes\n- Condiciones de interrupción cuando fallen las pruebas o exista un alto grado de incertidumbre\n- Registros de todas las entradas, llamadas a herramientas, cambios y aprobaciones\n- Etapa de aprobación humana antes de aplicar cambios en producción\n- Procedimiento de rollback para volver al estado original\n\n### Agente único y múltiples agentes\n\nPlan, Draft y Review no requieren necesariamente tres modelos o agentes independientes. Un solo agente también puede llevar a cabo estas etapas mediante instrucciones y herramientas específicas para cada una.\n\nEn una estructura de múltiples agentes, las funciones pueden separarse de la siguiente manera.\n\n- **Planner:** analiza los requisitos y examina la necesidad, el alcance y los riesgos de la función.\n- **Generator:** crea código, pruebas y documentación conforme al plan.\n- **Evaluator:** inspecciona los resultados según criterios independientes y presenta defectos y mejoras.\n \nLa separación de funciones puede facilitar la crítica independiente y la exploración en paralelo. Por otro lado, también complica los costes de las llamadas, la latencia, la sincronización del estado y el rastreo de las causas de los errores. Para las tareas sencillas, un script determinista o un agente único pueden ser más estables, y los múltiples agentes deben adoptarse cuando las mejoras medidas justifiquen la complejidad.\n\n## Procedimiento de adopción en equipos y empresas\n\nUn anuncio sobre la adopción de la IA y la formación por sí solos no convierten a una organización en nativa de IA. También deben establecerse el ámbito permitido, las políticas de datos, los criterios de calidad y la estructura de responsabilidades.\n\n### Etapa 1: establecimiento de la línea de base y las políticas\n\n- Medir el tiempo actual de trabajo, la tasa de defectos, el tiempo de espera de las revisiones y la frecuencia de despliegue.\n- Determinar qué datos no pueden introducirse y qué herramientas pueden utilizarse.\n- Distinguir las tareas que pueden ejecutarse automáticamente de las que requieren aprobación humana.\n\n### Etapa 2: champion y piloto limitado\n\nSe designa en el equipo a un champion que tenga experiencia en el uso de IA y capacidad de formación. El champion no actúa como promotor de herramientas, sino que se encarga de organizar casos de uso reproducibles, casos de fallo y normas de seguridad.\n\nEs más seguro comenzar el piloto con tareas cuyos resultados sean fáciles de verificar, como la generación de pruebas, la organización de documentación interna o las refactorizaciones de bajo riesgo.\n\n### Etapa 3: estandarización de patrones exitosos\n\n- Registrar prioritariamente los documentos de entrada y los criterios de evaluación, en lugar de los prompts que hayan resultado eficaces.\n- Crear plantillas comunes de Issue y una definición de finalización.\n- Automatizar las pruebas, el lint, las comprobaciones de seguridad y los procedimientos de revisión.\n- Documentar las causas de los fallos y los puntos de intervención humana.\n\n### Etapa 4: operación y expansión\n\nEl ámbito de aplicación se amplía cuando los resultados del piloto mejoran respecto a la línea de base. La selección de herramientas, la formación, la gestión de costes, los permisos de acceso, la respuesta ante incidentes y las evaluaciones periódicas deben conectarse en un único sistema operativo.\n\n## Indicadores para medir el rendimiento\n\nEl número de líneas de código generadas o la cantidad de usos de la IA no reflejan directamente la productividad ni la calidad. También deben medirse indicadores centrados en los resultados, como los siguientes.\n\n| Área | Indicador recomendado | Precauciones al interpretarlo |\n|---|---|---|\n| Velocidad | Tiempo desde el inicio de la tarea hasta el despliegue | Incluir también el tiempo de revisión y reelaboración. |\n| Calidad | Tasa de defectos después del despliegue, tasa de fallos de pruebas | Separar las tareas fáciles de las difíciles. |\n| Eficiencia | Coste del modelo por tarea, número de llamadas a herramientas | No excluir el coste de la revisión humana. |\n| Estabilidad | Tasa de rollback, alertas de seguridad, infracciones de permisos | Considerar también la posibilidad de problemas no detectados. |\n| Adopción | Proporción de equipos que lo utilizan repetidamente, trabajo real completado | Distinguirlo de un simple inicio de sesión o del número de llamadas. |\n| Experiencia | Satisfacción de los desarrolladores, carga cognitiva, fatiga por revisiones | La fatiga puede aumentar aunque mejore la velocidad. |\n\nLos resultados del grupo que utiliza IA y los del método convencional deben compararse en el mismo tipo de tareas, y es necesario observar no solo la velocidad a corto plazo, sino también los costes de mantenimiento y los fallos.\n\n## Riesgos de seguridad y calidad\n\nDado que los agentes de IA pueden leer código, ejecutar comandos y obtener contenido externo, tienen una superficie de ataque más amplia que un chat convencional.\n\nLos principales riesgos son los siguientes.\n\n- Inyección de prompts que hace que el agente siga instrucciones ocultas en documentos del repositorio o páginas externas\n- Concesión de permisos excesivos sobre archivos, bases de datos o despliegues\n- Código incorrecto que utiliza API o paquetes inexistentes\n- Introducción de dependencias vulnerables o código con licencias poco claras\n- Acciones que debilitan los propios criterios de verificación para superar las pruebas\n- Transmisión externa de datos de clientes, claves secretas y código interno\n- Incrementos inesperados de los costes debido a ejecuciones repetidas\n\nLos principios de respuesta son el privilegio mínimo, un entorno de ejecución aislado, listas de elementos permitidos, separación de la información secreta, pruebas independientes, registros de cambios y aprobación humana. En particular, si la implementación de un agente se evalúa únicamente con las pruebas creadas por ese mismo agente, pueden pasarse por alto errores comunes, por lo que conviene mantener las pruebas de regresión existentes y criterios de revisión independientes.\n\n## Cómo evitar una reacción excesiva ante las herramientas\n\nSiguen apareciendo nuevos modelos, plugins y frameworks de agentes, pero no es necesario aprender todas las herramientas. Deben evaluarse mediante las siguientes preguntas, en lugar de hacerlo por su nombre o popularidad.\n\n1. ¿Está claramente definida la tarea repetitiva que se intenta resolver actualmente?\n2. ¿Puede conectarse de forma segura con el entorno de desarrollo y el sistema de permisos existentes?\n3. ¿Puede verificarse la calidad del resultado de forma automática o manual?\n4. ¿Pueden observarse los costes, la latencia y la tasa de fallos?\n5. Aunque se sustituya la herramienta, ¿se conservan las especificaciones, las pruebas y la documentación?\n\nCompletar una mejora real del producto con una herramienta adecuada para el equipo y medir sus resultados tiene más valor que aprender superficialmente a utilizar varias herramientas.\n\n## Lista de comprobación práctica para desarrolladores nativos de IA\n\n- [ ] Documentar los objetivos, los objetivos excluidos y los criterios de aceptación antes de la implementación.\n- [ ] Minimizar las herramientas y el ámbito de acceso que utilizará la IA.\n- [ ] Dividir las tareas grandes en unidades que puedan verificarse de forma independiente.\n- [ ] Exigir pruebas, documentación y un método de rollback junto con el código.\n- [ ] Hacer que una persona revise el diff y los resultados de ejecución de los cambios importantes.\n- [ ] Registrar los fallos, los reintentos, los costes y las intervenciones humanas.\n- [ ] Medir si la automatización ha mejorado realmente la calidad y el tiempo de finalización.\n- [ ] Permitir que el agente rechace o derive tareas de poco valor o de alto riesgo.\n\n## Conclusión\n\nLa competitividad de un desarrollador nativo de IA no procede de un prompt concreto ni del nombre de una herramienta. Procede de **la capacidad de definir el problema con precisión, crear un entorno en el que el agente pueda actuar de forma segura, evaluar la calidad de los resultados y asumir la responsabilidad por ellos**.\n\nLa IA puede crear rápidamente gran parte de una implementación, pero no garantiza automáticamente una dirección correcta del producto, la experiencia del usuario, la seguridad del sistema ni la responsabilidad final. Por tanto, los desarrolladores no deben abandonar la programación, sino ampliar su función, basándose en sus conocimientos de programación, hacia las especificaciones, la evaluación, las decisiones de producto y la operación de sistemas.","content_html":"\u003cp\u003eUn desarrollador nativo de IA no es simplemente alguien que utiliza con destreza herramientas como ChatGPT, Claude Code o GitHub Copilot. Con mayor precisión, puede definirse como \u003cstrong\u003eun desarrollador que diseña el contexto, las herramientas, los permisos y los criterios de evaluación para que la IA realice tareas ejecutables, mientras la persona se encarga de establecer los objetivos, verificar, aprobar y asumir la responsabilidad\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eSin embargo, «desarrollador nativo de IA» no es una certificación oficial ni un cargo profesional estandarizado sobre el que exista consenso en todo el sector. Dado que el alcance de la automatización también varía según el nivel de riesgo de la organización y del producto, no debe equipararse con una situación en la que todas las decisiones se delegan en la IA.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#definici%C3%B3n-de-desarrollador-nativo-de-ia\" class=\"anchor\" id=\"definición-de-desarrollador-nativo-de-ia\"\u003e\u003c/a\u003eDefinición de desarrollador nativo de IA\u003c/h2\u003e\n\u003cp\u003eEl desarrollo nativo de IA consiste en tratar la IA no como una herramienta complementaria de autocompletado de código, sino como una \u003cstrong\u003ecapa de ejecución del desarrollo\u003c/strong\u003e. La persona estructura lo que debe hacerse y establece las condiciones de éxito y las prohibiciones, mientras que la IA realiza tareas de exploración, redacción, ejecución y modificación dentro del ámbito permitido.\u003c/p\u003e\n\u003cp\u003eLas funciones principales se dividen de la siguiente manera.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003ePersona:\u003c/strong\u003e definición del problema, prioridades, restricciones, clasificación del riesgo, criterios de aprobación y responsabilidad final\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAgente de IA:\u003c/strong\u003e búsqueda de información, borrador del plan, creación de código y pruebas, análisis estático y modificaciones iterativas\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eArnés:\u003c/strong\u003e documentación, herramientas, permisos, gestión del estado, pruebas, registros, límite de costes y condiciones de interrupción\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003ePor agente de IA se entiende generalmente un sistema en el que un modelo de lenguaje utiliza herramientas y elige la siguiente acción en función de los resultados intermedios. A diferencia de un flujo de trabajo que sigue procedimientos predefinidos, un agente puede decidir dinámicamente el orden de las tareas dentro del ámbito permitido.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategoría\u003c/th\u003e\n\u003cth\u003eDesarrollo asistido por IA\u003c/th\u003e\n\u003cth\u003eDesarrollo nativo de IA\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoría\"\u003ePosición de la IA\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo asistido por IA\"\u003eHerramienta de autocompletado de código o de preguntas y respuestas\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo nativo de IA\"\u003eParte de la capa de ejecución del trabajo\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoría\"\u003eEntrada\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo asistido por IA\"\u003eCentrada en prompts breves\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo nativo de IA\"\u003eEspecificaciones, contexto del repositorio, restricciones y criterios de evaluación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoría\"\u003eFunción de la persona\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo asistido por IA\"\u003eImplementación directa con ayuda posterior de la IA\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo nativo de IA\"\u003eDiseño del problema, juicio sobre excepciones, verificación y aprobación\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoría\"\u003eControl de calidad\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo asistido por IA\"\u003eDepende de la comprobación manual del desarrollador\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo nativo de IA\"\u003eIncluye pruebas, evaluadores y reglas de revisión en el arnés\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Categoría\"\u003eForma de operación\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo asistido por IA\"\u003eDepende de la manera de trabajar de cada persona\u003c/td\u003e\n\u003ctd data-label=\"Desarrollo nativo de IA\"\u003eSe gestiona mediante procesos y políticas de equipo reproducibles\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eUn principio importante es que \u003cstrong\u003elas tareas pueden delegarse, pero la responsabilidad no\u003c/strong\u003e. La IA puede tomar decisiones operativas de bajo riesgo, pero las decisiones de gran impacto relacionadas con la seguridad, los datos personales, los pagos, la medicina, el ámbito jurídico o los cambios en producción requieren una aprobación humana más estricta.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#nivelaci%C3%B3n-de-la-programaci%C3%B3n-y-nuevos-factores-de-diferenciaci%C3%B3n-de-los-desarrolladores\" class=\"anchor\" id=\"nivelación-de-la-programación-y-nuevos-factores-de-diferenciación-de-los-desarrolladores\"\u003e\u003c/a\u003eNivelación de la programación y nuevos factores de diferenciación de los desarrolladores\u003c/h2\u003e\n\u003cp\u003eLa IA generativa reduce las barreras de entrada a implementaciones repetitivas, como escribir código repetitivo, buscar ejemplos de uso de API, crear borradores de pruebas o proponer refactorizaciones. Produce cierto efecto de nivelación, ya que incluso los desarrolladores con poca experiencia pueden crear borradores funcionales con mayor rapidez que antes.\u003c/p\u003e\n\u003cp\u003eSin embargo, no es correcto afirmar categóricamente que «la brecha de habilidades de programación ha desaparecido». Para evaluar los resultados creados por la IA, siguen siendo necesarios los siguientes conocimientos.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eCapacidad para detectar si los requisitos son contradictorios o están incompletos\u003c/li\u003e\n\u003cli\u003eCapacidad para diseñar los límites del sistema y los flujos de datos\u003c/li\u003e\n\u003cli\u003eCapacidad para valorar los compromisos entre rendimiento, seguridad, costes y mantenibilidad\u003c/li\u003e\n\u003cli\u003eCapacidad para identificar implementaciones plausibles pero incorrectas\u003c/li\u003e\n\u003cli\u003eCapacidad para rastrear la causa y recuperarse cuando se produce un fallo\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eLas competencias que marcan una mayor diferencia en la era de la IA son las siguientes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eDefinición del problema:\u003c/strong\u003e concretar el problema que experimenta realmente el usuario y las condiciones de éxito.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCriterio de producto y UX:\u003c/strong\u003e valorar el flujo de uso, la comprensibilidad, la accesibilidad y la confianza, más allá de la mera existencia de una función.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eCapacidad de descomposición:\u003c/strong\u003e dividir un objetivo grande en tareas pequeñas y verificables.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eDiseño de la evaluación:\u003c/strong\u003e crear primero las pruebas, listas de comprobación, tablas de puntuación y criterios de aprobación.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eDiseño del contexto:\u003c/strong\u003e organizar la documentación y el repositorio para que la IA encuentre con precisión solo la información necesaria.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEvaluación del riesgo:\u003c/strong\u003e distinguir entre las tareas que pueden automatizarse y las que requieren aprobación humana.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEn definitiva, cuanto mayor sea la velocidad de implementación, más valiosa será la capacidad de decidir «qué crear y por qué» y «si el resultado es suficientemente bueno».\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#dise%C3%B1o-de-documentos-markdown-y-documentos-de-referencia\" class=\"anchor\" id=\"diseño-de-documentos-markdown-y-documentos-de-referencia\"\u003e\u003c/a\u003eDiseño de documentos Markdown y documentos de referencia\u003c/h2\u003e\n\u003cp\u003eLos agentes no conocen automáticamente el conocimiento implícito de una organización. Si los requisitos y las restricciones están dispersos entre conversaciones, reuniones, comentarios del código y recuerdos individuales, aumenta la probabilidad de que repitan las mismas preguntas o trabajen con supuestos diferentes.\u003c/p\u003e\n\u003cp\u003eMarkdown es útil como formato de documentación práctica porque permite gestionar fácilmente el historial de cambios en Git y es relativamente sencillo tanto para la lectura humana como para el procesamiento por parte de la IA. Sin embargo, más importante que el propio formato del archivo es \u003cstrong\u003eestablecer con claridad qué documento constituye la referencia más reciente\u003c/strong\u003e.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#informaci%C3%B3n-que-debe-incluirse-en-la-referencia\" class=\"anchor\" id=\"información-que-debe-incluirse-en-la-referencia\"\u003e\u003c/a\u003eInformación que debe incluirse en la referencia\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eObjetivos del producto, objetivos excluidos y escenarios de usuario\u003c/li\u003e\n\u003cli\u003eRequisitos funcionales y criterios de aceptación verificables\u003c/li\u003e\n\u003cli\u003eEstructura del repositorio y responsabilidades de cada módulo\u003c/li\u003e\n\u003cli\u003eContratos de API, modelos de datos y reglas de migración\u003c/li\u003e\n\u003cli\u003eReglas de programación, comandos de prueba y procedimiento de despliegue\u003c/li\u003e\n\u003cli\u003eRegistro de decisiones arquitectónicas y motivos de los cambios\u003c/li\u003e\n\u003cli\u003ePermisos de acceso, acciones prohibidas y condiciones de aprobación humana\u003c/li\u003e\n\u003cli\u003eLimitaciones conocidas, procedimientos de respuesta ante fallos y responsables\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEn una GitHub Issue se pueden registrar el contexto de la tarea, el alcance, los criterios de aceptación, los documentos relacionados y la definición de finalización. Resulta adecuado mantener la arquitectura a largo plazo y las reglas operativas en documentos con control de versiones, como un directorio \u003ccode\u003edocs\u003c/code\u003e, y hacer referencia a esos documentos desde la Issue.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#ejemplo-de-especificaci%C3%B3n-de-una-tarea\" class=\"anchor\" id=\"ejemplo-de-especificación-de-una-tarea\"\u003e\u003c/a\u003eEjemplo de especificación de una tarea\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e# Objetivo\n\u003c/span\u003e\u003cspan\u003eMejorar el mensaje de error de inicio de sesión para que el usuario pueda saber cómo recuperarse.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Alcance\n\u003c/span\u003e\u003cspan\u003e- Pantalla web de inicio de sesión\n\u003c/span\u003e\u003cspan\u003e- Mensajes en coreano e inglés\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Fuera del alcance\n\u003c/span\u003e\u003cspan\u003e- Cambios en el método de autenticación\n\u003c/span\u003e\u003cspan\u003e- Cambios en la política de contraseñas\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Criterios de aceptación\n\u003c/span\u003e\u003cspan\u003e- No se revela externamente si una cuenta existe o no.\n\u003c/span\u003e\u003cspan\u003e- Supera la comprobación de accesibilidad y las pruebas de autenticación existentes.\n\u003c/span\u003e\u003cspan\u003e- En caso de fallo, es posible volver al comportamiento original.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Comandos de verificación\n\u003c/span\u003e\u003cspan\u003e- npm test\n\u003c/span\u003e\u003cspan\u003e- npm run lint\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eUna documentación bien organizada puede reducir la necesidad de que el agente lea toda la base de código cada vez. No obstante, esto no implica necesariamente una reducción de tokens o costes. Si la documentación está duplicada o desactualizada, puede provocar aún más búsquedas y modificaciones incorrectas. También deben establecerse responsables de la documentación, momentos de actualización y reglas de verificación automática.\u003c/p\u003e\n\u003cp\u003eLas contraseñas, las claves de API, los datos reales de clientes y los permisos excesivos de bases de datos no deben registrarse en la documentación. Los ejemplos de esquemas deben anonimizarse y la información secreta debe gestionarse en un almacén seguro independiente.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#estructura-m%C3%ADnima-de-un-arn%C3%A9s-para-agentes-de-ia\" class=\"anchor\" id=\"estructura-mínima-de-un-arnés-para-agentes-de-ia\"\u003e\u003c/a\u003eEstructura mínima de un arnés para agentes de IA\u003c/h2\u003e\n\u003cp\u003eLa ingeniería de arneses consiste en diseñar los mecanismos de ejecución que rodean al modelo. Esto incluye instrucciones del sistema, conexión de herramientas, búsqueda de contexto, permisos, memoria, pruebas, observabilidad, reintentos y condiciones de interrupción.\u003c/p\u003e\n\u003cp\u003eEl bucle mínimo de ejecución puede constar de Plan, Draft y Review.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEtapa\u003c/th\u003e\n\u003cth\u003ePregunta principal\u003c/th\u003e\n\u003cth\u003eResultado\u003c/th\u003e\n\u003cth\u003eTratamiento en caso de fallo\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Etapa\"\u003ePlan\u003c/td\u003e\n\u003ctd data-label=\"Pregunta principal\"\u003e¿Es necesaria esta tarea y cuáles son su alcance y sus riesgos?\u003c/td\u003e\n\u003ctd data-label=\"Resultado\"\u003ePlan, elementos que cambiar y método de verificación\u003c/td\u003e\n\u003ctd data-label=\"Tratamiento en caso de fallo\"\u003eSolicitud de información adicional o interrupción de la tarea\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Etapa\"\u003eDraft\u003c/td\u003e\n\u003ctd data-label=\"Pregunta principal\"\u003e¿Se ha implementado el plan en la unidad segura más pequeña posible?\u003c/td\u003e\n\u003ctd data-label=\"Resultado\"\u003eCódigo, pruebas y cambios en la documentación\u003c/td\u003e\n\u003ctd data-label=\"Tratamiento en caso de fallo\"\u003eModificación durante un número limitado de intentos\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Etapa\"\u003eReview\u003c/td\u003e\n\u003ctd data-label=\"Pregunta principal\"\u003e¿Cumple los requisitos y los criterios de calidad?\u003c/td\u003e\n\u003ctd data-label=\"Resultado\"\u003eResultados de la evaluación, lista de defectos y propuesta de aprobación\u003c/td\u003e\n\u003ctd data-label=\"Tratamiento en caso de fallo\"\u003eReelaboración o derivación a una persona\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eUn arnés real necesita los siguientes mecanismos de control.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eArchivos, comandos, redes y ámbitos de datos permitidos\u003c/li\u003e\n\u003cli\u003eTiempo máximo de ejecución, número de llamadas a herramientas y límite de costes\u003c/li\u003e\n\u003cli\u003eCondiciones de interrupción cuando fallen las pruebas o exista un alto grado de incertidumbre\u003c/li\u003e\n\u003cli\u003eRegistros de todas las entradas, llamadas a herramientas, cambios y aprobaciones\u003c/li\u003e\n\u003cli\u003eEtapa de aprobación humana antes de aplicar cambios en producción\u003c/li\u003e\n\u003cli\u003eProcedimiento de rollback para volver al estado original\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#agente-%C3%BAnico-y-m%C3%BAltiples-agentes\" class=\"anchor\" id=\"agente-único-y-múltiples-agentes\"\u003e\u003c/a\u003eAgente único y múltiples agentes\u003c/h3\u003e\n\u003cp\u003ePlan, Draft y Review no requieren necesariamente tres modelos o agentes independientes. Un solo agente también puede llevar a cabo estas etapas mediante instrucciones y herramientas específicas para cada una.\u003c/p\u003e\n\u003cp\u003eEn una estructura de múltiples agentes, las funciones pueden separarse de la siguiente manera.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003ePlanner:\u003c/strong\u003e analiza los requisitos y examina la necesidad, el alcance y los riesgos de la función.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eGenerator:\u003c/strong\u003e crea código, pruebas y documentación conforme al plan.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEvaluator:\u003c/strong\u003e inspecciona los resultados según criterios independientes y presenta defectos y mejoras.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eLa separación de funciones puede facilitar la crítica independiente y la exploración en paralelo. Por otro lado, también complica los costes de las llamadas, la latencia, la sincronización del estado y el rastreo de las causas de los errores. Para las tareas sencillas, un script determinista o un agente único pueden ser más estables, y los múltiples agentes deben adoptarse cuando las mejoras medidas justifiquen la complejidad.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#procedimiento-de-adopci%C3%B3n-en-equipos-y-empresas\" class=\"anchor\" id=\"procedimiento-de-adopción-en-equipos-y-empresas\"\u003e\u003c/a\u003eProcedimiento de adopción en equipos y empresas\u003c/h2\u003e\n\u003cp\u003eUn anuncio sobre la adopción de la IA y la formación por sí solos no convierten a una organización en nativa de IA. También deben establecerse el ámbito permitido, las políticas de datos, los criterios de calidad y la estructura de responsabilidades.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-1-establecimiento-de-la-l%C3%ADnea-de-base-y-las-pol%C3%ADticas\" class=\"anchor\" id=\"etapa-1-establecimiento-de-la-línea-de-base-y-las-políticas\"\u003e\u003c/a\u003eEtapa 1: establecimiento de la línea de base y las políticas\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eMedir el tiempo actual de trabajo, la tasa de defectos, el tiempo de espera de las revisiones y la frecuencia de despliegue.\u003c/li\u003e\n\u003cli\u003eDeterminar qué datos no pueden introducirse y qué herramientas pueden utilizarse.\u003c/li\u003e\n\u003cli\u003eDistinguir las tareas que pueden ejecutarse automáticamente de las que requieren aprobación humana.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-2-champion-y-piloto-limitado\" class=\"anchor\" id=\"etapa-2-champion-y-piloto-limitado\"\u003e\u003c/a\u003eEtapa 2: champion y piloto limitado\u003c/h3\u003e\n\u003cp\u003eSe designa en el equipo a un champion que tenga experiencia en el uso de IA y capacidad de formación. El champion no actúa como promotor de herramientas, sino que se encarga de organizar casos de uso reproducibles, casos de fallo y normas de seguridad.\u003c/p\u003e\n\u003cp\u003eEs más seguro comenzar el piloto con tareas cuyos resultados sean fáciles de verificar, como la generación de pruebas, la organización de documentación interna o las refactorizaciones de bajo riesgo.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-3-estandarizaci%C3%B3n-de-patrones-exitosos\" class=\"anchor\" id=\"etapa-3-estandarización-de-patrones-exitosos\"\u003e\u003c/a\u003eEtapa 3: estandarización de patrones exitosos\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eRegistrar prioritariamente los documentos de entrada y los criterios de evaluación, en lugar de los prompts que hayan resultado eficaces.\u003c/li\u003e\n\u003cli\u003eCrear plantillas comunes de Issue y una definición de finalización.\u003c/li\u003e\n\u003cli\u003eAutomatizar las pruebas, el lint, las comprobaciones de seguridad y los procedimientos de revisión.\u003c/li\u003e\n\u003cli\u003eDocumentar las causas de los fallos y los puntos de intervención humana.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#etapa-4-operaci%C3%B3n-y-expansi%C3%B3n\" class=\"anchor\" id=\"etapa-4-operación-y-expansión\"\u003e\u003c/a\u003eEtapa 4: operación y expansión\u003c/h3\u003e\n\u003cp\u003eEl ámbito de aplicación se amplía cuando los resultados del piloto mejoran respecto a la línea de base. La selección de herramientas, la formación, la gestión de costes, los permisos de acceso, la respuesta ante incidentes y las evaluaciones periódicas deben conectarse en un único sistema operativo.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#indicadores-para-medir-el-rendimiento\" class=\"anchor\" id=\"indicadores-para-medir-el-rendimiento\"\u003e\u003c/a\u003eIndicadores para medir el rendimiento\u003c/h2\u003e\n\u003cp\u003eEl número de líneas de código generadas o la cantidad de usos de la IA no reflejan directamente la productividad ni la calidad. También deben medirse indicadores centrados en los resultados, como los siguientes.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eÁrea\u003c/th\u003e\n\u003cth\u003eIndicador recomendado\u003c/th\u003e\n\u003cth\u003ePrecauciones al interpretarlo\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eVelocidad\u003c/td\u003e\n\u003ctd data-label=\"Indicador recomendado\"\u003eTiempo desde el inicio de la tarea hasta el despliegue\u003c/td\u003e\n\u003ctd data-label=\"Precauciones al interpretarlo\"\u003eIncluir también el tiempo de revisión y reelaboración.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eCalidad\u003c/td\u003e\n\u003ctd data-label=\"Indicador recomendado\"\u003eTasa de defectos después del despliegue, tasa de fallos de pruebas\u003c/td\u003e\n\u003ctd data-label=\"Precauciones al interpretarlo\"\u003eSeparar las tareas fáciles de las difíciles.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eEficiencia\u003c/td\u003e\n\u003ctd data-label=\"Indicador recomendado\"\u003eCoste del modelo por tarea, número de llamadas a herramientas\u003c/td\u003e\n\u003ctd data-label=\"Precauciones al interpretarlo\"\u003eNo excluir el coste de la revisión humana.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eEstabilidad\u003c/td\u003e\n\u003ctd data-label=\"Indicador recomendado\"\u003eTasa de rollback, alertas de seguridad, infracciones de permisos\u003c/td\u003e\n\u003ctd data-label=\"Precauciones al interpretarlo\"\u003eConsiderar también la posibilidad de problemas no detectados.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eAdopción\u003c/td\u003e\n\u003ctd data-label=\"Indicador recomendado\"\u003eProporción de equipos que lo utilizan repetidamente, trabajo real completado\u003c/td\u003e\n\u003ctd data-label=\"Precauciones al interpretarlo\"\u003eDistinguirlo de un simple inicio de sesión o del número de llamadas.\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Área\"\u003eExperiencia\u003c/td\u003e\n\u003ctd data-label=\"Indicador recomendado\"\u003eSatisfacción de los desarrolladores, carga cognitiva, fatiga por revisiones\u003c/td\u003e\n\u003ctd data-label=\"Precauciones al interpretarlo\"\u003eLa fatiga puede aumentar aunque mejore la velocidad.\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eLos resultados del grupo que utiliza IA y los del método convencional deben compararse en el mismo tipo de tareas, y es necesario observar no solo la velocidad a corto plazo, sino también los costes de mantenimiento y los fallos.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#riesgos-de-seguridad-y-calidad\" class=\"anchor\" id=\"riesgos-de-seguridad-y-calidad\"\u003e\u003c/a\u003eRiesgos de seguridad y calidad\u003c/h2\u003e\n\u003cp\u003eDado que los agentes de IA pueden leer código, ejecutar comandos y obtener contenido externo, tienen una superficie de ataque más amplia que un chat convencional.\u003c/p\u003e\n\u003cp\u003eLos principales riesgos son los siguientes.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eInyección de prompts que hace que el agente siga instrucciones ocultas en documentos del repositorio o páginas externas\u003c/li\u003e\n\u003cli\u003eConcesión de permisos excesivos sobre archivos, bases de datos o despliegues\u003c/li\u003e\n\u003cli\u003eCódigo incorrecto que utiliza API o paquetes inexistentes\u003c/li\u003e\n\u003cli\u003eIntroducción de dependencias vulnerables o código con licencias poco claras\u003c/li\u003e\n\u003cli\u003eAcciones que debilitan los propios criterios de verificación para superar las pruebas\u003c/li\u003e\n\u003cli\u003eTransmisión externa de datos de clientes, claves secretas y código interno\u003c/li\u003e\n\u003cli\u003eIncrementos inesperados de los costes debido a ejecuciones repetidas\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eLos principios de respuesta son el privilegio mínimo, un entorno de ejecución aislado, listas de elementos permitidos, separación de la información secreta, pruebas independientes, registros de cambios y aprobación humana. En particular, si la implementación de un agente se evalúa únicamente con las pruebas creadas por ese mismo agente, pueden pasarse por alto errores comunes, por lo que conviene mantener las pruebas de regresión existentes y criterios de revisión independientes.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#c%C3%B3mo-evitar-una-reacci%C3%B3n-excesiva-ante-las-herramientas\" class=\"anchor\" id=\"cómo-evitar-una-reacción-excesiva-ante-las-herramientas\"\u003e\u003c/a\u003eCómo evitar una reacción excesiva ante las herramientas\u003c/h2\u003e\n\u003cp\u003eSiguen apareciendo nuevos modelos, plugins y frameworks de agentes, pero no es necesario aprender todas las herramientas. Deben evaluarse mediante las siguientes preguntas, en lugar de hacerlo por su nombre o popularidad.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e¿Está claramente definida la tarea repetitiva que se intenta resolver actualmente?\u003c/li\u003e\n\u003cli\u003e¿Puede conectarse de forma segura con el entorno de desarrollo y el sistema de permisos existentes?\u003c/li\u003e\n\u003cli\u003e¿Puede verificarse la calidad del resultado de forma automática o manual?\u003c/li\u003e\n\u003cli\u003e¿Pueden observarse los costes, la latencia y la tasa de fallos?\u003c/li\u003e\n\u003cli\u003eAunque se sustituya la herramienta, ¿se conservan las especificaciones, las pruebas y la documentación?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eCompletar una mejora real del producto con una herramienta adecuada para el equipo y medir sus resultados tiene más valor que aprender superficialmente a utilizar varias herramientas.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#lista-de-comprobaci%C3%B3n-pr%C3%A1ctica-para-desarrolladores-nativos-de-ia\" class=\"anchor\" id=\"lista-de-comprobación-práctica-para-desarrolladores-nativos-de-ia\"\u003e\u003c/a\u003eLista de comprobación práctica para desarrolladores nativos de IA\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e Documentar los objetivos, los objetivos excluidos y los criterios de aceptación antes de la implementación.\u003c/li\u003e\n\u003cli\u003e Minimizar las herramientas y el ámbito de acceso que utilizará la IA.\u003c/li\u003e\n\u003cli\u003e Dividir las tareas grandes en unidades que puedan verificarse de forma independiente.\u003c/li\u003e\n\u003cli\u003e Exigir pruebas, documentación y un método de rollback junto con el código.\u003c/li\u003e\n\u003cli\u003e Hacer que una persona revise el diff y los resultados de ejecución de los cambios importantes.\u003c/li\u003e\n\u003cli\u003e Registrar los fallos, los reintentos, los costes y las intervenciones humanas.\u003c/li\u003e\n\u003cli\u003e Medir si la automatización ha mejorado realmente la calidad y el tiempo de finalización.\u003c/li\u003e\n\u003cli\u003e Permitir que el agente rechace o derive tareas de poco valor o de alto riesgo.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclusi%C3%B3n\" class=\"anchor\" id=\"conclusión\"\u003e\u003c/a\u003eConclusión\u003c/h2\u003e\n\u003cp\u003eLa competitividad de un desarrollador nativo de IA no procede de un prompt concreto ni del nombre de una herramienta. Procede de \u003cstrong\u003ela capacidad de definir el problema con precisión, crear un entorno en el que el agente pueda actuar de forma segura, evaluar la calidad de los resultados y asumir la responsabilidad por ellos\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eLa IA puede crear rápidamente gran parte de una implementación, pero no garantiza automáticamente una dirección correcta del producto, la experiencia del usuario, la seguridad del sistema ni la responsabilidad final. Por tanto, los desarrolladores no deben abandonar la programación, sino ampliar su función, basándose en sus conocimientos de programación, hacia las especificaciones, la evaluación, las decisiones de producto y la operación de sistemas.\u003c/p\u003e\n","tags":["Ingeniería de harness","Agentes de IA","Nativo de IA","Desarrollo de software","Documentación"],"faqs":[{"question":"¿Un desarrollador nativo de IA es lo mismo que un ingeniero de prompts?","answer":"No es lo mismo. La redacción de prompts es solo una de las habilidades; un desarrollador nativo de IA se ocupa de todo el sistema de ejecución, incluida la descomposición de problemas, el suministro de contexto, el diseño de herramientas y permisos, las pruebas, la observación, la aprobación y las operaciones."},{"question":"¿Los desarrolladores nativos de IA no programan directamente?","answer":"No necesariamente. Aunque puede reducirse la proporción de código que escriben directamente, se necesitan sólidos conocimientos de desarrollo para entender y depurar el código generado por la IA y evaluar problemas de arquitectura, rendimiento y seguridad."},{"question":"¿Se pueden dejar todas las decisiones en manos de un agente de IA?","answer":"No. Las decisiones limitadas y de bajo riesgo pueden automatizarse, pero las decisiones de gran impacto, como la eliminación de datos, los pagos, los permisos de seguridad y el despliegue en producción, requieren una aprobación humana explícita y procedimientos de recuperación."},{"question":"¿Plan, Draft y Review requieren necesariamente tres agentes?","answer":"No. Un solo agente o un flujo de trabajo determinista también puede ejecutar las tres etapas. Los sistemas multiagente son adecuados cuando los beneficios de la evaluación independiente o la exploración paralela superan los costes adicionales y la complejidad operativa."},{"question":"¿Los documentos en Markdown siempre reducen el coste de tokens?","answer":"No siempre. Los documentos breves, estructurados y actualizados pueden reducir la exploración innecesaria, pero los documentos duplicados u obsoletos provocan tareas incorrectas y exploraciones adicionales. También es necesario establecer la responsabilidad de actualizar la documentación y los procedimientos de verificación."},{"question":"¿Por dónde se debe empezar la transición hacia un enfoque nativo de IA?","answer":"Tras medir la referencia del rendimiento actual, conviene elegir una tarea fácil de verificar, como la generación de pruebas, la organización de la documentación o una refactorización de bajo riesgo. Se debe ampliar su uso después de comprobar la calidad, el tiempo de finalización, el coste y la carga de revisión en un proyecto piloto limitado."},{"question":"¿La IA ha igualado por completo las habilidades de programación?","answer":"La IA reduce las barreras de entrada para la implementación repetitiva y la elaboración de borradores, pero no elimina las diferencias en las capacidades de desarrollo. La capacidad para analizar requisitos, diseñar la arquitectura, depurar, abordar la seguridad y el rendimiento y verificar los resultados sigue teniendo un gran impacto en la calidad."},{"question":"¿Es necesario aprender a usar varias herramientas de desarrollo con IA para ser competitivo?","answer":"La cantidad de herramientas no constituye por sí misma una ventaja competitiva. Es mejor elegir primero una herramienta que permita completar de forma fiable una tarea real y medir la calidad y el coste. Si las especificaciones y las pruebas se gestionan sin depender de una herramienta concreta, también será más fácil sustituirla más adelante."},{"question":"¿Cómo se mide el rendimiento de un equipo de desarrollo nativo de IA?","answer":"En lugar de centrarse en la cantidad de código generado, se deben medir conjuntamente el tiempo de finalización de las tareas, los defectos posteriores al despliegue, el retrabajo, las reversiones, el coste de los modelos, el tiempo de revisión y la fatiga de los desarrolladores. Para poder interpretar los resultados, deben compararse con la referencia previa a la adopción y con tipos de tareas similares."}],"sources":[{"url":"https://www.anthropic.com/research/building-effective-agents","title":"Anthropic: Creación de agentes eficaces","type":"source"},{"url":"https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues","title":"Documentación de GitHub: Acerca de las incidencias","type":"source"},{"url":"https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/about-writing-and-formatting-on-github","title":"Documentación de GitHub: Acerca de la escritura y el formato en GitHub","type":"source"},{"url":"https://www.nist.gov/itl/ai-risk-management-framework","title":"Marco de Gestión de Riesgos de la IA del NIST","type":"source"},{"url":"https://genai.owasp.org/llm-top-10/","title":"OWASP Top 10 para aplicaciones de modelos de lenguaje de gran tamaño","type":"source"}],"images":[{"id":461,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ1NiwicHVyIjoiYmxvYl9pZCJ9fQ==--dcc52a99856a48635d1882fba812226f930329f5/ai-4dab44ed.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"개발자가 여러 대시보드에서 AI 에이전트의 설계, 코딩, 검증, 배포 흐름을 관리하는 다이어그램","caption":"AI 네이티브 개발자가 연결된 에이전트와 도구를 운영하는 전체 개발 구조를 보여준다.","description":null},"en":{"alt":"Developer managing AI agent design, coding, testing, security, and deployment across connected dashboards","caption":"The diagram shows an AI-native developer orchestrating connected agents and tools throughout development.","description":null},"ja":{"alt":"開発者が複数の画面でAIエージェントの設計、実装、検証、展開を管理する図","caption":"AIネイティブ開発者が連携するエージェントとツールを運用する開発構造を示している。","description":null},"es":{"alt":"Desarrollador gestionando diseño, código, pruebas, seguridad y despliegue de agentes de IA en paneles conectados","caption":"El diagrama muestra a un desarrollador nativo de IA coordinando agentes y herramientas durante el desarrollo.","description":null},"id":{"alt":"Pengembang mengelola desain, kode, pengujian, keamanan, dan penerapan agen AI lewat dasbor terhubung","caption":"Diagram ini menunjukkan pengembang native AI yang mengorkestrasi agen dan alat dalam proses pengembangan.","description":null},"pt":{"alt":"Desenvolvedor gerenciando design, código, testes, segurança e implantação de agentes de IA em painéis conectados","caption":"O diagrama mostra um desenvolvedor nativo de IA orquestrando agentes e ferramentas ao longo do desenvolvimento.","description":null},"zh-hant":{"alt":"開發者透過多個互連儀表板管理 AI 代理的設計、編碼、測試、安全與部署","caption":"此圖呈現 AI 原生開發者在開發流程中協調代理與工具的整體架構。","description":null},"de":{"alt":"Entwickler steuert Entwurf, Code, Tests, Sicherheit und Bereitstellung von KI-Agenten über vernetzte Dashboards","caption":"Das Diagramm zeigt, wie ein KI-nativer Entwickler vernetzte Agenten und Werkzeuge im Entwicklungsprozess koordiniert.","description":null}}},{"id":462,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6NTQ2MiwicHVyIjoiYmxvYl9pZCJ9fQ==--9fdf22aa2cbd420f209ff5c18baea59124f816b9/ai-f15eba1a.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"보안 장벽 안에서 여러 AI 에이전트가 개발 모듈을 연결하고 검증하는 워크플로 다이어그램","caption":"AI 에이전트들이 코딩, 도구, 설정, 배포 단계를 협업하며 보안과 성능 지표로 검증받는 구조를 보여준다.","description":null},"en":{"alt":"Workflow diagram of AI agents connecting and validating development modules inside a secure boundary","caption":"AI agents collaborate across coding, tooling, configuration, and deployment stages with security and performance checks.","description":null},"ja":{"alt":"安全な領域内で複数のAIエージェントが開発モジュールを連携・検証するワークフロー図","caption":"AIエージェントがコーディング、ツール、設定、デプロイを分担し、セキュリティと性能を確認する構造を示している。","description":null},"es":{"alt":"Diagrama de agentes de IA que conectan y validan módulos de desarrollo en un entorno seguro","caption":"Los agentes de IA colaboran en las fases de código, herramientas, configuración y despliegue con controles de seguridad y rendimiento.","description":null},"id":{"alt":"Diagram alur agen AI yang menghubungkan dan memvalidasi modul pengembangan dalam batas aman","caption":"Agen AI berkolaborasi pada tahap pengodean, alat, konfigurasi, dan penerapan dengan pemeriksaan keamanan serta kinerja.","description":null},"pt":{"alt":"Diagrama de agentes de IA conectando e validando módulos de desenvolvimento em um ambiente seguro","caption":"Agentes de IA colaboram nas etapas de código, ferramentas, configuração e implantação com verificações de segurança e desempenho.","description":null},"zh-hant":{"alt":"多個 AI 代理在安全邊界內連接並驗證開發模組的工作流程圖","caption":"AI 代理協作完成編碼、工具、設定與部署階段，並接受安全和效能檢查。","description":null},"de":{"alt":"Workflow-Diagramm von KI-Agenten, die Entwicklungsmodule in einer sicheren Umgebung verbinden und prüfen","caption":"KI-Agenten arbeiten bei Code, Werkzeugen, Konfiguration und Bereitstellung zusammen und durchlaufen Sicherheits- und Leistungsprüfungen.","description":null}}}],"published_at":"2026-08-04T10:59:54+09:00","updated_at":"2026-08-04T10:59:54+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/es/articles/ai-native-developer-definition-and-practices"}