Últimamente veo a muchos desarrolladores publicando extensiones para VS Code, plugins para Claude Code, mods para agentes y colecciones de skills. Cada semana sale uno nuevo que promete cambiar tu forma de programar.

Y cada vez que veo uno me hago la misma pregunta: ¿para qué necesitas la herramienta de otro desarrollador si hoy le puedes pedir a tu agente que te cree la tuya? En esta época prácticamente cualquiera puede tener un flujo personalizado, adaptado a lo que de verdad necesita.

Pero ojo, tampoco es tan simple. Hay herramientas que sí valen la pena, y hay otras, como los skills, que parecen inofensivas pero esconden mucho más trabajo del que imaginas.

1. Las extensiones de editor pierden sentido

Si programabas hace unos años, seguro llenaste tu editor de extensiones: una para resaltar código, otra para generar snippets, otra para crear componentes, otra para escribir pruebas. Tenían sentido, porque te ayudaban a escribir código más rápido. Microsoft, Google y casi todas las empresas grandes siguen publicando las suyas.

Pero piénsalo así: hoy trabajas con agentes como Claude Code, Cursor, Codex u OpenCode, y cada vez necesitas menos extensiones. En mi caso, ya no uso ninguna, ni siquiera un editor de código. Eso no significa que no revise lo que hace la IA: hoy hay exploradores de archivos, testing adversarial y otras formas nuevas de revisar código sin tener que leerlo línea por línea.

Aun así sigo viendo extensiones nuevas para resaltar código o escribir snippets. ¿Para qué, si la gran mayoría ya casi no escribe código a mano? Y lo curioso es que muchas de esas extensiones también están generadas con IA. Ahí está justamente el punto: si ya usas un agente, no necesitas la extensión. Le puedes pedir que la cree para ti.

2. Mods y plugins: pídele al agente que los cree

Anthropic lanzó hace poco los mods de Claude Code: plugins escritos en TypeScript que te dejan modificar Claude Code y añadirle paneles, una franja encima del prompt, la línea de estado o avisos, dentro de la misma terminal. Y no es mala idea. Hay proyectos como Terminal Browser, que abre un navegador real dentro de la terminal, y otros que añaden gráficas a Claude Code.

Pero no hace falta instalar el mod de otra persona. Si necesitas algo así, se lo puedes pedir a Claude, que te lo cree, y lo mantienes en tu propio repositorio, adaptado a tu forma de trabajar.

Muchos me dirán que para una persona no técnica esto es más difícil. Y sí, pero recuerda que los plugins y los mods son para desarrolladores, no para un usuario común. Un usuario común ya tiene problemas solo con los skills.

Además, hoy es más fácil que nunca que una aplicación soporte plugins. Herdr, por ejemplo, es una interfaz para controlar varios agentes y tiene su propio catálogo de plugins. Varios de los que vi no soportaban Windows, solo Linux y Mac. ¿Y qué? Si falta el plugin que necesitas, lo puedes generar. ¿Te falta un explorador de archivos? Pídeselo al agente.

Mi recomendación: si necesitas una característica en Claude Code, en OpenCode, en Herdr o en cualquier otra herramienta, pídele al agente que investigue cómo se integra y que genere el plugin a partir de ahí. Crear y publicar una extensión todavía tiene sentido si ofreces algo que no existe, por ejemplo una integración con un modelo inteligente al estilo de la extensión de Claude Code. Para casi todo lo demás, adáptalo a tu propio flujo.

Y lo digo porque casi a diario me llega algún correo de alguien que creó su propio editor de código con IA. En este punto, muy poca gente está buscando un editor nuevo.

3. Lo que sí vale la pena: MCP, CLI y skills

¿Entonces ya nada tiene sentido? No. Hay herramientas que sí importan: los MCP y los skills.

Uso bastante los MCP, aunque muchas veces podrías resolver lo mismo con un CLI y un skill. La razón es que, desde el chat de Claude o de Codex, puedes usar el MCP y dictarle por voz tareas, ideas, proyectos o cambios. Es una forma mucho más moderna de interactuar con tus programas.

Te pongo un ejemplo. En fazt.dev añadí una sección para aprender con lecciones en forma de juego. Cuando aprendo algo y pienso que a otras personas les puede interesar practicarlo, le pido al chat que me proponga lecciones, por ejemplo una de índices y otra de transacciones de bases de datos, y las crea directamente en el sitio como borrador. No tengo que escribir nada a mano.

Otro ejemplo es un tablero que uso para seguir varios proyectos a la vez. Cuando lanzo tareas a varios agentes en paralelo (rediseñar una landing, crear una app móvil con Expo, revisar el rendimiento de un backend), cada una aparece en el tablero y voy viendo cómo avanza, si crea una rama y cuándo termina. Para un solo proyecto no hace falta, y además ya existen plugins de trackers que le puedes pedir a Herdr. Pero con varios agentes a la par me ahorra mucho.

Y para escanear un proyecto uso un skill que analiza su estructura y genera el diagrama de su arquitectura: si lleva API, frontend, CLI, extensión de navegador o MCP, y qué servicios integra, como los webhooks de Stripe. Con muchos proyectos es imposible tener toda la arquitectura en la cabeza, y verla así es mucho más fácil que leer un documento gigante.

La idea es esta: si vas a dedicarle tiempo a crear un editor nuevo o una extensión para un editor, mejor dedícalo a un MCP, un CLI o un skill. Hoy son mucho más útiles. Y crear tus propios programas como desarrollador vale mucho, porque aprendes en el proceso y porque se adaptan exactamente a lo que necesitas. Si instalas las herramientas de otro, te estás adaptando a su forma de trabajar.

4. Los skills: no los copies, entiéndelos

Generar código hoy es fácil. Lo que irónicamente se volvió más útil son los skills. Yo tengo skills para casi todo: publicar videos, corregirlos, desplegar proyectos, escanearlos, generar changelogs o hacer reviews. Prácticamente todo lo que le puedes enseñar a un modelo cabe en un skill.

Pero no se trata de copiarlos o descargarlos de sitios como skills.sh, donde hay una cantidad enorme porque todo el mundo busca el truco mágico. Pasa lo mismo que con las extensiones: puedes descargar el skill de otra persona, pero primero entiende qué hace y léelo.

Un skill no es un archivo de configuración complicado. Puede ser muy simple. El problema es que, cuando se lo pides a la IA, te devuelve algo muy largo y verboso, y a veces con código incluido. Lo que hago yo es pedirle que, a partir de lo que aprendió en la sesión, genere el skill, y después lo reviso y lo recorto hasta que queda en unos pocos textos y descripciones sencillas. Así, cuando quiero cambiar algo, sé exactamente qué paso hace cada parte.

Un ejemplo es el skill grill-me de Matt Pocock, que te interroga hasta cerrar cada decisión de un plan. Ya lo uso menos, pero lo importante es entender su idea. Si después quiero ir por mi propia ruta, por ejemplo que al final me dé un reporte, no necesito otro skill: adapto el que tengo, porque ya entendí cómo funciona.

Con los plugins pasa exactamente lo mismo. Puedes pedir cualquier plugin y generarlo para ti, sin adaptarte al trabajo de otro desarrollador.

5. El valor ya no está en crear la herramienta

En resumen: el valor ya no está en construir una herramienta, porque el código se puede generar casi al instante. El tablero que te mostré seguramente lo publicaré como open source, porque está conectado a un sitio, y es básicamente el Linear y el Notion que usaba antes, adaptados a un flujo con agentes. A alguien le puede servir y a otro no.

Por eso no se trata de decir «usa este software». Hoy mucha gente crea su propio software y promociona su entorno de desarrollo, cuando probablemente no necesitas tantas herramientas para hacer algo muy simple.

Lo que más te recomiendo es entender lo que hacen tus herramientas. Si mañana aparece un flujo de trabajo mejor, no vas a estar amarrado a ellas. Se nota mucho con los editores: hay personas atadas a VS Code como si fuera la única forma de generar o revisar código, cuando hoy hay proyectos nuevos para revisar código y hacer reviews. Es mucho mejor seguir esas ideas nuevas que adaptarte a un flujo que quizá ya cambió.

Si estás empezando, usa herramientas ya hechas, entiende cómo funcionan y verás que pronto puedes crear las tuyas.

Lo que viene

Estoy preparando un video, casi un curso, sobre cómo desarrollo con IA paso a paso, con una aplicación donde se aplica todo lo de este video. Antes de armarlo voy a leer los comentarios, así que me sirve mucho saber cómo trabajas tú.

¿Qué extensiones, MCP o skills sigues usando todos los días? ¿Todavía valen la pena o ya los reemplazaste con los tuyos?

Fuentes