Lo que he aprendido trabajando con agentes en desarrollo de software

Llevo dieciséis meses trabajando de forma intensiva con agentes aplicados al desarrollo de software en tareas reales. No hablo solo de pedir una función aislada ni de preparar una demostración. Hablo de entrar en repositorios con años de evolución, modificar flujos que afectan a usuarios, trabajar sobre configuración e infraestructura, preparar migraciones, revisar pruebas y entregar cambios que después tendrá que mantener otra persona.

La mayor parte de esta experiencia la he adquirido con Claude Code. Cuando hablo de agentes en desarrollo de software me refiero a aplicaciones capaces de investigar un repositorio, modificar código y configuración, ejecutar herramientas, preparar pruebas y ayudar en tareas de revisión, infraestructura o documentación. No pretendo comparar productos ni atribuirme el mismo recorrido con todos ellos. Creo que muchos de los problemas que trato pueden aparecer, con sus propios matices, en otras herramientas de la misma categoría.

Es una reflexión profesional basada en mi forma de trabajar y en los límites que he encontrado; no pretende convertir esa experiencia en una comparación universal entre herramientas o equipos.

Al principio me interesaba, sobre todo, aprender a pedir mejor. Pensaba que, con suficiente contexto y una buena colección de instrucciones, el agente acabaría comportándose como un desarrollador muy rápido al que bastaba con asignar tareas. Con el tiempo vi que el reto no estaba en obtener más código o más archivos, sino en controlar lo que ocurre antes, durante y después de cada cambio.

Una solución puede estar bien ordenada, superar todas las comprobaciones y, aun así, resolver el problema equivocado.

Bloque 1 · Comprender el problema

El primer error fue dar por hecho que había entendido la necesidad

Un agente puede construir una solución muy convincente a partir de una interpretación equivocada. Los nombres encajan, la estructura se parece a la del proyecto y el resumen final suena seguro. Todo parece razonable, pero que la solución sea coherente no significa que haya entendido el problema.

Los requisitos reales rara vez caben en la frase con la que abrimos una tarea. Se reparten entre el comportamiento actual, las reglas de negocio, los permisos, los datos, los estados intermedios, las integraciones y decisiones tomadas quizá años atrás. Quien conoce el producto completa muchos huecos sin darse cuenta. El agente trabaja con lo que encuentra, con lo que le damos y con las suposiciones que utiliza para rellenar el resto.

Me ha ocurrido con cambios aparentemente sencillos de autorización. Se protege la acción visible en la interfaz y la ruta principal de la API, pero la misma operación también puede ejecutarse desde una tarea programada, una importación o una herramienta administrativa. Si el encargo se interpreta como «oculta este botón» en vez de «impide esta transición para determinados actores», el cambio puede estar bien implementado y dejar abierto el flujo que de verdad importaba.

Lo mismo sucede al añadir un estado nuevo. Modificar el modelo, la persistencia y la vista suele ser la parte fácil. Lo difícil es localizar todos los lugares en los que ese estado cambia el comportamiento: búsquedas, informes, notificaciones, reintentos, permisos, procesos en segundo plano, migraciones y datos antiguos. El agente suele cerrar el caso que tiene delante. El sistema real casi nunca termina ahí.

Ahora empiezo por investigar el sistema, no por pedir cambios

Antes de pedir cambios, le encargo reconstruir el funcionamiento actual. Le pido que identifique actores, entradas, estados, reglas, errores, integraciones y efectos secundarios. Después reviso ese mapa. Si la interpretación inicial está mal, prefiero descubrirlo en el análisis y no después de crear quince archivos o modificar varias configuraciones.

Tampoco doy por buena esa investigación sin revisarla. El agente me ayuda a recorrer más código, configuración y documentación, pero sigo teniendo que decidir si lo encontrado representa de verdad el comportamiento del sistema. La cantidad de información recuperada no determina su validez.

La especificación me ayuda, pero también puede fijar un error

Trabajar con especificaciones ha mejorado mucho mi forma de utilizar estas herramientas. Dejar por escrito el comportamiento esperado, los límites y los criterios de aceptación reduce las decisiones que el agente tiene que improvisar. También conserva una referencia cuando la conversación crece, se resume o se retoma más tarde.

El riesgo está en tratar la especificación como una garantía. Un documento puede estar bien estructurado y contener la misma lectura equivocada que habría cabido en una petición de tres líneas. El desarrollo guiado por especificaciones, o SDD, ordena el trabajo, pero no vuelve correcta una especificación por el mero hecho de existir.

He aprendido a separar dos planos que los agentes mezclan con facilidad. Uno describe qué debe ocurrir: necesidad, actores, reglas, estados, restricciones y resultados observables. El otro define cómo integrarlo en el sistema: componentes afectados, límites, dependencias, tratamiento de datos y pruebas. Si se mezclan demasiado pronto, una decisión técnica puede acabar presentada como un requisito.

Lo que dejo claro antes de implementar

Qué comportamiento cambia y cuál debe mantenerse; qué actores y canales ejecutan el mismo caso de uso; qué datos existen ya; qué situaciones invalidan la operación; qué decisiones arquitectónicas no quiero que el agente improvise; y qué pruebas necesito para dar el resultado por válido.

Tampoco intento volcar todo el conocimiento en un documento enorme. Un exceso de contexto puede ocultar contradicciones, diluir lo importante y hacer que el agente pierda las prioridades. Para mí, una buena especificación no describe cada detalle de la implementación: acota las decisiones que el agente no debe tomar por su cuenta y deja visibles las que aún requieren criterio.

Con TDD y BDD me ocurre algo parecido. Escribir primero una prueba ayuda a fijar el comportamiento y los escenarios acercan el lenguaje técnico al del negocio. Aun así, puede faltar un actor, estar mal planteada la prueba u omitirse justo el estado que provoca el fallo. La metodología aporta disciplina, pero no formula el problema por nosotros.

Bloque 2 · Diseñar y comprobar

Sin criterio técnico, no puedes dirigir ni revisar bien el trabajo

Este fue uno de los aprendizajes más incómodos. En los trabajos complejos que he abordado, los agentes no han reducido la necesidad de conocer ingeniería de software. La han hecho más visible, porque producen mucho material que hay que evaluar y lo presentan con suficiente seguridad como para que un error de diseño pase desapercibido.

Es posible obtener un cambio localmente correcto sin dominar toda la teoría que hay detrás. Lo difícil es decidir si esa solución encaja en un sistema que seguirá evolucionando, si introduce una dependencia equivocada o si resuelve el caso actual a costa del siguiente. Ahí entran Clean Code, SOLID, KISS, YAGNI, los patrones de diseño y la experiencia acumulada trabajando con sistemas reales.

No uso estos principios como una lista de palabras que se añade a la petición. Pedir «aplica SOLID» no dirige una solución. El agente puede crear interfaces que no desacoplan nada, factorías para construcciones triviales o repositorios sobre capas que ya aislaban la persistencia. También puede irse al extremo contrario y concentrar reglas de dominio, validación, acceso a datos y presentación en una misma clase porque así cierra la tarea con menos cambios.

Ambos resultados pueden venir acompañados de una explicación convincente. Para distinguirlos necesito conocer qué problema intenta resolver cada principio y qué coste introduce: cuándo una abstracción reduce la complejidad y cuándo solo la desplaza, cuándo una dependencia debe invertirse y cuándo un patrón deja una estructura que el equipo tendrá que mantener sin necesidad.

KISS no significa elegir siempre la opción con menos archivos. Una solución aparentemente sencilla puede mezclar responsabilidades y dificultar el siguiente cambio. YAGNI evita construir posibilidades de ampliación que quizá nunca se utilicen, pero no justifica ignorar requisitos conocidos. Clean Code no consiste en trocear métodos hasta ocultar el flujo. SOLID tampoco es una plantilla de carpetas.

El conocimiento teórico es necesario, pero no basta por sí solo. También hay que conocer el producto, la historia del repositorio y las restricciones del equipo. Una arquitectura impecable sobre el papel puede ser una mala decisión si rompe convenciones que sostienen decenas de módulos o exige un coste de adopción que el proyecto no puede asumir.

Pedir demasiado trabajo de una vez me ha salido caro

La primera tentación fue pedir una tarea completa de principio a fin. Si el agente podía investigar, implementar, actualizar las pruebas, modificar la configuración y preparar la documentación, dividir el trabajo parecía ineficiente. En mi caso, esa forma de avanzar ha salido cara siempre que todavía quedaban decisiones importantes sin validar.

Una interpretación equivocada tomada al principio se propaga. Puede aparecer primero en el modelo de datos o en la configuración y llegar después a los servicios, la API, la interfaz, el despliegue, las pruebas y la documentación. Cuando descubro el error ya no corrijo una decisión: tengo que desmontar todas sus consecuencias.

También he gastado más tokens intentando reconducir una arquitectura extendida por muchos archivos que acordando el enfoque sobre un primer caso completo. Cada intento fallido deja la conversación llena de rectificaciones y explicaciones contradictorias, hasta que cuesta saber qué supuestos siguen vigentes.

Ahora empiezo por un caso completo, pequeño y comprobable. Ese caso debe recorrer las capas necesarias y permitirme comprobar pronto si el enfoque es correcto. Reviso si he entendido bien la necesidad, si la solución encaja en la arquitectura y si las pruebas detectan los fallos que me preocupan. Solo entonces amplío el mismo enfoque.

Esto no significa convertir cualquier tarea en cambios microscópicos. Una migración mecánica o una sustitución sistemática puede afectar a cientos de archivos. El punto está en validar primero la regla de transformación sobre una muestra representativa y comprobar sus efectos antes de extenderla. Intento reducir cuanto antes la incertidumbre que podría obligarme a rehacer el trabajo.

Pruebas que pasan y revisiones que dan todo por bueno

Que las pruebas pasen no significa que comprueben lo correcto. La prueba y la implementación suelen nacer de la misma interpretación. Si el agente ha entendido mal el requisito, puede escribir una prueba que confirme esa lectura. Código y prueba están de acuerdo, pero el producto sigue mal.

También es habitual que cubra el camino principal y algunos errores evidentes, pero deje fuera estados previos, valores límite, permisos, reintentos, idempotencia, datos heredados o combinaciones entre componentes. En otras ocasiones la prueba existe, pero solo verifica que se devuelve una respuesta o se invoca un método, no las propiedades que definen el comportamiento.

Tuve un ejemplo muy concreto en mi propio blog. Había una comprobación automática de contraste que devolvía 18,25:1 y daba el resultado por bueno. El valor real era 3,44:1. El cálculo leía los tres primeros números del color y omitía el canal alfa. La prueba se ejecutaba, terminaba correctamente y comprobaba otra cosa. El fallo lo detectó Lighthouse, no la batería que yo había preparado.

Desde entonces reviso las pruebas por separado, sin dejarme condicionar por el código que ya existe. Me pregunto qué requisito demuestra cada una, qué implementación plausible pero incorrecta haría que fallase y qué riesgo sigue sin estar representado. La cobertura ayuda a localizar zonas no ejecutadas, pero no demuestra que hayamos formulado las preguntas adecuadas.

Un agente que revisa no se convierte por ello en auditor

Encadenar revisores produce una gran sensación de control. Un agente implementa, otro revisa la arquitectura, un tercero inspecciona las pruebas y otro analiza la seguridad. Puede ayudar mucho, pero no equivale a disponer de opiniones independientes.

Los revisores pueden compartir el mismo modelo, la misma especificación incompleta, el mismo repositorio y los mismos criterios de aceptación. Un contexto nuevo reduce parte del sesgo de la sesión anterior, aunque no elimina el error de partida. El revisor puede confirmar que el código sigue el plan sin cuestionar si el plan resolvía realmente la necesidad.

Lo comprobé al automatizar parte de mi ciclo editorial. Encontré varias formas de que el sistema aprobara sus propios fallos. En una de ellas, el encargo que generaba el contenido determinaba también qué podía ver el auditor. La revisión era extensa y ordenada, pero trabajaba dentro de los límites del mismo proceso que debía cuestionar. Loop Engineering desarrolla este problema y varias formas de hacerlo visible.

La revisión automática puede señalar problemas; la decisión mejora cuando se apoya en comprobaciones reproducibles, evidencias y contexto técnico.

Ver a tamaño originalCerrar

Por eso separo los hechos comprobables de los juicios generales. Una prueba rota, un error de tipos, una dependencia vulnerable o una consulta que supera un umbral son resultados reproducibles. Afirmaciones como «la arquitectura es sólida» o «el código es mantenible» solo tienen valor si explican qué se revisó, con qué criterio y qué quedó fuera. El resumen del agente es una señal más dentro de esa revisión.

Bloque 3 · Gobernar el entorno

La etapa en la que instalaba demasiadas skills

Esa misma búsqueda de control me llevó a llenar el entorno de añadidos. Durante una primera etapa incorporé una skill para planificar, otra para revisar, otra para preparar pruebas, además de subagentes, automatizaciones y conectores. Cada pieza parecía razonable por separado. El conjunto no siempre funcionaba mejor.

Una skill reúne instrucciones y, según la plataforma, otros recursos o scripts para realizar una tarea de una forma determinada. Cuando procede de terceros, también incorpora los supuestos, criterios y decisiones de quien la ha creado. Puede estar muy bien hecha, pero también arrastrar ideas que no encajan en el proyecto, criterios desactualizados o una aplicación superficial de la práctica que promete automatizar.

Cuando instalé muchas, aparecieron problemas difíciles de atribuir. Algunas se solapaban y competían por dirigir el mismo trabajo; otras imponían estilos incompatibles. Una pedía cambios mínimos y otra convertía cualquier tarea en una refactorización. Por separado parecían razonables y, juntas, podían producir una solución incoherente.

No todas las extensiones tienen el mismo alcance. Una instrucción reutilizable no equivale a un complemento capaz de ejecutar código. Una automatización puede lanzar comandos y un servidor MCP puede dar acceso a datos o acciones externas. Antes de adoptar una pieza necesito saber qué añade, qué permisos utiliza, cómo se actualiza y cómo retirarla.

Una skill solo permanece cuando resuelve un problema concreto, puede probarse y retirarse, y la dependencia que introduce resulta asumible.

Ver a tamaño originalCerrar

También dejé de confundir popularidad con validación técnica

He dejado de instalar todo lo que durante una semana parece imprescindible. A menudo ocurre lo mismo: un vídeo muestra un flujo espectacular, aparece un repositorio con miles de estrellas, varias personas lo comparten en X, LinkedIn o YouTube y se crea la impresión de que no adoptarlo significa quedarse atrás.

Esos canales ayudan a descubrir herramientas, pero no certifican su calidad. Una demostración suele enseñar el recorrido más favorable: la tarea está preparada, el repositorio elegido y el vídeo termina cuando el resultado visible funciona. Rara vez vemos qué ocurre tres semanas después, cuánto cuesta modificar lo generado o por qué el agente siguió una convención que nadie recuerda haber configurado.

Las estrellas de GitHub indican que un proyecto ha llamado la atención; no demuestran que encaje en mi arquitectura, que sea seguro, que esté bien mantenido ni que tenga calidad técnica. Tampoco puedo afirmar que quien recomienda una herramienta no la haya probado. Sí puedo comprobar que muchas recomendaciones no explican durante cuánto tiempo se utilizó, en qué clase de repositorio, con qué permisos, qué errores aparecieron ni por qué se decidió mantenerla.

Los catálogos y buscadores de skills sirven para encontrar opciones, pero no resuelven la selección ni la compatibilidad. Como instalar es tan fácil, el entorno puede crecer más deprisa que nuestra capacidad para entenderlo. La comunidad me sirve para localizar herramientas; decido si incorporarlas después de probarlas. Prefiero una configuración pequeña que sé explicar a otra cuyo comportamiento no entiendo.

El modelo no es toda la aplicación

Para evaluar bien todas esas piezas tuve que entender algo que al principio pasé por alto. Un agente utilizado en desarrollo de software no es solo un modelo conectado a un repositorio. Lo rodea una aplicación que decide qué contexto recibe, qué instrucciones tienen prioridad, qué herramientas y permisos utiliza, qué memoria conserva y cuándo continúa, reintenta o se detiene. En este artículo llamo harness al sistema de orquestación y control que rodea al modelo.

El comportamiento del agente depende de toda la aplicación y de sus límites operativos, no solo del modelo elegido.

Ver a tamaño originalCerrar

La deuda técnica ya no está solamente en el código; también puede vivir en el harness que hemos construido alrededor del agente.

Entenderlo cambia la forma de buscar el fallo. Una respuesta deficiente no siempre se debe a que el modelo sea incapaz. Puede haber recibido contexto incompleto, una regla antigua, un resumen defectuoso de una sesión larga o una herramienta que no permite ejecutar la comprobación necesaria. También puede haber intervenido una extensión activada por error o una política de permisos.

Cada producto resuelve estas capas de forma distinta: jerarquía de instrucciones, memoria, compactación del contexto, ejecución local o remota, aislamiento, confirmaciones y extensiones. Por eso no conviene copiar una configuración de otra herramienta o proyecto sin entender cómo la procesará la plataforma.

Antes pensaba, sobre todo, en qué podía añadir al agente. Ahora intento comprender qué parte del sistema altera cada añadido: qué reglas se cargan siempre, qué comandos se ejecutan, qué acceso existe a la red y a las credenciales y qué información persiste. Para investigar, prefiero acceso de solo lectura al contexto aprobado. Una acción que modifica estado, llama a un servicio externo o usa una credencial con alcance amplio necesita límites técnicos: solo operaciones y destinos autorizados, credenciales fuera del contexto y un registro de la acción y su resultado. Sin ese conocimiento, cualquier problema parece un fallo del modelo y la reacción inmediata es cambiar la petición, instalar otra skill o probar otro modelo.

Antes de pedir al agente que comprenda mi proyecto, necesito comprender cómo la aplicación construye el contexto desde el que trabaja.

Bloque 4 · Operar

No todos los modelos me sirven para lo mismo

También he tenido que dejar de hablar de «el modelo» como si cada plataforma ofreciera una única opción y todas se comportaran igual. En Claude Code, por ejemplo, he tenido que distinguir entre familias como Opus, Sonnet y Haiku. En otras herramientas cambian los nombres, pero la decisión de fondo es la misma: cuánto razonamiento exige la tarea, cuánto tiempo puedo esperar, qué coste puedo asumir y cómo se desenvuelve el modelo con las herramientas disponibles.

Al principio cometí dos errores opuestos. A veces utilizaba el modelo más capaz para cualquier tarea, incluso para búsquedas mecánicas o cambios bien acotados. Otras intentaba ahorrar cuota recurriendo a uno más ligero cuando el trabajo exigía reconstruir una arquitectura, investigar un fallo transversal o cuestionar una especificación. En el primer caso gastaba más sin obtener una mejora real. En el segundo reducía el consumo inmediato y lo pagaba después en correcciones.

Ahora separo las tareas por riesgo, ambigüedad y facilidad de comprobación. Para analizar requisitos incompletos, tomar decisiones arquitectónicas, depurar problemas que atraviesan varias capas o revisar una migración delicada prefiero el modelo que mejor resultado me haya dado al razonar y utilizar herramientas. Para inventarios, búsquedas, transformaciones repetitivas o comprobaciones bien definidas puede bastar otro más rápido. No hay una clasificación universal: depende del repositorio, de la versión del modelo y de cómo esté construida la aplicación.

La descripción comercial y una comparativa basada en tareas ajenas a mi trabajo no me sirven por sí solas. Mantengo un pequeño conjunto de casos de referencia: reconstruir un flujo, localizar el impacto de un cambio, proponer una corrección, escribir pruebas que detecten una implementación defectuosa y revisar un conjunto de cambios. Los ejecuto con el mismo contexto y comparo omisiones, correcciones, uso de herramientas, tiempo y consumo. Una omisión que comprometa el cambio descarta un resultado aunque sea más rápido o barato; el tiempo y el consumo solo ayudan a desempatar opciones igualmente aceptables.

También he tenido que aprender dónde se selecciona el modelo en cada aplicación. En algunas se elige para toda la sesión; en otras puede configurarse por agente o subagente, y algunas reparten las tareas automáticamente. Cuando la plataforma lo permite, lo hago explícito. Una revisión arquitectónica no tiene por qué utilizar el mismo modelo que una búsqueda mecánica, y una tarea que se ejecuta cientos de veces no debería usar sin más el modelo más caro.

La configuración tiene que quedar visible y ser estable. Si una skill cambia de modelo sin que yo lo sepa, o un alias apunta a otra versión, también puede cambiar el resultado. Defino qué debe ocurrir cuando el modelo previsto no está disponible o se alcanza un límite. En una fase crítica prefiero detener el trabajo y elegir la alternativa antes que continuar sin avisar con otro modelo. Repito las pruebas cuando cambia una versión o la aplicación modifica el reparto de tareas.

La elección del modelo parte del riesgo y de la dificultad de la tarea; el coste, el consumo y la cuota se valoran después como restricciones adicionales.

Ver a tamaño originalCerrar

Por qué dejé de encadenar planes gratuitos

Seleccionar el modelo adecuado para cada tarea no me obliga a perseguir todas las cuotas gratuitas que aparecen. Durante un tiempo caí en ese juego: surgía un modelo con una modalidad gratuita, un servicio que distribuía peticiones entre muchos modelos, otro que prometía elegir el más adecuado y una nueva integración. Era fácil pensar que, combinándolo todo, podría trabajar sin límite.

Cada capa añade dependencias que no quiero perder de vista: cuotas de uso, límites por minuto o por día, ventanas de contexto, concurrencia, disponibilidad, cambios de modelo, diferencias en las herramientas, políticas de datos y decisiones comerciales que no controlo. Un servicio que distribuye peticiones entre modelos no elimina esas dependencias. Las concentra y, a veces, hace más difícil saber cuál está condicionando el resultado.

Una tarea larga puede empezar con un modelo y terminar en otro que interpreta las instrucciones de otra manera. También puede quedarse sin margen justo cuando el contexto acumulado hace más costoso continuar o cuando falta una última revisión. Que la interfaz permita seguir enviando peticiones tampoco garantiza que el plan contratado sea ilimitado ni que tengamos capacidad suficiente para terminar con el mismo nivel de calidad.

Antes de planificar una tarea extensa reviso la capacidad disponible: cuánto uso queda, cuándo se renueva la cuota, qué límites existen, cuántos trabajos pueden ejecutarse a la vez, qué modelos están incluidos y qué ocurrirá si una fase debe repetirse. Si la tarea no cabe, la divido, reduzco el alcance, cambio el enfoque o contrato la capacidad necesaria antes de empezar. Prefiero decidirlo al principio y no descubrir a mitad del trabajo que el plan dependía de recursos que ya no están disponibles.

Tengo que poder continuar sin la herramienta

Más grave que agotar una cuota es perder la capacidad de continuar sin el sistema que produjo el cambio. Si no entiendo el código, la configuración, las decisiones tomadas o sus efectos, no puedo explicar por qué se eligió una solución, no sé dónde hacer la siguiente modificación y tampoco sabría reparar un fallo sin volver a abrir la misma conversación. En ese punto, la ayuda ya se ha convertido en una dependencia.

Por eso procuro que las decisiones importantes queden en la especificación, en el código, en la configuración, en las pruebas y en la documentación del proyecto, no solo en el historial del agente. Reviso hasta poder continuar por mi cuenta. No necesito escribir manualmente cada línea, pero sí conservar la capacidad de entender, modificar y defender lo que se ha construido.

Si al retirar el agente no puedo explicar el cambio, continuar la tarea o reparar un fallo, el trabajo todavía no está bajo mi control.

Bloque 5 · Mi forma de trabajar hoy

Cómo trabajo ahora

Con el tiempo, todo esto se ha convertido en una forma de trabajo mucho más estable que la de los primeros meses. No he encontrado un prompt perfecto ni una configuración que automatice el desarrollo. Empiezo por el problema y termino revisando yo el resultado, no dando por bueno el resumen del agente.

Antes de ejecutar el primer cambio elijo también el modelo. Valoro la ambigüedad, el riesgo, el volumen de contexto, las herramientas que necesitará y lo fácil que será comprobar el resultado. Cuando intervienen varios agentes o skills, dejo anotado qué modelo debe utilizar cada uno y compruebo cuál ejecutó realmente cada fase.

Una tarea puede desviarse mucho antes de que aparezca el código; la decisión final debe revisar también los supuestos, la cobertura y el criterio utilizado.

Ver a tamaño originalCerrar

1. Comprendo la necesidad y el riesgo. Aclaro qué cambia, quién puede verse afectado y qué coste tendría equivocarse.

2. Pido una investigación sin modificar el repositorio ni la configuración. El agente reconstruye el comportamiento actual, localiza puntos afectados y señala lo que no puede determinar.

3. Convierto el análisis en una especificación y en comprobaciones concretas. Dejo por escrito el comportamiento, las decisiones arquitectónicas que no deben improvisarse y las pruebas que necesito.

4. Implemento un primer caso completo. Busco una parte pequeña, pero suficiente para comprobar que he entendido bien la necesidad y que la solución encaja en el sistema.

5. Reviso antes de que el cambio crezca. Leo el conjunto de cambios, recorro los flujos, compruebo código y configuración, ejecuto las verificaciones y examino las pruebas por separado.

6. Decido. Integro, corrijo o retiro. La conclusión del agente es un dato más para decidir, no la decisión final.

Relaciono el riesgo con la evidencia

Antes de ampliar un cambio, relaciono el riesgo que introduce con una evidencia concreta:

No todas las tareas requieren el mismo nivel de control. Renombrar una función interna o aplicar una transformación mecánica no exige lo mismo que una migración, un cambio de autorización o una decisión que afectará a varios equipos. Ajusto la autonomía al riesgo y evito convertir un método útil en un ritual.

Mantengo además el entorno deliberadamente pequeño. Las instrucciones persistentes son pocas y responden a convenciones estables. Las skills propias tienen un objetivo definido y se versionan. Las de terceros se estudian, se prueban en un entorno controlado y se eliminan cuando no aportan una mejora comprobable.

Dónde me aportan valor

Mi experiencia con los agentes es positiva. Los utilizo para investigar repositorios amplios, seguir el recorrido de una operación, comparar implementaciones, analizar configuraciones, preparar inventarios de impacto y convertir una pregunta inicial en hipótesis que puedo revisar. También aceleran transformaciones repetitivas, migraciones bien acotadas, infraestructura declarativa, documentación técnica, primeras baterías de pruebas y análisis de errores.

Me resultan más útiles cuando el objetivo está claro y puedo comprobar pronto si el resultado va por buen camino. Cuanto más global, subjetiva o dependiente del negocio sea la decisión, mayor tiene que ser mi intervención. Les doy autonomía allí donde puedo detectar y corregir un error antes de que se extienda.

Qué sigo revisando personalmente

La interpretación final de la necesidad sigue siendo mía. También la elección de una arquitectura que condicionará el sistema durante años. No acepto unas pruebas solo porque estén en verde ni incorporo una extensión que amplíe permisos o modifique el entorno sin haberla revisado antes.

Lo que he aprendido, en concreto

Si tuviera que reducir todo este recorrido a decisiones concretas, me quedaría con estas:

• Primero reconstruyo el problema y valido un cambio completo y comprobable antes de extenderlo. Una solución rápida no compensa una necesidad mal entendida.

• Una especificación no queda validada solo porque esté completa y bien presentada. También reviso sus supuestos, omisiones y decisiones implícitas.

• No utilizo SOLID, KISS, YAGNI o los patrones como consignas genéricas. Los traduzco a responsabilidades, dependencias y límites concretos.

• Reviso el conjunto y no solo el componente modificado, porque una solución limpia en una parte puede deteriorar la arquitectura general.

• Reviso las pruebas por separado. Deben detectar una implementación plausible pero incorrecta, no limitarse a confirmar la actual.

• Uso revisores automáticos para detectar problemas y encontrar puntos ciegos. Los trato como una fuente de señales, no como una auditoría independiente, y mantengo la decisión sobre la aceptabilidad del cambio.

• Mantengo pocas skills, plugins, hooks y conexiones externas. Cada elemento debe resolver un problema real, tener un alcance conocido y poder retirarse.

• Utilizo vídeos, redes, catálogos y estrellas de GitHub para descubrir. Adopto una herramienta solo después de probarla en mi contexto.

• Necesito entender la aplicación que rodea al modelo: cómo construye el contexto, qué memoria conserva, qué permisos concede, qué herramientas ejecuta y qué límites aplica.

• Trato la elección del modelo como una decisión técnica. Lo pruebo con tareas representativas, lo asigno según el riesgo y repito la evaluación cuando cambia de versión. No doy por hecho que el más potente, el más barato o el predeterminado sea siempre el adecuado.

• Compruebo las cuotas y la capacidad disponible antes de planificar trabajos largos. No baso un proceso profesional en encadenar planes gratuitos ni en confiar en que siempre habrá otro modelo disponible.

• Doy por terminado un cambio solo cuando puedo explicarlo, continuarlo y repararlo sin depender del agente que lo generó. Mido su valor por el ciclo completo, no por la cantidad de archivos o cambios producidos.

Los aprendizajes se reparten entre comprender el problema, diseñar la solución, gobernar el entorno y operar sin perder el control técnico.

Ver a tamaño originalCerrar

Qué reviso antes de adoptar un repositorio, una skill o un servicio

No aplico el mismo control a todo. Trato un repositorio como código que voy a mantener, una skill como una extensión que modifica el comportamiento del entorno y un servicio como una dependencia externa con sus propios límites operativos.

Repositorio

• Qué problema recurrente resuelve y por qué el proceso actual no lo cubre ya.

• Qué código, scripts y dependencias incorpora; no me quedo solo con el README o la demostración.

• Quién lo mantiene, si sigue activo y cómo gestiona versiones, cambios incompatibles e incidencias abiertas.

• Qué supuestos hace sobre la arquitectura, el lenguaje y la forma de trabajar del proyecto.

• Si puedo fijar la versión del componente, cómo puedo volver al estado anterior y qué quedará en el proyecto al retirarlo.

• Qué ocurre al probarlo en un entorno controlado con una tarea representativa y qué mejora objetiva aporta.

• Si el equipo puede entender, continuar y mantener el trabajo sin depender de convenciones que nadie documenta.

Skill

• Qué instrucciones, scripts, hooks, agentes, servidores MCP o dependencias incorpora y qué hace cada uno.

• A qué archivos, al terminal, a la red, a las credenciales y a los servicios externos puede acceder.

• Qué modelo utiliza por defecto, dónde se configura, si puedo fijar una versión y qué ocurre cuando el modelo previsto no está disponible.

• Con qué reglas o extensiones existentes se solapa y qué conflictos podría introducir.

• Si puedo fijar la versión, volver al estado anterior y retirarla sin dejar cambios o dependencias residuales.

• Qué ocurre al probarla en un entorno controlado con una tarea representativa y qué mejora objetiva aporta.

• Si puedo conservar solo el componente necesario en lugar de instalar una colección completa.

• Si el equipo puede entender, continuar y mantener el trabajo cuando esa skill no esté disponible.

Servicio

• Qué modelo o modelos utiliza, cómo reparte las peticiones, si puedo fijar una versión y qué ocurre cuando el modelo previsto no está disponible.

• Qué cuotas y límites de peticiones tiene, qué ventanas de contexto y concurrencia admite, cuánto cuesta y qué disponibilidad ofrece.

• Qué datos recibe, qué política de retención aplica y qué credenciales o servicios externos intervienen.

• Qué pruebas reales utilizaré para compararlo con las alternativas y cuándo repetiré la evaluación después de una actualización.

• Cómo puedo volver al estado anterior o retirar la dependencia si cambia su comportamiento o sus condiciones.

• Si el equipo puede entender, continuar y mantener el trabajo cuando el servicio no esté disponible.

La herramienta puede hacer mucho más que escribir código. Yo sigo respondiendo por el resultado.

Es razonable pensar que los agentes seguirán mejorando: comprenderán repositorios más grandes, conservarán mejor el contexto y sostendrán trabajos más largos. Aun así, seguiré necesitando comprobar si han entendido la necesidad y si el resultado encaja en el sistema. Cuanto más convincente sea la salida, más fácil será bajar la guardia antes de tiempo.

A día de hoy tengo claro que el agente puede hacer una parte creciente del trabajo, ya sea sobre código, configuración, pruebas, infraestructura o documentación. Yo sigo necesitando entender lo que ha hecho, revisar las decisiones importantes y saber cuándo parar.