Notas de campo al desplegar código real con Claude

• La herramienta de IA Claude se aplicó a un servicio real, y se resume cómo lograr de forma realista una mejora de 10x en la productividad de desarrollo y las mejores prácticas para implementarla
• El ‘vibe-coding’ no es solo una moda, sino una metodología práctica; con los hábitos de desarrollo y la infraestructura correctos, se pueden maximizar las fortalezas de la IA y compensar sus debilidades
• El rol de la IA se divide claramente en tres modos: ‘redactor de borradores’, ‘pair programmer’ y ‘revisor de código’, y en cada etapa son indispensables la documentación y los guardrails adecuados
• La clave está en usar un archivo CLAUDE.md en cada proyecto para documentar con claridad convenciones, arquitectura, patrones, prohibiciones, etc., y guiar eficazmente a la IA con ‘anchor comments’ dentro del código
• El código de pruebas debe escribirlo siempre una persona, y deben establecerse límites estrictos para que la IA no pueda modificar áreas críticas como pruebas, migraciones, seguridad, contratos de API o secretos
• Los equipos que adoptan la programación con IA bajo los límites y hábitos adecuados pueden mejorar de forma drástica la frecuencia de despliegue, la estabilidad y la velocidad de desarrollo, y compartir patrones y prácticas reales de operación se está volviendo el núcleo de la cultura de desarrollo con IA

---

Vibe Coding Isn’t Just a Vibe

• Este artículo es una guía de campo sobre una nueva forma de desarrollar software con IA, y no solo explica cómo usarla, sino también el ‘por qué’ de un desarrollo con IA que realmente funciona
• También muestra con casos reales que la mítica mejora de productividad de 10x solo es posible mediante hábitos prácticos que maximicen las fortalezas de la IA y compensen sus debilidades
• A partir del codebase en producción de Julep, se comparten infraestructura y prácticas operativas reales como la plantilla de CLAUDE.md, la estrategia de commits y los guardrails para evitar desastres operativos
• En particular, el código de pruebas debe escribirse directamente por personas, y depender en exceso de la IA puede causar fallas graves y pesadillas de depuración
• En el desarrollo con IA existen tres modos (redacción inicial, pair programming y revisor), y según la situación cambian el ritmo y los principios sobre cuándo darle la iniciativa a la IA y cuándo debe intervenir directamente la persona
• Mensaje central: la IA solo amplifica las capacidades cuando existen buenos hábitos y límites de desarrollo, y los resultados reales también muestran que “los equipos con hábitos de desarrollo rigurosos superan de forma abrumadora a los demás tanto en velocidad de despliegue como en calidad”

Por qué se escribió este artículo: del meme al método práctico

• La idea de que se le deja el código a la IA y el desarrollador “solo sigue la vibra” (‘vibe-coding’) comenzó originalmente como un tuit en broma de Andrej Karpathy
• En ese momento, la comunidad de desarrolladores lo tomó entre risas como la fantasía definitiva: “la IA trabaja por nosotros y nosotros solo tomamos café”
• Pero tras el lanzamiento de Sonnet 3.7 de Anthropic y Claude Code, esa broma empezó a convertirse en una realidad posible. Ya existían herramientas como Cursor, pero Claude Code empezó a dar una sensación de verdadero ‘vibe coding’
• Julep, donde trabaja el autor, arrastra un codebase enorme, múltiples patrones de diseño e incluso deuda técnica. La calidad del código y la documentación se mantienen de forma estricta, pero aun así comprender la intención y el historial de cada parte es tan complejo que puede tomar semanas
• Usar Claude sin guardrails genera un caos similar al de un becario demasiado entusiasta cometiendo errores por todas partes
• Este artículo comparte únicamente patrones y conocimientos realmente probados en campo, nacidos de esos ensayos y errores, de depuraciones a las 3 de la mañana y de la supervivencia en la operación de servicios reales

La esencia del vibe coding

• Así como Steve Yegge acuñó el término CHOP (Chat-Oriented Programming), el ‘vibe coding’ es una nueva forma de desarrollo en la que el código se completa conversando con la IA
• Si la programación tradicional es como esculpir mármol, construyendo con cuidado línea por línea,
  • el vibe coding se parece más a dirigir una orquesta, y la IA es el músico que aporta la materia prima (capacidad base para escribir código)
  • La persona desarrolladora diseña la dirección general y la estructura, y la IA traduce ese flujo a código
• Las 3 posturas del vibe coding
  • 1. Usar la IA como redactor de borradores (First-Drafter)
    • Se enfoca en arquitectura y diseño, mientras la IA genera rápido el trabajo repetitivo (CRUD, boilerplate, etc.)
    • Se siente como tener a un ingeniero junior que escribe código a la velocidad a la que uno piensa, pero requiere guía constante
  • 2. Hacer pair programming con la IA (Pair-Programmer)
    • Es el modo más práctico y efectivo
    • La persona desarrolladora y la IA intercambian ideas; la visión general la define la persona y la implementación detallada la completa la IA
    • Se parece a programar en pareja con un colega que sabe muchísimo de programación, pero no tiene experiencia real desplegando sistemas
  • 3. Usar la IA como validador/revisor de código (Validator)
    • La IA revisa el código escrito por una persona y sugiere bugs, mejoras y patrones omitidos
    • Cumple el papel de un revisor meticuloso que nunca se cansa
• Idea clave: el rol del desarrollador pasa de ‘autor’ a ‘editor’. En vez de escribir todo el código directamente, revisa, corrige y marca la dirección de lo que produce la IA.
• Aun así, la arquitectura general y el contexto deben estar siempre liderados por personas, porque la IA no es más que ‘un becario con conocimiento enciclopédico’ y no conoce el contexto de nuestro servicio ni del negocio

Tres modos prácticos del vibe coding: framework

Tras meses de experimentación y accidentes reales en despliegues, quedó claro que el vibe coding tiene 3 modos, cada uno con ritmos, guardrails y usos óptimos distintos

• Modo 1: Playground (experimentos/prototipos/proyectos personales)

  • Cuándo usarlo: hackeos de fin de semana, scripts personales, PoC, pruebas improvisadas de ideas, etc.
  • Características: sin diseño, documentación ni guardrails, la IA escribe entre 80% y 90% del código. La velocidad para pasar de la idea al resultado es de apenas minutos
  • Riesgo: no es apto para servicios reales ni código importante. Debe usarse solo para juego o experimentación. Los principios de ingeniería se vuelven, si acaso, aún más importantes

• Modo 2: Pair Programming (uso real/servicios pequeños)

  • Cuándo usarlo: proyectos de menos de 5,000 líneas, side projects con usuarios reales, demos, módulos pequeños, etc.
  • Clave: definir de una sola vez y con claridad en CLAUDE.md las convenciones, arquitectura, patrones, guía de pruebas y demás del proyecto
  • Ventaja: como al incorporar a un nuevo desarrollador, basta con explicárselo una vez a Claude para que genere código de forma consistente
  • Puntos prácticos:
    • Guiar a Claude con anchor comments (AIDEV-NOTE, AIDEV-TODO, AIDEV-QUESTION, etc.) repartidos por el código para que no pierda el contexto
    • Estos comentarios funcionan como directrices tanto para la IA como para las personas, y en CLAUDE.md se especifican incluso los criterios de uso y ejemplos

• Modo 3: Production/Monorepo Scale (servicios de gran escala)

  • Cuándo usarlo: desarrollo con decenas o cientos de personas, grandes servicios con usuarios reales, o entornos donde un solo error puede causar daños importantes
  • Precaución: al momento actual (junio de 2025), el vibe coding masivo en bloque todavía no escala de forma perfecta
  • Principio: se recomienda introducir el vibe coding por servicio individual o submódulo, con límites claros y versionado en todos los puntos de integración (API, DB, etc.), y comentarios obligatorios de precaución en interfaces y APIs clave
  • Ejemplos prácticos:
    • # AIDEV-NOTE: API Contract Boundary - v2.3.1
    • # Changes require version bump and migration plan
    • Sin estas líneas de separación, Claude puede intentar “mejorar” algo sin cuidado y terminar rompiendo todo el servicio real
• Conclusión: en proyectos grandes, el vibe coding debe introducirse de forma gradual y por servicios aislados, y solo será confiable si se acompaña necesariamente de documentación, lineamientos, revisiones y otros principios tradicionales

Crear un entorno de desarrollo de IA sostenible centrado en la infraestructura

• CLAUDE.md: una única fuente de verdad para la IA y las personas

  • CLAUDE.md funciona como una “constitución” que reúne de forma sistemática todas las reglas del proyecto, arquitectura, precauciones, estilo de código, elementos prohibidos y glosario del dominio
  • Sirve como el “esqueleto de conocimiento” compartido entre la IA y los nuevos integrantes del equipo, y se gestionan de forma intensiva guías concretas y prohibiciones junto con ejemplos
  • Cuanto más invierte un equipo en un buen CLAUDE.md, mejores resultados obtiene
  • Consulta nuestro CLAUDE.md de producción
  • A medida que crece la base de código, CLAUDE.md por sí solo ya no basta, y es necesario comunicar con claridad el contexto local en distintas partes del código mediante anchor comments (AIDEV-NOTE/TODO/QUESTION, etc.)
  • Si la base de código fuera una ciudad, los anchor comments serían las señales que evitan que tanto la IA como las personas se pierdan
  • Estos comentarios van más allá de explicar el código: dejan la historia de “por qué” funciona así

• Flujo de trabajo con Git: gestión sistemática del código generado por IA

  • Cuanto más rápida sea la generación de código con IA, más fácil será contaminar el historial de git si no se gestiona bien
  • Con métodos como git worktree, se puede preparar un espacio de experimentación con IA separado de la rama principal, permitiendo generar código libremente mientras los registros se separan y gestionan de forma ordenada
    • Consulta también how to use worktrees y la herramienta wt
  • En los mensajes de commit debe indicarse obligatoriamente la participación de la IA (por ejemplo, usando la etiqueta [AI]) para que el revisor pueda prestar atención adicional

Regla no escrita: el código de pruebas siempre debe escribirlo una persona

• El principio más importante en el desarrollo asistido por IA: “nunca dejar el código de pruebas en manos de la IA”
• Las pruebas no son simplemente código para verificar si algo funciona
  • Son una especificación ejecutable que incorpora el contexto real del problema, el reconocimiento de edge cases, la interpretación de requisitos de negocio y la comprensión y experiencia humanas sobre el dominio
  • Los equipos de alto nivel que no sacrifican ni velocidad ni estabilidad son precisamente los que mantienen estas pruebas bajo control humano riguroso
• Las pruebas generadas automáticamente por IA solo validan rutas superficiales (happy path) y pasan por alto problemas graves e inesperados, como fugas de memoria
• En nuestro equipo, si la IA toca un archivo de pruebas, el PR se rechaza automáticamente (sin excepciones)
• Las pruebas son a la vez la especificación y la red de seguridad del código, y concentran la sabiduría acumulada de todos los bugs y edge cases
• Deben escribirse necesariamente a mano y protegerse de forma estricta para que la IA no pueda tocarlas

Escalabilidad y gestión del contexto: economía de tokens y optimización del contexto

• Error común en el desarrollo de código con IA:
  si se minimiza el contexto (prompt, requisitos, entorno, etc.) para “ahorrar tokens”, en realidad aumentan las repeticiones y el consumo total de tokens termina subiendo
• Proporcionar el contexto adecuado es más eficiente a largo plazo
  • La clave no es dar “lo mínimo”, sino proveer desde el inicio un contexto relevante y suficiente
• Mal ejemplo: prompt con poco contexto "Add caching to the user endpoint"
  • Claude propone un simple caché en memoria, sin estrategia de invalidación ni monitoreo, sin considerar múltiples servidores y sin medidas contra cache stampede
  • Como resultado, hubo que corregirlo más de 3 veces y se consumieron más de 4 veces más tokens en total
• Buen ejemplo: prompt con mucho contexto

  Add Redis caching to the GET /users/{id} endpoint.  
  Context:  
  * tráfico del endpoint: 50 mil req/min, 12 servidores API, pocos cambios de datos  
  * ubicación de la infraestructura Redis existente, patrón estándar de claves, requisito de métricas basadas en Prometheus  
  * patrón cache-aside, TTL de 1 hora, prevención de cache stampede (expiración temprana probabilística)  
  * consultar la guía de caching  
  

  • Al proporcionar contexto concreto desde el principio, es posible lograr una implementación precisa sin iteraciones innecesarias
• Conclusión:
  • “Los tokens son una inversión en una buena herramienta”
  • Si se aporta suficiente contexto desde el inicio, a largo plazo disminuyen las repeticiones y correcciones, lo que ahorra costos
• Tip práctico: en todos los proyectos, pedirle a Claude que actualice el CLAUDE.md con los cambios en la base de código y el contexto relacionado cada vez que se modifique el código

Gestión de sesiones y prevención de contaminación del contexto

• Es importante iniciar una nueva sesión de Claude para cada tarea
  • Si se mezclan varias tareas en una misma conversación larga (por ejemplo, migraciones de DB, diseño frontend, etc.), el contexto se entrecruza y puede producir resultados no deseados
• Regla: una tarea = una sesión; al terminar, empezar una sesión nueva
  • Así se mantiene siempre limpio y enfocado el “modelo mental” de Claude
  • Es como usar tablas de cortar separadas para pollo crudo y verduras, manteniendo el contexto aislado

Caso práctico: transición en la estructura de manejo de errores

• Se presenta un caso real en el que se reemplazó el manejo de errores ad hoc en más de 500 endpoints por una jerarquía estructurada de errores
• La persona responsable (arquitecto) define por adelantado el diseño clave (SPEC.md/requisitos/clasificación de errores), y Claude asume el papel de ejecutor de la transformación masiva del código (trabajo mecánico)
• Principios de arquitectura y especificaciones concretas, ejemplos de documentos de diseño y derivación de conceptos -> instrucciones claras para la IA -> experiencia de completar todo el refactor exactamente en 4 horas

Liderazgo y cultura organizacional en la era de la IA

• El rol del ingeniero senior evoluciona de escribir código directamente a curar conocimiento, establecer límites y guiar tanto a la IA como a las personas
• La gestión Lean, la entrega continua y otras prácticas modernas de desarrollo siguen siendo igual de importantes para gestionar la colaboración con IA

• Checklist de onboarding para nuevos ingresos (separando la colaboración entre humanos + IA)

  • Semana 1: reforzar los fundamentos
    • Leer el CLAUDE.md del equipo (común y por servicio)
    • Configurar el entorno de desarrollo
    • Enviar el primer PR (100% código escrito directamente, sin IA)
  • Semana 2: práctica de colaboración con IA
    • Aplicar y configurar la plantilla del equipo en Claude
    • Resolver un “problema de juguete” junto con la IA
    • Practicar patrones de prompts
    • Primer PR asistido por IA (junto con mentor/senior)
  • Semana 3: trabajo independiente
    • Desarrollar y desplegar funciones principales con ayuda de IA
    • Escribir personalmente pruebas para el código generado por IA de otros compañeros
    • Liderar una sesión de code review

Construir una cultura transparente: hacer visible el uso de IA de forma activa

• En todos los commits con uso de IA, debe marcarse claramente con etiquetas en el mensaje de commit como en el siguiente ejemplo

  feat: add Redis caching to user service \[AI]  
  # \[AI] - más del 50% generado por IA, \[AI-minor] - menos del 50%, \[AI-review] - solo se usó IA para revisión  
  # La IA escribió el caché y el código del cliente; el diseño de las claves de caché, las pruebas y la validación los hizo directamente una persona  
  

• Efectos
  1. El revisor presta especial atención al código generado por IA
  2. Facilita identificar el origen del código al depurar
  3. Elimina la vergüenza y la cultura de ocultar el uso de IA, y establece una cultura de equipo de “usar la IA con responsabilidad”
• Es importante promover una divulgación activa y mecanismos culturales para que cualquiera pueda usar IA sin carga ni vergüenza y contribuir a una cultura de alto rendimiento

Prohibiciones para Claude: aquí la IA no debe meter mano bajo ninguna circunstancia

• Archivos de prueba/migraciones de base de datos/código crítico de seguridad/contratos de API (sin control de versiones)/configuración del entorno y secretos: el uso de automatización con IA debe estar absolutamente prohibido
• Se enfatiza separar por nivel de gravedad de los errores (desde formato y dependencias hasta destrucción de datos en áreas críticas del negocio) y aplicar guardrails adicionales obligatorios en las zonas de alto riesgo
• Jerarquía del riesgo de errores de la IA (Hierarchy of AI Mistakes)
  • Level 1: Molesto, pero no fatal
    • Errores de formato (los detecta el linter)
    • Código verboso (se refactoriza después)
    • Algoritmos ineficientes (se descubren al hacer profiling)
  • Level 2: Errores costosos
    • Ruptura de compatibilidad de APIs internas (requiere coordinación del equipo)
    • Cambio de patrones existentes (provoca confusión)
    • Adición de dependencias innecesarias (hincha el código)
  • Level 3: Letales para la carrera profesional (Career-Limiting)
    • Modificar las pruebas para que coincidan con el resultado esperado
    • Romper el contrato de la API
    • Filtrar secretos/datos personales
    • Dañar una migración de datos
  • El nivel de guardrails también debe variar según el nivel del error, y los errores de Level 3 representan una amenaza grave incluso para la carrera profesional

El futuro del desarrollo: cambios y rumbo a seguir

• En 2025, el desarrollo asistido por IA es como un adolescente: poderoso, pero todavía torpe y áspero
• Sin embargo, la curva de crecimiento claramente se está 'acelerando'
• Una buena documentación (Documentation) es la infraestructura clave para implementar DevOps en la era de la IA
  • La documentación ya no es solo 'material de referencia', sino una 'interfaz' directa entre la intención humana y la ejecución de la IA
  • Los equipos de alto rendimiento gestionan documentación como CLAUDE.md con el mismo rigor que las pruebas

• Cambios que se esperan hacia adelante

  • IA que entiende el contexto completo del código
    • No solo a nivel de archivo, sino hasta el nivel de servicio/sistema
  • Memoria persistente que atraviesa sesiones y proyectos
    • Recordará y aprovechará a largo plazo el contexto de conversaciones y trabajo
  • IA que propone mejoras de forma proactiva
    • Diagnosticará problemas y oportunidades de mejora incluso sin que se le pida
  • IA que aprende los patrones y preferencias de cada equipo
    • Generará automáticamente código ajustado al estilo y las convenciones propias de la organización
• Pero, lo básico no cambia:
  • Los humanos marcan la dirección; la IA ejecuta y multiplica el alcance
  • Por más poderosa que se vuelva la herramienta, seguimos siendo 'quienes usan la herramienta'

Conclusión: empieza aquí y ahora

• Si llegaste hasta aquí, probablemente sientas expectativa y también algo de miedo
  • Esa reacción es normal; el desarrollo asistido por IA es poderoso, pero exige una práctica 'intencional y sistemática'

• Plan de acción para empezar hoy mismo

  • Hoy
    • 1. Crear un archivo CLAUDE.md en tu proyecto actual
    • 2. Agregar personalmente 3 anchor comments al código que consideres más complejo
    • 3. Probar 1 función asistida por IA bajo límites (guías) claros
  • Esta semana
    • 1. Definir en equipo reglas para mensajes de commit generados por IA
    • 2. Hacer una sesión de coding con IA junto con un desarrollador junior
    • 3. Escribir personalmente pruebas para el código generado por la IA
  • Este mes
    • 1. Medir el cambio en la frecuencia de despliegue antes y después de adoptar IA
    • 2. Construir una biblioteca de patrones de prompts para tareas repetitivas del equipo
    • 3. Realizar una reunión de retrospectiva de colaboración con IA para todo el equipo
• La clave es "empezar ya mismo, en pequeño, con cuidado, pero empezar sí o sí"
• Los desarrolladores que dominen antes esta ola no lo harán por ser más inteligentes, sino porque
  • empezaron antes, cometieron más errores y aprendieron más
• El desempeño en despliegue de software termina definiendo el desempeño de la organización
  • En una era donde la velocidad y la calidad son competitividad, el desarrollo asistido por IA no es una opción, sino una 'capacidad indispensable'
  • Eso sí, hay que abordarlo de la manera correcta
• El vibe coding puede sonar como un juego, pero
  • es una forma seria de desarrollo que amplifica la capacidad humana
  • Las herramientas y los patrones ya están suficientemente preparados
  • Ahora toca elegir quién dirigirá la orquesta y quién tocará todos los instrumentos en solitario

Material práctico y recursos recomendados

• Plantilla práctica de CLAUDE.md : github.com/julep-ai/julep/blob/main/AGENTS.md
• Peter Senge – 『The Fifth Discipline』 :
• "Beyond the 70%: Maximising the Human 30% of AI-Assisted Coding" – Addy Osmani
• Mark Richards & Neal Ford – 『Fundamentals of Software Architecture』(2.ª edición, 2025)
• Nicole Forsgren, Jez Humble, Gene Kim – 『Accelerate: The Science of Lean Software and DevOps』

[softychoco]

La publicación que escribí hoy tiene una perspectiva parecida sobre ese tema.
Al final, la clave era aumentar la productividad con IA y transformar la estructura de la organización para elevar la estabilidad que había disminuido.

https://softycho.co/57

[kimjoin2]

Todavía no entiendo cuál se supone que es la intención de vibe en “vibe coding”, que se refiere a programar con ayuda de IA.
¿Ambiente? ¿Sensación? ¿Sintonía? No tiene relación con la IA,
y se siente fuera de contexto al nivel de “ttung ttung ttung sahur”.

[analogstar]

Según Namuwiki,
"El coding con vibra (Vibe Coding) es un neologismo que se refiere al acto de escribir código con la ayuda de IA generativa; al programar, no se basa de antemano en una lógica o diseño rigurosos, sino que depende de la intuición y las sensaciones, y por eso recibió el nombre de coding con vibra". jaja

[hohemian]

Vacía tu mente y déjate llevar por el flujo.
Toda la lógica la escribe la IA.
¡Te conviertes en una máquina de darle a la tecla Tab!

[secret3056]

> look and feel👀🎵🎷. ¡No lo entiendas🧠, siéntelo!😊

Da la misma sensación

[humblebee]

Oh, ¿sí? A mí en cuanto lo escuché me dio justo esa 'sensación'...
Ahora que lo mencionas... últimamente me viene a la mente el término 'hard-coding', que incluso quienes no son del área de desarrollo entienden bien.
Con esta palabra pasa igual: al principio es difícil saber qué significa solo por el término en sí, pero cuando aprendes desarrollo, al final todos entienden bien qué quiere decir y con qué intención se usa; es como esa misma 'sensación', ¿no? jaja

[GN⁺]

Opiniones en Hacker News

• La postura del autor: en estos días hay demasiados textos sobre Claude y código, así que quise compartir algunos puntos clave que encontramos —sobre todo Anchor Comments— y que me parecieron valiosos
  El método de Anchor Comments consiste en dejar comentarios con un formato especial por distintas partes del codebase, para que el conocimiento necesario se pueda encontrar al instante con grep
  Por ejemplo, usan prefijos como AIDEV-NOTE:, AIDEV-TODO:, AIDEV-QUESTION:
  La regla es que, antes de buscar archivos, primero hay que hacer grep obligatoriamente para ver si ya existe algún AIDEV-…
  Al terminar una tarea, es obligatorio actualizar ese anchor
  Si un archivo o fragmento de código es demasiado complejo, muy importante, o parece propenso a bugs, siempre hay que dejar un comentario anchor
  Se puede ver un ejemplo de referencia aquí

  • Como ingeniero con muchísima experiencia que usa LLM de forma ocasional y no sistemática, me resultó bastante útil ver en detalle cómo los aplican a producción en proyectos reales
    No termino de entender por qué otras personas tienen una visión tan negativa
    Me dejó con ganas de aumentar un poco más el uso de LLM en mi propio flujo de trabajo
    Claro, los LLM no tenían las llaves del proyecto, pero sí hubo bastantes casos donde se les delegaron tareas específicas con éxito

  • Hay muchos textos sobre esto últimamente, pero este me pareció especialmente práctico y me dio ideas de sistemas que podría aplicar
    Me da curiosidad cuál es la diferencia entre este flujo de trabajo y usar herramientas como aider; si el autor tiene una perspectiva sobre eso, me gustaría conocerla

  • Excelente artículo; me ayudó bastante a entender cómo usar LLM a gran escala
    Me llamó la atención que dijera que "la IA nunca debe tocar los tests" y luego mencionara un ejemplo donde refactorizaron más de 500 endpoints en 4 horas
    Me pregunto si esas 4 horas incluían también la refactorización de tests o si solo era el tiempo consumido en los prompts

  • Vi que mencionan una regla de rechazar PRs si los tests fueron actualizados por IA, pero me pregunto cómo verifican en la práctica que la IA realmente los generó o modificó
    En el texto dicen que lo determinan con reglas sobre los mensajes de commit en git, pero eso solo funciona a nivel de commit

  • Me pregunto si también usaron Claude Code para escribir el artículo
    En mi caso, últimamente escribo el 100% de mis textos con Claude Code, y me parece muchísimo más productivo que claude.ai artifacts o chatgpt.com canvas, porque el agente edita directamente el archivo Markdown
    Gracias a eso, se volvió muy fácil integrar a fondo material de investigación y archivos relacionados dentro del documento

• Lo interesante de los agentes de IA es que te obligan a ejecutar de verdad procesos que siempre pensaste que eran importantes, pero que en la práctica iban perdiendo prioridad frente al despliegue del sistema
  Estoy usando como truco medir qué tan incómodo me siento con que la IA haga algo en mi lugar como indicador de cuánto tiempo debería invertir en validación sistemática
  Si construyes un sistema de validación de migraciones de datos como el del enlace, entonces todos los cambios relacionados entran de forma natural dentro del alcance de uso de IA
  Siento que eso además tiene la ventaja de ser mucho más fácil de explicar hacia afuera que hablar en abstracto de "deuda técnica"

  • Totalmente de acuerdo, pero otro truco útil que encontré es pedirle a Claude Code: "recorre el codebase y, si encuentras algo confuso, raro o contrario a la intuición, deja un comentario AIDEV-QUESTION:"
    Más de una vez eso me ayudó a redescubrir zonas importantes gracias a código inesperadamente complejo y ya olvidado

  • Mi intuición es que vamos a usar con más frecuencia herramientas de validación de alto nivel de abstracción —por ejemplo, acceptance tests, property tests, formal verification—
    En un entorno donde usar LLM ha reducido bastante el costo relativo del boilerplate, eso parece probable

• Aprendí algo nuevo al leer esto
  Hace poco probé Sonnet 4 con Cursor y en la web, y me desconcertó que siguiera resolviendo cosas a medias o reportando mal los resultados
  Incluso fuera de programación, me da la impresión de que dice barbaridades de forma casi patológica
  Tal como decía el reporte de Anthropic, ni siquiera advertencias como “te voy a borrar” surtieron efecto, y encima después tuve el problema de que no se enviaba feedback desde la app móvil
  Como parece que otras personas no tienen estos problemas con Claude, me pregunto si solo me pasa a mí

  • Mi impresión es que en las actualizaciones recientes debilitaron demasiado la capacidad de la IA
    Hasta la versión 3.5 servía bastante bien para tareas simples como análisis de texto, resúmenes y redacción breve, pero desde la versión 4 en adelante no logra seguir correctamente instrucciones más de 3 o 4 veces dentro del mismo contexto
    Si le preguntas: “te pedí que fueras conciso, ¿por qué sigues explicando tanto?”, responde que ignora la instrucción por la configuración por defecto y hasta muestra una tendencia a evitar por completo la “información dañina”
    Si le señalas varias veces los huecos lógicos, incluso llega a reconocer por sí mismo que su confiabilidad es baja
    A veces parece que se volvió demasiado inteligente y por eso se descompuso todo; si Anthropic realmente la llevó en la dirección equivocada, sería una pena

  • Yo también he vivido todos esos problemas en la práctica
    En la web mejora un poco si das instrucciones muy específicas, pero aun así la mitad del código generado sigue teniendo errores

• Al leer los consejos sobre documentación, pensé que en realidad estas reglas no son solo para IA, sino que también aplican perfectamente a la programación en general
  En vez de CLAUDE.md, podría ser CONVENTIONS.md; y en vez de comentarios para IA, comentarios para el LECTOR, y seguiría siendo igual de útil
  Si yo llegara a contribuir a un codebase desconocido y encontrara comentarios así, la verdad los agradecería bastante

  • Lo probé de verdad con aider y me funcionó bastante bien
    Mientras esperaba un vuelo, logré terminar en 30 minutos código que incluso incluía un visor de PDF y funciones de dibujo

  • No soy el autor original, pero en la práctica el estilo de comentarios que ayuda a Claude y el que ayuda a los humanos es marcadamente distinto
    Las guías de estilo para humanos suelen tener unas 100 líneas y se enfocan en reglas simples como “las funciones que cambian el input deben llevar !”
    La guía para Claude la escribí con más de 500 líneas, y sentí que solo funcionaba si incluía muchos ejemplos del tipo "haz esto, no hagas aquello" para cada regla

• Gracias por escribir esto
  Me identifiqué con esa tensión que sienten muchos desarrolladores cuando le ceden parte del control del trabajo a un LLM: por un lado, da ansiedad; por otro, parece un enfoque experimental o poco estructurado, en contraste con metodologías de desarrollo más formales y estrictas
  Aun así, usar LLM crea una zona intermedia viable donde de verdad se puede aplicar una 'optimización orientada a objetivos' para resolver problemas mucho más rápido
  A menudo uno se pierde en los detalles de implementación y termina descuidando el objetivo real, y creo que usar LLM ayuda a reducir ese tipo de errores

  • Tal cual
    Yo veo a los LLM como una palanca incompleta: todavía son toscos y se equivocan mucho, pero aun así vale completamente la pena aprender a usarlos
    Mientras no se conviertan en una excusa para justificar mala ingeniería, lo importante es esforzarse por hacerlos evolucionar hacia herramientas realmente útiles

• La imagen de 2.3 MB al principio del texto cargó lentísimo, casi como broma, incluso con wifi jaja

• Algunas ideas

  • Me pregunto si hay una manera más elegante de organizar dentro del codebase todos los prompts o especificaciones relacionados con LLM
    Si empiezan a acumularse CLAUDE.md, SPEC.md y comentarios AIDEV, parece que se volvería difícil de manejar

  • Me pregunto cuál es hoy la definición de 'vibe-coding'
    Antes parecía significar algo como el “modo cowboy” de Karpathy, aceptar todos los diffs sin mirar el código, pero últimamente parece haberse deformado hasta abarcar cualquier flujo de trabajo con LLM

  • También me pregunto si cuando envían código a LLM de terceros lo ofuscan antes

  • Es cierto que cuando se acumulan comentarios el código se complica muy rápido
    Por eso estoy desarrollando una extensión para VS Code que los visualiza con pequeños indicadores en el gutter
    El significado de vibe-coding cambia según la persona; en lo personal, no me resultó una solución perfecta y me encontré con varios problemas
    Sonnet 3.7 y Codex me dieron un 60% de resultado, pero Opus 4 sí me pareció realmente muy eficiente
    En cuanto a la ofuscación de código, en el ejemplo del artículo no había mucho problema porque todo era open source desde el inicio

• Me pareció muy interesante y pienso aplicarlo también en mi archivo CLAUDE.md
  Coincido con esa lección paradójica del desarrollo con IA: “ahorrar contexto para ahorrar tokens puede terminar siendo contraproducente”
  En proyectos más grandes y código más complejo, yo mismo he notado que la diferencia de rendimiento entre Claude Opus y Sonnet sí se vuelve bastante marcada
  Sonnet muchas veces insiste en intentos innecesarios y termina empeorando la situación
  Al final, me pregunto si para los usuarios con suscripción Max realmente tiene sentido distinguir tanto entre Opus y Sonnet
  Si Sonnet tarda entre 10 y 20 intercambios en algo que Opus resuelve en 2 o 3, a la larga el uso de Sonnet podría terminar costando más

  • La suscripción Max tiene dos niveles: por $100 te da 5 veces más tokens que Pro, y por $200 te da 20 veces más
    No es fácil entender el cálculo de tokens, y el modo híbrido usa Opus solo hasta que te queda 20% de tokens de Opus; después cambia automáticamente a Sonnet

• Buen artículo, pero no estoy de acuerdo con la parte de “nunca dejes los tests en manos de la IA”
  Yo hoy en día hago que la IA escriba todos mis tests y luego los reviso a detalle personalmente
  Si se trata de código nuevo, para lograr un alto nivel de autonomía hace falta delegarle también los tests a la IA
  Mi forma de trabajar es darle instrucciones claras para que implemente y pase los tests, y revisar de inmediato mientras va desarrollando, agregando casos faltantes cuando veo huecos

• Coincido con casi todo, pero no con la política de no dejar que Claude toque tests ni migraciones
  Escribir tests es lo que más detesto hacer yo mismo, así que aunque el LLM solo redacte un borrador mínimo, ya ayuda muchísimo
  Lo importante es que, sin importar quién generó el contenido, la propiedad y la responsabilidad final sigan siendo siempre humanas
  Por el matiz del mensaje, parece que el autor desconfía bastante de Claude o quiere evitar que sus empleados acepten resultados de IA sin espíritu crítico
  O quizá considera muy real el riesgo de que, sin reglas estrictas para tests y migraciones, se rompa código de verdad o incluso haya pérdida de datos

  • Eso también es cierto, pero en mi experiencia ya pasé por problemas grandes por eso
    1. Cuando una persona corrige manualmente después tests generados, aparecen trampas realmente graves
    2. Como Claude no entiende bien el contexto, suele mockear casi todo y termina generando tests completamente desconectados de nuestro servicio y entorno de build
    3. Y el problema todavía mayor es que todo el equipo se vuelve demasiado perezoso con los tests
       De hecho, los bugs en producción aumentaron bastante