- GenAI (LLM) está aumentando la productividad de los desarrolladores con funciones de generación automática y asistencia de código
- Desde hace tiempo han existido herramientas de “programación sin código”, pero al final el proceso real de ingeniería de software sigue teniendo una complejidad propia
- Desde el lanzamiento de ChatGPT, el rápido avance de las herramientas de IA ha sido notable, pero más que transformar radicalmente todo el proceso, su papel ha sido acortar de forma importante algunas etapas dentro de un problema dado
La forma real de uso entre desarrolladores se divide en dos ramas
- Bootstrappers
- Usan herramientas como Bolt, v0 y Screenshot-to-code para implementar rápidamente nuevos proyectos o MVP
- A partir de un diseño (como Figma) o incluso de un concepto preliminar, la IA genera una base de código inicial completa
- Crean prototipos funcionales en cuestión de días o incluso horas
- Aunque no sean completos a nivel de producción, destacan para validar ideas
- Priorizan la validación rápida y la iteración
- Iterators
- Usan Cursor, Cline, Copilot, WindSurf y similares en el desarrollo cotidiano
- Utilizan IA para autocompletado de código, refactorizaciones complejas y generación de pruebas y documentación
- Delegan en la IA tareas como pruebas complejas, documentación y refactorización, pero revisan constantemente los resultados
- La usan como una especie de “programador en pareja” para resolver problemas en conjunto
- Repiten el proceso de seleccionar, corregir y complementar las sugerencias de la IA hasta evolucionar el código hacia una mejor versión
El problema del 70%: la dificultad del “último 30%” - la paradoja de la curva de aprendizaje de la IA
- La IA puede producir código rápidamente hasta alrededor del 70%, pero el último 30% se convierte en un gran obstáculo
- Se genera un círculo vicioso donde al corregir un bug menor se rompe otra parte del sistema
- En especial, las personas sin formación técnica o los juniors suelen aceptar todo el código sugerido por la IA y provocar problemas en cadena con facilidad
- Les cuesta entender por qué los cambios sugeridos por la IA terminan causando problemas
- Los desarrolladores senior con experiencia pueden inferir rápidamente la causa de los bugs, reestructurar el código y además considerar seguridad y rendimiento para cubrir lo que la IA pasó por alto
- Aunque usan activamente la IA, revisan y refactorizan sin parar para convertirlo en “código mantenible”
- Si un junior o una persona no desarrolladora acepta sin pensar el código generado por IA, existe el riesgo de crear un “código castillo de naipes” que se derrumba fácilmente en producción
- Paradoja del conocimiento
- Un senior puede implementar rápidamente junto con la IA problemas que ya conoce
- Un junior necesita aprender a través de la IA, pero si le falta base técnica, tendrá grandes dificultades al depurar y validar
Patrones de uso efectivos
- Borrador de IA y luego refinamiento
- Cuando la IA realiza una implementación inicial, luego una persona la revisa, refactoriza y prueba directamente
- Se agregan manualmente el manejo de errores y los casos excepcionales, y se refuerzan las pruebas automatizadas y el proceso de revisión para elevar la confiabilidad
- Se fortalece la modularidad, el manejo de errores, las definiciones de tipos y el diseño de arquitectura para hacer posible el mantenimiento
- Mantener conversaciones por unidad de trabajo
- En lugar de entregar un contexto grande de una sola vez, se usan prompts independientes para problemas pequeños y así obtener respuestas más enfocadas
- Se revisan y confirman cambios con frecuencia, y se incorpora feedback en ciclos cortos
- Un enfoque de “confiar, pero verificar”
- La IA puede crear el borrador, pero la lógica importante, el manejo de errores y los temas de seguridad deben quedar en manos humanas
- Siempre se escriben casos de prueba y se revisan cuidadosamente el rendimiento, la seguridad y la solidez estructural
Implicaciones para los desarrolladores
- Empezar en pequeño
- Conviene empezar usando IA en tareas pequeñas bien definidas o problemas de alcance claro, y revisar con cuidado el código generado
- Antes de pasar a funciones de gran escala, hay que cubrir bien las pruebas y la documentación, y luego ampliar el alcance gradualmente
- Mantener la modularidad
- Se debe separar adecuadamente la base de código para evitar que el código generado por IA se mezcle estructuralmente
- Conviene dividir archivos y funciones en unidades pequeñas, y definir con claridad las interfaces y el flujo de dependencias
- Confiar en la experiencia
- La IA debe usarse como apoyo, pero el juicio final debe basarse en la propia experiencia
- Es mejor desconfiar de código o diseños sospechosos y respetar los estándares de ingeniería
El auge de la ingeniería de software agentic
- Si antes las herramientas de IA se limitaban a responder instrucciones y generar código, hacia adelante evolucionarán hacia el concepto de Agentic
- La IA agentic planifica, ejecuta y verifica objetivos por sí misma, y opera con mayor autonomía
- Claude (Anthropic), Cline y otros ya van más allá del simple autocompletado: pueden abrir automáticamente el navegador y ejecutar pruebas
- El proceso de depuración también cambia
- Un agente puede detectar posibles problemas por su cuenta, ejecutar conjuntos de pruebas e incluso revisar el estado de la UI para proponer correcciones
- Las herramientas del futuro no tratarán solo con código
- Podrán entender e integrar varios canales de entrada, como capturas de pantalla de UI, diagramas y conversaciones por voz
- Lo que debe hacer el desarrollador en este flujo
- Permitir que la IA trabaje de forma creativa, pero mantenerla guiada por humanos y operando dentro de una arquitectura sana
- Construir un fuerte ciclo de retroalimentación entre humanos e IA
- Se espera un modelo de colaboración donde los humanos definan el marco general y los objetivos, y los agentes se encarguen de las tareas de detalle
- Así como se dice que “el lenguaje de programación más importante es el inglés”, crecerá la importancia de expresar los requisitos con lenguaje natural de forma clara y precisa
¿Volverá la artesanía del software?
- Gracias a la IA, los prototipos y demos pueden construirse rápidamente
- Sin embargo, cuando los usuarios reales empiezan a usar el software en entornos variados y con casos límite, aparecen los problemas
- Mensajes de error incomprensibles para el usuario
- Entornos especiales que provocan fallas (casos límite)
- Diseños que no consideran en absoluto la accesibilidad (Accessibility)
- Problemas de rendimiento en dispositivos lentos
- Los detalles de UI/UX y similares terminan definiendo la calidad
- Desde la perspectiva del consumidor, para que un producto esté bien pulido hacen falta atención al detalle y consideración humana
- Si la IA reduce el trabajo repetitivo, los desarrolladores podrán concentrarse en ese nivel de acabado detallado
- Podrán dedicar más tiempo a áreas humanas y profesionales como la experiencia de usuario, los casos límite y un manejo de errores con sentido
Reflexiones adicionales
- El proceso de ingeniería de software abarca muchas áreas como planificación, diseño, implementación, validación, monitoreo y mantenimiento, y actualmente la IA mejora sobre todo la eficiencia en la parte de “escritura de código”
- En el pasado también hubo intentos de hacer que “personas no desarrolladoras creen software fácilmente” mediante COBOL, Visual Basic y plataformas no-code, pero cuando la complejidad aumentaba, al final siempre se necesitaban desarrolladores con experiencia
- Cuanto más hagan crecer las herramientas LLM la cantidad de código, más probable es que los proyectos complejos necesiten más ingenieros senior
- Los desarrolladores con experiencia que sepan usar IA pueden incrementar aún más su valor
- En conclusión, en lugar de reemplazar por completo a los desarrolladores, parece que las herramientas de IA evolucionarán para volver todavía más poderosos a quienes ya tienen criterio y experiencia
Reflexiones adicionales (incluyendo comentarios de Gergely)
- En ingeniería de software, la codificación en sí nunca ha representado una parte tan grande del trabajo
- En el pasado, Fred Brooks clasificó aproximadamente el tiempo de trabajo en software así:
- ⅓ planificación
- ⅙ codificación
- ¼ pruebas de componentes y del sistema
- ¼ pruebas del sistema (todos los componentes manualmente)
- Desde la perspectiva actual, el tiempo de codificación (incluyendo pruebas) ha aumentado, pero la planificación, la revisión de código, el monitoreo y el rollout siguen ocupando una parte importante
- 20% planificación
- 40% codificación (código + pruebas)
- 20% revisión de código (del trabajo de otras personas)
- 20% preparación para producción + rollout + pequeños ajustes durante ese período + monitoreo + alertas
- El proceso de crear buen software
- 1. What: decidir qué construir
- Incluye brainstorming, diseño, pruebas con usuarios y colaboración con product managers y stakeholders del negocio
- En una startup, esta etapa puede ser muy breve (“construyámoslo y veamos la reacción”)
- En una empresa ya establecida, puede tomar más tiempo decidir qué construir para no confundir a los clientes actuales
- 2. How: planear cómo construirlo
- Se diseña en detalle cómo implementar el producto, función o servicio
- Se analizan impactos en la arquitectura, dependencias y estrategia de pruebas
- Las startups pueden omitir este proceso e ir directo a ejecutar, pero en organizaciones grandes ignorar el diseño previo puede hacer que después los problemas sean mayores
- La mayoría de los equipos pasa por cierto proceso de planificación usando Design doc, RFC, ADR y similares
- 3. Build: implementar la funcionalidad
- Se escribe en código la función o producto deseado y se verifica que funcione correctamente
- 4. Verify: validar
- Antes de desplegar a producción, se comprueba minuciosamente que funcione como se esperaba
- Especialmente en servicios financieros, donde un mal funcionamiento puede causar consecuencias graves, el proceso de QA es riguroso
- 5. Ship it: desplegar
- Se hace merge de los cambios y se libera a los clientes
- Existen muchas formas de desplegar a producción
- 6. Monitoring and oncall: monitoreo y on-call
- Si surge un problema en el producto, se detecta y resuelve de inmediato
- También se toman medidas posteriores para evitar que la misma falla vuelva a ocurrir
- 7. Maintain: mantenimiento
- Se recopilan quejas y feedback de usuarios, y se decide qué bugs corregir y qué mejoras priorizar
- También incluye filtrar el feedback que puede ignorarse
- 8. Migrate: migración
- Cuando el producto cambia de forma importante o cambia el stack tecnológico, puede ser necesaria una migración grande
- Aunque hoy las herramientas de IA ayudan mucho en la etapa de “Build”, también vale la pena preguntarse qué tan útiles serán en las otras 7 partes mencionadas arriba
- Desde la década de 1960 ha persistido el “sueño de que personas no desarrolladoras puedan crear software sin desarrolladores”
- COBOL, Visual Basic y no-code son algunos ejemplos
- Sitios web simples pueden hacerse incluso sin escribir código, pero en productos complejos la ingeniería sigue siendo necesaria
- Cuanto mayor es la expresividad, mayor es también la complejidad, porque hay que indicarle a la IA con mucho detalle “cómo debe comportarse”
- Cuanto más código produzca la IA, más probable es que aumente la necesidad de ingenieros especializados que mantengan ese código y gestionen la arquitectura
- Los desarrolladores senior que hoy aprenden a trabajar con LLM tienden a ser más productivos y a aportar más valor dentro de las empresas
Agentes de IA: una promesa importante, pero también un “territorio desconocido” en 2025
- Dos años después del lanzamiento de los LLM, muchos desarrolladores han aprendido a usar LLM para coding e ingeniería de software
- Los LLM aportan mucho en tareas como prototipado, cambio a lenguajes desconocidos, validación de la precisión de los resultados y detección de respuestas incorrectas (alucinaciones)
- Sin embargo, los agentes de IA aún están en una etapa temprana
- Hoy, el agente disponible de forma relativamente general es más o menos Devin, con un costo elevado de 500 dólares al mes y opiniones divididas
- A medida que entra más capital de venture, se espera la aparición de más herramientas de agentes de IA para coding
- También es muy probable que los precios vayan bajando gradualmente
- GitHub Copilot parece que pondrá a disposición general su propuesta agentic, Copilot Workspace, en 2025
- También está previsto el lanzamiento de /dev/agents, fundado por el ex CTO de Stripe, entre otros
- Los agentes de IA buscan mejorar la precisión a costa de respuestas más lentas (proceso de “pensamiento”) y mayor costo
- Aún no está claro cuánto mejorará realmente la precisión con este enfoque ni en qué casos de ingeniería traerá aumentos importantes de productividad
Posible aumento en la demanda de ingenieros de software con experiencia
- Es posible que se necesiten más ingenieros de software con experiencia (senior o superior) que hoy
- Ellos pueden manejar mejor las herramientas de IA, saben cómo luce un “gran resultado” y pueden “instruirlas” con precisión
- Si detectan una generación de código incorrecta, pueden decidir en qué punto detener el proceso y corregir directamente el código fuente
- Con ayuda de las herramientas de IA, se escribirá muchísimo más código y más personas y empresas crearán sus propias soluciones
- Pero a medida que crezca la complejidad, también hará falta gente experta capaz de controlarla
- Incluso las empresas tecnológicas ya existentes podrían necesitar personal para manejar la complejidad adicional que traerá la IA
- Si los ingenieros de software desarrollan la capacidad de trabajar junto con la IA, pueden volverse más productivos y más valiosos
- Como lleva tiempo aprender a “dominar” por completo estas herramientas, es importante experimentar y aprender activamente en un entorno que cambia muy rápido
11 comentarios
Es un texto realmente muy bueno.
Estoy muy de acuerdo con el último párrafo, "posible aumento de la demanda de ingenieros de software con experiencia". ¿Será que uno lo aprovecha tan bien como lo que sabe? ^^
Como con Expo 52, en áreas donde últimamente han ocurrido cambios grandes, ni siquiera Claude, por más inteligente que sea, ayudaba mucho.
Tuve la experiencia de que insistía en sugerir código viejo y ya desaparecido, así que más bien terminaba estorbando.
Al final, parece que para usar bien la IA hay que tener entrenado el "ojo" para saber mirar.
Un detalle menor, pero tengo entendido que /dev/agents no es un agente de programación. Aún no se ha lanzado, pero se describe a sí mismo como un "SO para agentes de IA".
Personalmente, creo y apuesto a que en el futuro (o, según cómo se vea, en el mediano plazo) el rol de programador se reducirá en todos los puestos de ingeniería y el rol de TPM se ampliará.
Como Cursor escribe mejor el código, se lo delegaremos y las personas probablemente harán la mayor parte del trabajo en la capa de abstracción que está por encima.
Gracias por compartir. Yo también escribí hace poco un texto relacionado, y veo algunas similitudes. https://www.stdy.blog/can-junior-beat-coding-agent/
Resumen: el futuro de los desarrolladores en la era de la IA (versión optimista)
?? : ahora ya no se necesitan desarrolladores (versión pyme negrera)
Dios mío jajajaja
1+ jajaja
jaja, 100 puntos