Una reflexión necesaria sobre el “AI-Native Engineer”
He leído el artículo de Addyo sobre el “AI-Native Software Engineer” y, como Principal Backend Engineer que lleva años viendo promesas tecnológicas ir y venir, tengo opiniones bastante sinceras al respecto. No todas son cómodas de escuchar.
He visto suficientes “revoluciones” como para separar el grano de la paja. Y aquí hay mucho de ambos.
Lo que está funcionando (de verdad)
1. IA como copiloto, no como piloto
La metáfora del artículo sobre tratar la IA como un “programador junior disponible 24/7” es acertada. En mi experiencia trabajando con equipos, he visto developers usar GitHub Copilot y Claude de manera efectiva para:
- Boilerplate y código repetitivo: Escribir tests, generar configs, crear CRUDs básicos
- Documentación: Generar docstrings, READMEs, comentarios de código
- Refactoring simple: Renombrar variables, cambiar patrones básicos
// Esto funciona bien con IA
func (h *UserHandler) CreateUser(w http.ResponseWriter, r *http.Request) {
// La IA puede generar el boilerplate básico
// Pero la lógica de negocio sigue siendo tuya
}
2. Aceleración de la curva de aprendizaje
Donde realmente brilla la IA es ayudando a developers a entender ecosistemas nuevos. Un dev que viene de Java puede usar Claude para entender idioms de Go más rápido. Esto es oro para equipos con tecnologías diversas.
3. Debugging como rubber duck que habla
La capacidad de explicar un error a Claude y obtener hipótesis es genuinamente útil. No siempre acierta, pero te obliga a articular el problema, que ya de por sí es valioso.
Donde el hype se estrella con la realidad
1. “10x productivity” es marketing, no realidad
El artículo sugiere que la IA puede darte un “2x, 5x o tal vez 10x” en productividad. Como engineer que mide estas cosas, esto es wishful thinking.
La realidad que veo:
- 20-30% de mejora en tareas mecánicas (tests, configs)
- Prácticamente nulo en arquitectura, debugging complejo, o decisiones de producto
- Tiempo perdido cuando la IA te lleva por caminos erróneos
2. “Every engineer is a manager now” es problemático
La idea de que los engineers ahora “orquestan trabajo en lugar de ejecutarlo” me parece fundamentalmente errónea. Como engineer que trabaja con equipos, sé que gestionar requiere:
- Contexto de negocio que la IA no tiene
- Decisiones interpersonales que van más allá del código
- Responsabilidad por outcomes, no solo outputs
Los developers no se convierten en managers por usar IA. Siguen siendo developers con mejores herramientas.
3. La ilusión del “AI-first workflow”
La sugerencia de “dar toda tarea a la IA primero” es operacionalmente insostenible. En equipos reales:
- El contexto importa más que el código
- Las restricciones legacy no están en el training data de la IA
- Los requerimientos cambian más rápido de lo que puedes prompt-engineer
Herramientas: Lo bueno, lo malo, y lo innecesario
GitHub Copilot: El estándar de facto
- ✅ Funciona: Se integra bien, no estorba
- ✅ Predecible: Sabes qué esperar de él
- ❌ Limited: No va más allá de autocompletado inteligente
Cursor: Promisorio pero caro
- ✅ Potente: Realmente entiende contexto de proyecto
- ❌ Pricing: $20/mes por dev se suma rápido
- ❌ Vendor lock-in: Cambiar de editor es friction
Claude/ChatGPT: Útiles pero sobrevalorados
- ✅ Buenos para research y documentación
- ❌ Inconsistentes para código de producción
- ❌ Privacy concerns para código propietario
Bolt, v0, Replit: Marketing > Realidad
Los “one-prompt full-stack generators” son demos impresionantes pero productos cuestionables:
- Generan código que parece funcional
- Nunca está listo para producción
- Más rápido escribir desde cero que debuggear su output
// Lo que genera Bolt
const handleSubmit = async (e) => {
e.preventDefault();
// TODO: Add validation
// TODO: Handle errors
// TODO: Add loading state
console.log('Form submitted');
};
// Lo que necesitas en realidad
const handleSubmit = async (e) => {
e.preventDefault();
setLoading(true);
try {
const validatedData = validateForm(formData);
await submitToAPI(validatedData);
showSuccessNotification();
resetForm();
} catch (error) {
handleError(error);
logToSentry(error);
} finally {
setLoading(false);
}
};
La realidad en equipos de producción
Lo que funciona en la práctica:
IA para tasks específicos y acotados
- Generar tests para funciones existentes
- Explicar código legacy
- Crear documentación básica
Como herramienta de aprendizaje
- Entender patrones nuevos
- Explorar APIs desconocidas
- Traducir entre lenguajes/frameworks
Automation de lo obvio
- Commit messages
- PR descriptions
- Boilerplate code
Lo que NO funciona:
Autonomous agents en producción
- Demasiado imprevisibles
- Requieren más supervisión que hacer el trabajo tú mismo
- El debugging del debugging del AI es kafkiano
AI-first para arquitectura
- La IA no entiende trade-offs de negocio
- No conoce restricciones técnicas específicas
- Las decisiones arquitectónicas son irreversibles
Delegar responsabilidad a la IA
- El código sigue siendo tu responsabilidad
- Los bugs siguen siendo tu problema
- “Lo generó la IA” no es una excusa válida
Mis recomendaciones pragmáticas
Para Individual Contributors:
- Usa Copilot para boilerplate, nada más
- Claude/ChatGPT para research y explicaciones
- Mantén el escepticismo sobre autonomous agents
- Nunca commits sin review código generado por IA
Para Tech Leads:
- Establece guidelines claras sobre uso de IA
- Monitorea la calidad del código AI-asistido
- No ajustes estimaciones hasta ver resultados reales
- Educa al equipo sobre limitaciones de IA
Para Managers:
- No compres el hype de “10x productivity”
- Invierte en herramientas probadas (Copilot) antes que experiments
- Mantén procesos de QA rigurosos
- Budget para learning curve, no solo para licenses
El verdadero valor de ser “AI-native”
Ser “AI-native” no significa usar IA para todo. Significa saber cuándo usarla y cuándo no.
Los mejores developers que conozco usan IA como:
- Acelerador para tareas mecánicas
- Tutor para aprender conceptos nuevos
- Rubber duck que puede responder
NO como:
- Arquitecto de sistemas
- Decision maker de producto
- Replacement para pensar
Conclusión: Evolución, no revolución
El artículo original pinta un futuro donde engineers “orquestan” en lugar de “ejecutar”. Mi experiencia dice que esto es una interpretación romántica de lo que está pasando.
La realidad es más mundana pero también más sostenible: la IA está haciendo algunas tareas más fáciles, igual que lo hicieron los IDEs, los frameworks, o Stack Overflow.
Ser “AI-native” no es una transformación existencial. Es adoptar herramientas útiles mientras mantienes el juicio crítico.
Como dije cuando mi equipo empezó a usar Docker: “Es una herramienta poderosa, pero todavía necesitas entender lo que estás containerizando”.
Con IA es igual: es una herramienta poderosa, pero todavía necesitas entender lo que estás buildando.
¿Qué opináis? ¿Estáis viendo los “10x improvements” que promete el article? ¿O vuestra experiencia es más parecida a la mía?
Me encantaría escuchar historias reales, no demos de marketing. La realidad suele ser más interesante que el hype.
PD: Si tu company está considerando “autonomous AI agents” para production code, por favor, habla conmigo primero. Quiero evitarte algunos errores que he visto.
Comentarios