Modelos dentro del flujo de trabajo
Integro modelos de distintos proveedores por API en herramientas internas que el equipo abre todos los días.
Límite: si la tarea no se repite, no justifica un modelo.
Desde 2011 arreglo y modernizo sistemas que sostienen negocios. Ahora también con modelos, agentes y servidores MCP adentro, y con revisión del código que generan antes de que llegue a producción.
Herramientas principales: Java · Spring Boot · .NET · Node · Python · PostgreSQL · APIs REST · modelos · agentes · MCP
Aplicaciones Java 8 y JSP, .NET viejo, módulos que entiende una sola persona. Leo, documento y recién después muevo algo.
Copilotos generando código que nadie lee, prompts con datos de clientes, agentes con más permisos de los que necesitan. Reviso qué entra, qué sale y qué queda registrado.
Reportes que tardan minutos sobre tablas enormes. Mido, separo, indexo y vuelvo a medir.
Sin CI/CD, sin rollback, sin entorno de pruebas. Armo el camino para que un deploy deje de ser un evento.
APIs de terceros, el mismo dato en tres bases, integraciones a mano. Defino el contrato y lo dejo escrito.
Cada uno despliega distinto y nadie revisa código. Pongo revisión, ramas y reglas que el equipo puede sostener.
Integro modelos de distintos proveedores por API en herramientas internas que el equipo abre todos los días.
Límite: si la tarea no se repite, no justifica un modelo.
Permisos claros, alcance definido y registro de lo que hacen.
Riesgo: un agente sin límites es un incidente esperando su turno.
Conecto modelos con herramientas y datos propios usando MCP (Model Context Protocol), con el acceso mínimo que la tarea necesita.
Límite: lo que el agente no puede leer, no puede filtrar.
Leo lo que el modelo escribe antes de que llegue a producción: validación de entrada, contratos, manejo de errores, dependencias y pruebas.
Riesgo: rápido no es lo mismo que correcto.
Un modelo no arregla un índice faltante, un modelo de datos mal pensado ni un proceso que nadie definió.
Límite: cuando la respuesta es código y no IA, lo digo.
No toco una línea sin saber qué hace el sistema y quién lo usa.
Una cosa por vez, con pruebas donde se puede. Si el código salió de un modelo, alguien lo leyó antes de entrar.
Código documentado, decisiones anotadas y alguien del equipo que entiende lo que hice.
Stack: Java 8 · JSP · APIs REST
Stack: Spring Boot · React · PostgreSQL
Stack: .NET · Angular · SQL Server · Azure
La CSP, las fuentes autoalojadas, cero dependencias y lo que un sitio estático no puede proteger.
Leer
Por qué un índice faltante no se arregla con un prompt y qué preguntar antes de integrar un modelo.
Leer
La lista corta que uso antes de aprobar un cambio que salió de un modelo.
Leer
Cuéntame qué se rompió. Del otro lado hay una persona, no un bot.