Hace tres meses casi contrato a un segundo desarrollador backend. Teníamos un backlog vergonzoso, catorce features prometidas a clientes, dos personas estiradas al máximo, y yo cambiando de contexto entre llamadas de ventas y pull requests como un completo idiota. Entonces comencé a usar Claude Code de verdad. No solo pegando funciones en una ventana de chat. Me refiero a integrarlo en el flujo diario real. Limpiamos ese backlog en seis semanas. No contraté al segundo desarrollador.
Eso no es un argumento de venta. Es solo lo que pasó.
Qué significa "correctamente"
La mayoría de las personas con las que hablo en meetups están usando herramientas de codificación con IA de la misma manera perezosa. Pegan una función, obtienen algo, lo pegan en su editor, se rompe, se rinden. Eso no es un flujo de trabajo. Eso es desesperación.
De verdad, para mí, significa que Claude Code vive dentro de mi terminal vía la Claude Code CLI, trabajando directamente en mi repo actual, leyendo archivos reales, no fragmentos sanitizados. La diferencia es enorme. Cuando tiene contexto completo de un plugin de WordPress de 4,000 líneas que construimos para un cliente de salud en Estados Unidos hace un año, el output es utilizable. Cuando trabaja a ciegas basándose en un paste de 40 líneas, está adivinando.
Lo ejecuto en una MacBook Pro M3. Mi editor sigue siendo VS Code con los sospechosos habituales, Prettier, ESLint, GitLens. Claude Code no reemplaza nada de eso. Se sienta junto a ello.
La configuración que realmente uso
- Claude Code CLI instalado globalmente vía npm
- Un directorio .claude en la raíz de cada proyecto con un archivo CLAUDE.md, esto es básicamente un brief que escribo para Claude sobre el proyecto: stack, convenciones, qué no tocar.
- iTerm2 con paneles divididos: código a la izquierda, sesión de Claude a la derecha
- Commits de Git después de cada cambio generado por Claude, sin excepciones. He aprendido por las malas.
Ese último punto. En 2022 un proyecto de cliente, migración de Shopify para una tienda de muebles en Manchester, dejé que tres horas de ediciones asistidas por IA se acumularan sin hacer commit. Toda la sesión se corrompió. Seis horas de trabajo desaparecidas. Ahora hago commit compulsivamente, casi neuróticament. Claude Code o no.
La rutina matutina (Esto es específico a propósito, de forma aburrida)
Estoy en la oficina a las 8:30. Café del lugar en Exmouth Market. Abro Notion, veo qué hay en el tablero para el día, y luego abro mi terminal.
Lo primero que hago con Claude Code cada mañana es lo que he empezado a llamar un "context dump". Abro el proyecto, ejecuto claude y le doy un párrafo de dónde lo dejé el día anterior. Lee automáticamente el git diff reciente. Esto toma unos tres minutos y significa que no estoy gastando veinte minutos releyendo mi propio código para recordar qué estaba haciendo. Eso solo ya vale la suscripción.
Entonces trabajo. No le estoy pidiendo a Claude que escriba features desde cero, aunque a veces lo hago. Principalmente le estoy pidiendo que haga las cosas que me ralentizan pero requieren cero creatividad.
Cosas como:
- Escribir casos de prueba de PHPUnit para funciones que ya he escrito
- Generar interfaces de TypeScript a partir de una respuesta JSON que pego
- Refactorizar un componente de 300 líneas que sé que necesita dividirse pero no quiero pensar en ello.
- Documentación de primer borrador para APIs internas
Nada de eso es emocionante. Todo eso solía consumirme una hora que no tenía.
Dónde Realmente Ahorra Tiempo (Con Números)
Seahawk ha construido más de 12,000 sitios en este punto. Una buena parte es WordPress, temas, plugins, personalizaciones de WooCommerce. Hay una categoría de tarea en desarrollo de WordPress que es adormecedora pero técnicamente precisa: escribir hooks personalizados, registrar endpoints de REST API, construir páginas de configuración con la Settings API.
Lo medí el mes pasado. Escribir una clase de método de envío personalizado de WooCommerce desde cero: históricamente me toma alrededor de 45 minutos incluyendo testing. Con Claude Code haciendo el scaffold mientras yo describo la lógica del negocio en inglés plano: 12 minutos. Y el scaffold es bueno, sigue los estándares de codificación de WordPress porque se lo dije en mi CLAUDE.md.
Eso no es 10% más rápido. Es una categoría completamente diferente de velocidad.
El ahorro más grande es el costo de cambiar de contexto. Cuando estoy a mitad de una funcionalidad y un cliente me avisa sobre un bug en un proyecto completamente diferente, antes tenía que ignorar al cliente (malo) o perder mi hilo de pensamiento completamente (también malo). Ahora puedo pedirle a Claude que escriba un bloque de comentarios detallado resumiendo exactamente dónde estamos en la tarea actual, cambiar al bug, arreglarlo, volver, leer el comentario y retomar en unos cuatro minutos. Antes, esa recuperación me costaba veinte.
Dónde se desmorona
Siendo honesto. Y esto importa más que los éxitos.
Claude Code es genuamente malo en cualquier cosa que requiera entender por qué se tomó una decisión históricamente. Teníamos un proyecto fintech en Seahawk, un dashboard para una startup de pagos con sede en Londres, donde existía un bit particularmente complicado de gestión de estado por una razón que predataba nuestra participación. Algún caso extremo en cómo su API heredada agrupaba respuestas. Claude seguía "arreglándolo". Cada sugerencia era técnicamente más limpia y completamente incorrecta. No sabía lo que no sabía.
Este es el failure mode del que nadie habla lo suficiente. El output se ve correcto. Pasa revisión básica. Y luego se rompe en producción un jueves a la noche cuando un usuario toca ese edge case.
Mi regla ahora: Claude Code no toca nada donde el comentario dice "no cambies esto sin preguntarle a Ravi." (Ravi es nuestro lead developer backend.) Punto final.
También tiene dificultades severas con:
- Refactorizaciones multi-archivo donde la cadena de dependencias es más de tres niveles de profundidad
- Cualquier cosa que implique un SDK de terceros que tenga menos de dos años, alucina con confianza nombres de métodos.
- CSS que necesita coincidir exactamente con el comp del diseñador (se acerca, luego te vuelve loco con pequeños errores)
- Optimización de rendimiento donde el cuello de botella no es obvio, optimiza la cosa equivocada.
En el punto dos específicamente: estaba integrando la API de Resend en un proyecto de Next.js en enero. Claude seguía haciendo referencia a un método.send() que no existe en el Resend Node SDK. Me llevó más tiempo debuggear la confianza incorrecta de Claude que lo que me habría tomado solo leer los docs. Lección aprendida. Para cualquier SDK, pego el README actual en la ventana de contexto primero.
Los Patrones de Prompt Que Realmente Funcionan
He iterado esto durante meses. Prompts malos producen outputs malos. Aquí está en qué he llegado.
Sé el desarrollador senior, no el becario. No preguntes "escribe una función que haga X." Pregunta "Necesito implementar X. Aquí está la restricción: Y. Aquí está lo que ya he descartado: Z. ¿Cuál es tu enfoque antes de escribir nada?" Hazlo pensar primero. El output después de esa conversación es dramáticamente mejor.
Dale una persona con responsabilidades. Literalmente escribo: "Eres un desarrollador senior de WordPress que se preocupa profundamente por no introducir vulnerabilidades de seguridad. El cliente es una empresa de healthcare. Prioriza sanitización y verificación de nonce por encima de todo." ¿Se siente tonto? Sí. ¿Funciona? También sí.
Especifica el formato del output. "Dame solo la función, sin explicación" o "Dame la función, luego una lista de puntos de lo que debo verificar manualmente." El output no estructurado es una pérdida de tiempo.
Un patrón que utilizo constantemente:
- Describe el objetivo en una oración
- Pega el código existente relevante con un comentario explicando su propósito
- Establece la restricción ("debe ser compatible hacia atrás con PHP 7.4")
- Pregunta por un enfoque primero, código después
- Revisa el enfoque, cuestiona si es necesario, luego pide el código
Cinco pasos. Suena como mucho trabajo. Me ahorra quince minutos de código deficiente cada vez.
Cómo ha cambiado lo que delego
Este es el punto que más me sorprendió. Claude Code no solo me hizo más rápido. Cambió lo que le entrego a los desarrolladores junior.
Antes, un desarrollador junior en Seahawk pasaba sus primeras dos semanas simplemente familiarizándose con nuestras convenciones y nuestro stack. Ahora le entrego un proyecto con un CLAUDE.md bien escrito y le digo que use Claude Code para generar código scaffold, luego que lo revise contra las convenciones. Están contribuyendo trabajo real en tres días en lugar de tres semanas.
El archivo CLAUDE.md está haciendo la mentoría que yo solía hacer en walkthroughs por hora. Eso es un cambio significativo. No porque no quiera ser mentor, sí quiero, sino porque ahora las conversaciones de mentoría son sobre decisiones y trade-offs, no "recuerda usar wp_nonce_field() en cada formulario".
La documentación de especificaciones del modelo Anthropic vale la pena leer si te interesa conocer los guardrails dentro de los cuales opera Claude. Entenderlos te ayuda a trabajar con sus tendencias en lugar de contra ellas.
El ángulo específico del fundador
La mayoría de artículos sobre herramientas de IA para código están escritos para desarrolladores. Está bien. Pero hay un problema específico del fundador que Claude Code resuelve y que no he visto bien articulado.
Cuando diriges una agencia y además escribes código, tu enemigo más grande no son las brechas de habilidad. Es el costo de re-entrada. Te llaman a una junta de precios por cuarenta minutos, luego necesitas arreglar una regresión de CSS, luego tienes un 1-on-1 con un miembro del equipo. Para cuando regresas a la característica que estabas construyendo, has perdido el hilo tan completamente que empezar de nuevo se siente más fácil que retomarlo.
Claude Code, usado correctamente, reduce el costo de re-entrada dramáticamente. Mencioné el truco del bloque de comentarios resumido anteriormente. También lo uso para generar un rápido mensaje de Slack hacia mí mismo con puntos sobre qué está hecho, qué sigue, y qué está bloqueado. Toma diez segundos. Ahorra diez minutos de reconstrucción.
No te hará un mejor gestor. No despejará tu calendario. Pero si eres un fundador que todavía programa, y creo que más de nosotros deberíamos hacerlo, elimina un impuesto específico y doloroso en tu tiempo de codificación.
FAQ
¿Vale la pena Claude Code si no eres desarrollador de tiempo completo?
Honestamente, probablemente menos. El valor se compone cuando estás en la herramienta todos los días e inviertes tiempo construyendo buenos archivos de contexto (CLAUDE.md, briefs de proyecto claros, etc.). Si solo entras una vez a la semana, pasarás más tiempo restableciendo contexto de lo que ahorres. GitHub Copilot podría ser más adecuado para usuarios ocasionales, es más ambiental y requiere menos configuración deliberada.
¿Cómo manejas la calidad del código, simplemente confías en lo que genera?
Nunca ciegamente. Cada archivo generado por Claude pasa por ESLint y nuestra configuración Prettier automáticamente. Para cualquier cosa que toque autenticación, pagos o manejo de datos, hago una lectura manual línea por línea. Para funciones de utilidad y tests, soy más relajado. Calibras basándote en el riesgo. El OWASP Top Ten es un checklist mental útil cuando revisas código generado por IA que maneja entrada de usuario.
¿Funciona bien específicamente con WordPress?
Mejor de lo que esperaba, con salvedades. Conoce WordPress profundamente, hooks, filters, la Settings API, internals de WooCommerce. Pero su conocimiento del desarrollo más nuevo de bloques Gutenberg (particularmente la Interactivity API) es parcial. Siempre verifico contra el Block Editor Handbook para cualquier cosa relacionada con bloques.
¿Y qué hay del costo?
Pago por Claude Pro, que son $20/mes. Al nivel que lo uso, el ahorro de tiempo está entre cuatro y seis horas a la semana. Haz las cuentas con tu propia tarifa horaria. Para mí no es una pregunta que valga la pena hacer.
---
Todavía escribo mucho código yo mismo. No me interesa convertirme en un prompt jockey que nunca toca una función real. Pero el fundador que pretende que las herramientas de codificación IA no han cambiado el oficio se está engañando. La pregunta no es si usarlas. Es si las estás usando con suficiente rigor para obtener valor real, o solo con suficiente descuido como para introducir problemas reales.
Para mí, la diferencia entre esas dos cosas se redujo a tratar Claude Code como un desarrollador capaz pero junior. Inteligente. Rápido. Necesita un buen briefing. Necesita revisión. Y absolutamente no debería quedarse sin supervisión cerca de nada crítico para la misión.
Ese enfoque lo cambió todo.