La conversación sobre inteligencia artificial aplicada al desarrollo de software se está moviendo hacia un punto más interesante que el simple “hazme este código”. Una publicación viral en X resumía esta idea con una frase bastante acertada: muchos usuarios están usando Claude, o modelos similares, como si fueran un becario junior, cuando podrían sacarle más partido si lo trataran como un ingeniero senior al que se le pide análisis, arquitectura, revisión y criterio.
La idea tiene sentido, pero conviene matizarla. Un modelo avanzado no se convierte en ingeniero senior por recibir un prompt largo. Lo que sí cambia mucho es la calidad de la tarea cuando se le pide razonar antes de ejecutar, identificar riesgos, definir una arquitectura, revisar el contexto, proponer alternativas y dejar criterios de validación. En desarrollo de software, la diferencia entre una petición pobre y una buena especificación puede ser la diferencia entre un prototipo que “parece funcionar” y una base de código mantenible.
El problema no es Claude, es cómo se le pide trabajar
Muchos desarrolladores usan modelos de IA con instrucciones demasiado vagas: “corrige este bug”, “haz una app”, “mejora este componente” o “optimiza este código”. El resultado puede ser útil para salir del paso, pero también puede generar cambios superficiales, soluciones temporales, refactors innecesarios o código que no encaja con la arquitectura real del proyecto.
Los prompts compartidos en la publicación apuntan a un uso más maduro: pedir primero arquitectura, después implementación mínima, luego revisión, optimización y refactorización. Es una forma de obligar al modelo a actuar con más estructura. No se trata solo de obtener código, sino de obtener razonamiento técnico antes del código.
| Uso habitual pobre | Enfoque más útil |
|---|---|
| “Hazme una app” | “Diseña arquitectura, base de datos, API, UI y después implementa un MVP escalable” |
| “Arregla este error” | “Analiza causa raíz, casos límite y propón una corrección lista para producción” |
| “Optimiza esto” | “Detecta cuellos de botella, coste de memoria, renderizados innecesarios y valida impacto” |
| “Refactoriza” | “Mantén comportamiento, separa responsabilidades y mejora mantenibilidad” |
| “Crea un componente” | “Define props, estados, accesibilidad, responsive y ejemplos de uso” |
La diferencia no está en la longitud del prompt, sino en la calidad del encargo. Los buenos prompts describen rol, objetivo, contexto, entregables, límites y criterios de éxito. Esa estructura reduce la improvisación del modelo y facilita revisar si la respuesta sirve realmente.
Ocho formas de usar mejor un modelo de código
Los ocho prompts compartidos pueden agruparse en varias categorías: creación de producto, auditoría de código, depuración, arquitectura, rendimiento, Clean Architecture, flujo multiagente y componentes de interfaz. Todos tienen algo en común: empujan al modelo a pensar como parte de un proceso de ingeniería, no como una máquina de autocompletar.
| Prompt | Para qué sirve | Riesgo si se usa mal |
| App completa desde cero | Convertir una idea en MVP con arquitectura inicial | Puede generar demasiado código sin validar requisitos reales |
| Análisis y reestructura | Entender un proyecto y detectar deuda técnica | Puede proponer refactors excesivos si no se acota |
| Depuración senior | Buscar causa raíz y no solo parchear errores | Necesita logs, contexto y pasos de reproducción |
| Diseño de sistema + desarrollo | Unir arquitectura y primera implementación | Puede sobrediseñar si el producto aún es pequeño |
| Optimización de rendimiento | Detectar cuellos de botella y mejorar eficiencia | Sin métricas puede optimizar lo que no importa |
| Clean Architecture | Separar responsabilidades y reducir acoplamiento | Puede introducir complejidad innecesaria |
| Flujo multiagente | Simular roles de arquitectura, ingeniería, revisión y optimización | Puede producir mucha salida difícil de verificar |
| Componentes UI de producción | Crear UI reutilizable, accesible y robusta | Requiere sistema de diseño y convenciones del proyecto |
Este enfoque es especialmente útil en proyectos con cierta complejidad. Una app sencilla quizá no necesite un diseño de sistema completo, pero un producto que va a crecer sí puede beneficiarse de una primera arquitectura razonada. Del mismo modo, una revisión multiagente puede ser excesiva para un bug menor, pero útil antes de una migración importante.
Lo que falta en muchos prompts: límites, tests y contexto real
El mayor riesgo de estos prompts virales es que suenan muy bien, pero pueden quedarse cortos si se copian sin adaptar. Pedir a Claude que actúe como “ingeniero senior” no basta. Hay que darle el repositorio, las restricciones, el stack, las convenciones, los comandos de test, los requisitos no funcionales, el público objetivo y los límites de lo que no debe tocar.
En código real, la IA necesita contexto. Si no sabe qué framework se usa, cómo se despliega, qué versión de base de datos hay, qué librerías están permitidas o qué estándares sigue el equipo, puede producir una solución técnicamente plausible pero inútil para ese proyecto concreto.
| Elemento que debería añadirse | Por qué importa |
| Stack exacto | Evita soluciones incompatibles |
| Estructura actual del repo | Permite respetar convenciones |
| Requisitos funcionales | Define qué debe hacer el sistema |
| Requisitos no funcionales | Rendimiento, seguridad, accesibilidad o escalabilidad |
| Comandos de test y lint | Permiten validar el resultado |
| Límites de alcance | Evitan cambios laterales innecesarios |
| Casos de uso reales | Reducen código genérico |
| Datos de entrada/salida | Mejoran precisión de APIs, formularios y validaciones |
| Criterios de aceptación | Ayudan a saber cuándo la tarea está terminada |
Una buena instrucción no solo dice qué hacer. También dice qué no hacer. Por ejemplo: “no cambies la API pública”, “no introduzcas dependencias nuevas sin justificarlo”, “mantén compatibilidad con PostgreSQL 15”, “no modifiques el diseño visual salvo en accesibilidad” o “si falta información, pregunta antes de asumir”.
Prompting senior no significa delegar sin revisar
La tentación con estos prompts es creer que un modelo avanzado puede sustituir el proceso de ingeniería. No debería ser el objetivo. La IA puede acelerar análisis, escritura de especificaciones, generación de código, revisión de casos límite y propuestas de arquitectura, pero sigue necesitando revisión humana, pruebas y criterio de negocio.
De hecho, cuanto más ambicioso es el prompt, más importante es revisar. Pedir una aplicación completa desde cero puede generar mucho código en pocos minutos, pero también puede esconder errores de seguridad, malas decisiones de modelo de datos, dependencias innecesarias o supuestos no validados. El resultado debe entrar en el mismo circuito que cualquier código humano: tests, revisión, ejecución local, revisión de seguridad y evaluación de mantenibilidad.
| Tarea generada por IA | Revisión mínima recomendable |
| Arquitectura de sistema | Revisar supuestos, escalabilidad real y simplicidad |
| Esquema de base de datos | Validar relaciones, índices, migraciones y constraints |
| Endpoints API | Comprobar autenticación, validación y errores |
| Componentes UI | Revisar accesibilidad, estados y responsive |
| Refactor | Asegurar que no cambia comportamiento |
| Optimización | Medir antes y después |
| Depuración | Reproducir el error y validar causa raíz |
| Código de producción | Ejecutar tests, lint y revisión humana |
La IA puede actuar como copiloto técnico, pero no como autoridad final. El valor está en usarla para ampliar la capacidad de análisis del equipo, no para saltarse controles.
De los prompts a los flujos de trabajo
La evolución natural de estos prompts no será tener una lista cada vez más larga para copiar y pegar, sino convertirlos en flujos reutilizables. Herramientas como skills, comandos personalizados, plantillas de issues o agentes especializados permiten transformar una buena instrucción en una práctica repetible.
Por ejemplo, un equipo podría tener un comando para auditorías de seguridad, otro para revisión de rendimiento, otro para componentes UI y otro para análisis de deuda técnica. Cada uno incluiría las convenciones reales del proyecto, los comandos de test y las reglas internas. Así se evita depender de prompts genéricos y se construye una capa de conocimiento propia.
| Flujo de trabajo | Qué podría automatizar |
| Auditoría inicial | Mapa del repositorio, riesgos y deuda técnica |
| Revisión de rama | Análisis solo de cambios antes de PR |
| Generación de componente | Props, estados, accesibilidad y ejemplos |
| Depuración guiada | Causa raíz, reproducción y solución |
| Optimización | Perfilado, cambios propuestos y validación |
| Refactor controlado | Plan por fases sin cambiar comportamiento |
| Plan de arquitectura | Decisiones, trade-offs y límites |
| QA multiagente | Revisión desde seguridad, rendimiento y mantenibilidad |
Este paso es importante porque la productividad real no viene de un prompt aislado, sino de un sistema. Los equipos que más aprovechen la IA no serán necesariamente los que usen el modelo más caro, sino los que sepan integrarlo en procesos verificables.
Cómo mejorar esos prompts antes de usarlos
Los prompts compartidos son buenos puntos de partida, pero se pueden endurecer para uso profesional. La primera mejora es pedir siempre un plan antes del código. La segunda es exigir preguntas si falta información. La tercera es pedir criterios de aceptación y pruebas. La cuarta es limitar dependencias y cambios fuera de alcance.
Una versión más robusta de cualquier prompt de código debería incluir algo así: “Antes de implementar, resume tu comprensión del problema, enumera supuestos, identifica riesgos, propone un plan por pasos y espera confirmación si hay decisiones ambiguas”. Esto reduce una parte del riesgo de que el modelo produzca una solución convincente pero equivocada.
También conviene pedir formato de salida. Un modelo puede responder con una mezcla de explicación, código y recomendaciones difícil de convertir en trabajo real. Es mejor pedir secciones claras: análisis, decisiones, archivos afectados, código, tests, riesgos y próximos pasos.
Lo más valioso: cambiar la relación con la IA
El mensaje de fondo de la publicación es acertado: si se usa un modelo potente solo para escribir fragmentos de código, se está desaprovechando parte de su capacidad. Los modelos avanzados pueden ayudar más cuando se les pide pensar en arquitectura, entender restricciones, encontrar riesgos y producir planes verificables.
Pero esa idea debe aplicarse con disciplina. Un prompt que dice “piensa como un senior” no convierte la salida en senior automáticamente. Lo que sí ayuda es pedir evidencias, límites, tests, trade-offs y claridad. Ahí es donde la IA empieza a parecerse menos a un generador de snippets y más a una herramienta de ingeniería.
Claude, ChatGPT, Gemini o cualquier modelo avanzado pueden escribir código. La pregunta ya no es esa. La pregunta es si pueden ayudar a construir mejor software sin aumentar el caos. Para conseguirlo, los prompts deben dejar de ser órdenes sueltas y convertirse en especificaciones pequeñas, revisables y conectadas al flujo real del equipo.
Preguntas frecuentes
¿Por qué no basta con pedir a Claude que “escriba código”?
Porque el modelo puede producir una solución rápida, pero sin entender arquitectura, restricciones, tests, seguridad o mantenibilidad. Un buen prompt debe pedir análisis y criterios de validación.
Qué debe incluir un buen prompt para desarrollo?
Debe incluir contexto del proyecto, objetivo, stack, límites, entregables, criterios de aceptación, comandos de prueba y una instrucción clara para preguntar si falta información.
Son útiles los prompts que piden actuar como “ingeniero senior”?
Pueden ser útiles como marco de trabajo, pero no garantizan calidad por sí solos. Lo importante es acompañarlos de contexto real, pruebas y revisión humana.
Puede la IA sustituir el proceso de revisión de código?
No debería. Puede ayudar a detectar problemas y proponer mejoras, pero el código debe pasar tests, revisión humana y validaciones de seguridad antes de producción.
