El Verdadero Problema con la IA en Programación NO es la Herramienta

No me importa cómo llegó el código a tu IDE

Me encontré con un artículo en Genbeta que resume perfectamente lo que pienso sobre el uso de IA en programación. Citan a Alex Kondov, ingeniero de software, quien lo expresa con una claridad brutal: el código podría venir de tus dedos, un foro, un LLM o monos infinitos escribiendo. Lo único que importa es lo que se fusiona en el repositorio.

La pregunta no es si usar o no IA, sino si quienes la usan se preocupan por el impacto de su trabajo a largo plazo. Y ese es el punto clave: la herramienta nunca fue el problema; la falta de responsabilidad y criterio sí lo es.

Los tres pilares del código que importan

Cuando apruebo un pull request, me centro en tres aspectos fundamentales que Kondov identifica perfectamente: exactitud (el código produce el resultado correcto), comprensibilidad (el equipo podrá entenderlo dentro de seis meses) y mantenibilidad (será posible modificarlo sin romper todo).

El origen del código es completamente irrelevante si cumple estos criterios. Tener la IA a mano se ha convertido para muchos en un incentivo para pasar del criterio, y ese es el verdadero problema.

El "bad coding" de la era IA

En mi experiencia revisando y desarrollando código generado por IA, encuentro patrones que Kondov define como "bad coding". Implementaciones completas de utilidades que ya existen en el proyecto. Configuraciones globales alteradas sin necesidad. Clases orientadas a objetos en proyectos que adoptaron explícitamente el paradigma funcional.

Este estilo donde todo parece correcto superficialmente pero chirría en contexto no lo genera la IA por sí sola. Lo genera la falta de criterio al aceptar sugerencias automáticas. Como dice Kondov, son soluciones técnicamente válidas pero completamente ajenas a las convenciones del equipo.

La idolatría destructiva a la velocidad

El artículo menciona una anécdota de Kondov que me parece la completamente acertada: un camarero novato preparando cafés con prisa ante una fila de clientes. Resultado: bebidas mal hechas, derrames, caos. La programación actual vive este momento, obsesionada con entregar rápido, sacrificando calidad y principios fundamentales.

Lo sorprendente es que Kondov esperaba que esta presión llegara del área de finanzas (supervisores), pero se encontró con que muchos programadores son quienes voluntariamente abandonan estándares construidos durante décadas en nombre de la velocidad. Esa es la verdadera traición a nuestra profesión.

Mi aproximación con Claude Code

Trabajo diariamente con Claude Code, pero mi metodología es específica. Le doy contexto tanto de Laravel como de mi proyecto particular. Le explico cómo están definidas las piezas, cómo funciona todo. No cargo 20 agentes para hacerlo todo o cada una de las partes, porque he visto que eso realmente se convierte en algo que resta más que suma.

En lugar de usar lo que llaman "ingeniería de contexto segmentada" (múltiples archivos de contexto para todo), prefiero trabajar con contexto sobre mi proyecto y prompts específicos para cada feature, fix, refactor o test. Soy muy productivo, pero mantengo la consistencia del proyecto. Nunca activo el autopilot para que acepte todo automáticamente. Todo lo que se genera lo valido, rectifico y ajusto según mis estándares.

La IA se equivoca. La IA no suple desarrolladores, los agiliza, pero no los reemplaza en absoluto.

El problema de los "prototipos" vendidos como aplicaciones

Veo demasiados vídeos en YouTube donde se presentan "aplicaciones completas" hechas con IA. Seamos claros: no son aplicaciones, son prototipos efímeros. Una aplicación real es un sistema que debe sostenerse en el tiempo, no un demo que funciona durante cinco minutos.

Estos YouTubers creen dominar Claude Code de manera espectacular, pero terminan con aplicaciones mediocres, en demasiado tiempo, y con código del cual no han revisado ni una línea. Eso es lamentable y engañoso para quienes están aprendiendo.

Usar IA con responsabilidad: Mi flujo de trabajo

El mensaje central no es rechazar la IA, sino usarla bien. Mi proceso es sistemático:

Al arrancar un nuevo proyecto, lo primero que hago es ejecutar el comando init para dar contexto. Recientemente salió Laravel Boost, un servidor MCP que podemos añadir a Claude Code. Proporciona contexto actualizado de tu proyecto Laravel y las dependencias que estés utilizando.

Segundo, le explico mi arquitectura y patrones en pequeños archivos llamados guidelines. En Laravel se pueden hacer las cosas de mil maneras, pero cada equipo tiene su forma. En la plataforma he publicado libros digitales sobre estos patrones: acciones, viewmodels, modelos organizados, filtros. Son piezas pequeñas que puedes aplicar según necesites, no arquitecturas complejas que abarcan todo el proyecto.

Tercero, le asigno tareas pequeñas y específicas. No le pido que haga un blog completo con un prompt. Le doy una feature, le explico de qué trata, que haga un plan inicial, valido ese plan, y recién entonces procede. Si no estoy de acuerdo, le doy más información.

El costo oculto de la velocidad

Conforme el proyecto crece, mantener la consistencia se vuelve más difícil. Gran parte del tiempo que "ahorramos" con IA lo invertimos después en refactorización. Tenemos que ser consecuentes: si algo se hace muy rápido, no tendrá la misma calidad inicial.

Kondov lo expresa perfectamente: no basta con aceptar lo que produce un modelo. Hay que revisarlo, ajustarlo, asegurarse de que respeta las convenciones del proyecto. La mantenibilidad es clave. El código no se mide solo por lo que funciona hoy, sino por cómo se podrá modificar mañana.

Mejores prompts, mejores resultados

Las recomendaciones prácticas de Kondov son sólidas: escribir mejores prompts, especificar qué librerías usar, dar ejemplos concretos, trabajar en archivos pequeños. Y sobre todo, seguir los principios de siempre. La IA puede ser un aliado poderoso, pero no sustituye el juicio profesional.

La realidad que muchos no quieren ver

Me siento completamente identificado con este análisis. No podemos, como desarrolladores de software, pretender que la IA haga todo el trabajo con un prompt mágico. Si creemos eso, somos ilusos e ingenuos.

Lo que sí podemos hacer es usar la IA como herramienta potente bajo nuestro control. Darle contexto de calidad, guiarla con criterio, validar cada resultado. Un desarrollador sigue siendo esencial: para pilotar, controlar y saber qué se está haciendo.

Los prototipos rápidos tienen su lugar, pero no los confundamos con software de producción. Software real es el que se mantiene en el tiempo, el que otros pueden entender y modificar, el que sigue estándares y convenciones. Esa es nuestra responsabilidad profesional, con o sin IA.