Tras recibir duras acusaciones por falta de rigor, además de otros comentarios sobre mi artículo acerca de intentar usar un 'asistente de código por IA' por primera vez, la única respuesta racional y académica es asumir las críticas tras una revisión por pares particularmente difícil e intentar abordar los puntos planteados. La realidad, después de todo, no se preocupa por los sentimientos de uno, y puede haber más en esta tecnología de asistencia por IA que puede extraerse con una mirada más profunda.
Con este fin, haré lo posible por trabajar en cada punto, crítica y acusación planteada, para ver qué puedo aprender yo —y quizás otros— de este esfuerzo. Dichos puntos incluyen el uso del frontend incorrecto (es decir, Copilot) y el modelo incorrecto (siendo Claude Haiku 4.5), así como el error garrafal por mi parte de 'promptear mal'.
En aras de la debida diligencia, se investigarán los mejores frontends y modelos para tareas específicas, y finalmente se examinará el campo de minas verbal de la 'ingeniería de prompts' para conocer los enfoques estándar de la industria.
Junior Developer
La forma exacta de referirse a un asistente de codificación LLM sigue siendo fluida, con algunos comparándolo con la programación en parejas (pair programming), mientras que otros ven al asistente más como un motor de búsqueda glorificado que también tiene funciones de autocompletado de código, una especie de fusión entre un motor de búsqueda web e IntelliSense en Visual Studio. Esta relación y cómo mirarla es la causa de mucha controversia como resultado.
Otra perspectiva es la de que estos asistentes son más parecidos a desarrolladores junior. Después de todo, aparentemente pueden hacer todo el trabajo básico de boilerplate, escribir pruebas unitarias y realizar una serie de otras tareas básicas que están por debajo de los desarrolladores más senior. El corolario aquí es, por supuesto, por qué las empresas querrían contratar a otro desarrollador junior si el LLM puede cubrir estos puestos. Como era de esperar, ya se está informando que esto está sucediendo.
La pregunta del millón que queda es si todo esto es cierto, si un desarrollador junior todavía tiene valor. La respuesta parece ser 'sí', incluso si le preguntas a Microsoft. El argumento parece reducirse a que estos asistentes supuestamente automatizan gran parte del tedio que solía recaer sobre los desarrolladores junior, dejándolos libres para desarrollar habilidades más avanzadas, apoyados naturalmente por los mismos asistentes de codificación.
Fancier Automation
Esto nos lleva a la pregunta de si estos asistentes son realmente mucho mejores que las herramientas de automatización que han existido en los IDE durante muchas décadas, con mejoras discutibles a lo largo del tiempo. Ciertamente parecen ser más capaces, pero nunca superarán su programación y requieren mucho ajuste para que hagan lo correcto.
Volviendo a los desarrolladores junior por un momento: dejando de lado las manzanas podridas, ellos te avisarán si no entendieron algo correctamente, pedirán aclaraciones, admitirán que no saben algo y se ofrecerán a buscar información en la documentación si la desconocen. Ninguna de estas cosas son capaces de hacer estos chatbots glorificados, lo que hace que una comparación con las herramientas de automatización de IDE sea bastante justa, especialmente porque los desarrolladores junior tienden a ser despedidos si cometen errores tan graves como los que las herramientas LLM parecen cometer regularmente.
Si bien es cierto que estos nuevos asistentes de codificación tienen una ventana de contexto en la que "recuerdan" detalles previos, todavía estás lidiando con las limitaciones del modelo subyacente sin importar cuán buenas sean tus habilidades de ingeniería de prompts. También confabularán regularmente y tienes que aceptar que generan código y documentación que tiene tantas probabilidades de ser correcta como de estar completamente mal, incluso si muchos usuarios de estas herramientas parecen creer que son realmente más eficientes.
El gráfico anterior muestra la brecha entre la percepción del usuario y la realidad técnica. Por lo tanto, terminarás escribiendo casos de prueba para los casos de prueba y el código generado, mientras también realizas tareas de revisión de código, ya que no existe la posibilidad de establecer un nivel de confianza. Especialmente después de que borre todo tu disco duro o la base de datos de producción por segunda vez en la semana.
Si eso suena como el tipo de desarrollador junior o herramienta de automatización con la que te encantaría trabajar, entonces tienes un espíritu bastante aventurero. Mientras tanto, he tenido suficiente diversión incluso con herramientas de autocompletado de código como el mencionado IntelliSense o sus equivalentes en los diversos otros IDE que he usado a lo largo de los años como para no volver a usarlos nunca más. Es bastante malo cuando una herramienta de autocompletado de código se equivoca, pero es peor cuando el humano en el bucle no logra detectar el error evidente.
Model Frontends
Aunque generalmente nos referimos a ChatGPT, Claude o Copilot como un LLM, esto es técnicamente incorrecto, ya que estos son simplemente los frontends de chatbot que están escritos para proporcionar una experiencia de interfaz de lenguaje natural. La elección aquí es naturalmente bastante vertiginosa, ya que tienes una gama de actores principales, incluido el mencionado, cada uno de los cuales ofrece una interfaz web, así como la integración con varios IDE y el uso en la CLI para una fácil automatización.
De ahí la afirmación de que uno nunca debería usar el frontend web para programar, ya que necesita acceso a tu código y entorno local, lo cual tiene sentido si quieres más una experiencia de programación en parejas. Como mis 'IDE' de elección son Notepad++ y Vim, mis opciones aquí son, por supuesto, bastante limitadas. Existe un plugin de integración de terceros de OpenAI para NP++ llamado NPPOpenAI, pero eso parece ser todo.
Los chicos cool están, por supuesto, usando Visual Studio Code con integración directa de todos los frontends, pero esa opción parece tan atractiva como arrancarle la mitad de la memoria RAM a mi PC y golpearme los dedos con un martillo. Incluso como ex usuario ávido de Visual Studio Pro, me siento insultado a un nivel fundamental ante la mera idea.
Tal vez una de las herramientas de CLI como Copilot CLI sea una mejor opción para mí aquí como se sugirió, pero esto parecería ser más una forma de automatizar varias tareas de GitHub. A pesar de buscar, no pude encontrar una comparación objetiva de los diferentes frontends, solo muchas opiniones fuertes y varios planes de precios para el acceso a modelos, por lo que a todos los efectos, están siendo tratados como lo mismo.
The Model Catwalk
Se sugirió además que echara un vistazo a LiveBench.ai para comparar cómo funcionan los modelos en diversas tareas. Esto parece ser un recurso valioso, aunque solo sea por proporcionar lo que parece ser una forma bastante objetiva de comparar estos modelos individuales entre sí.
Al ordenar por el encabezado Coding Average, coloca a GPT-5.2 Codex de OpenAI en la parte superior, con Claude 4.7 Opus Thinking High Effort cerca, ambos con un poco más del 83%. El modelo Haiku 4.5 que estaba usando llega a un mero 72.17%, lo cual sigue siendo mucho mejor que los modelos por debajo del 60 por ciento cerca de la parte inferior. De los modelos gratuitos, Haiku 4.5 al menos parece no ser tan terrible, con Anthropic promocionándolo en octubre de 2025 como equivalente a Sonnet 4 cuando se trata de rendimiento de codificación:
El análisis de estos datos permite entender por qué la elección del modelo es crítica según la complejidad de la tarea. Vía CNX Software.
