El cambio de rol del desarrollador en la era de la codificación con IA: de ejecutor de código a diseñador de contexto, verificación y productización

baeba · 2026-07-06T10:13:13+09:00

Resumen general Tesis central A medida que la IA alcanza el nivel de escribir, modificar y probar código directamente, el rol del desarrollador se está desplazando desde la simple codificación hacia la definición de problemas, el diseño de tareas, la verificación, la gestión del contexto y el apoyo a la productización. Causas estructurales La IA ha aumentado mucho la velocidad de producción de código, pero el código no se convierte de inmediato en un buen producto. Áreas fuera de la codificación, como requisitos, documentación, pruebas, estructuración, criterios de UX y mantenibilidad, se volvieron aún más importantes. Casos principales La experiencia de hacer que la IA realizara incluso pruebas de navegador mediante Playwright. La experiencia de especificar trabajos repetitivos como comandos, skills y workflows. Un caso en el que un prototipo frontend creado con IA se veía excelente por fuera, pero tenía una estructura interna frágil. Dirección de la solución No hay que encargarle a la IA solo el código; también hay que diseñar junto con ella los procedimientos y criterios de todo el proceso de desarrollo. El desarrollador debe revisar los resultados de la IA, dejar contexto y ordenar la estructura para que puedan convertirse en un producto sostenible. Introducción La transición en la era de la codificación con IA La publicación parte de la pregunta: “¿qué debe hacer un desarrollador en una era en la que las personas no codifican directamente?”. Antes, el autor consideraba que, como la IA provocaba alucinaciones y errores, el juicio final debía quedar en manos de una persona. Sin embargo, evalúa que, gracias a las mejoras recientes en el rendimiento de los modelos de IA, la IA llegó al nivel de comprender issues, explorar archivos, modificar código y pasar pruebas. Debido a este cambio, los desarrolladores pasan de usar la IA simplemente como herramienta auxiliar a pensar cómo hacer que la IA ejecute el propio procedimiento de desarrollo. La inquietud central Que la IA haya aprendido a escribir buen código no significa que el rol del desarrollador vaya a desaparecer. Al contrario, cuanto más se automatiza la codificación, más visibles se vuelven los demás elementos del desarrollo. Ordenar requisitos, registrar decisiones, diseñar pruebas, gestionar la estructura del código y revisar la experiencia de producto emergen como tareas centrales del desarrollador. Desarrollo 1. La IA pasó de ser una herramienta para escribir código a ser un agente que ejecuta tareas El autor considera que la IA superó el nivel de generar simples fragmentos de código y ya puede manejar flujos reales de trabajo de desarrollo. Antes, una persona tenía que vigilar y corregir continuamente los resultados de la IA, pero ahora es posible delegarle una tarea a la IA y revisar el resultado. La mejora en el rendimiento de benchmarks como SWE Bench se menciona como un indicador de este cambio. El cambio clave no es preguntar “¿puede la IA escribir código?”, sino que la pregunta pasó a ser “¿hasta qué alcance se le puede delegar trabajo a la IA?”. 2. Cuando la IA falla, el problema no es solo “falta de capacidad” La IA todavía no siempre tiene éxito. Hay casos en los que los errores se repiten, o en los que dice haber corregido algo pero el problema permanece en la pantalla real. Al principio, el autor respondía copiando los errores y pasándoselos a la IA. Luego, al usar Playwright para hacer que la IA abriera directamente el navegador y ejecutara pruebas, se dio cuenta de que también podía delegarle a la IA los procedimientos de verificación que antes hacía una persona. Este caso muestra que algunas cosas que se consideraban límites de la IA en realidad eran límites que surgían porque el usuario no se las había indicado. 3. Pensar de forma AI Native es delegar el procedimiento completo El autor deja atrás la mirada de usar la IA como una simple herramienta auxiliar y pasa a hacer que la IA ejecute el procedimiento completo que él mismo realizaba. Convierte trabajos repetitivos en comandos, skills y workflows, e intenta especificar su conocimiento tácito. Como ejemplo, crea flujos de comandos como /plan, /prd, /debug, /refactor, /verify y /retrospect. Lo importante no es decirle simplemente a la IA “escribe el código”, sino convertir en reglas incluso cuándo debe preguntar, cuándo debe detenerse y cuándo debe verificar. Con esto, el desarrollador transforma su forma de trabajar y sus criterios de juicio en una estructura reutilizable por la IA. 4. El know-how personal se absorbe rápidamente como funcionalidad de las herramientas Los comandos y workflows que el autor creaba por su cuenta aparecen con el tiempo como funciones y conceptos oficiales, como Skill, memory, hooks y orchestration. Cuanto más efectiva es una metodología individual de uso de IA, más rápido se absorbe como funcionalidad de producto o como metodología común. Por lo tanto, es difícil crear una diferenciación de largo plazo solo con prompts o tips específicos para usar bien la IA. Lo importante no es la metodología en sí, sino hasta dónde se la aplicó a problemas reales y qué límites se experimentaron. 5. La IA amplía el tamaño de los problemas que puede abordar un desarrollador La IA permite que el autor experimente en la práctica con ideas grandes que antes no intentaba por costos y tiempo. Por ejemplo, crea rápidamente herramientas para desplegar código y documentos como si fueran un canvas, visores de MD, herramientas de análisis de código y herramientas auxiliares para desarrollo. El punto clave no es que la IA entregue de inmediato un producto terminado, sino que reduce la barrera de entrada para comenzar. El desarrollador cambia su forma de pensar de “¿podré construir esto?” a “¿hasta dónde puedo intentar construirlo, al menos para empezar?”. 6. Al abordar problemas grandes, aparecen las tareas de desarrollo fuera de la codificación Cuando aumenta la producción de código con IA, al desarrollador le cuesta leer todo el código directamente y guardar el contexto en su cabeza. Al codificar directamente, el contexto, el juicio y la comprensión de la estructura se acumulaban de forma natural; al delegarle la codificación a la IA, eso no queda registrado automáticamente. Por eso, la documentación, las pruebas, los issues, los reportes de trabajo y los registros de los motivos de los cambios se vuelven importantes. Esto no es trabajo administrativo, sino un mecanismo central para mantener el contexto de desarrollo en la era de la IA. Se enfatiza que la capacidad de preservar contexto y criterio se vuelve tan importante como la capacidad de codificar. 7. Más commits y pruebas no significan necesariamente mejor producto Al usar IA, la cantidad de commits, archivos, pruebas y documentos crece rápidamente. Sin embargo, que aumenten los números no significa que el producto mejore realmente. Pueden agregarse funciones, pero con una UX incómoda, o las pruebas pueden pasar mientras el flujo real de la pantalla sigue siendo inestable. Al principio, el autor intentó ver esto solo como un problema de calidad y estructura del código. Pero experimenta que mejorar la estructura del código no hace que la experiencia de producto mejore automáticamente. En definitiva, la producción de código y la mejora del producto son problemas distintos, y se necesita un juicio separado sobre la calidad como producto. 8. El frontend es un área especialmente propensa a tambalear con IA La IA puede crear rápidamente una UI inicial convincente, como dashboards, landing pages o pantallas de administración. Sin embargo, un frontend a nivel de producto real exige criterios complejos como sistema de diseño, gestión de estado, accesibilidad, manejo por teclado, estados de excepción y flujos de usuario. Muchas exigencias del frontend se expresan con lenguaje ambiguo, como “que se sienta natural”, “menos incómodo” o “que dé sensación de estar seleccionado”. En el proceso de convertir esos requisitos ambiguos en código, los resultados de la IA pueden dispersarse fácilmente. Por eso, para usar bien la IA en frontend, se necesitan criterios y capacidad de juicio para fijar las partes que salieron bien y hacer que solo se vuelvan a corregir las partes deficientes. 9. Los buenos resultados no salen de una sola vez, se construyen mediante un proceso de convergencia El autor cambia su percepción al ver un prototipo de alta calidad creado con IA por una persona de planificación. Ese resultado no fue creado con un único prompt especial, sino mediante correcciones repetidas “hasta que saliera”. Este caso muestra que lo central en el uso de IA no es la generación automática simple, sino un proceso de convergencia en el que se observan continuamente las partes deficientes y se vuelven a pedir ajustes. Quienes generan buenos resultados juzgan qué le falta al resultado creado por la IA y lo ajustan con persistencia hasta alcanzar el nivel deseado. Incluso en la era de la IA, los criterios, la sensibilidad y la revisión continua de las personas marcan la diferencia en los resultados. 10. El desarrollador asume el rol de llevar resultados prometedores hacia un producto Los resultados creados con IA pueden verse bien por fuera, pero tener una estructura interna de código frágil. Surgen problemas como gestión de estado inestable, responsabilidades ambiguas entre componentes o pruebas que no garantizan el flujo real. El rol del desarrollador no es evaluar esos resultados de forma incondicionalmente negativa ni descartarlos. Al mismo tiempo, tampoco deben productizarse tal como están. El desarrollador debe ordenar la estructura, señalar riesgos, crear unidades testeables y dejar contexto para que los resultados prometedores puedan llegar más lejos. Es decir, el rol del desarrollador se amplía: pasa de ser “la persona que construye todo sola hasta el final” a “la persona que conecta los resultados creados por la IA y las personas con un producto sostenible”. 11. Los roles de desarrollo en la era de la IA no convergen en uno solo Cuando baja la barrera de entrada para codificar, también se diversifican los tipos de personas que participan en el desarrollo. Planificadores, diseñadores, PM y responsables de negocio también pueden crear prototipos funcionales o herramientas internas mediante IA. Esto no significa que desaparezca la necesidad de desarrolladores, sino que los roles relacionados con el desarrollo se vuelven más segmentados. El autor lo compara con el ecosistema de YouTube. Así como YouTube no eliminó a los profesionales del video, sino que diversificó roles como presentadores, editores, planificadores, operadores de canales y creadores de plataformas, la IA también puede diversificar los roles de desarrollo. En el futuro probablemente coexistirán quienes construyen sistemas profundos, quienes refinan prototipos hasta convertirlos en productos, quienes crean capas donde la IA pueda trabajar bien y quienes resuelven problemas directamente. Conclusión El desarrollador debe diseñar el desarrollo posterior a la codificación La conclusión de la publicación no es una dicotomía entre “¿hay que seguir codificando o hay que soltarlo?”. En la medida en que la IA ya puede ejecutar la codificación, los desarrolladores deben aprender empíricamente qué delegarle a la IA y qué juzgar directamente. En particular, las siguientes capacidades se vuelven importantes. La capacidad de plantear problemas más grandes La capacidad de convertir procedimientos repetitivos en skills y workflows La capacidad de estructurar requisitos, documentación, pruebas e issues La capacidad de revisar los resultados de la IA y volver a indicarle lo que falta La capacidad de pulir resultados rudimentarios hasta convertirlos en productos sostenibles La capacidad de conectar con IA incluso herramientas y flujos de trabajo fuera del código Mensaje central La IA no es tan perfecta como esperan los desarrolladores, pero puede realizar muchas más tareas de lo que parece. Antes de concluir que la IA no puede hacer algo, hay que experimentar hasta dónde se le puede pedir. A la inversa, que la IA facilite algo no significa que haya que confiar sin más en sus resultados. El desarrollador debe asumir el rol de juzgar, hacer converger, preservar el contexto y llevar a producto los resultados creados por la IA. En definitiva, el desarrollador en la era de la IA se acerca menos a alguien que escribe mucho código directamente y más a alguien que diseña problemas, procedimientos, criterios y contexto para que los resultados creados por la IA y las personas conduzcan a mejores resultados.

(velog.io/@teo)

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

Resumen general

Tesis central
- A medida que la IA alcanza el nivel de escribir, modificar y probar código directamente, el rol del desarrollador se está desplazando desde la simple codificación hacia la definición de problemas, el diseño de tareas, la verificación, la gestión del contexto y el apoyo a la productización.
Causas estructurales
- La IA ha aumentado mucho la velocidad de producción de código, pero el código no se convierte de inmediato en un buen producto.
- Áreas fuera de la codificación, como requisitos, documentación, pruebas, estructuración, criterios de UX y mantenibilidad, se volvieron aún más importantes.
Casos principales
- La experiencia de hacer que la IA realizara incluso pruebas de navegador mediante Playwright.
- La experiencia de especificar trabajos repetitivos como comandos, skills y workflows.
- Un caso en el que un prototipo frontend creado con IA se veía excelente por fuera, pero tenía una estructura interna frágil.
Dirección de la solución
- No hay que encargarle a la IA solo el código; también hay que diseñar junto con ella los procedimientos y criterios de todo el proceso de desarrollo.
- El desarrollador debe revisar los resultados de la IA, dejar contexto y ordenar la estructura para que puedan convertirse en un producto sostenible.

Introducción

La transición en la era de la codificación con IA

La publicación parte de la pregunta: “¿qué debe hacer un desarrollador en una era en la que las personas no codifican directamente?”.
Antes, el autor consideraba que, como la IA provocaba alucinaciones y errores, el juicio final debía quedar en manos de una persona.
Sin embargo, evalúa que, gracias a las mejoras recientes en el rendimiento de los modelos de IA, la IA llegó al nivel de comprender issues, explorar archivos, modificar código y pasar pruebas.
Debido a este cambio, los desarrolladores pasan de usar la IA simplemente como herramienta auxiliar a pensar cómo hacer que la IA ejecute el propio procedimiento de desarrollo.

La inquietud central

Que la IA haya aprendido a escribir buen código no significa que el rol del desarrollador vaya a desaparecer.
Al contrario, cuanto más se automatiza la codificación, más visibles se vuelven los demás elementos del desarrollo.
Ordenar requisitos, registrar decisiones, diseñar pruebas, gestionar la estructura del código y revisar la experiencia de producto emergen como tareas centrales del desarrollador.

Desarrollo

1. La IA pasó de ser una herramienta para escribir código a ser un agente que ejecuta tareas

El autor considera que la IA superó el nivel de generar simples fragmentos de código y ya puede manejar flujos reales de trabajo de desarrollo.
Antes, una persona tenía que vigilar y corregir continuamente los resultados de la IA, pero ahora es posible delegarle una tarea a la IA y revisar el resultado.
La mejora en el rendimiento de benchmarks como SWE Bench se menciona como un indicador de este cambio.
El cambio clave no es preguntar “¿puede la IA escribir código?”, sino que la pregunta pasó a ser “¿hasta qué alcance se le puede delegar trabajo a la IA?”.

2. Cuando la IA falla, el problema no es solo “falta de capacidad”

La IA todavía no siempre tiene éxito.
Hay casos en los que los errores se repiten, o en los que dice haber corregido algo pero el problema permanece en la pantalla real.
Al principio, el autor respondía copiando los errores y pasándoselos a la IA.
Luego, al usar Playwright para hacer que la IA abriera directamente el navegador y ejecutara pruebas, se dio cuenta de que también podía delegarle a la IA los procedimientos de verificación que antes hacía una persona.
Este caso muestra que algunas cosas que se consideraban límites de la IA en realidad eran límites que surgían porque el usuario no se las había indicado.

3. Pensar de forma AI Native es delegar el procedimiento completo

El autor deja atrás la mirada de usar la IA como una simple herramienta auxiliar y pasa a hacer que la IA ejecute el procedimiento completo que él mismo realizaba.
Convierte trabajos repetitivos en comandos, skills y workflows, e intenta especificar su conocimiento tácito.
Como ejemplo, crea flujos de comandos como /plan, /prd, /debug, /refactor, /verify y /retrospect.
Lo importante no es decirle simplemente a la IA “escribe el código”, sino convertir en reglas incluso cuándo debe preguntar, cuándo debe detenerse y cuándo debe verificar.
Con esto, el desarrollador transforma su forma de trabajar y sus criterios de juicio en una estructura reutilizable por la IA.

4. El know-how personal se absorbe rápidamente como funcionalidad de las herramientas

Los comandos y workflows que el autor creaba por su cuenta aparecen con el tiempo como funciones y conceptos oficiales, como Skill, memory, hooks y orchestration.
Cuanto más efectiva es una metodología individual de uso de IA, más rápido se absorbe como funcionalidad de producto o como metodología común.
Por lo tanto, es difícil crear una diferenciación de largo plazo solo con prompts o tips específicos para usar bien la IA.
Lo importante no es la metodología en sí, sino hasta dónde se la aplicó a problemas reales y qué límites se experimentaron.

5. La IA amplía el tamaño de los problemas que puede abordar un desarrollador

La IA permite que el autor experimente en la práctica con ideas grandes que antes no intentaba por costos y tiempo.
Por ejemplo, crea rápidamente herramientas para desplegar código y documentos como si fueran un canvas, visores de MD, herramientas de análisis de código y herramientas auxiliares para desarrollo.
El punto clave no es que la IA entregue de inmediato un producto terminado, sino que reduce la barrera de entrada para comenzar.
El desarrollador cambia su forma de pensar de “¿podré construir esto?” a “¿hasta dónde puedo intentar construirlo, al menos para empezar?”.

6. Al abordar problemas grandes, aparecen las tareas de desarrollo fuera de la codificación

Cuando aumenta la producción de código con IA, al desarrollador le cuesta leer todo el código directamente y guardar el contexto en su cabeza.
Al codificar directamente, el contexto, el juicio y la comprensión de la estructura se acumulaban de forma natural; al delegarle la codificación a la IA, eso no queda registrado automáticamente.
Por eso, la documentación, las pruebas, los issues, los reportes de trabajo y los registros de los motivos de los cambios se vuelven importantes.
Esto no es trabajo administrativo, sino un mecanismo central para mantener el contexto de desarrollo en la era de la IA.
Se enfatiza que la capacidad de preservar contexto y criterio se vuelve tan importante como la capacidad de codificar.

7. Más commits y pruebas no significan necesariamente mejor producto

Al usar IA, la cantidad de commits, archivos, pruebas y documentos crece rápidamente.
Sin embargo, que aumenten los números no significa que el producto mejore realmente.
Pueden agregarse funciones, pero con una UX incómoda, o las pruebas pueden pasar mientras el flujo real de la pantalla sigue siendo inestable.
Al principio, el autor intentó ver esto solo como un problema de calidad y estructura del código.
Pero experimenta que mejorar la estructura del código no hace que la experiencia de producto mejore automáticamente.
En definitiva, la producción de código y la mejora del producto son problemas distintos, y se necesita un juicio separado sobre la calidad como producto.

8. El frontend es un área especialmente propensa a tambalear con IA

La IA puede crear rápidamente una UI inicial convincente, como dashboards, landing pages o pantallas de administración.
Sin embargo, un frontend a nivel de producto real exige criterios complejos como sistema de diseño, gestión de estado, accesibilidad, manejo por teclado, estados de excepción y flujos de usuario.
Muchas exigencias del frontend se expresan con lenguaje ambiguo, como “que se sienta natural”, “menos incómodo” o “que dé sensación de estar seleccionado”.
En el proceso de convertir esos requisitos ambiguos en código, los resultados de la IA pueden dispersarse fácilmente.
Por eso, para usar bien la IA en frontend, se necesitan criterios y capacidad de juicio para fijar las partes que salieron bien y hacer que solo se vuelvan a corregir las partes deficientes.

9. Los buenos resultados no salen de una sola vez, se construyen mediante un proceso de convergencia

El autor cambia su percepción al ver un prototipo de alta calidad creado con IA por una persona de planificación.
Ese resultado no fue creado con un único prompt especial, sino mediante correcciones repetidas “hasta que saliera”.
Este caso muestra que lo central en el uso de IA no es la generación automática simple, sino un proceso de convergencia en el que se observan continuamente las partes deficientes y se vuelven a pedir ajustes.
Quienes generan buenos resultados juzgan qué le falta al resultado creado por la IA y lo ajustan con persistencia hasta alcanzar el nivel deseado.
Incluso en la era de la IA, los criterios, la sensibilidad y la revisión continua de las personas marcan la diferencia en los resultados.

10. El desarrollador asume el rol de llevar resultados prometedores hacia un producto

Los resultados creados con IA pueden verse bien por fuera, pero tener una estructura interna de código frágil.
Surgen problemas como gestión de estado inestable, responsabilidades ambiguas entre componentes o pruebas que no garantizan el flujo real.
El rol del desarrollador no es evaluar esos resultados de forma incondicionalmente negativa ni descartarlos.
Al mismo tiempo, tampoco deben productizarse tal como están.
El desarrollador debe ordenar la estructura, señalar riesgos, crear unidades testeables y dejar contexto para que los resultados prometedores puedan llegar más lejos.
Es decir, el rol del desarrollador se amplía: pasa de ser “la persona que construye todo sola hasta el final” a “la persona que conecta los resultados creados por la IA y las personas con un producto sostenible”.

11. Los roles de desarrollo en la era de la IA no convergen en uno solo

Cuando baja la barrera de entrada para codificar, también se diversifican los tipos de personas que participan en el desarrollo.
Planificadores, diseñadores, PM y responsables de negocio también pueden crear prototipos funcionales o herramientas internas mediante IA.
Esto no significa que desaparezca la necesidad de desarrolladores, sino que los roles relacionados con el desarrollo se vuelven más segmentados.
El autor lo compara con el ecosistema de YouTube.
Así como YouTube no eliminó a los profesionales del video, sino que diversificó roles como presentadores, editores, planificadores, operadores de canales y creadores de plataformas, la IA también puede diversificar los roles de desarrollo.
En el futuro probablemente coexistirán quienes construyen sistemas profundos, quienes refinan prototipos hasta convertirlos en productos, quienes crean capas donde la IA pueda trabajar bien y quienes resuelven problemas directamente.

Conclusión

El desarrollador debe diseñar el desarrollo posterior a la codificación

La conclusión de la publicación no es una dicotomía entre “¿hay que seguir codificando o hay que soltarlo?”.
En la medida en que la IA ya puede ejecutar la codificación, los desarrolladores deben aprender empíricamente qué delegarle a la IA y qué juzgar directamente.
En particular, las siguientes capacidades se vuelven importantes.
- La capacidad de plantear problemas más grandes
- La capacidad de convertir procedimientos repetitivos en skills y workflows
- La capacidad de estructurar requisitos, documentación, pruebas e issues
- La capacidad de revisar los resultados de la IA y volver a indicarle lo que falta
- La capacidad de pulir resultados rudimentarios hasta convertirlos en productos sostenibles
- La capacidad de conectar con IA incluso herramientas y flujos de trabajo fuera del código

Mensaje central

La IA no es tan perfecta como esperan los desarrolladores, pero puede realizar muchas más tareas de lo que parece.
Antes de concluir que la IA no puede hacer algo, hay que experimentar hasta dónde se le puede pedir.
A la inversa, que la IA facilite algo no significa que haya que confiar sin más en sus resultados.
El desarrollador debe asumir el rol de juzgar, hacer converger, preservar el contexto y llevar a producto los resultados creados por la IA.
En definitiva, el desarrollador en la era de la IA se acerca menos a alguien que escribe mucho código directamente y más a alguien que diseña problemas, procedimientos, criterios y contexto para que los resultados creados por la IA y las personas conduzcan a mejores resultados.