De Saiyajin a Super Saiyajin 3: mi viaje desarrollando Agentikas con Claude

Crecí con Dragon Ball. La transformación de Goku — de Saiyajin normal a Super Saiyajin, después Super Saiyajin 2, después 3 — siempre me pareció una metáfora exagerada del crecimiento profesional. Cada nivel multiplicaba la fuerza, pero también la complejidad de mantenerse en él. La fuerza no era gratis. Costaba foco, costaba sueño, costaba versiones de uno mismo que ya no volvían.

Los últimos seis meses construyendo Agentikas Blog con Claude me han hecho pensar en esa metáfora más de lo que admitiría en sobrio. No porque me sienta especialmente fuerte — sino porque cada nivel ha exigido un tipo distinto de habilidad, y el ingeniero que escribió el primer commit no se parece al que escribe esto.

Saiyajin normal: el terminal y el modelo

El primer mes fue limpio. Yo, un editor, Claude Code en una ventana, un repositorio nuevo en otra. Cada feature era una conversación. Pedía. Claude proponía. Yo revisaba, ajustaba, aprobaba. Avancé más en cuatro semanas que en proyectos anteriores en cuatro meses.

La sensación dominante era de velocidad reciente. Veinte años escribiendo código y de repente todo iba más rápido sin que la calidad bajara. Pensar antes de teclear se volvía la habilidad central — porque mi tecleo ya no era el cuello de botella, mi pensamiento sí lo era.

Si me hubieran preguntado en ese momento "¿qué cambió?", habría dicho "Claude escribe el código". Habría sido una respuesta incompleta. Lo que cambió fue otra cosa, y tardé en verla.

Super Saiyajin: el monorepo y los tres frontends

El segundo mes empezó cuando duplique código. Tenía dos frontends, mismo blog, dos copias del componente. Lo solucioné con un monorepo. Y ahí cambió mi rol.

Cuando hay tres apps que comparten paquetes, cuando un cambio en packages/blog-ui impacta tres builds, cuando una decisión arquitectónica se propaga por veinte ficheros — el "yo conduzco, tú implementas" deja de funcionar bien. Tienes que pensar en sistemas, no en features.

Aprendí en ese mes que la diferencia entre un dev que usa Claude bien y uno que lo usa regular no es la velocidad de prompts — es la claridad del modelo mental que le pasa al modelo. Si puedes describir tu arquitectura en cinco frases, Claude la sigue. Si la tienes solo en la cabeza, Claude propone seis cosas distintas y dos de ellas chocan entre sí.

La habilidad central pasó de "saber código" a "saber traducir una intención de sistema a una conversación que un modelo puede ejecutar".

Super Saiyajin 2: la disciplina como infraestructura

El tercer mes vino con un susto. Hicimos un refactor grande. Tres apps cambiando a la vez. Claude lo ejecutó perfectamente — los commits estaban bien, los tests pasaban, el deploy funcionó. Una semana después descubrimos que en dos rutas críticas habíamos perdido una validación de seguridad. No por descuido — por confianza.

Esa semana entendí algo que he repetido desde entonces: cuando dejas que un agente ejecute, tus guardarraíles tienen que ser mecánicos, no sociales. Un humano nota que un código es inseguro leyéndolo. Un agente, no. Un humano nota que falta un test. Un agente, solo si le pides que lo note.

El blog tiene 247 tests automatizados. No los escribí porque sí — los escribí porque cada vez que algo se rompió en producción, el patrón fue "Claude lo hizo bien excepto en este caso que no estaba cubierto". Los tests son la red de seguridad que te permite seguir avanzando rápido sin que la calidad colapse.

RLS estricta en la base de datos. Test E2E del flujo de login. Lint rule custom para cookies cross-subdomain. Brand reviewer que valida cada generación de IA. Cada uno es un compromiso con mi yo del futuro: "si confías demasiado en este punto, esto te va a parar antes de que llegue a producción".

Super Saiyajin 3: ingeniero por momentos, copywriter por momentos

El cuarto y quinto mes fueron raros. Empecé a hacer cosas que un ingeniero normalmente no hace.

Escribir BRAND.md. Decidir el tono de Agentikas. Diseñar el design system en markdown. Pensar cómo se siente la voz de marca cuando sale por LinkedIn vs. cuando sale por X. Ajustar prompts para que Claude no use "transformación digital" porque odio esa frase. Escribir copys de la home que estoy reescribiendo ahora mismo.

Esto antes lo hacía otra persona. En un equipo más grande, lo seguiría haciendo. Pero la realidad de construir solo con un modelo — con velocidad de equipo de cinco — es que muchos roles se colapsan en uno. El ingeniero solo escribiendo código deja de ser suficiente. Tienes que escribir las reglas que el modelo va a seguir: para escribir, para revisar, para diseñar, para publicar.

Y eso es agotador de una forma distinta. La fatiga no es física — es de switching de contexto. Pasar de "diseña el endpoint del worker de la cola" a "escribe el subtítulo de este post para LinkedIn" en quince minutos te exige cambiar de cabeza. La que escribe TypeScript no es la misma que decide si una frase suena demasiado corporativa.

Lo que NO se parece a Goku

La metáfora de las transformaciones tiene un límite. Goku se transformaba para pelear. Yo no peleo — construyo. La fuerza de Super Saiyajin no es "trabajar más horas" — son capacidades nuevas que no tenía antes. Saber usar bien la API de Anthropic. Saber qué patrones de prompt cache hacen una factura sostenible. Saber cuándo un test E2E es necesario y cuándo es overhead. Saber dejar que el modelo escriba mientras yo pienso en lo siguiente.

Y, sobre todo, la fuerza nueva que más me costó adquirir: saber qué NO automatizar. La voz, el gusto, las decisiones que requieren contexto humano. Eso no lo delego al modelo. Eso lo hago yo, lentamente, leyéndome a mí mismo en voz baja antes de pulsar publicar.

El siguiente nivel

Goku tras Super Saiyajin 3 va a Super Saiyajin God, después Super Saiyajin Blue, después Ultra Instinto. Cada uno es un orden de magnitud más complicado y más raro de mantener. La metáfora se quiebra ahí — no creo que haya un orden de magnitud más allá del que estamos. Pero sí creo que hay una transformación pendiente, y es la que llega cuando dejas de ser tú solo construyendo con un agente y pasas a coordinar varios agentes coordinándose entre sí.

Eso ya no es vibe coding. Es algo distinto. Y si los próximos seis meses son la mitad de raros que los seis anteriores, voy a tener cosas que contar.

Mientras tanto, este post sale publicado en agentikas.blog.agentikas.ai, en español y en inglés, en LinkedIn y en X, con cover image de Unsplash, con schema.org en el HTML y manifest WebMCP en /.well-known/mcp.json. Todo lo descrito en los posts anteriores, ejecutándose ahora mismo, sin que yo toque nada después de pulsar publicar.

Esa es la fuerza nueva. No es magia — es disciplina, infraestructura y un modelo bueno. Pero a veces, cuando lo veo funcionar, se parece un poquito a magia.

---

Agentikas es open source. Si quieres ver el código que cuento — desde el primer commit hasta este post — está en github.com/agentikas/agentikas-blog. Y si te animas a construir algo así, mi DM en LinkedIn está abierto.