Soy developer senior y Claude Code me obligó a destruir todo lo que creía saber
Leí el artículo del CEO. Cada palabra. Y mi primera reacción fue cerrar la laptop, salir a caminar y no volver en una hora.
Una respuesta al artículo “Cuando un CEO decide codear” — desde adentro de B&W
Antes de que sigas leyendo
Leí el artículo del CEO. Cada palabra. Y mi primera reacción fue cerrar la laptop, salir a caminar y no volver en una hora.
No porque fuera mentira. Sino porque era verdad.
Me llamo Andrés. Llevo 11 años escribiendo código. Soy developer senior full-stack en Bricks & Walls desde hace 4 años. He liderado proyectos de ecommerce que procesan miles de transacciones diarias. He diseñado arquitecturas en NestJS que siguen en producción sin una caída grave. He mentorado a 6 developers junior que hoy son mid-level. He dormido en la oficina debuggeando un WebSocket que se desconectaba cada 47 minutos en producción.
Soy bueno en lo que hago.
Y Claude Code me hizo cuestionarlo todo.
El día que vi al CEO commitear
Fue un martes. Yo estaba en mi tercer café, peleando con un componente de React que no renderizaba bien en Safari — el clásico bug que te come 4 horas y la solución es una línea de CSS. Tenía Jira abierto con 14 tickets asignados, el standup en 20 minutos, y un PR pendiente de review que llevaba 3 días esperando porque el otro senior estaba en otro proyecto.
Entonces vi el mensaje en el canal de #arquitectura.
El CEO había subido un repositorio completo. Un proyecto interno que llevábamos 2 meses esperando que “alguien tuviera tiempo” de arrancar. Arquitectura en NestJS, front en Next.js, modelos de MongoDB, seeds de datos, tests unitarios, documentación de API, Docker Compose, pipeline de CI/CD para Jenkins.
Todo.
En una noche.
Mi primera reacción fue: “Seguro es un boilerplate genérico que no funciona.” Abrí el repo. Empecé a leer. Y sentí algo que no había sentido en años.
Miedo.
No era un boilerplate. Era código que entendía nuestras convenciones. Que usaba nuestros patrones de error handling. Que seguía nuestra estructura de carpetas. Los modelos tenían validaciones reales, no placeholders. Los tests cubrían edge cases que yo mismo habría considerado. La documentación era mejor que cualquiera que hubiéramos escrito en los últimos 2 años.
No era perfecto. Había cosas que yo habría hecho diferente. Pero era funcional, coherente y desplegable. En una noche. Un proyecto que nuestro equipo había estimado en 6 semanas.
Cerré el repo. Cerré la laptop. Salí a caminar.
Las cinco etapas del developer ante la IA
Lo que siguió fue un proceso que hoy puedo describir con claridad, pero que en el momento viví como un caos emocional.
1. Negación
“Esto no escala. Seguro funciona para un MVP, pero en producción se cae. No maneja concurrencia real. No tiene observabilidad. No considera los edge cases que solo aparecen con usuarios reales.”
Revisé el código buscando fallas. Encontré algunas. Me aferré a ellas como un náufrago a una tabla. “¿Ven? No puede reemplazarnos. Le falta manejo de rate limiting en esta ruta. No tiene circuit breaker en la integración con el ERP.”
Tenía razón en las observaciones. Pero estaba equivocado en la conclusión.
2. Rabia
“¿Entonces para qué llevo 11 años estudiando? ¿Para qué me certifiqué en AWS? ¿Para qué pasé 6 meses aprendiendo patrones de diseño? ¿Para que una máquina haga en minutos lo que yo hago en semanas?”
Esta fase fue la más corta pero la más intensa. Duró unos 3 días. Incluía resentimiento silencioso en los standups, mensajes pasivo-agresivos en Slack (“interesante enfoque, pero en el mundo real…”), y una noche entera leyendo artículos que confirmaban que la IA “no puede reemplazar a los programadores de verdad.”
3. Negociación
“OK, tal vez sirve para cosas simples. CRUD endpoints. Componentes de UI básicos. Documentación. Pero el trabajo REAL — la arquitectura, las decisiones de trade-off, el debugging de producción — eso sigue siendo nuestro.”
Esta fue la etapa más peligrosa. Porque era parcialmente cierta, y las verdades parciales son las mentiras más convincentes.
4. Depresión
“¿Y si realmente no me necesitan?”
No voy a adornar esto. Hubo una semana en la que programé con el piloto automático. Hacía mis tickets, asistía a las reuniones, escribía mis PRs. Pero por dentro estaba procesando algo que ningún tutorial de Udemy te prepara para enfrentar: la posibilidad de que tu identidad profesional — eso que te define, que te da orgullo, que contestas cuando alguien pregunta “¿a qué te dedicas?” — esté a punto de transformarse en algo irreconocible.
5. Aceptación (o algo parecido)
Llegó un jueves a las 11pm. Yo estaba intentando implementar una integración con un ERP que tenía una API con documentación en PDF de 200 páginas, autenticación OAuth2 con refresh token rotativo, y respuestas XML que había que transformar a JSON con un schema que cambiaba según el tenant.
Llevaba 3 días. Había avanzado un 40%.
Entonces, por primera vez, abrí Claude Code.
La primera vez
No sabía qué esperar. Había visto las demos. Había escuchado al CEO hablar de workflows, skills, MCPs. Sonaba a buzzwords corporativos. Pero eran las 11 de la noche, tenía un deadline el lunes, y mi orgullo ya no era un lujo que pudiera pagar.
Le di contexto. Le pasé la documentación del ERP. Le expliqué nuestra arquitectura. Le describí el flujo de datos esperado.
Y entonces hice algo que nunca pensé que haría: le pedí que escribiera el módulo de integración.
Lo que pasó en los siguientes 40 minutos cambió mi carrera.
Claude Code no solo escribió el código. Preguntó cosas que yo no había considerado. “¿El refresh token tiene TTL fijo o variable? Si es variable, necesitamos un mecanismo de retry con backoff exponencial antes de solicitar uno nuevo.” Yo no había pensado en eso. Revisé la documentación. Tenía razón — el TTL era variable.
Generó el módulo completo. Tipado estricto. Manejo de errores por tipo de falla del ERP. Transformación XML→JSON con validación de schema. Tests unitarios que cubrían los 5 escenarios de error que la API podía devolver. Logging estructurado compatible con nuestro stack de observabilidad.
Revisé cada línea. Modifiqué 3 cosas. Agregué un caso edge que era específico de un cliente nuestro. Corrí los tests. Pasaron.
A la medianoche tenía lista una integración que me habría tomado hasta el viernes.
Me quedé sentado en la oscuridad de mi departamento, con el monitor como única luz, pensando: “No me reemplazó. Me liberó.”
Lo que realmente aprendí
Las semanas siguientes fueron las más intensas de aprendizaje en mis 11 años de carrera. No aprendí un nuevo framework ni un nuevo lenguaje. Aprendí a trabajar de una forma completamente diferente.
Aprendí que yo no era mi código
Esta fue la lección más dolorosa. Durante años, mi valor como profesional estaba atado a mi capacidad de escribir código. Buenas funciones. Arquitecturas elegantes. Soluciones ingeniosas a problemas complejos.
Claude Code escribe código bueno. A veces mejor que el mío. Y descubrir eso me obligó a preguntarme: si la IA puede escribir el código, ¿cuál es mi valor real?
La respuesta me tomó semanas, pero cuando llegó fue clarísima: mi valor nunca fue escribir código. Mi valor es saber qué código debe escribirse, por qué, y qué consecuencias tendrá dentro de 6 meses.
La IA no tiene contexto de negocio. No sabe que el cliente de México necesita facturación electrónica con CFDI 4.0. No sabe que nuestro equipo de DevOps tiene un trauma colectivo con Kubernetes y prefiere Cloud Run. No sabe que la última vez que usamos GraphQL en un proyecto, el developer que lo implementó se fue de la empresa y nadie pudo mantenerlo.
Ese conocimiento — el contexto humano, organizacional, histórico — es irreemplazable. Y resulta que yo tenía toneladas de él. Solo que nunca lo había valorado porque estaba demasiado ocupado escribiendo for loops.
Aprendí a ser director, no albañil
Antes de Claude Code, mi día era: leer ticket → pensar solución → abrir VS Code → escribir código → debuggear → escribir tests → hacer PR → esperar review → corregir → mergear. Ocho horas. Un ticket y medio si tenía suerte.
Ahora mi día es: leer ticket → pensar solución → describir la solución con precisión quirúrgica → dejar que Claude Code la implemente → revisar → ajustar → mejorar → mergear. Las mismas ocho horas. Seis o siete tickets.
Pero atención: la parte de “describir la solución con precisión quirúrgica” no es trivial. Es, de hecho, la habilidad más difícil que he tenido que desarrollar. Porque requiere que tengas toda la arquitectura en la cabeza, que anticipes los edge cases antes de que exista el código, y que comuniques tu intención con una claridad que no deja espacio para ambigüedades.
Es como pasar de ser el albañil que pone los ladrillos a ser el arquitecto que diseña el edificio. Sigues necesitando entender cómo funcionan los ladrillos. Pero tu trabajo ya no es ponerlos uno por uno.
Aprendí que los workflows son el nuevo superpoder
Lo que más me costó entender fue el ecosistema de herramientas alrededor de Claude Code. No es solo “un chat que escribe código.” Es una plataforma.
Skills: Son como recetas especializadas. Hay skills para análisis de requerimientos, para scaffolding de proyectos, para auditorías de seguridad, para generación de tests. La primera vez que vi una skill bien configurada convertir un documento de requerimientos en historias de usuario con criterios de aceptación, entendí por qué el CEO estaba tan entusiasmado.
MCPs (Model Context Protocol): Esto fue lo que me voló la cabeza. Conectas Claude Code directamente a tus herramientas — Jira, BitBucket, tu base de datos, tu documentación interna — y de repente la IA no trabaja en el vacío. Trabaja dentro de tu ecosistema. Sabe cuáles son tus tickets abiertos. Puede leer tu código existente. Entiende tu contexto.
Plugins: Extensiones que agregan capacidades específicas. Análisis de performance. Generación de diagramas de arquitectura. Auditoría de dependencias. Cada plugin es como agregarle una herramienta nueva a tu cinturón.
Agentes en paralelo: Esto es lo que hace que la velocidad sea absurda. Mientras un agente trabaja en el front-end de un módulo, otro está construyendo el back-end, otro escribiendo tests, otro documentando. Coordinados. Consistentes. Simultáneos. Es como tener un equipo de developers invisibles que trabajan a velocidad de máquina pero con la coherencia de un solo cerebro.
La curva de aprendizaje fue empinada. Pero una vez que la dominé, no hubo vuelta atrás.
Las conversaciones difíciles
No todo fue epifanía y productividad. Hubo conversaciones incómodas.
Con developers junior que me preguntaban, con los ojos llenos de preocupación: “¿Debería seguir estudiando programación?” Mi respuesta, siempre la misma: “Sí. Más que nunca. Pero estudia diferente. No memorices sintaxis — entiende sistemas. No copies patrones — comprende por qué existen. No aprendas a escribir código — aprende a pensar en código.”
Con developers mid-level que se resistían: “Yo prefiero escribir mi propio código, así sé que funciona.” Los entendía. Yo había estado exactamente ahí 2 meses antes. Pero la realidad es que el código generado por IA no es “código de otra persona” que tienes que confiar a ciegas. Es tu código. Tú lo especificaste. Tú lo revisaste. Tú lo aprobaste. Tú eres responsable. La IA es la herramienta, no el autor.
Con mi propia pareja, que una noche me preguntó por qué estaba tan callado: “Estoy repensando los últimos 11 años de mi carrera en tiempo real. Dame un momento.”
Lo que no te dicen los artículos optimistas
El artículo del CEO presenta la versión ejecutiva. Los números. Las métricas. La reducción de tiempos. Y todo eso es real.
Pero desde la trinchera, hay cosas que nadie te dice:
La primera semana es humillante. Ver cómo una IA genera en minutos algo que te habría tomado un día completo es un golpe al ego. No hay forma de suavizarlo. Duele.
No todo el código es bueno a la primera. Claude Code a veces genera soluciones que funcionan pero no son óptimas. A veces no conoce las particularidades de tu infraestructura. A veces propone un approach que técnicamente es correcto pero que en tu contexto específico es una mala idea. Por eso necesitas ser senior para usarlo bien. Un junior que acepta todo lo que genera la IA sin cuestionarlo es más peligroso que un junior sin IA.
El síndrome del impostor se intensifica. Si antes te preguntabas “¿soy suficientemente bueno?”, ahora te preguntas “¿soy suficientemente bueno en un mundo donde la IA hace lo que yo hago, pero más rápido?” La respuesta es sí — pero llegar a esa conclusión toma tiempo.
Tus métricas de productividad pierden sentido. Antes medías tu output en PRs mergeados, tickets cerrados, líneas de código. Ahora un developer con Claude Code cierra 5x más tickets. ¿Es 5x mejor? No. Simplemente tiene una herramienta que elimina la fricción mecánica. Las métricas deben evolucionar para medir impacto, no volumen.
Donde estoy hoy
Escribo esto 3 meses después de mi primera sesión con Claude Code. Y honestamente, soy un developer diferente.
No mejor ni peor. Diferente.
Sigo escribiendo código. Pero escribo menos líneas y tomo más decisiones. Paso más tiempo pensando en arquitectura y menos tiempo implementándola. Hago más code review — no solo de lo que escriben mis compañeros, sino de lo que genera la IA. Me he convertido, sin proponérmelo, en un curador de código.
Mi productividad se multiplicó. Pero más importante que eso: mi estrés se redujo. Ya no me quedo hasta las 11pm peleando con una integración. Ya no llego al standup con cara de que dormí 4 horas. Ya no siento que los tickets se acumulan más rápido de lo que puedo resolverlos.
¿Extraño algo? Sí. Extraño la sensación de pasar 3 horas debuggeando un problema imposible y encontrar la solución yo solo. Ese subidón de dopamina del “¡lo encontré!” Todavía lo tengo, pero es diferente. Ahora el subidón viene de diseñar un sistema completo, verlo implementado en horas, y saber que cada decisión arquitectónica fue mía.
Lo que le diría a un developer que está donde yo estaba hace 3 meses
Si estás leyendo esto con el estómago apretado, con esa mezcla de curiosidad y terror que yo sentí, te digo esto:
Tu conocimiento no perdió valor. Cambió de forma.
Todo lo que sabes sobre arquitectura de software, patrones de diseño, debugging, performance, seguridad, bases de datos, APIs, testing — todo eso sigue siendo necesario. Pero se aplica diferente. Ya no eres el que ejecuta. Eres el que dirige, evalúa y decide.
No estás compitiendo con la IA. Estás evolucionando con ella.
El developer que se niega a usar IA no está “protegiendo su arte.” Está eligiendo ser el último en llegar a la fiesta. Y cuando llegue, los que ya estaban ahí van a estar 3 años de experiencia por delante.
Empieza hoy. No mañana. Hoy.
Abre Claude Code. Dale un problema real — no un todo-app de tutorial, un problema real de tu trabajo. Y observa qué pasa. No con miedo. Con curiosidad.
Porque la peor versión de esta historia no es que la IA te reemplace. La peor versión es que te quedes parado viendo cómo el mundo cambia y decidas que eso no va contigo.
Va contigo. Va con todos nosotros.
Ahora, si me disculpan, tengo 7 tickets que cerrar antes del almuerzo.
Andrés es un personaje ficticio, pero su historia está construida a partir de experiencias reales de developers que han atravesado el proceso de adoptar IA generativa en sus flujos de trabajo profesionales. Si te sentiste identificado, no estás solo.