El programador en la era de la IA: del código generado al control de la no determinación

baeba · 2026-06-22T10:32:20+09:00

Resumen general A medida que la IA automatiza gran parte de la escritura de código, el rol central del desarrollador se está desplazando de la implementación directa hacia el diseño, la verificación y el control. La esencia del programador no está en teclear mucho código, sino en completar los detalles de requisitos ambiguos y abstraerlos en formas reutilizables. En lugar de indicarle a la IA métodos de implementación detallados, resulta más efectivo presentarle objetivos y contexto, y delegarle el juicio. En vez de pedirle a la IA que resuelva todo de una sola vez, la calidad mejora cuando se separan los entregables en especificación, pruebas, implementación, refactorización y verificación. Como la salida de la IA es no determinista, se necesitan harnesses deterministas como pruebas, compiladores, linters y compuertas de validación. Se proyecta que el desarrollador del futuro se parecerá menos a un simple escritor de código y más a un diseñador de sistemas e ingeniero de harnesses que conecta agentes de IA con mecanismos de validación. Introducción La identidad del desarrollador sacudida por la IA A medida que la IA genera cientos de líneas de código solo con instrucciones en lenguaje natural, están cambiando los criterios con los que se medían las capacidades tradicionales de desarrollo. En el pasado, la habilidad de escribir código rápido desde un editor vacío se consideraba una ventaja competitiva clave para un desarrollador. Hoy, como la IA proporciona conocimiento y métodos de implementación, surgen preguntas como las siguientes. ¿Se puede seguir llamando desarrollo si uno no escribe el código directamente? Si la IA se encarga de los detalles de implementación, ¿qué papel le queda al desarrollador? ¿Siguen siendo necesarios hoy los conocimientos tradicionales de ciencias de la computación y la historia de la programación? El artículo explica este problema a partir de los conceptos de detalle, abstracción, no determinación y harness. El sentido de la historia de la programación El conocimiento histórico de programación no es solo una lista de técnicas, sino el proceso mediante el cual los desarrolladores de cada época resolvieron problemas y construyeron nuevas capas de abstracción. El lenguaje de máquina, el ensamblador, la programación estructurada, la orientación a objetos y los frameworks surgieron para ocultar la complejidad de capas inferiores. Aunque ya no se usen directamente tecnologías antiguas, entender esa historia permite ver cómo el rol del desarrollador ha ido cambiando de forma recurrente. Desarrollo 1. El desarrollador es quien concreta los detalles La planificación normalmente presenta el propósito del producto y su dirección general, pero no especifica todas las condiciones necesarias para la implementación real. Por ejemplo, incluso una función tan simple como “editar apodo” tiene condiciones detalladas como las siguientes. Si se permitirá o no una cadena vacía Cómo manejar caracteres especiales y emojis Cómo tratar errores de red y retrasos en la respuesta Qué debe pasar si el usuario sale de la pantalla durante la edición Dónde y cómo mostrar los mensajes de error El trabajo del desarrollador consiste en convertir esos vacíos en reglas lógicas y manejo de excepciones. Por eso, la especialidad del desarrollador está menos en implementar funciones sueltas y más en transformar requisitos ambiguos en un comportamiento de sistema completo. 2. La abstracción es el proceso de ocultar detalles ya resueltos Para reducir trabajo repetitivo, los desarrolladores empaquetan problemas ya resueltos en funciones, módulos, librerías, frameworks y similares. Lo esencial de la abstracción es lo siguiente. Ocultar el comportamiento interno repetitivo. Exponer solo la funcionalidad necesaria hacia afuera. Definir el límite entre lo que puede variar y lo que debe permanecer fijo. Cuando se acumulan abstracciones sólidas, se forma una nueva capa, y los desarrolladores de niveles superiores pueden trabajar sin conocer toda la implementación inferior. El entorno de desarrollo actual funciona sobre capas de abstracción construidas por generaciones anteriores de desarrolladores. 3. La profundidad que necesita un desarrollador depende de su posición No todas las abstracciones están terminadas. Una capa que logra ocultar su implementación interna de forma estable puede verse como una “abstracción completada”. Una capa cuyos detalles internos siguen filtrándose como problemas de rendimiento o errores corresponde a una “abstracción en curso”. Incluso la misma tecnología cambia de estado según el rol del desarrollador. Para un desarrollador web generalista, el navegador es una capa relativamente terminada. Para un desarrollador del motor del navegador, el proceso de renderizado es un detalle que debe tratar directamente. La profundidad que necesita un desarrollador no consiste en conocer todas las tecnologías, sino en entender las fugas y límites de la capa que le toca manejar. 4. La IA apareció como una nueva capa de abstracción La IA ejecuta rápidamente tareas de escritura de código e implementación repetitiva que antes el desarrollador hacía de forma directa. Por eso, la IA empieza a funcionar no solo como una herramienta de productividad, sino como una nueva capa que abstrae el proceso mismo de desarrollo. Sin embargo, que la IA genere código no significa que también resuelva automáticamente la interpretación de requisitos, el diseño estructural, la verificación de calidad o la responsabilidad operativa. Al contrario, a medida que baja el costo de implementar, aumenta la importancia del costo de ensamblar y validar el código generado. 5. Las instrucciones demasiado detalladas pueden limitar el desempeño de la IA El autor intentó desarrollar un proyecto paralelo de UI accesible usando solo IA, sin escribir código directamente. Al principio le daba a la IA métodos de implementación concretos, pero eso hizo que la IA quedara fijada en ese enfoque y agregara manejo de excepciones de forma repetitiva. Como resultado, el código se volvió más complejo, aparecieron varios efectos secundarios y un enfoque estándar más adecuado se aplicó demasiado tarde. Este caso muestra que el método inicial propuesto por el usuario puede actuar como un ancla que limita el juicio de la IA. En lugar de dictar demasiado la solución y la estructura del código, es más efectivo proporcionar lo siguiente. El trasfondo y propósito del problema El contexto del sistema actual Los resultados que deben cumplirse sí o sí Las restricciones que no deben modificarse 6. Más que instrucciones, hay que delegar objetivos y contexto A medida que mejora el desempeño de la IA, puede ser más efectivo delegar en función de objetivos que especificar directamente cada procedimiento detallado. En este enfoque, el desarrollador no define por completo “cómo implementarlo”, sino que comunica con claridad “por qué hace falta” y “qué se debe lograr”. Aun así, si se le da autonomía total, la IA puede concentrarse más en modificar código que en respetar la intención del usuario. Por eso, hace falta limitar el procedimiento de trabajo para que primero realice las siguientes acciones. Analizar la intención de la solicitud Hacer preguntas sobre la información faltante Proponer un plan de solución Ejecutar después de la aprobación del usuario Lo clave no es dar órdenes prohibitivas sin más, sino definir con claridad qué entregables están permitidos en la etapa actual. 7. En cada tarea debe definirse un solo entregable Los LLM tienen límites en la cantidad de salida y el alcance de razonamiento que pueden manejar en una sola respuesta. Si se les pide escribir pruebas e implementar al mismo tiempo, los recursos pueden concentrarse en completar el código final y bajar la calidad de las pruebas. El autor separa el trabajo de TDD de la siguiente manera. /red: escribir solo pruebas que fallen /green: escribir la implementación mínima que haga pasar las pruebas /refactor: mejorar la estructura del código manteniendo las pruebas Cuando se limita cada etapa a un solo entregable, se reduce el problema de que la IA se salte pasos intermedios o los resuelva de manera superficial. Esto significa que la clave del diseño de prompts no está en describir acciones con demasiada extensión, sino en definir el resultado que debe generarse en una sola tarea. 8. Los documentos Markdown y las skills se convierten en el nuevo código Si se separan especificación, pruebas, implementación, verificación y commits como skills distintas, puede construirse un pipeline como el siguiente. Redacción de especificaciones Generación de pruebas fallidas Implementación de la funcionalidad Refactorización Verificación Commit Cada skill tiene entradas, salidas y restricciones, por lo que funciona de manera similar a una función. Los documentos Markdown que registran skills y reglas no son simples manuales, sino reglas de ejecución que determinan el comportamiento de la IA. En este proceso también pueden aplicarse principios clásicos de diseño de software. El principio de responsabilidad única, asignando una sola responsabilidad a cada skill La modularización, separando conocimiento y reglas en archivos distintos El principio abierto-cerrado, ampliando mediante archivos externos de conocimiento sin cambiar las skills centrales Aunque la plataforma haya cambiado del IDE a documentos Markdown, descomponer y conectar trabajo sigue siendo programación. 9. El riesgo clave de programar con IA es la no determinación Los programas tradicionales suelen devolver la misma salida ante la misma entrada. La IA puede generar código y juicios distintos incluso ante la misma solicitud. Cuando la IA realiza una refactorización grande, aunque la funcionalidad parezca operar, siguen quedando problemas como los siguientes. Revisar si el código modificado es correcto Determinar si el código eliminado realmente era innecesario Evaluar la posibilidad de nuevos efectos secundarios Asumir la responsabilidad de mantenimiento y despliegue La IA acelera la generación de código, pero no aporta automáticamente estabilidad ni responsabilidad sobre el resultado. En un entorno de producción, importa más la capacidad de controlar el alcance de los cambios y verificar los resultados que la mera capacidad de generar. 10. La IA es fuerte en problemas con techo bajo Los problemas que la IA resuelve con facilidad suelen ser “problemas bien definidos”, donde los requisitos y la forma de resolverlos ya son suficientemente conocidos. Estos problemas pueden resolverse combinando elementos de abstracción ya consolidados, como librerías, frameworks y patrones. La fortaleza de la IA está en combinar de forma probabilística el código y los patrones de resolución de problemas acumulados por la humanidad. En cambio, problemas de mayor dificultad como los siguientes siguen requiriendo juicio humano adicional. Problemas con requisitos incompletos Reglas de dominio complejas Interacciones de sistemas a gran escala Situaciones excepcionales en entornos operativos Problemas donde se combinan seguridad, rendimiento, regulación y responsabilidad Esto no significa que desaparezca el valor de la implementación simple, pero sí que la implementación en sí puede moverse gradualmente hacia un terreno que incluso usuarios generales podrán manejar. 11. Los detalles del desarrollador se desplazan hacia el control de la IA Antes, los desarrolladores escribían código determinista para defenderse de entradas impredecibles de usuarios y entornos operativos. En la era de la IA, hay que construir productos deterministas usando una IA no determinista. Los detalles que el desarrollador debe manejar se trasladan a áreas como las siguientes. Definir el alcance del trabajo para que la IA no quede fijada en objetivos erróneos Definir el formato de entradas y salidas por etapa Gestionar contexto y documentos de conocimiento Limitar el alcance de cambios grandes Diseñar procedimientos de recuperación ante errores Verificar la calidad y seguridad de los resultados Cuanto más se automatiza la implementación simple, más probable es que el trabajo de desarrollo se concentre en manejo de excepciones y problemas de control. 12. Los resultados de la IA deben verificarse con herramientas deterministas No es fácil asegurar suficiente confiabilidad solo haciendo que otra IA verifique lo que una IA generó. Para juzgar si la salida de un sistema es correcta, hace falta un criterio claro de respuesta correcta, es decir, un oráculo. Si una IA no determinista genera de forma arbitraria incluso el criterio de validación, puede corregir mal un resultado correcto o distorsionar el estándar de verificación. Por eso, los criterios de validación deben construirse tanto como sea posible con herramientas deterministas. Compiladores y verificadores de tipos Pruebas automatizadas Linters y análisis estático Validación de esquemas Criterios de rendimiento y seguridad Procedimientos de aprobación y límites al alcance de cambios El juicio de la IA puede usarse como apoyo, pero la decisión final de aprobación debe estar conectada a criterios reproducibles. 13. El harness se vuelve la infraestructura clave del desarrollo con IA Un harness es un mecanismo de validación dispuesto por etapas para evitar que la IA acumule errores durante el proceso de trabajo o se salga de su alcance. Sus componentes principales son los siguientes. Un pipeline que separa las etapas del trabajo Formatos de entrada y salida por etapa Pruebas automatizadas y análisis estático Compuertas de validación que detienen el proceso si hay fallas Restricciones sobre qué archivos y qué alcance pueden modificarse Procedimientos de aprobación y revisión humana El harness evita que un error pequeño en una etapa se amplifique en la siguiente. Es posible que la capacidad de aprovechar la IA se evalúe menos por escribir buenos prompts y más por encerrar salidas impredecibles dentro de un sistema estable. Conclusión El desarrollador no desaparece; su rol se desplaza La IA está automatizando con rapidez la escritura de código simple y la implementación repetitiva. Pero para producir resultados a nivel de producto, siguen siendo necesarios roles como los siguientes. Definir problemas y objetivos Diseñar la estructura del sistema Separar etapas de trabajo y entregables Coordinar el flujo entre agentes de IA Construir criterios de validación y harnesses Asumir la responsabilidad final sobre los resultados operativos Es probable que el trabajo del desarrollador reduzca la proporción de código escrito directamente y evolucione hacia organizar y controlar como sistema el código generado por IA. Escribir prompts es una nueva forma de programar Convertir instrucciones de uso repetido en skills y reglas, y conectarlas en un pipeline, es parecido a diseñar funciones y módulos. Los documentos Markdown pueden funcionar como una nueva capa de código que define el contexto, comportamiento y formato de salida de la IA. El desarrollador debe documentar su experiencia y sus criterios implícitos de juicio para abstraerlos en formas reutilizables por la IA. Esto no solo abstrae sistemas existentes, sino también la propia forma de trabajar y el proceso de decisión del desarrollador. Capacidades clave del desarrollador del futuro Capacidad de definir problemas con precisión Capacidad de delegar trabajo en torno a objetivos y contexto Capacidad de descomponer tareas complejas en entregables pequeños Capacidad de organizar skills y agentes en pipelines Capacidad de diseñar criterios de validación deterministas Capacidad de construir harnesses que controlen los riesgos de resultados no deterministas Profundidad técnica para entender los resultados generados por IA y asumir la responsabilidad final Evaluación general La IA no está eliminando la esencia del desarrollo, sino cambiando la capa de abstracción que el desarrollador debe manejar. Si antes el desarrollador trataba los detalles del código y del sistema, en el futuro tendrá que tratar los detalles que surgen del comportamiento y las salidas de la IA. El costo de generar código baja, pero la importancia de verificar, ensamblar, operar y controlar probablemente crecerá aún más. La esencia del programador no está en tipear por sí mismo, sino en descubrir detalles, abstraerlos y organizarlos en sistemas confiables.

(velog.io)

6 puntos por baeba 5 시간 전 | Aún no hay comentarios. | Compartir por WhatsApp

Resumen general

A medida que la IA automatiza gran parte de la escritura de código, el rol central del desarrollador se está desplazando de la implementación directa hacia el diseño, la verificación y el control.
La esencia del programador no está en teclear mucho código, sino en completar los detalles de requisitos ambiguos y abstraerlos en formas reutilizables.
En lugar de indicarle a la IA métodos de implementación detallados, resulta más efectivo presentarle objetivos y contexto, y delegarle el juicio.
En vez de pedirle a la IA que resuelva todo de una sola vez, la calidad mejora cuando se separan los entregables en especificación, pruebas, implementación, refactorización y verificación.
Como la salida de la IA es no determinista, se necesitan harnesses deterministas como pruebas, compiladores, linters y compuertas de validación.
Se proyecta que el desarrollador del futuro se parecerá menos a un simple escritor de código y más a un diseñador de sistemas e ingeniero de harnesses que conecta agentes de IA con mecanismos de validación.

Introducción

La identidad del desarrollador sacudida por la IA

A medida que la IA genera cientos de líneas de código solo con instrucciones en lenguaje natural, están cambiando los criterios con los que se medían las capacidades tradicionales de desarrollo.
En el pasado, la habilidad de escribir código rápido desde un editor vacío se consideraba una ventaja competitiva clave para un desarrollador.
Hoy, como la IA proporciona conocimiento y métodos de implementación, surgen preguntas como las siguientes.
- ¿Se puede seguir llamando desarrollo si uno no escribe el código directamente?
- Si la IA se encarga de los detalles de implementación, ¿qué papel le queda al desarrollador?
- ¿Siguen siendo necesarios hoy los conocimientos tradicionales de ciencias de la computación y la historia de la programación?
El artículo explica este problema a partir de los conceptos de detalle, abstracción, no determinación y harness.

El sentido de la historia de la programación

El conocimiento histórico de programación no es solo una lista de técnicas, sino el proceso mediante el cual los desarrolladores de cada época resolvieron problemas y construyeron nuevas capas de abstracción.
El lenguaje de máquina, el ensamblador, la programación estructurada, la orientación a objetos y los frameworks surgieron para ocultar la complejidad de capas inferiores.
Aunque ya no se usen directamente tecnologías antiguas, entender esa historia permite ver cómo el rol del desarrollador ha ido cambiando de forma recurrente.

Desarrollo

1. El desarrollador es quien concreta los detalles

La planificación normalmente presenta el propósito del producto y su dirección general, pero no especifica todas las condiciones necesarias para la implementación real.
Por ejemplo, incluso una función tan simple como “editar apodo” tiene condiciones detalladas como las siguientes.
- Si se permitirá o no una cadena vacía
- Cómo manejar caracteres especiales y emojis
- Cómo tratar errores de red y retrasos en la respuesta
- Qué debe pasar si el usuario sale de la pantalla durante la edición
- Dónde y cómo mostrar los mensajes de error
El trabajo del desarrollador consiste en convertir esos vacíos en reglas lógicas y manejo de excepciones.
Por eso, la especialidad del desarrollador está menos en implementar funciones sueltas y más en transformar requisitos ambiguos en un comportamiento de sistema completo.

2. La abstracción es el proceso de ocultar detalles ya resueltos

Para reducir trabajo repetitivo, los desarrolladores empaquetan problemas ya resueltos en funciones, módulos, librerías, frameworks y similares.
Lo esencial de la abstracción es lo siguiente.
- Ocultar el comportamiento interno repetitivo.
- Exponer solo la funcionalidad necesaria hacia afuera.
- Definir el límite entre lo que puede variar y lo que debe permanecer fijo.
Cuando se acumulan abstracciones sólidas, se forma una nueva capa, y los desarrolladores de niveles superiores pueden trabajar sin conocer toda la implementación inferior.
El entorno de desarrollo actual funciona sobre capas de abstracción construidas por generaciones anteriores de desarrolladores.

3. La profundidad que necesita un desarrollador depende de su posición

No todas las abstracciones están terminadas.
Una capa que logra ocultar su implementación interna de forma estable puede verse como una “abstracción completada”.
Una capa cuyos detalles internos siguen filtrándose como problemas de rendimiento o errores corresponde a una “abstracción en curso”.
Incluso la misma tecnología cambia de estado según el rol del desarrollador.
- Para un desarrollador web generalista, el navegador es una capa relativamente terminada.
- Para un desarrollador del motor del navegador, el proceso de renderizado es un detalle que debe tratar directamente.
La profundidad que necesita un desarrollador no consiste en conocer todas las tecnologías, sino en entender las fugas y límites de la capa que le toca manejar.

4. La IA apareció como una nueva capa de abstracción

La IA ejecuta rápidamente tareas de escritura de código e implementación repetitiva que antes el desarrollador hacía de forma directa.
Por eso, la IA empieza a funcionar no solo como una herramienta de productividad, sino como una nueva capa que abstrae el proceso mismo de desarrollo.
Sin embargo, que la IA genere código no significa que también resuelva automáticamente la interpretación de requisitos, el diseño estructural, la verificación de calidad o la responsabilidad operativa.
Al contrario, a medida que baja el costo de implementar, aumenta la importancia del costo de ensamblar y validar el código generado.

5. Las instrucciones demasiado detalladas pueden limitar el desempeño de la IA

El autor intentó desarrollar un proyecto paralelo de UI accesible usando solo IA, sin escribir código directamente.
Al principio le daba a la IA métodos de implementación concretos, pero eso hizo que la IA quedara fijada en ese enfoque y agregara manejo de excepciones de forma repetitiva.
Como resultado, el código se volvió más complejo, aparecieron varios efectos secundarios y un enfoque estándar más adecuado se aplicó demasiado tarde.
Este caso muestra que el método inicial propuesto por el usuario puede actuar como un ancla que limita el juicio de la IA.
En lugar de dictar demasiado la solución y la estructura del código, es más efectivo proporcionar lo siguiente.
- El trasfondo y propósito del problema
- El contexto del sistema actual
- Los resultados que deben cumplirse sí o sí
- Las restricciones que no deben modificarse

6. Más que instrucciones, hay que delegar objetivos y contexto

A medida que mejora el desempeño de la IA, puede ser más efectivo delegar en función de objetivos que especificar directamente cada procedimiento detallado.
En este enfoque, el desarrollador no define por completo “cómo implementarlo”, sino que comunica con claridad “por qué hace falta” y “qué se debe lograr”.
Aun así, si se le da autonomía total, la IA puede concentrarse más en modificar código que en respetar la intención del usuario.
Por eso, hace falta limitar el procedimiento de trabajo para que primero realice las siguientes acciones.
- Analizar la intención de la solicitud
- Hacer preguntas sobre la información faltante
- Proponer un plan de solución
- Ejecutar después de la aprobación del usuario
Lo clave no es dar órdenes prohibitivas sin más, sino definir con claridad qué entregables están permitidos en la etapa actual.

7. En cada tarea debe definirse un solo entregable

Los LLM tienen límites en la cantidad de salida y el alcance de razonamiento que pueden manejar en una sola respuesta.
Si se les pide escribir pruebas e implementar al mismo tiempo, los recursos pueden concentrarse en completar el código final y bajar la calidad de las pruebas.
El autor separa el trabajo de TDD de la siguiente manera.
- /red: escribir solo pruebas que fallen
- /green: escribir la implementación mínima que haga pasar las pruebas
- /refactor: mejorar la estructura del código manteniendo las pruebas
Cuando se limita cada etapa a un solo entregable, se reduce el problema de que la IA se salte pasos intermedios o los resuelva de manera superficial.
Esto significa que la clave del diseño de prompts no está en describir acciones con demasiada extensión, sino en definir el resultado que debe generarse en una sola tarea.

8. Los documentos Markdown y las skills se convierten en el nuevo código

Si se separan especificación, pruebas, implementación, verificación y commits como skills distintas, puede construirse un pipeline como el siguiente.
- Redacción de especificaciones
- Generación de pruebas fallidas
- Implementación de la funcionalidad
- Refactorización
- Verificación
- Commit
Cada skill tiene entradas, salidas y restricciones, por lo que funciona de manera similar a una función.
Los documentos Markdown que registran skills y reglas no son simples manuales, sino reglas de ejecución que determinan el comportamiento de la IA.
En este proceso también pueden aplicarse principios clásicos de diseño de software.
- El principio de responsabilidad única, asignando una sola responsabilidad a cada skill
- La modularización, separando conocimiento y reglas en archivos distintos
- El principio abierto-cerrado, ampliando mediante archivos externos de conocimiento sin cambiar las skills centrales
Aunque la plataforma haya cambiado del IDE a documentos Markdown, descomponer y conectar trabajo sigue siendo programación.

9. El riesgo clave de programar con IA es la no determinación

Los programas tradicionales suelen devolver la misma salida ante la misma entrada.
La IA puede generar código y juicios distintos incluso ante la misma solicitud.
Cuando la IA realiza una refactorización grande, aunque la funcionalidad parezca operar, siguen quedando problemas como los siguientes.
- Revisar si el código modificado es correcto
- Determinar si el código eliminado realmente era innecesario
- Evaluar la posibilidad de nuevos efectos secundarios
- Asumir la responsabilidad de mantenimiento y despliegue
La IA acelera la generación de código, pero no aporta automáticamente estabilidad ni responsabilidad sobre el resultado.
En un entorno de producción, importa más la capacidad de controlar el alcance de los cambios y verificar los resultados que la mera capacidad de generar.

10. La IA es fuerte en problemas con techo bajo

Los problemas que la IA resuelve con facilidad suelen ser “problemas bien definidos”, donde los requisitos y la forma de resolverlos ya son suficientemente conocidos.
Estos problemas pueden resolverse combinando elementos de abstracción ya consolidados, como librerías, frameworks y patrones.
La fortaleza de la IA está en combinar de forma probabilística el código y los patrones de resolución de problemas acumulados por la humanidad.
En cambio, problemas de mayor dificultad como los siguientes siguen requiriendo juicio humano adicional.
- Problemas con requisitos incompletos
- Reglas de dominio complejas
- Interacciones de sistemas a gran escala
- Situaciones excepcionales en entornos operativos
- Problemas donde se combinan seguridad, rendimiento, regulación y responsabilidad
Esto no significa que desaparezca el valor de la implementación simple, pero sí que la implementación en sí puede moverse gradualmente hacia un terreno que incluso usuarios generales podrán manejar.

11. Los detalles del desarrollador se desplazan hacia el control de la IA

Antes, los desarrolladores escribían código determinista para defenderse de entradas impredecibles de usuarios y entornos operativos.
En la era de la IA, hay que construir productos deterministas usando una IA no determinista.
Los detalles que el desarrollador debe manejar se trasladan a áreas como las siguientes.
- Definir el alcance del trabajo para que la IA no quede fijada en objetivos erróneos
- Definir el formato de entradas y salidas por etapa
- Gestionar contexto y documentos de conocimiento
- Limitar el alcance de cambios grandes
- Diseñar procedimientos de recuperación ante errores
- Verificar la calidad y seguridad de los resultados
Cuanto más se automatiza la implementación simple, más probable es que el trabajo de desarrollo se concentre en manejo de excepciones y problemas de control.

12. Los resultados de la IA deben verificarse con herramientas deterministas

No es fácil asegurar suficiente confiabilidad solo haciendo que otra IA verifique lo que una IA generó.
Para juzgar si la salida de un sistema es correcta, hace falta un criterio claro de respuesta correcta, es decir, un oráculo.
Si una IA no determinista genera de forma arbitraria incluso el criterio de validación, puede corregir mal un resultado correcto o distorsionar el estándar de verificación.
Por eso, los criterios de validación deben construirse tanto como sea posible con herramientas deterministas.
- Compiladores y verificadores de tipos
- Pruebas automatizadas
- Linters y análisis estático
- Validación de esquemas
- Criterios de rendimiento y seguridad
- Procedimientos de aprobación y límites al alcance de cambios
El juicio de la IA puede usarse como apoyo, pero la decisión final de aprobación debe estar conectada a criterios reproducibles.

13. El harness se vuelve la infraestructura clave del desarrollo con IA

Un harness es un mecanismo de validación dispuesto por etapas para evitar que la IA acumule errores durante el proceso de trabajo o se salga de su alcance.
Sus componentes principales son los siguientes.
- Un pipeline que separa las etapas del trabajo
- Formatos de entrada y salida por etapa
- Pruebas automatizadas y análisis estático
- Compuertas de validación que detienen el proceso si hay fallas
- Restricciones sobre qué archivos y qué alcance pueden modificarse
- Procedimientos de aprobación y revisión humana
El harness evita que un error pequeño en una etapa se amplifique en la siguiente.
Es posible que la capacidad de aprovechar la IA se evalúe menos por escribir buenos prompts y más por encerrar salidas impredecibles dentro de un sistema estable.

Conclusión

El desarrollador no desaparece; su rol se desplaza

La IA está automatizando con rapidez la escritura de código simple y la implementación repetitiva.
Pero para producir resultados a nivel de producto, siguen siendo necesarios roles como los siguientes.
- Definir problemas y objetivos
- Diseñar la estructura del sistema
- Separar etapas de trabajo y entregables
- Coordinar el flujo entre agentes de IA
- Construir criterios de validación y harnesses
- Asumir la responsabilidad final sobre los resultados operativos
Es probable que el trabajo del desarrollador reduzca la proporción de código escrito directamente y evolucione hacia organizar y controlar como sistema el código generado por IA.

Escribir prompts es una nueva forma de programar

Convertir instrucciones de uso repetido en skills y reglas, y conectarlas en un pipeline, es parecido a diseñar funciones y módulos.
Los documentos Markdown pueden funcionar como una nueva capa de código que define el contexto, comportamiento y formato de salida de la IA.
El desarrollador debe documentar su experiencia y sus criterios implícitos de juicio para abstraerlos en formas reutilizables por la IA.
Esto no solo abstrae sistemas existentes, sino también la propia forma de trabajar y el proceso de decisión del desarrollador.

Capacidades clave del desarrollador del futuro

Capacidad de definir problemas con precisión
Capacidad de delegar trabajo en torno a objetivos y contexto
Capacidad de descomponer tareas complejas en entregables pequeños
Capacidad de organizar skills y agentes en pipelines
Capacidad de diseñar criterios de validación deterministas
Capacidad de construir harnesses que controlen los riesgos de resultados no deterministas
Profundidad técnica para entender los resultados generados por IA y asumir la responsabilidad final

Evaluación general

La IA no está eliminando la esencia del desarrollo, sino cambiando la capa de abstracción que el desarrollador debe manejar.
Si antes el desarrollador trataba los detalles del código y del sistema, en el futuro tendrá que tratar los detalles que surgen del comportamiento y las salidas de la IA.
El costo de generar código baja, pero la importancia de verificar, ensamblar, operar y controlar probablemente crecerá aún más.
La esencia del programador no está en tipear por sí mismo, sino en descubrir detalles, abstraerlos y organizarlos en sistemas confiables.