500 horas programando con IA: los hábitos que separan los buenos resultados de los malos

La premisa suena casi demasiado simple: un desarrollador conocido como The Coding Sloth, después de más de quinientas horas programando con ayuda de la IA, afirma haber descubierto por qué los resultados varían tanto de un usuario a otro. Algunos programadores descartan los asistentes como inútiles mientras otros los elogian, y su respuesta es que la diferencia rara vez es el modelo. Lo que decide el resultado es el operador, sobre todo con qué precisión expresa su intención y qué tan sólidos son sus hábitos de ingeniería.

El consejo inicial es deliberadamente provocador: aprende a programar antes de apoyarte en la máquina. En este planteamiento, la IA multiplica el conocimiento existente en lugar de reemplazarlo. Una persona que no puede leer el código generado no puede evaluarlo, no puede depurarlo y no puede distinguir un disparate seguro de una respuesta correcta. La fórmula aproximada es que externalizar tu pensamiento solo funciona cuando hay un pensamiento que valga la pena externalizar.

El segundo consejo extiende el primero: sé tan específico como puedas. La mayoría de los resultados decepcionantes se remontan a solicitudes mal especificadas, y el video argumenta que los programadores, rara vez famosos por sus habilidades de comunicación, ahora necesitan esas habilidades más que nunca. La calidad de las respuestas sigue la calidad del contexto proporcionado, así que describir el trabajo de forma superficial casi garantiza un resultado genérico o defectuoso.

Para respaldar la afirmación, monta un pequeño experimento controlado, pidiendo al asistente de codificación de JetBrains, Junie, que construya un clon de Google Docs tres veces con detalle creciente. El nivel uno es una exigencia de tres palabras, sin stack, sin diseño y sin restricciones. El nivel dos añade una descripción del producto en lenguaje llano pero sin tecnicismos. El nivel tres se lee como una orden de trabajo real: stack tecnológico exacto, comandos de terminal, documentación de referencia, capturas de pantalla de la apariencia deseada y enlaces que el asistente puede consultar.

Los resultados se dividen con nitidez. La solicitud mínima no produce nada utilizable, aunque Junie gana crédito por detenerse a pedir aclaraciones en lugar de adivinar y emitir basura. La solicitud intermedia produce un andamiaje donde la mayoría de las funciones pedidas existen pero llegan rotas, con errores y una pantalla sin estilos que exige reparación manual. La solicitud detallada funciona al primer intento, con las funciones en su lugar y un código visiblemente más limpio, porque el humano había decidido casi todas las elecciones de arquitectura de antemano.

Dos tácticas de apoyo acompañan al experimento principal. Primera, deja de tratar la búsqueda y la IA como rivales: localiza tú mismo la documentación y entrégasela al asistente, ya que los asistentes actuales pueden navegar por la web y muchos proyectos ahora publican documentación apta para máquinas en formato llms.txt. Segunda, un atajo para los perezosos con apalancamiento real: redacta la solicitud técnicamente completa pero tosca, y luego pide al propio modelo que la reescriba bajo buenas reglas de prompting.

El siguiente principio es el consejo más antiguo del video: divide los trabajos grandes en pequeños. Los asistentes brillan en trabajo de alcance acotado y tropiezan con asignaciones desbordantes, lo que reformula la sabiduría clásica de la ingeniería de mucho antes de los modelos de lenguaje. Planificar la solución, descomponerla y entregarle la escritura al asistente mantiene al humano en el asiento del pensamiento. La regla cabe en una frase: entrega la escritura, nunca el pensamiento.

Reducir los resultados descuidados merece su propio patrón, una forma de solicitud en tres partes: la tarea descrita de la forma más concreta posible, material de contexto con archivos, documentación e imágenes, más una sección do-not que enumere todo lo que debe permanecer intacto. La demostración añade una función de comentarios al estilo Docs siguiendo exactamente esta forma y lo logra en cuestión de minutos. Resulta que restringir al asistente importa tanto como instruirlo.

Los archivos de memoria y las integraciones de herramientas se complementan: un documento markdown que vive en el repositorio registra qué es el proyecto, qué stack usa y qué comandos importan, de modo que el asistente lo lee en cada sesión en lugar de redescubrir lo básico. MCP, el protocolo abierto que conecta capacidades externas a los asistentes, añade un recuperador de documentación para trabajo web, una integración de framework que expone errores de compilación y un puente de navegador que muestra datos de consola y rendimiento. El consejo es armar la combinación que coincida con tu propio stack en lugar de copiar la lista, con plantillas listas para stacks populares que abaratan el inicio.

La última regla de trabajo es la verificación: nunca dejes que el asistente solo escriba código, dale siempre una forma de demostrar que el código funciona. Pruebas, ejecutar la aplicación en un navegador, comprobaciones por línea de comandos, pipelines de integración, cualquier cosa falsable cuenta, y el asistente puede redactar las comprobaciones él mismo siempre que un humano confirme que realmente pasan. Las tareas de diseño se combinan naturalmente con las herramientas de navegador descritas antes.

El argumento final ata todos los cabos: los asistentes amplifican los hábitos que ya llevas. Los desarrolladores que especifican con cuidado, descomponen problemas, documentan proyectos y prueban el código reciben esas virtudes devueltas con intereses. Los desarrolladores que se saltan las pruebas e ignoran los casos límite reciben esos defectos devueltos con intereses también, por eso el video termina más como un llamado a mantenerse preparado que como un discurso de venta.