Jesús L.C. – Apuntes de un aprendiz

He pasado de ignorar la IA a usarla todos los días en mi trabajo como ingeniero. Ni hype, ni miedo. Pragmatismo.

Este post es básicamente eso: qué me está funcionando en el día a día, qué no, y cómo estoy intentando «surfear» esta ola sin fliparme demasiado. He pasado por varias fases: negacionismo, FOMO, probar todo lo nuevo que salía… hasta que he llegado a un punto más estable: usarla como herramienta, no como religión. Además, intento no casarme con ningún modelo o herramienta (vendor lock-in), así que todo esto son ideas que me sirven hoy y probablemente en unos meses haya que revisarlas.

Mayoritariamente uso Claude Code en el trabajo, junto con Cursor, por lo que puede que haya algunos tips que solo sirvan ahí y ahora.

Principios que me están funcionando

Antes de entrar en herramientas y comandos concretos, hay una serie de ideas que para mí son clave y que vertebran todo lo demás:

• El contexto es el rey (pero mejor si es pequeño y fresco)
• Tus habilidades como ingeniero siguen siendo críticas: Claude se vuelve mucho más potente cuando lo guías bien
• Mejor dividir problemas que intentar resolverlos de una vez
• La IA amplifica lo bueno… y lo malo
• Automatizar sí, pero con cabeza

Con esto en mente, voy a lo práctico.

Mi setup actual

Aprende unos cuantos comandos

Lo mejor es conocer unos cuantos comandos para no tener que buscarlos. Yo normalmente utilizo:

• /clear: borra todo el contexto y empieza de cero
• /compact: cuando tengo el contexto algo lleno, lo compacta para seguir con la misma sesión
• /copy: copia la última respuesta, ideal si quieres compartir algo en Slack o empezar una nueva sesión con ese contexto
• /mcp: para saber qué MCPs tengo habilitados; normalmente los tengo todos desactivados y los habilito solo cuando los necesito
• /skills: para saber qué skills tengo activas (más adelante cuento sobre esto)

Una técnica que uso mucho: cuando Claude está en medio de algo y ves que se le va la pinza, o que se te olvidó mencionar algo importante, puedes escribirle directamente en el chat para redirigirle sin esperar a que termine.

¿En qué idioma le hablo?

Normalmente le escribo en inglés porque siento que soy más directo y me fuerza a interiorizar bien lo que quiero hacer y qué cosas son importantes. Escribir prompts en inglés me hace pensar mejor, y en proyectos donde hay terminología específica, usar el mismo idioma del código reduce ambigüedad. He probado a hablarle pero no me sale natural. Para speech to text uso Handy, que funciona bastante bien y encima es open source.

Customiza el status line

Yo uso claude-powerline para saber el modelo que estoy usando y, lo más importante, el contexto: cuando está en amarillo sé que tengo que hacer /compact o empezar una nueva sesión. Solo añadiendo esto en la configuración de Claude ya tendrás la línea. Si quieres más opciones, mira el repositorio:

"statusLine": {
    "command": "npx -y @owloops/claude-powerline@latest --style=minimal --theme=light",
    "type": "command"
}

Prepara bien tu proyecto (esto es clave)

Para que la IA funcione bien, tu proyecto tiene que estar preparado. ¿Qué quiere decir esto? Pues básicamente que sea fácil formatear el código, ejecutar los tests unitarios, chequear los tipos, ejecutar un solo test… En mi caso tenemos Makefiles en el proyecto con los comandos más útiles, e intentamos que sean los mismos en todos los proyectos:

.PHONY: check-typing
check-typing: pre-requirements  ## Run a static analyzer over the code to find issues
	uv run mypy .

.PHONY: lint
lint: pre-requirements ## Lints the code format
	uv run ruff check --fix

.PHONY: check-format
check-format: pre-requirements  ## Check format python code
	uv run ruff format --check

.PHONY: format
format: pre-requirements  ## Format python code
	uv run ruff format

.PHONY: check-unused
check-unused: pre-requirements ## Run a static analyzer over the code to find unused code
	uv run vulture src/ main.py

.PHONY: checks
checks: check-format lint check-typing docker-lint ## Run all checks (format, lint, typing)

.PHONY: pre-commit
pre-commit: checks test-unit  ## Run pre-commit checks (format, lint, typing, unit tests)

.PHONY: test-unit
test-unit: ## Run unit tests
	PROFILE=test uv run pytest tests/unit -ra -x --durations=5

Con esto puedo decirle a Claude que ejecute make pre-commit antes de que me diga que ha terminado. La consistencia entre proyectos también ayuda: Claude no necesita descubrir cómo se ejecutan los tests en cada repo porque siempre es lo mismo.

Aparte de eso, tenemos un README.md cuidado porque hemos aprendido que si hay buena documentación, Claude la usa bien. Así que antes de empezar cualquier proyecto lo mejor es crear un buen README con los comandos útiles. También tenemos documentación en ficheros Markdown sobre cómo nos gusta hacer las cosas: usamos la típica arquitectura de capas (application, domain, infrastructure), aka Hexagonal / Ports & Adapters; nos gusta tener separados los casos de uso entre Commands (hacer cosas) y Queries (devolver datos); tenemos interfaces… Si has visto los vídeos de Codely o has mirado sus repositorios, puedes hacerte una idea. Esto no solo ayuda a la IA, también ayuda a cualquier persona nueva en el equipo.

Cómo trabajo con la IA

Pequeño, planificado y simplificado

Este es uno de los consejos más importantes que me doy a mí mismo: mejor si es pequeño. Intenta romper problemas grandes en trozos pequeños, en fases. Por ejemplo, cuando empiezo a migrar un módulo a una nueva arquitectura, en lugar de decirle a Claude «migra esto», lo divido en fases: primero añadir los tests sobre el código existente, luego mover la lógica a la nueva capa, y por último eliminar el código viejo. Cada fase es un commit limpio y entendible. Claude tiene el plan-mode que hace un paso a paso detallado de lo que va a hacer — úsalo al principio. Cuando ya hayas cogido práctica, puedes crear una skill para que haga los planes como tú quieres.

Si ves que Claude Code no puede resolver un problema difícil de una sola vez, pídele que lo divida en varios problemas más pequeños. Comprueba si puede resolver una parte individual. Si aún es demasiado difícil, intenta con un subproblema aún más pequeño. Continúa hasta que todo sea simple y tenga solución.

Lo que hacemos nosotros con la planificación: crear el plan en un archivo, revisarlo a mano y commitearlo en el repositorio. Como el plan tiene fases, en una nueva sesión puedo decirle a Claude que ejecute la fase 1. Además podemos crear una skill para que ejecute las fases como queremos: con TDD, usando pasos pequeños, ejecutando make pre-commit antes de terminar.

Claude a veces complica demasiado las cosas y escribe demasiado código. Además realiza cambios que no se le han pedido — tiene una tendencia natural a escribir más. Lo peor es que el código que genera funciona, pero eso lo hace más difícil de revisar a la larga. Por eso conviene revisar el código y pedirle que lo simplifique: que aplique las 4 reglas de diseño simple de Kent Beck, crear una skill para que lo haga… A mí me gusta preguntarle por qué hizo un cambio, qué otras alternativas hay, e incluso empezar una sesión nueva probando una de esas alternativas. Nosotros nos aseguramos de entender todo el código, sobre todo porque si hay una incidencia, la alerta me va a llegar a mí. Mi consejo: simplifica más, usa herramientas para eliminar código muerto, y haz que el código se lea como prosa. Ir más despacio y simplificar es mejor que sacar 5 features que quizás nadie ha pedido.

En relación con todo esto: tus habilidades para resolver problemas y tus conocimientos de ingeniería de software siguen siendo muy relevantes, porque lo más importante que he aprendido es que tienes que tener criterio y actitud crítica ante las respuestas de Claude. Los problemas pueden resolverse de mil maneras distintas, pero tus habilidades para guiar a Claude son muy útiles — Claude se vuelve mucho más potente con ellas.

Usa git, commitea mucho y no te flipes

Nosotros trabajamos con trunk-based development, lo que nos obliga a estar muy seguros de lo que hacemos. Para eso intentamos hacer commits pequeños donde entendemos todo lo que se hace y por qué. Siempre intentamos crear el menor código posible e iteramos mucho para que las soluciones sean lo más simples posible.

En la práctica: commits de menos de 5 ficheros, muchas vueltas a cómo simplificar cada cambio, e inversión de tiempo en el principio de «mejor si es pequeño». Tenemos una actitud crítica ante las respuestas: si algo no termina de cuadrarnos, se lo preguntamos a Cursor, a Gemini, o incluso a Claude desde un ángulo distinto. También le pedimos que revise el código con frecuencia. Todo esto lo apoyamos con muchos tests, mutation testing, code coverage y herramientas de análisis estático.

El contexto es el rey — y si es fresco y condensado, mejor

Es mejor crear nuevas conversaciones con Claude cada vez que abres un topic nuevo o te enfrentas a un problema nuevo. Para eso sirve el status line: para saber si tienes mucho contexto consumido. Yo normalmente a partir del 50% empiezo a preocuparme e intento compactarlo o empezar una nueva conversación. Si no estoy encontrando buenas soluciones, vuelvo al principio, porque puede que no haya definido bien el problema o que el slice (subproblema) no esté bien hecho y tenga que replantearlo.

Al final Claude cobra por tokens, así que dar demasiado contexto puede subir la factura. Yo uso rtk, un proxy que se añade en la configuración y que mejora el consumo de tokens de manera transparente. Además tengo añadidos plugins de LSP para los lenguajes que utilizo. Para ello hay que habilitar LSP en los settings de Claude y añadir los plugins correspondientes. No doy más detalles porque es algo que cambia mucho, así que mejor que lo busques o le pidas a Claude que lo configure.

MCP Servers: sí y no

Los MCP son utilidades que podemos añadir a Claude. Imagina que le damos a Claude una OpenAPI para que pueda usar Jira haciendo llamadas HTTP — los MCP son más o menos algo así. Proveemos a Claude de más herramientas para que pueda hacer cosas: conectarse a Jira, leer la documentación de Confluence, hacer una PR en GitHub… hay miles de MCPs.

Yo por defecto los tengo todos desactivados y además he añadido Lazy Load a la configuración. ¿Por qué? Porque si tenemos muchos MCPs activos, Claude los envía en cada petición, lo que hace que el contexto se llene antes con información poco relevante. Por eso solo los uso cuando yo quiero. Los que utilizo principalmente: Jira, Confluence, Playwright, Postgres (solo a mi BD local) y Snowflake.

Entendiendo Claude.md vs Skills vs Commands vs Hooks

Esta es la parte del artículo que a mí me parece más interesante. Si esto está bien entendido es cuando Claude nos da ese plus de productividad y no alucina tanto en las respuestas.

	¿Qué es?	¿Cuándo usarlo?
Claude.md	Se carga en cada conversación	Contexto esencial del proyecto, siempre relevante
Skills	Instrucciones en .claude/skills/	Flujos repetibles que se invocan cuando se necesitan
Commands	Empiezan por /	Similar a skills, se invocan manualmente
Hooks	Scripts externos en .claude/settings.json	Comportamientos automáticos, no consumen tokens

Claude.md debe ser corto y conciso con lo más importante del proyecto. Lo mejor es que contenga enlaces para que la IA pueda coger contexto: repositorios, casos de uso, cómo testeamos, qué framework usamos, cómo hacemos los mocks… Además no es solo útil para la IA, también lo es cuando una persona nueva entra en el equipo.

Skills están en .claude/skills/ del proyecto. Cada skill es un archivo .md con su frontmatter (las líneas de configuración entre --- al inicio). La parte más importante del frontmatter es la descripción: es lo que Claude usa para decidir si activa automáticamente la habilidad. Si es vaga, Claude no la relacionará con tu intención. Úsalas para flujos de trabajo repetibles: /deploy, /pr-review, /changelog.

Commands empiezan por / y son similares a las skills, ya que permiten empaquetar instrucciones por separado. Pueden ser invocados manualmente por el usuario o por el propio Claude.

Hooks son scripts externos que se ejecutan automáticamente cuando ocurre un evento en Claude Code. Se configuran en .claude/settings.json y no consumen tokens porque se ejecutan completamente fuera del bucle del modelo. Los cuatro más relevantes para empezar son:

• PreToolUse: antes de que Claude use una herramienta (ideal para bloquear acciones)
• PostToolUse: después de que Claude use una herramienta (ideal para validaciones)
• Notification: cuando Claude necesita tu atención o está esperando permiso
• Stop: cuando Claude termina de responder

Yo tengo el hook de rtk para ahorrar tokens y el de formatear el código automáticamente. Una regla rápida para saber qué usar: si quieres que algo ocurra siempre, usa un hook o ponlo en Claude.md; si es algo repetible pero opcional, usa una skill; si es algo puntual, un command.

Para entender todo esto en profundidad, este artículo de AI Coding Patterns lo explica muy bien.

Cosas que no me han funcionado

Tener un Claude.md con 1000 líneas: con ejemplos de GOOD/BAD y todo explicado. Lo que acaba pasando es que Claude ignora parte de las instrucciones. Lo mejor es mantenerlo conciso y mover el detalle a skills o a documentación enlazada.

Usar skills para comportamientos permanentes: si quiero que algo ocurra siempre (por ejemplo, ejecutar el linter después de cada cambio), lo mejor es un hook o añadirlo en Claude.md. Las skills son para flujos que invocas cuando quieres, no para comportamiento constante.

Skills con malas descripciones: en internet hay miles de skills en repositorios públicos. Antes de usarlas, revísalas bien. Y si las creas tú, cuida la descripción — es lo que hace que Claude pueda usar la skill de manera automática.

No revisar Claude.md: a medida que el proyecto avanza, creamos nuevas herramientas, nuevos comandos en el Makefile, tenemos más documentación. Hay que revisar Claude.md periódicamente para que esté actualizado.

Las buenas prácticas de software valen más que nunca

Escribir tests, usar TDD, dejar que Claude solo escriba código si hay un test en rojo, usar code coverage, mutation testing, herramientas de análisis de código, tests de integración, tests end-to-end, Playwright, Docker, documentación, SOLID, arquitectura hexagonal, CQRS… Esto puede parecer una lista de los Reyes Magos, pero usar buenas prácticas hace que todo sea mucho más sencillo porque podemos confiar en que el código generado funciona como se espera y no tiene huecos sin cubrir.

Automatización

Al final todo esto va de automatización: iterar, intentar nuevas formas de hacer algo, ver qué más se puede hacer y cómo simplificarlo. Esa es la parte más divertida. No es sacar features como churros, sino pensar en cómo hacerlo mejor.

Personalmente empecé con GitHub Copilot con autocompletado, luego ChatGPT copiando y pegando, luego Junie de JetBrains, luego Claude. Al final es tener un proceso e ir iterando. Cuando te encuentres repitiendo la misma tarea una y otra vez, piensa en cómo automatizarla.

Crea tu propio workflow

Internet está lleno de posts explicando cómo trabajar con la IA. Lo mejor es que crees tu propio workflow, el que te funcione a ti. Lo que me funciona a mí puede que no te sirva porque no cuadre con tu contexto. Adapta lo que quieras y usa la IA a tu manera, porque ahora mismo no hay una manera buena o mala. Es cuestión de experimentar, ver qué skills usas y borrar lo que no utilices.

Creo que sirve más invertir tiempo en afilar las herramientas, aprender arquitectura de software o aprender a hacer slicing que revisar 1000 skills de internet.

La mejor manera de mejorar con la IA es usándola

«¿Cómo mejoras en la escalada?» — «Escalando.» Claro que hay otras cosas que puedes hacer: ver vídeos, leer libros, aprender trucos. Pero usar Claude es la mejor manera de aprender a usarlo.

Algunas skills para inspirarte

• eferro/skill-factory
• gojko/bugmagnet-ai-assistant
• Para definir tareas: eferro/augmented-lean-delivery
• Mutation testing: eferro/augmentedcode-skills

Para seguir aprendiendo

Mi recomendación para empezar son los cursos de Claude Code. Tuve la suerte de aprender muchísimo en el workshop de la gente de Codely, así que lo recomiendo 100% — además están generando mucho contenido de calidad. AI Coding Patterns también está muy bien. Y aunque me sepa mal reconocerlo, en X y en LinkedIn se genera mucho contenido, aunque es complicado filtrar cuál es de calidad.

Conclusión

La IA no te hace mejor ingeniero. Pero amplifica muchísimo lo que ya eres. Si tienes criterio, te multiplica. Si no, solo vas más rápido en la dirección equivocada. Así que mi consejo es simple: usa la IA, pero no dejes de pensar.

¿Hay algo que tú uses y te parezca interesante? Cuéntamelo en los comentarios.