- Las herramientas de programación con IA automatizan la tarea fácil de escribir código, lo que genera un problema estructural: al desarrollador solo le quedan las tareas difíciles de investigación, comprensión del contexto y validación
- El fenómeno de que un desarrollador diga "la IA lo hizo por mí" sin entender directamente la salida de la IA es una señal de alerta similar al viejo copiar y pegar de StackOverflow
- El vibe coding es útil para hacer prototipos, pero en entornos reales de producción a veces la IA termina consumiendo más tiempo en lugar de ahorrarlo
- Gracias a la IA, cuando algo se despliega rápido una vez, eso se convierte en una nueva línea base, lo que provoca presión constante por mantener ese ritmo y termina en burnout como problema de gestión
- La clave es usar la IA no como proveedora de soluciones, sino como herramienta de investigación, y que el desarrollador mantenga la responsabilidad sobre todo el código
El problema de decir "la IA lo hizo por mí"
- Antes, los desarrolladores leían respuestas de StackOverflow, artículos o issues de GitHub y sacaban sus propias conclusiones después de verificar el contexto
- Nadie decía "Google escribió el código por mí" ni "está bien porque era el primer resultado de búsqueda"
- Últimamente ha empezado a aparecer la frase "la IA lo hizo por mí"
- Esto exagera lo que realmente ocurrió, o implica que el desarrollador no llegó a su propia conclusión
- En ambos casos hay un problema, y surge la misma preocupación que cuando se copiaba y pegaba código de StackOverflow: ¿de verdad entendiste el código que pegaste?
Los límites del vibe coding
- El vibe coding al principio es divertido y resulta útil para prototipos o proyectos personales de bajo riesgo
- Pero en el trabajo real, cada línea de código tiene consecuencias
- En un proyecto personal, se le pidió a un agente de IA que agregara pruebas a un archivo específico, y el archivo pasó de 500 líneas a 100
- La IA aseguró que no había borrado nada más, y después afirmó que el archivo originalmente no existía
- Cuando se le mostró el historial de git, se disculpó y reconoció que primero debió haber verificado si el archivo existía
- En este caso, la ayuda de la IA terminó consumiendo más tiempo en lugar de ahorrarlo
- Discutir con el agente y restaurar el archivo tomó más tiempo que escribir las pruebas directamente
- Si lo mismo ocurriera en un entorno como un codebase de salud, las consecuencias podrían ser graves
- Es importante usar la IA no como proveedora de soluciones, sino como herramienta de investigación, y detectar cuándo se equivoca requiere práctica
Una estructura donde la parte difícil se vuelve aún más difícil
- Escribir código era originalmente la parte fácil del trabajo de desarrollo
- Lo difícil era investigar, entender el contexto, validar supuestos y saber por qué cierto enfoque era el correcto
- Si la parte fácil se delega a la IA, el trabajo no disminuye; solo quedan las tareas difíciles
- Si se omite la investigación porque la IA ya dio una respuesta, entonces ni siquiera existe el contexto necesario para evaluar lo que produjo
- Leer y entender el código de otra persona es mucho más difícil que escribir código
- El código generado por IA es, en esencia, código de alguien más
- Se termina entregando a la máquina la parte en la que el desarrollador suele ser bueno (escribir), y dejando solo la parte más difícil (leer y revisar)
- Hay que revisar sin contar con el contexto que se construye al escribirlo uno mismo
Expectativas de sprint y burnout
- Si gracias a la ayuda de la IA algo se despliega rápido una vez, eso se convierte en una nueva línea base y luego se exige siempre esa misma velocidad
- La conversación cambia de "¿cómo lo hiciste tan rápido?" a "¿por qué no puedes hacerlo así siempre?"
- Esto no es un problema de ingeniería, sino un problema de gestión
- Un ingeniero agotado pasa por alto edge cases, omite pruebas y termina lanzando bugs
- Más incidentes → más presión → más sprints: un círculo vicioso
- Frente a la afirmación de que "la IA crea una productividad 10x", en realidad podría significar que un ingeniero de 0.1x pasó a ser de 1x
- Técnicamente puede ser 10x, pero la pregunta clave es si eso es un aumento real de productividad o simplemente deja en evidencia cuánto trabajo de investigación antes no se estaba haciendo
- El burnout y el lanzamiento de código de baja calidad anulan las ganancias de productividad que promete la IA
Habilidades senior, confianza junior
- A los agentes de programación con IA hay que verlos como senior para escribir código, pero con un nivel de confianza propio de un ingeniero junior respecto a sus resultados
- El código puede verse bien y probablemente funcione, pero como no tiene experiencia, hace falta revisarlo con mucho más cuidado
- Como analogía, un agente de programación con IA es como alguien que lee muy rápido y de pronto se une al equipo
- Puede ayudar con la investigación y escribir código, pero no estuvo en la reunión de la semana pasada donde se discutió el contexto importante
La importancia de la propiedad del código
- El desarrollador debe asumir una propiedad responsable no solo del código que escribió directamente, sino también del código generado por la IA
- Si por metas de velocidad poco realistas se copia y pega la salida de la IA, habrá problemas cuando seis meses después un nuevo integrante del equipo intente entender ese código o cuando ocurra una caída a las 2 de la mañana
- Decir "lo escribió la IA" no ayuda en ninguna circunstancia
Cómo puede ayudar la IA con la parte difícil
- Caso de un bug en producción: justo después de un gran release, un usuario reportó un bug de edge case en la visualización de zonas horarias
- El desarrollador responsable tenía que irse a clase en 30 minutos y el resto del equipo ya había salido
- Se usó la IA para avanzar la investigación, indicando que el bug estaba relacionado con cambios recientes y explicando cómo reproducirlo
- La causa era que algunos métodos deprecated tenían prioridad sobre los métodos actuales con reconocimiento de zona horaria, por lo que la conversión de zona horaria no se hacía correctamente
- En 15 minutos se documentaron en un issue de GitHub la causa raíz, ideas de solución y notas de investigación
- El desarrollador responsable confirmó la corrección y otro integrante del equipo completó las pruebas y el despliegue
- Se resolvió sin emergencia y sin horas extra
- La idea central que muestra este caso es una estructura de colaboración donde la IA se encarga del trabajo repetitivo de investigación y la persona aporta el contexto y la validación
- La IA debe usarse para reforzar la investigación, la validación y la comprensión del contexto; de lo contrario, se afianza una estructura en la que la parte fácil se vuelve más fácil y la difícil más difícil
3 comentarios
En mi opinión, los desarrolladores que vivían del copiar y pegar siguen copiando y pegando aunque usen LLM,
mientras que los desarrolladores que desde antes se preocupaban mucho por la calidad ahora parecen ponerle todavía más atención.
Opiniones de Hacker News
Programar con herramientas de asistencia de IA es una habilidad nueva completamente distinta de la programación tradicional centrada en humanos
Los lenguajes, frameworks y principios de desarrollo que tenemos buscan superar las limitaciones humanas, pero la IA tiene otras limitaciones
Al resolver problemas complejos, no sirve solo con dar un prompt y recibir un resultado; fue más útil explorar el espacio del problema mediante conversación y diseño iterativo
Los errores o alucinaciones de la IA incluso funcionan como una señal de si realmente estoy entendiendo bien el problema
Probé hacer un emulador retro y un ensamblador con vibe coding, y obtuve buenos resultados incluso con pocos prompts
Pero cuando intenté una parte propietaria de una app industrial específica que había hecho antes, el resultado fue pésimo por más prompts que le diera
Hay miles de ejemplos de emuladores en GitHub, pero para lo que yo quería hacer no había ningún ejemplo
La conclusión es simple: algunas cosas son fáciles y otras simplemente no salen
Si hay muchos ejemplos en GitHub, también existen en el espacio latente del LLM y puede sacarlos cuando quiera
Lo que intentaste simplemente no tenía ese tipo de ejemplos
Los frameworks especializados para una industria son difíciles de manejar con vibe coding, pero si simplificas el problema la IA ayuda muchísimo más rápido
Si adoptas por completo el vibe coding puedes lograr resultados geniales, pero la deuda técnica crece tanto que al final se siente como volverse esclavo de la máquina
Si la IA escribe miles de líneas de código por ti, se vuelve muy difícil entender o revisar su estructura
Al final parece que aumentarán el código y el software desechables: es fácil crear apps para resolver un problema puntual, pero eso implica grandes riesgos para un SaaS sostenible
La IA es una herramienta que da un fuerte efecto multiplicador (force multiplier)
Si la base del codebase es mala, la IA también copia ese estilo tal cual
En cambio, si tienes una base limpia y consistente, la IA mantiene esa calidad y funciona sorprendentemente bien
Al final, la clave está en la base de diseño (foundation)
La mayoría de los codebases tienen estructuras difíciles de mantener y de escalar, y la IA solo hace más visible ese problema
Igual que en la construcción, si los cimientos son débiles, incluso la mejor herramienta tiene límites
Así, los desarrolladores que lleguen después pueden entender por completo el contexto del proyecto
Al final hay que corregir primero las abstracciones clave para que la IA funcione bien
Los requisitos cambian constantemente y aparecen compromisos por eficiencia
Al final, el tiempo y el costo de oportunidad terminan pesando más que la calidad, porque los humanos no pueden seguir un plan de manera perfecta
La IA hace menos tediosas las partes tediosas
Pero discutir con un LLM es perder el tiempo
Lo eficiente es hacer cambios pequeños, hacer commit si funciona, y si no, desecharlo e intentarlo de nuevo
La IA no sirve para todo, y es importante elegir la herramienta adecuada
Si vas a jugar con un niño con pistola, mejor ponte chaleco antibalas
Suele decirse que leer el código de otra persona es más difícil que escribirlo, pero a mí eso me parece raro
Una función que me toma medio día escribirla la puedo leer y revisar en 10 o 15 minutos
Verificar que un código sea correcto es mucho más fácil que crearlo
Solo leer es fácil, pero editar, entender la estructura y encontrar mejoras requiere mucho más esfuerzo
Es porque se pierde el contexto que tenía al escribirlo
En realidad no es que leer sea más difícil, sino que la gente simplemente prefiere escribir algo nuevo
La mentalidad correcta es pensar que la IA facilita todo, pero eso mismo es una habilidad nueva y difícil de aprender
Ahora estamos en la era ENIAC de la IA, y todavía no existen conceptos equivalentes a lenguajes de alto nivel o sistemas operativos
En el futuro surgirá una disciplina llamada context engineering, y lo que hacemos hoy se verá primitivo
Si estructuras bien las cosas, la capacidad de la IA parece prácticamente infinita
Decir "se hizo con IA" en realidad significa "se usaron masivamente recursos de CPU de una empresa externa"
Hasta que no exista un agente de IA que yo posea por completo, me parece menos un progreso real y más bien robo de recursos a escala planetaria
La IA no hace más difícil el desarrollo
Más bien deja al descubierto las partes realmente difíciles que la gente venía ignorando
Durante los últimos 15 años, los desarrolladores ya venían haciendo una versión humana del vibe coding: copiar y pegar de Stack Overflow, refactorizar sin plan, y trabajar con la lógica de "mientras funcione en mi laptop, está bien"
Ahora que la IA hace eso mismo, de repente todos quieren planear y escribir tests
Si aunque sea más lento mejora la calidad, entonces eso sí es progreso real
La cultura actual de "sprint dentro de un maratón" se está acelerando todavía más por culpa de la IA
Pero si se usa sin supervisión, la IA se descarrila rápido, y leer código escrito por otros agota mucho más que corregir el propio
Le pedí a una IA "agrega tests a este archivo", y un archivo de 500 líneas terminó reducido a 100
Cuando le pregunté por qué, respondió: "ese archivo originalmente no existía"
Le mostré el historial de git y se disculpó diciendo que "debí haber verificado primero si existía"
Ayer le dije "olvida ese archivo" y literalmente borró el archivo
Un pequeño costo de revertir cambios es aceptable comparado con el valor que aporta la IA