“Lately I have seen you take a more active role in PR review and really investigating, catching and detailing issues that come up. This is a big help to the team in my opinion.”
Eso me lo dijo un tech lead después de las semanas en que más he usado IA para escribir código. No menos: más. Y cuando corrí /insights, el comando que analiza tu historial de sesiones en Claude Code y genera un reporte de patrones, fricciones y métricas, entendí por qué.
Disclaimer rápido: no tengo relación con Anthropic. Uso estas herramientas porque me funcionan, y lo comparto porque los datos me parecen útiles para otros devs.
Esto no es “dejar de programar”: es otra etapa del oficio 🧬
El desarrollo siempre ha sido una cadena de abstracciones: cada salto nos quitó tecleo, no responsabilidad. Los agentes parecen ser el siguiente salto: menos escribir, más decidir y mantener.
Mi setup 🧩
Pasé de usar ChatGPT para dudas puntuales a integrar Claude Code como herramienta diaria.
- Claude Code (Sonnet 4.5) en terminal: implementaciones completas, multi-archivo, iteración con feedback.
- JetBrains AI (con Sonnet 4.5): dudas puntuales en el IDE, PR reviews, prompts específicos.
No me interesa lo que algunos llaman vibe coding: construir muy rápido con IA e iterar hasta que funcione, sin necesariamente profundizar en el porqué técnico de cada decisión. A mí me interesa desarrollo asistido con control: que el agente acelere, pero yo mantengo la dirección. Todo lo que se mergea pasa por mi revisión línea por línea. Si algo se rompe, el responsable soy yo.
Los números: qué dice /insights sobre mi uso real 📊
Ejecuté /insights dentro de Claude Code y me devolvió un reporte que cubre solo mi actividad desde la terminal en las dos últimas semanas. Ojo: llevo meses usando la herramienta; este reporte captura solo ese periodo.
- 445 mensajes en 12 días (≈ 37.1 msgs/día)
- +5,867 / −3,088 líneas en 61 archivos
- Un patrón dominante: Iterative Refinement en 13 sesiones
Las dos categorías principales de lo que le pedí empatan: Feature implementation (17) y Bug fix (17), seguidas de UI refinement (8), clasificación de comentarios de PR (7) y redacción de respuestas a code review (7).
No lo uso solo para “generar código”. Lo uso para recorrer el ciclo completo: desde implementación inicial hasta responder code reviews.
Dónde se rompe el flujo (y ahí está lo bueno) 🧯
La parte más útil del reporte no fue lo que hice bien. Fue esto:
- Buggy Code (13): primeros intentos con type mismatches, props mal usados, errores lógicos.
- Wrong Approach (9): construir desde cero cuando el codebase ya tenía el patrón que debía seguir.
- Otros: cambios demasiado agresivos, imprecisiones menores.
Sí: los primeros intentos suelen tener errores. Pero el aprendizaje fue claro: mis problemas con el agente no se arreglan usándolo menos, sino dándole mejor contexto.
Cuando el contexto es vago, el agente adivina. Cuando el contexto incluye los tipos correctos y el patrón existente del codebase, converge rápido.
El patrón que me describió mejor de lo que yo lo habría escrito 🪞
/insights identificó mi flujo dominante: delego implementaciones ambiciosas (multi-archivo) y luego piloteo iteraciones hasta aterrizarlas. Los primeros borradores con errores no son un bloqueo; son el costo esperado de ir rápido… siempre que yo esté guiando el rumbo.
Es el mismo enfoque que usaría con un dev junior talentoso: pido un primer borrador ambicioso sabiendo que va a necesitar ajustes, y lo guío con contexto y reglas del repo.
Lo que refuerzo: lo que funciona según el reporte ✅
Tres patrones que quiero mantener:
1) Code reviews con criterio. Distingo bugs reales de comentarios no accionables y respondo con objeciones fundamentadas cuando toca. El agente ayuda a ordenar y redactar, pero la decisión de qué aceptar y qué rechazar es mía.
2) Iteración completa dentro del mismo flujo. Implementación → feedback → fixes → tests. Un dato que me gustó: 86 usos de TodoWrite. Con agentes, el plan también es parte del trabajo.
3) Decisiones guiadas por patrones existentes. Prefiero consistencia del codebase a “ideas nuevas” que suben el costo de mantenimiento. Cuando una propuesta se salía de las convenciones, hice la llamada de reiniciar usando el patrón existente como referencia.
Takeaways que voy a institucionalizar (y medir) 📌
De las fricciones, el reporte sugiere reglas que voy a codificar en CLAUDE.md… Aquí van dos ejemplos:
- Pattern-first: antes de implementar una feature, buscar si hay un patrón existente en el codebase y usarlo como referencia.
- Types-first: antes de proponer fixes en TypeScript, leer tipos e interfaces relevantes. Cero “adivinar shapes”.
El reporte también sugiere crear skills (comandos reutilizables para flujos repetibles). Por ejemplo, uno para responder code reviews: listar comentarios, clasificar por tipo, proponer fix mínimo, redactar respuesta y verificar build.
Responsabilidad: la parte que no se delega 🧱
Hay una diferencia entre usar agentes y dejar de pensar. Un amigo que es administrador —no dev— construye apps rapidísimo con herramientas de IA. Es impresionante, y su objetivo es que las apps funcionen. El mío es que además sean mantenibles y defendibles.
La herramienta se puede caer (hasta servicios grandes como AWS se caen). Si se cae, yo tengo que poder entrar al repo, entender lo que está pasando y resolver —especialmente en lo que yo mismo metí en mis PRs. El código lo puede escribir cualquier herramienta. Lo que no puede escribir es el criterio para decidir qué código debería existir y cuál no. La IA puede escribir. El ownership no.
Si quieres probar esto sin volverte dependiente 🧪
Si estás en la misma transición, lo único que sí recomendaría (a nivel general) es esto:
- Trata la IA como compañero, no como autopilot. Acelera la ejecución, pero tú decides el rumbo.
- Invierte en contexto. Los tipos correctos y los patrones del repo valen más que un prompt elaborado.
-
Después de 2–4 semanas (y si usas Claude Code), ejecuta
/insights. No para “validarte”, sino para encontrar fricciones repetidas (y corregir hábitos). - Si estás empezando, a mí me sirvió un punto de partida estructurado: el curso gratuito AI-Assisted Programming by Nebius x JetBrains (lo dejo en créditos).
Qué sigue 🧭
No creo que usar agentes mate el desarrollo. Creo que desplaza dónde está el trabajo valioso: menos tecleo, más criterio, más revisión, más decisiones defendibles.
Mi próximo paso es medir si los ajustes (especialmente pattern-first y types-first) reducen las instancias de buggy code y wrong approach en el siguiente ciclo de /insights. Si los datos mejoran, lo comparto. Si no, también. Para mí, tener feedback con datos sobre mi workflow es oro.
Créditos 🙌
- Curso que me metió en esto: AI-Assisted Programming by Nebius x JetBrains
- Herramienta en terminal: Claude Code
- En mi IDE (WebStorm): JetBrains AI
- Foto por Daniil Komov en Unsplash
Top comments (0)