Saltar al contenido
Programemos.net Un espacio para compartir conocimientos relacionados con la programación.
IA / OPINIONES / PROGRAMACIÓN

El subsidio de la IA se está acabando. Y no es algo malo.

Quiero contar una experiencia sencilla que me hizo pensar bastante sobre cómo estamos usando la inteligencia artificial en el desarrollo.

Durante estos últimos años nos acostumbramos a pagar una suscripción y usar la IA sin mirar demasiado el consumo. Abríamos conversaciones, cargábamos contexto, conectábamos herramientas y dejábamos que el agente trabajara. No era gratis, pero se sentía bastante cerca.

Eso está empezando a cambiar.

Desde el 1 de junio de 2026, GitHub Copilot pasó de contar solicitudes premium a medir el uso por tokens y convertirlo en GitHub AI Credits. La suscripción sigue existiendo e incluye consumo. La diferencia es que ahora una conversación corta y una sesión larga de un agente no cuestan lo mismo.

No quiero convertir esto en un artículo sobre los precios de GitHub. El cambio solo hace más visible algo que ya deberíamos estar pensando: no todo lo que puede hacer un agente necesita seguir haciéndose con un agente.

El problema no son las skills

En una empresa donde trabajé se usaban mucho las skills y los archivos Markdown para darle contexto a la IA. Algunas eran bastante grandes. Explicaban los patrones del proyecto, comandos, decisiones y casi cualquier detalle que pudiera ayudar al agente.

Eso puede estar bien. Tengo mis reservas porque creo que los modelos actuales ya pueden descubrir una parte importante de esos patrones leyendo el proyecto, pero entiendo el motivo. Para el equipo funcionaba como una red de seguridad.

Pero ese no es el punto que quiero discutir.

Lo que me llamó la atención fue otra cosa: empezamos a usar agentes para tareas que eran útiles, pero también completamente repetitivas. La IA las resolvía bien y ahorraba tiempo. El problema es que nadie se detenía a pensar si, después de resolverlas una vez, todavía hacía falta volver a cargar todo ese contexto.

A veces nos quedamos con la primera mejora. Pasamos de hacerlo manualmente a pedírselo a la IA, y como ya era más cómodo, dejamos de buscar una solución mejor.

El caso de los comentarios de Sonar

Había un proceso relacionado con comentarios de Sonar en los pull requests. En algunos casos las personas cerraban esos comentarios para poder continuar con el pull request.

Cuando digo cerrar, no me refiero a resolver el hallazgo. Me refiero literalmente a cerrar el comentario. No voy a discutir aquí si eso era correcto o no. Era lo que se hacía en la empresa y alguien tenía que completar el proceso.

Al principio se hacía a mano. Después algunas personas empezaron a usar un agente conectado mediante MCP. Le indicaban el pull request, el agente buscaba los comentarios y los cerraba.

Era útil. Mucho mejor que entrar comentario por comentario.

Pero cada vez había que iniciar una conversación, entregar el contexto, dejar que el agente consultara las herramientas y esperar el resultado. Funcionaba, aunque en el fondo siempre estaba haciendo lo mismo.

La tarea tenía varios pasos y llamadas a APIs, pero no estaba tomando una decisión especialmente compleja. Recibía el identificador del issue y del pull request, buscaba los comentarios y ejecutaba la misma acción.

Ahí fue cuando pensé: esto no necesita una conversación cada vez. Necesita parámetros.

Usé la IA para crear el script

Primero le pedí al agente que hiciera el proceso completo para un pull request. Quería comprobar que entendía las APIs, la autenticación y el orden de los pasos.

Cuando terminó, le pedí algo más: que generara un script de PowerShell con el mismo proceso y que dejara parametrizados los identificadores necesarios.

Lo hizo prácticamente al primer intento.

A partir de ahí ya no tenía que volver a pedirle lo mismo. Ejecutaba el script, pasaba los parámetros y listo. El resultado era el mismo, pero ya no había que reconstruir el contexto ni consumir tokens para repetir una tarea que conocíamos.

Flujo donde un agente entiende una tarea una vez, genera un script parametrizado y sale de las ejecuciones repetitivas
La IA ayudó a entender y construir el proceso. El script se quedó con la parte repetitiva.

Para mí, ahí estuvo la parte realmente valiosa de usar IA.

No fue que cerrara los comentarios más rápido. Fue que me ayudó a convertir un proceso que no conocía bien en una automatización que podía ejecutar sin ella.

Yo no tuve que investigar desde cero cada endpoint ni pelear demasiado con PowerShell. La IA redujo el esfuerzo inicial. Pero una vez que ese conocimiento estaba en el script, mantener al agente en el medio ya no aportaba mucho.

Un script tampoco es gratis

Esto no significa que todo deba terminar en un script.

El script hay que mantenerlo. Si cambia la API, puede romperse. También necesita manejo de errores, autenticación y una forma segura de trabajar con credenciales. La diferencia es que su comportamiento es más directo y se puede probar con facilidad.

Tampoco hace falta convertir cada automatización en una aplicación completa con interfaz, base de datos y despliegue. En este caso PowerShell era suficiente. En otro puede ser una herramienta de línea de comandos, una GitHub Action o una aplicación pequeña.

Lo importante es no agregar más aparato del necesario.

Yo mantendría al agente cuando la tarea realmente necesita interpretar información, investigar un repositorio, trabajar con excepciones difíciles o elegir entre acciones según el contexto. Ahí un script lleno de condiciones puede terminar siendo peor.

Ya había comentado algo parecido al hablar de agentes serverless en Azure Functions: si el proceso es una secuencia conocida de pasos, escribiría código. Si necesita interpretar contexto y decidir qué hacer, entonces sí pensaría en un agente.

No son bandos. Hay tareas para cada herramienta.

El punto que me interesa

Creo que el aumento de los costos de la IA puede tener un efecto positivo: obligarnos a pensar un poco más antes de abrir otra conversación.

No porque pedirle cosas pequeñas a la IA esté mal. Yo también la uso para tareas simples cuando me ahorra tiempo. Pero a veces la comodidad nos vuelve un poco perezosos. Repetimos la misma conversación varias veces aunque la primera respuesta ya contenía todo lo necesario para construir algo permanente.

Lo he visto incluso con tareas tan pequeñas como crear un commit. Se le pide al agente que lo haga, luego se corrige el mensaje, se ajustan los archivos y se mantiene una conversación para algo que quizá era más rápido hacer directamente. Puede tener sentido en un flujo grande. Para un cambio mínimo, no siempre.

Mi criterio ahora es bastante sencillo: si la IA resuelve una tarea y noto que la siguiente ejecución será prácticamente igual, intento convertir esa solución en un script o una herramienta. Si aparece una excepción que sí requiere razonamiento, vuelvo al agente.

El subsidio de la IA puede estar acabándose. No creo que eso signifique que vayamos a usarla menos, sino que tendremos que usarla mejor.

En mi caso, la mejor parte de esta experiencia no fue automatizar una tarea con IA. Fue usar la IA una vez para no necesitarla cada vez.

Si quieres seguir aprendiendo sobre estos temas, te invito a ver mis otras publicaciones.

Referencias

Jose Antonio Arias
Jose Antonio Arias

Soy un Ingeniero en Informática, apasionado de la tecnología y, siempre trato de estar aprendiendo para estar al día con las últimas tecnologías, me especializo en el desarrollo Backend con .NET, pero durante estos años, he trabajado con muchas otras tecnologías que me han ayudado en mi crecimiento profesional.