DEV Community: Peterson Andres Sena Arias

[Boost]

Peterson Andres Sena Arias — Sat, 03 Oct 2026 15:19:31 +0000

Peterson Andres Sena Arias

Oct 3

Le puse muros a mi agente de IA (y ahora rompe la web, pero porque se lo pido)

#spanish #ai #claude #codex

9 min read

I got tired of logging in and out of Claude Code, so I built a one-command account switcher

Peterson Andres Sena Arias — Sat, 03 Oct 2026 11:25:10 +0000

Quick confession: last week I logged out of my work Claude Code account four times in one afternoon. Nothing was broken. I just have a second account for personal projects, and Claude Code can only be logged into one of them at a time.

Sign in with the personal account and the work one is gone. Sign back in with work and personal is gone. Every switch is a browser tab, an OAuth dance and about forty seconds of my life. Multiply that by "I switch contexts a lot" and you get a genuinely annoying week.

So I fixed it. The result is cc-switch, and the whole thing is one command:

ccp use personal

Every claude you launch after that runs under the personal account. ccp use work flips it back. No re-login, no browser, no forty seconds. And ccp list tells you who is who:

  Claude Code profiles
  --------------------
  * default                   alice@company.com
    personal   [shared]       alice@gmail.com
    client-x   [isolated]     alice@client-x.com

The trick is a single environment variable

I expected to need something hacky with credential files. I didn't. Claude Code reads an environment variable called CLAUDE_CONFIG_DIR and uses it as the root for everything it stores: credentials, settings, session transcripts, the lot. Point it at a different folder and you get a completely separate identity.

So a "profile" in cc-switch is literally a directory:

~/.claude-profiles/
  personal/    ← its own login
  client-x/    ← its own login
~/.claude      ← your original account, untouched ("default")

ccp use <name> sets the variable for the current shell and persists it for new terminals. ccp run <name> sets it for a single invocation only, which means two terminals can talk to two different accounts at the same time:

# terminal 1
ccp run work

# terminal 2
ccp run personal -p "summarise yesterday's changes"

I use that far more than I expected to.

Then I lost all my chats

The first version worked great for about ten minutes. Then I opened a project under the personal profile and my conversation history was empty. Of course it was: transcripts live in projects/ inside the config dir, and the new profile had its own brand new, empty one.

For some setups that's exactly what you want (a clean-room profile for a client). For my day-to-day it was terrible. I wanted the login separated, not my memory of what I was doing yesterday.

The fix turned out to be clean. On a shared profile, cc-switch replaces the chat folders (projects/, sessions/, plans/, tasks/, file-history/) and history.jsonl with links back into ~/.claude: NTFS junctions and a hardlink on Windows, plain symlinks on Linux and macOS. Credentials and settings stay per profile, chats are one pool, and claude --resume shows the same list whichever account you're on.

If you do want a walled-off environment, you just say so:

ccp add client-x --isolated

You can flip a profile between the two modes later with ccp link and ccp unlink. Nothing gets deleted either way: unlink gives the profile its own empty folders and leaves the shared history where it is.

The bug that would have deleted everything

This is the part I actually want people to read, because it's a general Windows/PowerShell gotcha.

My first ccp remove was the obvious thing: Remove-Item -Recurse -Force <profile dir>. On a shared profile, that directory is full of junctions pointing at ~/.claude. And Remove-Item -Recurse will happily walk straight through a junction and delete the contents of the target.

In other words, "remove the test profile" would have wiped my entire real chat history. I only caught it because I was being paranoid in testing: I made a throwaway profile and counted the project folders on both sides before and after. The fix is to delete the links themselves first (DirectoryInfo.Delete() on a junction removes only the reparse point, not what it points to) and then recurse into whatever is left. rm -rf on Linux doesn't follow symlinks, so the bash version was never at risk, but it does the same explicit dance anyway.

If you write any tool that creates junctions on Windows: test your delete path against a directory you'd be sad to lose. I got lucky. You might not.

Install it

One line, no clone:

Windows (PowerShell)

irm https://raw.githubusercontent.com/petersonsenadevs/claude-code-switch/main/install.ps1 | iex

Linux / macOS

curl -fsSL https://raw.githubusercontent.com/petersonsenadevs/claude-code-switch/main/install.sh | bash

Then:

ccp add personal          # new profile, shares your chats
ccp login personal        # opens claude: sign in, then /exit
ccp use personal          # you're switched
ccp list                  # every profile, with the email signed in on each

It's plain shell (a PowerShell module and a bash script) with no dependencies and no daemon. It doesn't wrap or patch claude; it only sets a variable the CLI already respects. Profile names autocomplete with Tab, and ccp update pulls the latest version when there is one.

What I'd love feedback on

macOS Keychain. On macOS, Claude Code keeps its OAuth credentials in the system Keychain rather than in the config dir. Depending on your Claude Code version, that Keychain entry may be shared between profiles. I've built and tested this mainly on Windows and Linux, so if you're on a Mac and ccp list shows the right account on each profile (or doesn't), I'd really like to hear about it in an issue.
Which folders should be shared? I went with the ones that make --resume behave. settings.json and MCP configs stay per profile on purpose. Would you share anything else?

The repo is here: github.com/petersonsenadevs/claude-code-switch, MIT licensed. If it saves you the forty seconds, a star helps other people find it.

Le puse muros a mi agente de IA (y ahora rompe la web, pero porque se lo pido)

Peterson Andres Sena Arias — Sat, 03 Oct 2026 11:11:59 +0000

Empecé a trabajar mis proyectos con agentes de IA usando Codex, y después llegó Claude Code. Al poco me di cuenta de que, proyecto tras proyecto, le estaba diciendo al agente lo mismo una y otra vez. Que no commitee en main. Que revise en móvil antes de dar algo por hecho. Que deje escrito qué hizo y por qué. Que antes de diseñar decida la paleta y la tipografía, no a mitad de un componente.

A eso se sumaban las librerías y las skills de otros que iba encontrando: una muy buena para diseñar interfaces, otra para animar con GSAP, otra para 3D… Cada una funcionaba bien por su cuenta, pero no se conocían entre ellas. Yo era el pegamento, copiando y pegando instrucciones de un proyecto a otro.

Así que decidí juntarlo todo en un recopilatorio en el que las piezas se ayudaran entre sí. Lo llamé dev-standards, porque era literalmente eso: mis estándares de trabajo. Hoy se llama Senzu.

Y por el camino me siguieron pasando cosas como estas, todas en la misma semana:

Prettier, con su configuración por defecto, le metió 204 punto y coma a un archivo de un proyecto que no los usa. El agente lo dio por bueno.
El instalador de mis propias normas vació el .mcp.json de un proyecto Laravel y se llevó por delante un servidor MCP que estaba configurado.
El agente me dijo que había verificado la web en móvil. Las capturas existían, sí: en una carpeta temporal que yo nunca iba a abrir.
Un loader y una barra de carga «centrados». A ojo lo estaban. Midiendo, no.
Y mi favorita: yo daba por hecho que Codex no ejecutaba hooks. Sí los ejecuta. Lo que pasaba es que mis hooks no entendían cómo Codex describe una edición, así que dejaban pasar todo sin decir nada.

Ninguna de estas cosas es grave por separado. Juntas, son la diferencia entre fiarte del agente y tener que revisarle cada línea.

Las reglas en un CLAUDE.md son sugerencias

Ahí está el problema de fondo. Puedes escribir en el CLAUDE.md o en el AGENTS.md que no se commitea en main, que se verifica en móvil antes de cerrar una tarea o que no se toca el .env. El agente lo lee. Y casi siempre lo cumple.

«Casi siempre» no vale cuando es un proyecto de verdad.

Por eso el recopilatorio no se quedó en un montón de instrucciones: lo que podía ejecutarse, lo convertí en algo que se ejecuta, no que se lee. Y el nombre: si viste Dragon Ball de pequeño, ya sabes por qué Senzu. Una semilla y el proyecto se recupera.

Qué es Senzu

Un paquete para Claude Code y Codex, en castellano, con tres piezas que trabajan juntas:

Skills: las mías y las de otros proyectos (con su autor y su licencia), con una capa en castellano encima. El agente carga solo la que toca: diseño de interfaz, calidad de código, DDD, animación, despliegue… Un enrutador decide cuál leer según lo que pides y en qué orden: primero se decide el diseño y después se elige el efecto, no al revés. Así no se llena el contexto de cosas que no vienen al caso.
Muros (hooks): no aconsejan, bloquean. Si el agente intenta algo que no debe, la acción no se ejecuta y le explican por qué.
Comandos: /plan, /verificar, /brief, /propuestas… atajos para flujos que repito en todos los proyectos.

Así se ve un muro cuando salta:

[BLOQUEADO por Senzu] No se commitea en 'main'. Crea una rama
(git switch -c feat/...) y commitea ahí.

Hace unos días bloqueó al propio agente que me estaba ayudando a sacar la última versión de Senzu, cuando intentó commitear donde no debía. Ahí es cuando sabes que funciona.

Los muros que más me han salvado

Son dieciséis, pero hay unos cuantos que se ganan el sueldo cada semana:

guard: nada de git push sin que yo lo apruebe en ese momento, nada de rm -rf, de borrar la base de datos ni de desplegar a producción por las buenas. Para saltárselo hace falta una variable explícita y mi aprobación, y la norma es dejarlo apuntado en el devlog.
secrets-guard y protect-files: el agente no escribe claves reales en el código (las de AWS, Stripe, OpenAI… se reconocen por su forma) ni toca el .env, las migraciones ya aplicadas o los archivos que se generan solos.
stop-guard: este es mi favorito. El agente no puede dar la tarea por terminada si editó código y no pasó el build, el lint y los tests, si tocó la interfaz y no la verificó en móvil, o si no dejó escrito el devlog del día. Se acabó el «ya está» sin pruebas.
backend-guard: bloquea migraciones que borran o renombran columnas de golpe (primero se añade lo nuevo y luego se quita lo viejo) y datos personales escritos en los logs.
code-hygiene: fuera los console.log, los dd() y los .only olvidados en los tests. Y algo más, que cuento en el diseño.
conventions-guard: en un proyecto que ya existe, /adoptar analiza cómo está escrito de verdad, lo pactamos y lo sella. A partir de ahí, el código que se salga de esas reglas no entra. Manda la convención del proyecto, no la del agente.

Y uno que no bloquea pero que agradezco cada día: el formateo al guardar no impone estilo. Si el proyecto no tiene configuración del formateador, no formatea, y si al formatear cambian más líneas de las que tocó el agente, lo deshace y avisa. Lo de los 204 punto y coma no ha vuelto a pasar.

Las skills que más uso

Son más de cuarenta, pero el agente casi nunca carga más de una o dos por tarea. Las que más trabajan:

ui-ux-pro-max (de Next Level Builder): la puerta de entrada de todo lo visual. Antes de escribir una línea de interfaz decide estilo, paleta, tipografía y patrón según el negocio y el stack, y lo deja guardado en un design system del proyecto. Encima lleva mi capa: perfiles para Laravel con Inertia, Next, Astro y Vue, y las guías de diseño que cuento más abajo.
front-activation: el catálogo de efectos. Más de noventa, cada uno con su receta por stack, su versión para «reducir movimiento» y su coste en móvil. Pides «un marquee de logos» y el agente abre solo esa receta, no un manual entero.
code-quality: buenas prácticas por lenguaje y un verify-build que entiende monorepos y lanza el lint, los tipos, los tests y el build de lo que has tocado.
project-planner: /plan convierte una feature en fases y tareas pequeñas, cada una con la skill que toca y cómo se verifica. Luego /siguiente va una por una.
backend-audit: audita el backend con herramientas de verdad, y cada hallazgo lleva su prueba: la salida del comando, el archivo y la línea, o un test que falla. Nada de «podría mejorarse la arquitectura».

Para animación y 3D (GSAP, Three.js, React Three Fiber…) uso las de Claude Design Skills, también con su capa en castellano.

Memoria que no depende de que el agente se acuerde

Cada proyecto tiene un devlog (qué se hizo, por qué y cómo se verificó) y un archivo de memoria corto con las decisiones vigentes: D-012 · Esto se decidió así · ver entrada 063. Un hook lo inyecta al empezar cada sesión. Si el agente va a contradecir una decisión, tiene que citarla y preguntarme.

Para lo que no está en la memoria hay un buscador sobre el devlog que entiende raíces, erratas y sinónimos. Parece poca cosa. Es la diferencia entre explicar dos veces por qué no usamos tal librería o no tener que explicarlo nunca más.

Cómo diseña

Aquí es donde más se nota que las piezas se conocen entre ellas.

1. Primero pregunta. Si no hay brief ni design system, el primer intento de tocar la interfaz se bloquea. El agente tiene que preguntar antes: qué hace el negocio, qué tiene que hacer el visitante, si hay marca, y dos o tres webs que te gusten. La entrevista va en lenguaje llano (/brief), sin palabras como «hero» o «CTA», porque no todo el mundo habla así.

2. Estructura antes que estética. Con eso escribe un blueprint: las secciones de la página con texto real y, en cada una, qué cambia en móvil. Hasta que no lo apruebas, no se diseña nada.

3. Dos maquetas que se pueden abrir. /propuestas genera dos direcciones opuestas de verdad, en HTML que se abre con doble clic. Cada decisión lleva una etiqueta (A·T1 es la tipografía de la maqueta A, B·B2 los botones de la B…) y un panel «Tu opinión» para votar Sí o No pieza a pieza y copiarlo al chat.

4. Rondas. /ronda hace la siguiente: lo que te gustó queda fijado en todas las maquetas, lo que no te gustó desaparece y cada maqueta trae algo nuevo. Un verificador comprueba antes de enseñártela que se ha respetado todo eso.

5. Los vetos se cumplen. Lo que dices que no te gusta va a un archivo gustos.md. Y aquí vuelve code-hygiene: si vetaste un color o un carrusel, el agente no puede volver a escribirlo. Lo mismo con una lista negra de cosas que delatan una web hecha con IA, como los badges de «disponible», las secciones numeradas «01 / 02 / 03», el «trusted by» con logos en gris o las métricas inventadas. Están bloqueadas por defecto.

6. Construye sección a sección, enseñando cada una antes de pasar a la siguiente. Y cuando el logo ya está elegido, sus archivos finales quedan protegidos y el agente no se pone a hacer bocetos que nadie le ha pedido.

Y al final, verifica.

Verificar es medir, no mirar

Esta parte nació del loader descentrado. «Debería verse bien» no es verificar, así que el verificador de interfaz ahora mide en píxeles: si algo que su contenedor centra está a 4 px del centro, te lo dice, con la causa probable (un margin-left: 8px que sobraba, por ejemplo).

Lo calibré contra webs reales para que no fuera una máquina de falsos positivos. Empezó dando entre 33 y 41 avisos por página y lo dejé en 0-2. De paso encontró algo de verdad: en vuejs.org, un icono de play que está 3 px descentrado dentro de su propio SVG.

En móvil hace lo que yo hacía a mano: abre el menú de verdad. Lo pulsa, mide si los enlaces se pueden tocar con el dedo, prueba que se cierra con Escape y te deja una captura con cada aviso numerado encima de su elemento. La cifra y la imagen, juntas.

La parte divertida

No todo son muros. Senzu también trae un catálogo de efectos con recetas por stack (Astro, Next, Vue con Inertia), y hace poco le pedí algo concreto: que la web se viera normal y de repente se partiera como un cristal.

La demo, a media velocidad para que se vea algo: en tiempo real dura menos de un segundo.

Lo que se rompe es la propia página, no una imagen encima. Cada trozo es una copia del DOM recortada con clip-path a la forma del cristal. Por eso se lee el texto real, nítido, mientras cae girando en 3D. Sin capturas de pantalla y sin librerías.

Y con reglas, porque un efecto así puede acabar siendo un circo: una vez y con intención, se salta con Escape, quien tiene activado «reducir movimiento» solo ve un fundido, y al terminar no queda nada en el DOM. Tiene sus pruebas automáticas en un navegador real, como todo lo demás.

Cómo probarlo

En Claude Code:

/plugin marketplace add petersonsenadevs/senzu
/plugin install senzu-all@senzu

En Codex se añade el mismo marketplace desde la app. Luego, en tu proyecto, abre una sesión y escribe /instalar: detecta el stack, te pregunta qué quieres (todo, por categorías o a medida) y lo deja listo.

Repositorio: github.com/petersonsenadevs/senzu
Documentación: getsenzu.vercel.app

Lo que no es

Es opinado: son mis normas de trabajo, no las de todo el mundo. Lo puedes adaptar (los muros se apagan por proyecto y los permisos se cambian), pero parte de cómo trabajo yo.

Está en castellano, a propósito. Hay muchísimo para agentes en inglés y casi nada pensado para quien trabaja en español.

Y no hace que el agente deje de equivocarse. Se sigue equivocando. La diferencia es que ahora se entera antes que yo.

Es MIT. Usa skills de otros proyectos, cada una con su autor y su licencia en CREDITOS.md. Cada semana comprueba si esos proyectos han cambiado y me abre un PR para revisarlo.

Si lo pruebas, me encantará saber qué muro le pondrías tú a tu agente. Seguro que hay alguno que se me ha escapado.

Laravel SwaggenerAI: Generate Swagger Documentation with AI in Seconds

Peterson Andres Sena Arias — Tue, 03 Jun 2025 06:20:47 +0000

Tired of writing Swagger documentation manually for your Laravel APIs? Meet Laravel SwaggenerAI, a VS Code extension that uses artificial intelligence to automatically generate complete OpenAPI/Swagger documentation.

Key Features

Multiple AI Providers

The extension supports the best AI models on the market:

Google Gemini (gemini-2.0-flash)
OpenAI GPT-4
Anthropic Claude

Smart Generation

Automatic controller detection
Routes and request analysis
Intelligent caching for faster performance

Complete Customization

Flexible AI provider selection
Simple API key configuration
Multiple formatting options

How It Works

The extension uses an abstraction system that allows working with different AI providers uniformly. Each provider implements the same interface, ensuring consistency in documentation generation.

The process is simple:

Analyzes your Laravel controllers
Automatically detects routes and methods
Generates optimized prompts for each AI provider
Produces ready-to-use Swagger/OpenAPI annotations

Installation and Usage

Install from VS Code Marketplace

Search: "Laravel SwaggenerAI"

Install the extension

Configure your preferred AI provider and API key

Generate documentation with one click!

Optimized Performance

The extension includes an intelligent cache system that avoids regenerating documentation unnecessarily, significantly improving response times in large projects.

Why Laravel SwaggenerAI?

Save Time: What used to take hours, now takes minutes

Consistency: Uniform documentation across your entire project
Flexibility: Choose the AI model that best fits your needs
Free: Available on VS Code Marketplace

Useful Links

📦 VS Code Marketplace Marketplace
📚 Complete Documentation
GitHub Repository
☕ Support the Project
If you find this extension useful, consider:
⭐ Starring it on GitHub
Buy me a coffee
📣 Sharing it with other developers