El primer intento es 95% basura: el recorrido de un Staff Engineer junto a Claude Code

 (sanity.io)
24 puntos por GN⁺ 2025-09-03 | 5 comentarios | Compartir por WhatsApp
  • Un staff engineer comparte su experiencia tras experimentar durante 6 semanas con un flujo de trabajo de desarrollo junto a IA usando Claude Code
  • La clave para una integración exitosa es la mentalidad de considerar a la IA como un “desarrollador junior que no aprende”
  • La mayoría de los primeros intentos son un 95% fallidos, pero mediante iteración se van puliendo poco a poco hasta convertirse en código útil
  • Se resuelve el problema de falta de contexto de la IA usando archivos de contexto por proyecto (Claude.md) e integración de herramientas basada en MCP
  • El rol del desarrollador se desplaza de escribir código hacia la resolución de problemas y el diseño de arquitectura, marcando un nuevo patrón de productividad en la era del uso de IA

Contexto y enfoque

  • El autor antes escribía todo el código por su cuenta, pero recientemente la IA escribe el 80% y él se concentra en arquitectura, revisión y gestión de desarrollo multihilo
  • Este texto no adopta un tono optimista de “la IA impulsa la innovación”, sino que comparte la confusión y la metodología realista al integrar IA en un flujo de trabajo de desarrollo en producción
  • Tratar a la IA como un “desarrollador junior que no aprende” es la clave para usarla con éxito

El proceso de cambio del paradigma de desarrollo

  • Durante los primeros 5 años mantuvo una forma de desarrollo basada en libros y documentación de SDK
  • Después cambió durante 12 años a un enfoque de uso del conocimiento colectivo basado en búsquedas (Google)
  • En los últimos 18 meses estuvo experimentando con programación asistida por IA mediante Cursor
  • En las 6 semanas más recientes vivió un cambio drástico al usar Claude Code para una delegación integral a la IA
  • La adaptación a Claude Code permitió sentir una mejora en productividad en apenas unas horas

Flujo de trabajo real de producción basado en IA

  • Cuando trabaja en código que irá a producción, usa la IA sobre todo para “pensar”
  • Generar código perfecto de una sola vez es imposible. La misión del ingeniero es encontrar la mejor solución posible para el problema
    • Primer intento (95% fallido): la IA acumula contexto del sistema y el desarrollador define el problema, pero el código casi siempre está mal
    • Segundo intento (50% fallido): mejora la comprensión del contexto y se concreta el enfoque, pero aún la mitad sigue siendo inútil
    • Tercer intento (código utilizable): tras iterar y revisar, aparece una base de código realmente aprovechable que luego puede mejorarse
  • Este proceso no es un fracaso, sino un proceso deliberadamente planificado de experimentación y optimización iterativa

El problema del contexto y la solución

  • La IA no puede mantener memoria entre sesiones, así que existe la limitación de tener que repetir la misma explicación cada vez
  • Como solución, usa el archivo Claude.md para registrar decisiones de arquitectura, patrones y enlaces a documentación
  • A través de integración MCP, se conecta con Linear, Notion, GitHub, la base de código y bases de datos para proporcionar contexto automáticamente
    • Linear aporta contexto de tickets
    • Notion o Canvas permiten acceder a documentación
    • Bases de datos no productivas permiten verificar la estructura de datos
    • GitHub aporta información de contexto de PR anteriores

Operación en paralelo de instancias de Claude y estrategias clave

  • Opera varias instancias de Claude en paralelo, con un enfoque similar a gestionar un pequeño equipo de desarrollo que pierde la memoria todos los días
  • Estableció estrategias como prohibir la paralelización dentro del mismo dominio del problema, registrar todo el trabajo en herramientas de gestión de proyectos como Linear y marcar claramente el código modificado directamente por humanos
  • Usa activamente la IA no solo para escribir código, sino también para revisión de código: detecta rápido pruebas faltantes, errores evidentes y oportunidades de mejora, reduciendo trabajo repetitivo
  • Según la política de su empresa (Sanity), la responsabilidad final por la calidad sigue siendo del ingeniero, aunque el código lo haya generado la IA
  • En un entorno donde el código generado por IA y por humanos no se distingue fácilmente, disminuye el apego emocional y se vuelve posible una revisión de código más crítica y objetiva

Proceso de revisión de código en 3 etapas

  • Escribir código es solo una parte del trabajo, y revisar código también lo es
  • Revisión 1: revisión inicial de Claude
    • Detecta faltas de cobertura de pruebas y errores evidentes
    • Ahorra tiempo de revisión entre colegas con sugerencias de mejora
  • Revisión 2: mi propia revisión
    • Verifico mantenibilidad, arquitectura, lógica de negocio e integración
    • Aunque el código sea generado por IA, el ingeniero tiene la responsabilidad final
  • Revisión 3: revisión habitual del equipo
    • No saben qué partes fueron generadas por IA. Se aplica el mismo estándar de calidad
    • Es posible una revisión objetiva sin apego emocional
  • Al haber menos apego emocional al código escrito por IA, la revisión objetiva resulta más fácil

Experimentos de automatización del trabajo y agente activado por Slack

  • Hizo un piloto de un agente integrado con Slack usando Cursor: tuvo éxito con ajustes simples de lógica de negocio, pero falló con layouts CSS complejos
  • En este momento existen limitaciones como falta de soporte para paquetes NPM privados, commits sin firma y desvíos del seguimiento oficial
  • Aun así, hay entusiasmo por un escenario futuro en el que un agente procese tickets simples y repetitivos durante la noche

Costos y ROI

  • El costo de uso de Claude Code representa una cantidad nada menor que la empresa paga por ingeniero
  • Sin embargo, esa inversión genera mejoras de productividad
    • Velocidad de lanzamiento de funciones 2 a 3 veces mayor
    • Capacidad de gestionar múltiples hilos de desarrollo al mismo tiempo
    • Desaparece la necesidad de escribir manualmente código repetitivo o boilerplate
  • En la etapa inicial de adopción de IA, se necesita un presupuesto mensual de $1000 a $1500 para ingenieros senior, con expectativa de mejorar la eficiencia de costos a medida que aumente la experiencia

Problemas y límites persistentes del desarrollo asistido por IA

  • Problema de aprendizaje: la IA no aprende de sus errores y repite los mismos malentendidos; la solución es reforzar la documentación abundante y las instrucciones explícitas
  • Problema de confianza: la IA puede entregar código incorrecto con total seguridad, por lo que siempre debe verificarse, especialmente en gestión de estado compleja, rendimiento y zonas de seguridad
  • Problema de límite de contexto: las bases de código grandes superan la ventana de contexto de la IA, así que es esencial dividir los problemas en unidades pequeñas y dar contexto claro

El cambio emocional: del código al problema

  • Dejar atrás la obsesión con el código y pasar a una mentalidad centrada en resolver problemas
  • Eliminar rápido el código incorrecto, hacer revisiones más objetivas y reducir la carga emocional del refactor = cambios positivos
  • Si aparece una mejor herramienta de IA, existe disposición a cambiarla de inmediato
  • Lo esencial no es “el código en sí”, sino el valor del problema que debe resolverse

Consejos para adoptar IA desde la perspectiva de ingeniería

  • 1. Permitir experimentar con varias soluciones de IA: el equipo necesita usar distintas herramientas directamente para fortalecer su capacidad práctica
  • 2. Aplicar IA primero a tareas repetitivas y simples: así pueden obtenerse resultados rápidos
  • 3. Asegurar presupuesto para prueba y error: el primer mes hay que tolerar la confusión
  • 4. Rediseñar el proceso de revisión: reforzar las verificaciones según las características del código generado por IA
  • 5. Documentar a fondo: un buen contexto multiplica la productividad
  • Los ingenieros que se adapten al nuevo flujo de trabajo con IA descubrirán que ahora tienen un nuevo cuchillo afilado en su caja de herramientas
  • Los ingenieros que adopten flujos de trabajo con IA evolucionarán hacia un nuevo rol centrado en orquestar múltiples agentes de IA y enfocarse en arquitectura, revisión y resolución de problemas complejos

Tu siguiente paso

  • Elige una sola funcionalidad, pequeña pero bien definida,
  • dale a la IA tres oportunidades para implementarla,
  • y revisa el resultado como si estuvieras mentoreando a un desarrollador principiante
  • Eso es todo. No hace falta un gran cambio ni rehacer procesos
  • Solo necesitas una funcionalidad, tres intentos y una revisión honesta
  • El futuro no consiste en que la IA reemplace a los desarrolladores
    • sino en que los desarrolladores trabajen más rápido, construyan mejores soluciones y aprovechen las mejores herramientas

Lecturas relacionadas

5 comentarios

 
helio 2025-09-05

"Con un procedimiento tan sofisticado como este, pienso que sería mejor que uno mismo escribiera el código directamente"
 
skageektp 2025-09-05

La actitud de un líder de equipo que no les delega trabajo a los demás y se encarga de hacerlo él mismo jajajaja
 
greenbhj 2025-09-05

Parece que sí, pero para nada es así.
En los últimos 6 meses hice experimentos repetidos, tanto pequeños como grandes.
 
iolothebard 2025-09-05

Elige una sola función pequeña y bien definida,
dale a la IA tres oportunidades para implementar esa función,
y revisa el resultado como si estuvieras mentoreando a un desarrollador principiante.
Si puede hacer eso sin mí, es una “ganancia”… pero si yo tengo que estar ahí… entonces la “ganancia” es que mejor lo haga yo mismo.
 
GN⁺ 2025-09-03
Opinión de Hacker News

  • Da la sensación de que es importante dar instrucciones teniendo en cuenta los límites cognitivos del agente; por ejemplo, no pedir cambios grandes, sino hacer un plan y luego indicar que ejecute en pasos pequeños, probando cada etapa sobre la marcha. En pasos complejos, ayuda hacer que escriba código para visualizar el problema y la solución. Si falla en algún paso, resulta efectivo agregar logging al código, guardar los logs, probar, revisar los logs para identificar la causa y repetir ese proceso de forma iterativa. Si se logra que el modelo identifique qué debe cambiar a partir del diseño del código existente, se puede evitar que la IA meta todo en un solo archivo. He visto blogs donde varias personas comparten este tipo de consejos, y aunque todavía no es perfecto, al menos ya no siento que el 95% del resultado sea basura.

    • Yo ya probé todo eso y aun así la mayor parte del código que sale sigue siendo inútil; incluso cuando más o menos funciona, al final igual tengo que meter mano para que quede usable. Sí hay casos en los que realmente funciona bien y en esos momentos emociona, pero en lo personal no he sentido una gran mejora de eficiencia.
    • En tareas complejas y de gran escala, siento que funciona bien dar instrucciones como: "No escribas código todavía. Voy a describir cada paso en detalle". Por ejemplo, presentar un esquema por etapas como leer entradas, generar candidatos, puntuar candidatos, priorizar y ordenar, crear la estructura de datos de salida, guardar en la DB, etc. Claude organiza esas etapas en una lista de TODOs y en documentación para que sea fácil retomar después. De hecho, me pasó que trabajé una hora, lo dejé y luego le dije: “genera código para las etapas completadas y deja comentarios para seguir después”, y fue fácil continuar el trabajo.
    • Incluso usando varios LLM/agentes durante mucho tiempo, sigue siendo difícil obtener resultados realmente útiles. Para evitar salidas inútiles, hay que gastar más energía redactando prompts que si uno hiciera el trabajo directamente, y además termina poniéndose ansioso por el tono, la redacción y por evitar asociaciones no deseadas. Ojalá existiera una herramienta que gestionara prompts para LLM como si fuera un framework de frontend aparte, organizando estructuras generales de prompts o aplicando buenas prácticas por defecto para reducir mucho la carga mental al buscar algo en el código, diseñar una función nueva o escribir tests.
    • Si el procedimiento tiene que ser así de sofisticado, entonces mejor escribir el código uno mismo.
    • Al probar AI y vibe coding en un proyecto personal, vi que el desarrollo guiado por pruebas encaja bastante bien con el vibe coding. Recomiendo descomponer el problema en unidades pequeñas y testeables, pedirle primero a la IA que escriba los unit tests y después implementar el código real.

  • Ya estamos en un punto donde estos artículos deberían incluir ejemplos concretos de trabajo real donde “el agente procese de forma distribuida”, y no solo tareas simples de refactorización o boilerplate de React. Dicen que en Sanity había funciones largamente pedidas y que el agente paraleliza una cantidad importante del trabajo. Aun así, cuesta creer afirmaciones del tipo “un junior que no aprende escribió el 80% del código”.

    • En mi opinión, la expresión "junior que no aprende" está mal planteada. Claude se parece más a un senior muy educado que solo conoce la respuesta correcta de los libros pero no tiene experiencia real. Tiene un conocimiento enciclopédico excelente, pero le falta criterio práctico. Últimamente estoy construyendo un codebase comercial con Claude, y la mayor parte de mis inputs se enfocan en el 'sabor del código' y en definir qué significa el éxito; el código en sí termina siendo algo desechable.
    • Es curioso que esté aumentando tanto el código generado por IA y aun así el open source siga acumulando issues sin resolver.
    • Si mostraran ejemplos reales de tareas delegadas a IA y sus resultados, habría oportunidad de cuestionar las expectativas exageradas, pero la realidad es que siguen apareciendo publicaciones diciendo solo que Claude Code es increíble sin mostrar ejemplos prácticos.
    • Cuando veo blogs técnicos de ingenieros ya convertidos en vendedores, usando expresiones como "learnings" en vez de "lessons", siento que van por el camino opuesto al mío, porque con los años de experiencia dependo menos de Google y me limito más a revisar documentación.

  • El autor dijo que hubo mejora de productividad, pero también mencionó tal cual las limitaciones de siempre, así que al final pareció que no decía gran cosa. Estoy bastante seguro de que nadie delegaría el desarrollo de funciones clave a Claude Code.

  • Evitar boilerplate es parte del trabajo del desarrollador, y también una abstracción que le hace la vida más fácil a tu yo del futuro. Si generas boilerplate con IA, luego cuando toque cambiar cada instancia manualmente, la molestia puede ser todavía mayor, y si ese boilerplate disperso en varias partes queda inconsistente, el problema crece aún más.

    • La mayoría de frameworks y herramientas ya incluyen generadores automáticos de boilerplate, así que no está claro cuánto valor tiene gastar tokens y dinero en pedirle esto a una IA.

  • Lo interesante es que esta persona intenta hacer la implementación base con IA, mientras que yo hago lo contrario: siempre construyo primero la base por mi cuenta. Así puedo entender con precisión la estructura y cómo funciona, y después sí dejarle a la IA solo el boilerplate repetitivo. La IA es buena para seguir patrones, pero es muy débil para diseñar arquitectura.

    • Los LLM son muy malos para planificar una arquitectura mantenible. A medida que el código evoluciona, no logran refactorizar la estructura, y ahí puede estar uno de sus límites por su falta de comprensión de contexto.

  • Ya de por sí los sueldos base son caros, así que me cuesta comprar la idea de que además haya que gastar entre 1,000 y 1,500 dólares al mes en problemas menores donde quizá aumente la productividad. Al menos a mi jefe no creo que le guste.

    • Los fabricantes de hardware compran cada año licencias de herramientas EDA que cuestan más que el salario de un desarrollador. Si la productividad realmente mejora de forma visible, entonces 1,000 dólares no serían nada.
    • Si el salario de los desarrolladores es tan alto, entonces en realidad no invertir sería lo irracional. Si con 1k-1.5k dólares al mes puedes elevar claramente la productividad, dudarlo sería lo ineficiente. Desde esa perspectiva, centrarse solo en el costo de la IA es una visión demasiado simplificada. Y si gracias a la IA puedes reducir la cantidad de desarrolladores, eso también es un ahorro real.
    • Yo ni siquiera gasto 20 dólares al mes con IntelliJ Pro AI, así que me dio curiosidad si Claude realmente era tan caro; lo busqué y sí, parece que puede llegar a serlo. De todos modos, la realidad es que en algún presupuesto va a aparecer una suscripción de IA adicional, igual que hoy la empresa paga internet de alta velocidad: el costo de IA ya se está volviendo algo básico.
    • Y también hay que recordar que ese precio en realidad está subsidiado.
    • Tengo interés en ver cómo cambian las empresas de aquí en adelante. Lo que sí parece claro es que al final lo importante será bajo qué criterios se evalúe a los desarrolladores. Será clave si usar IA aumenta el riesgo de salir perjudicado en evaluaciones de desempeño o despidos, y cómo demostrar que el protagonista de los resultados fuiste tú y no el LLM.

  • No termino de entender la forma de usar MCP(Multi-Channel Processor) que se menciona en el texto. Claude Code puede llamar casi cualquier servicio de terceros desde el shell con curl o gh, así que usar MCP incluso podría traer problemas (por ejemplo, el servidor MCP de Linear recorta issues si son demasiado largas, mientras que con llamadas directas a la API esa limitación no existe). Me pregunto si se me está escapando algo.

  • Anthropic publicó una entrevista con Boris Cherny (el creador de Claude Code), donde también comparte ideas sobre el futuro del agentic coding con Claude Code y cómo usarlo https://youtu.be/iF9iV4xponk

  • Al ver la mención de un “presupuesto de $1000-1500/mes”, pensé que quizá solo usa API keys y no conoce planes mensuales fijos como claude MAX. Creo que con $100-200 al mes alcanza de sobra, siempre que no se trate solo de repetir queries sin parar.

    • Siento que $1k-1.5k es una cifra exagerada. Incluso el plan Max de 20x cubre bastante uso por $200 al mes y el límite se reinicia cada 5 horas. Aun así, si todos los días superas ese tope, puede que a ese nivel pagar por tokens termine siendo todavía más caro.

  • Si piensas usar Claude u otros agentes, recomiendo muchísimo hacer logging. Si le metes a la IA el archivo completo de logs, aumenta bastante la probabilidad de que organice el problema, te dé una respuesta o te ayude a pasar al siguiente paso. El logging de verdad lo es todo.