DESARROLLO DE SOFTWARE CON CLAUDE

Desarrollar software en 2026 con Claude como principal colaborador en ingeniería cambia la curva de costes y la estructura del equipo, pero no el oficio en sí. Las partes del software que requieren un alto grado de criterio (qué desarrollar, por qué, cómo debería comportarse en caso de fallo) siguen necesitando la intervención humana. Las tareas de ejecución (escribir el código, refactorizar, generar código repetitivo, ejecutar migraciones) se reducen drásticamente. Saber distinguir unas de otras es la clave en 2026.

Este es el flujo de trabajo que usaba para entregar productos personalizados en Seahawk Media y aún uso en proyectos personales como HostList.io, gautamkhorana.com y Deluxe Astrology. No es un tutorial de Claude, no es un manual de ingeniería de prompts. La disciplina de procesos que produce software entregable con Claude como ingeniero principal.

Fase 1: lluvia de ideas estructurada

Antes de escribir nada de código, realizo una sesión de lluvia de ideas estructurada con Claude. La consigna es la siguiente: describir el problema en un lenguaje sencillo, pedirle a Claude que plantee cinco preguntas cuyas respuestas cambiarían el diseño, responderlas y, a continuación, pedirle a Claude que resuma las especificaciones del producto resultantes en 200 palabras. Esta fase dura entre 30 y 60 minutos y da como resultado unas especificaciones escritas a partir de las cuales se desarrolla el resto del trabajo.

Fase 2: decisiones técnicas

Con las especificaciones en la mano, le pido a Claude que identifique las decisiones arquitectónicas que tendrán mayor repercusión en las fases posteriores. La estructura de la base de datos, la superficie de la API, la estrategia de renderizado y el modelo de implementación. Para cada una de ellas, Claude propone dos o tres opciones y sus ventajas e inconvenientes. Yo elijo. Las decisiones se recogen por escrito en el mismo documento, de modo que la fase de desarrollo cuente con una única fuente de información fiable.

Fase 3: implementación basada en especificaciones

La generación de código es la última fase y es la más rápida, ya que las especificaciones ya están completas. Claude escribe el esquema, las consultas, los componentes, las rutas y las pruebas, más o menos en ese orden. Yo reviso cada commit. La mayoría de las revisiones sacan a la luz alguna pequeña refactorización o algún caso límite que se había pasado por alto; las reescrituras completas son poco frecuentes cuando las especificaciones son claras.

Conclusión clave: Considera «el flujo de trabajo desde la lluvia de ideas hasta las especificaciones» ante todo como una decisión operativa. Las herramientas solo funcionan cuando la responsabilidad es sincera.

Se le da muy bien

Escribir código desde cero siguiendo patrones conocidos: API REST, paneles de administración CRUD, flujos de autenticación, motores de blogs y sitios web de marketing. Refactorizar código existente cuando la estructura final esté claramente definida. Generar pruebas para código con entradas y salidas claras. Escribir scripts de migración cuando la diferencia entre esquemas no dé lugar a ambigüedades. Redactar documentación. Depurar código cuando el síntoma sea reproducible y el seguimiento esté en contexto.

No se le da tan bien

Decisiones arquitectónicas en ámbitos desconocidos. Código de integración en el que la API de terceros está mal documentada o ha sufrido cambios recientes. Optimización del rendimiento cuando el cuello de botella no es evidente. Generación de código en lenguajes o marcos poco conocidos en los que los datos de entrenamiento son escasos. Cualquier situación en la que los requisitos sean ambiguos y el modelo de lenguaje grande (LLM) proporcione valores por defecto que, aunque parezcan plausibles, resulten erróneos para tu caso concreto.

La brecha en la capacidad de juicio

Claude es, sistemáticamente, mejor que el ingeniero medio a la hora de escribir la siguiente línea de código. Claude es, sistemáticamente, peor que un ingeniero sénior a la hora de decidir si la siguiente línea de código debería existir. Tú aportas la capacidad de juicio propio de un ingeniero sénior. Claude aporta la velocidad de ejecución. La combinación de ambos supera a cualquiera de ellos por separado.

Claude Code como superficie principal

Claude Code es el IDE para el desarrollo asistido por IA. Carga única del contexto del proyecto, acceso a la terminal, acceso al sistema de archivos e integración con la herramienta MCP. Es, con diferencia, la herramienta que más he utilizado de todas las que incorporé a mi entorno de trabajo en 2025. La mayor parte del trabajo de ingeniería se realiza ahora en Claude Code, en lugar de directamente en VS Code o Cursor.

Cursor para realizar modificaciones directamente en el editor

Cursor sigue siendo la mejor experiencia de edición para trabajar junto con la IA en un único archivo. Autocompletado con la tecla Tab, ediciones en línea, comparación de cambios en paralelo. Utilizo Cursor cuando el trabajo se centra en uno o dos archivos; cambio a Claude Code cuando el trabajo abarca todo el proyecto.

Claude Sonnet a través de la API para tareas por lotes

Cuando necesito generar o reescribir cientos de páginas mediante programación (el proceso de creación automática de blogs, la humanización de contenidos, la generación de esquemas), recurro directamente a la API de Claude a través de Sonnet. Ofrece una latencia menor que la interfaz de chat, un coste predecible y la posibilidad de automatizarlo mediante scripts. Es, sin duda, la herramienta ideal para los procesos de creación de contenidos.

OpenAI GPT-4o para la ingeniería de prompts

A finales de 2025 descubrí que las instrucciones para Kimi, Minimax o cualquier otro agente se redactan mejor con Claude o GPT, y no a mano. Describo el objetivo, le pido a GPT-4o que redacte la instrucción y, a continuación, la ejecuto en el ejecutor. La calidad del resultado es notablemente superior a la de las instrucciones redactadas a mano.

Kimi, investigador y agente Minimax

Investigación profunda y mockups de diseño de aplicación completa respectivamente. El post /blog/kimi-minimax-deep-research-design-mockups/ cubre el flujo de trabajo completo. Ambos fueron herramientas críticas en Seahawk para investigación de clientes y prototipado rápido.

Cambios pequeños, mensajes descriptivos

El desarrollo asistido por IA tiende a generar cambios de código muy grandes, ya que es fácil incluir 800 líneas de código generado en una sola confirmación. Esfuérzate por hacer confirmaciones más pequeñas. Un mensaje de confirmación que explique qué ha cambiado y por qué es la única pista de la que dispondrá tu «yo futuro» para depurar una regresión. Haz que sea fácil de leer.

Las pruebas como parte del contrato

Claude puede escribir código que se compila y se ejecuta, pero que, sin que se note, incumple una restricción implícita en las especificaciones. Las pruebas que codifican esas restricciones como contratos ejecutables detectan dichos incumplimientos. La disciplina de «primero las pruebas» cobra más importancia en la era de la inteligencia artificial que cuando los humanos escribían cada línea de código.

Por ahora, la revisión de código la realizan únicamente personas.

No dejo que Claude apruebe sus propias solicitudes de incorporación de cambios. El proceso de revisión es el control de calidad más importante que queda en manos de los humanos, y delegarlo en el mismo modelo que escribió el código va en contra del objetivo. El SDK de Anthropic y los flujos de trabajo de Claude Code facilitan la revisión asistida por IA, pero la aprobación final es mía.

Dependencias con versión y archivos de bloqueo

Fija todas las dependencias. Utiliza archivos de bloqueo. Ejecuta «npm audit» en cada compilación. La superficie de ataque de la cadena de suministro es real, y el desarrollo asistido por IA tiende a añadir más dependencias que sus equivalentes escritos por personas, ya que añadir un paquete es rápido. La disciplina en el uso de los archivos de bloqueo permite que la superficie sea auditable.

Conclusión clave: Considera la «disciplina en el repositorio que resiste el desarrollo asistido por IA» ante todo como una decisión operativa. Las herramientas solo funcionan cuando la responsabilidad es sincera.

Cinco tipos de decisiones en las que Claude no es la herramienta adecuada:

Qué crear, en primer lugar. La decisión sobre el producto requiere un gran criterio, depende del contexto del usuario, del que Claude carece, y es la decisión más trascendental en cualquier producto. Son los fundadores y los gestores de producto quienes tienen la responsabilidad última; la IA, como mucho, les ayuda.

Qué lanzar y qué descartar. Las decisiones sobre el alcance durante una fase de desarrollo siempre se reducen a limitaciones que el modelo no tiene en cuenta: la presión del tiempo, la moral del equipo, las relaciones con los socios, el posicionamiento de marketing. Decide como persona, documenta el razonamiento y, a continuación, pide a Claude que ejecute el alcance acordado.

Diseño de modos de fallo. Rara vez se especifica desde el principio cómo debería comportarse el sistema cuando las cosas van mal, y ahí es donde se originan la mayoría de los incidentes de producción. Dedica un tiempo desproporcionado a los modos de fallo; estos no surgirán de forma natural de la generación de código para el «camino ideal».

El aspecto ético. Lo que creas tiene consecuencias. Privacidad, ubicación de los datos, accesibilidad, impacto medioambiental. Se trata de decisiones humanas, no de resultados de optimización. Plantea la cuestión de forma explícita en la fase de diseño.

Mantenibilidad a largo plazo. Que el «yo del futuro» lea al «Claude del futuro» el código del «Claude del presente» es la forma más extrema de deuda técnica. Optimiza el código actual para que sea legible primero para los humanos y, en segundo lugar, para la IA.

Ejemplos concretos de mis últimos doce meses en Seahawk y de proyectos personales:

HostList.io (28 000 páginas programáticas en Next.js + Supabase): estructura inicial creada con Claude Code en cinco días; pipeline de contenido escrito por Claude con integración de investigación de Tavily; generación de imágenes destacadas mediante FAL; marcado de esquemas generado automáticamente. El tiempo total dedicado a la ingeniería fue aproximadamente un tercio de lo que habría estimado hace tres años.

gautamkhorana.com (esta web, en Astro + Supabase): reconstruida en un fin de semana de 24 horas con Claude Code como colaborador principal. La interfaz del editor de la web, el sistema de blog, la capa de esquema y la internacionalización (i18n) se generaron, revisaron y refactorizaron en su totalidad. El coste de crear una web personal con esta calidad se redujo a un fin de semana de trabajo intensivo.

El flujo de trabajo automatizado de Deluxe Astrology para la creación de entradas de blog y la traducción: el ciclo «Tavily (investigación) → Claude (borrador) → Winston (revisión) → FAL Hero → Supabase (publicación)» se ejecuta a diario en 30 idiomas y abarca más de 91 000 páginas. El propio proceso consta de unas 800 líneas de código que Claude escribió en unas 12 horas de trabajo intensivo, gran parte del cual habría llevado una semana a un equipo compuesto únicamente por personas.

Paneles de control administrativos internos en Seahawk: Minimax Agent genera el primer prototipo a partir de una descripción de seis líneas, Claude lo perfecciona y el resultado está listo para su implementación en una hora. El tiempo que transcurre desde que se dice «necesitamos una herramienta interna» hasta que «ya estamos utilizando la herramienta interna» se ha reducido de varios días a menos de un día laborable.

El desarrollo de software a medida en 2026 es un oficio en el que la velocidad de ejecución se ha reducido en un orden de magnitud, mientras que la complejidad de la toma de decisiones se ha mantenido más o menos constante. Los equipos que se adaptan son aquellos que aportan más capacidad de decisión (mejores especificaciones, mejores elecciones arquitectónicas, mejor diseño de modos de fallo) y delegan una mayor parte de la ejecución a la IA. Los equipos que no se adaptan producen software a una velocidad competitiva, pero pierden en calidad, o viceversa.

No es necesario que utilices todas las herramientas que se mencionan en esta guía. Lo que sí debes saber es qué decisiones te corresponden a ti y cuáles puedes delegar. La clave está en saber dónde trazar la línea divisoria, no en el conjunto de herramientas.

Si quieres ayuda para entregar un proyecto de software personalizado en esta curva de costos, ejecuto builds de productos directamente. La conversación es gratuita; los precios del proyecto reflejan la realidad de costos asistidos por IA, no la realidad de costos por hora de 2018.

Conclusión clave: Considera «el resultado final» ante todo como una decisión operativa. Las herramientas solo funcionan cuando la responsabilidad es sincera.