0:00–0:05
5 min
Bloque 0 — Apertura y sala en vivo TM04
Dos preguntas: qué copilot usan hoy y qué creen hoy sobre nube frente a propio.
GABOTRIX × TECNIMÁTICA S.A.S · PROGRAMA DE IA APLICADA
SESIÓN A-4 · 2 HORAS · GRUPO FOCAL DE INGENIERÍA Y DESARROLLO
Del copilot al agente: código asistido y arquitectura de agentes
Primera hora: IA en el flujo real de desarrollo de ChronoSoft con generación, refactorización, documentación y pruebas sobre un módulo de verdad, y cómo revisar con criterio lo que devuelve. Segunda hora: qué es un agente por dentro, qué se compra y qué se construye, y una matriz de decisión con costos por escenario para responder la pregunta que trae el equipo: nube o propio.
2 h
dos temas del plan
4 pasos
el ciclo de código asistido
4 stacks
comparados con costo
3 escenarios
de Tecnimática, con cifras
Traiga abierto Visual Studio con un módulo de ChronoSoft que pueda mostrar sin datos de cliente, o use el módulo simulado de esta página.
Idea fuerza
“Un copilot le ahorra minutos. Un agente le ahorra horas. Pero los dos fallan igual cuando nadie lee lo que devuelven. La diferencia entre adoptar IA en ChronoSoft y sembrar deuda técnica no está en la herramienta: está en las pruebas que corren antes de aceptar el cambio y en la cuenta de tokens que alguien hizo antes de firmar el contrato de nube.”
Agenda · ajustable por el facilitador
Dos horas, dos decisiones concretas
0:05–0:20
15 min
Bloque 1 — Dónde entra la IA en el flujo real (I-1)
Generar, refactorizar, documentar y probar. La IA propone; el compilador y las pruebas disponen.
0:20–0:55
35 min
Bloque 2 — Práctica I-1 sobre un módulo real
Explicar y documentar, generar pruebas antes de tocar, refactorizar con pruebas en verde y revisar críticamente.
0:55–1:00
5 min
Pausa y votación de medio tiempo
Registrar cuántas pruebas quedaron en rojo y cuáles.
1:00–1:15
15 min
Bloque 3 — Qué es un agente por dentro (I-3)
Modelo, herramientas, bucle, memoria y function calling con un ejemplo de Tecnimática.
1:15–1:35
20 min
Bloque 4 — Nube comercial contra orquestador propio
Cuatro stacks, la cuenta de tokens, tres escenarios y siete palancas para bajar el costo.
1:35–1:55
20 min
Bloque 5 — Matriz de decisión, en vivo
Cada participante puntúa criterios y la matriz calcula el stack ganador por escenario.
1:55–2:00
5 min
Cierre — Votación final y encargo
Comparar el voto inicial y final; definir una práctica real y una medición de volumen.
Bloque 1 · I-1
Dónde entra la IA en el flujo real
No hay un botón mágico. Hay cuatro momentos distintos y cada uno necesita una regla de control diferente.
Generar
Código nuevo a partir de una especificación.
Riesgo: Inventa APIs que no existen.
Regla: Pida la firma primero, el cuerpo después.
Refactorizar
Mismo comportamiento, mejor estructura.
Riesgo: Cambia el comportamiento sin avisar.
Regla: Nunca sin pruebas en verde antes y después.
Documentar
Comentarios XML, README y explicación de código heredado.
Riesgo: Describe lo que el código parece hacer, no lo que hace.
Regla: Verifique cada afirmación contra una prueba o ejecución.
Probar
Generar casos de prueba y datos.
Riesgo: Prueba lo fácil y omite los bordes.
Regla: Pida explícitamente casos borde y de error.
Copilots que aplican a su stack
| Herramienta | Dónde vive | Sirve mejor para | Costo | Datos y entrenamiento |
|---|---|---|---|---|
| GitHub Copilot en Visual Studio | Dentro del IDE que ya usan | Autocompletado, chat sobre el archivo y pruebas | Individual o Business | En Business no entrena con su código; en el gratuito revise la configuración |
| Antigravity | Agente de escritorio visto en la A-3 | Tareas largas multiarchivo con plan y artefactos | Según plan vigente | Revise el plan antes de ejecutar |
| Claude Code / Codex CLI / Gemini CLI | Terminal | Refactorizaciones grandes y migraciones | Uso o suscripción | Exigen disciplina con permisos y alcance |
| Cursor / Windsurf | Editor alternativo a VS Code | Trabajo agente dentro del editor | Suscripción | No reemplazan Visual Studio para WinForms y .NET Framework |
| Copilot para SQL Server | SSMS y Azure Data Studio | Consultas y explicación de planes de ejecución | Según producto | Valide siempre contra la versión y el plan real |
La regla
La IA propone. El compilador, las pruebas y la revisión humana disponen.
Checklist de revisión crítica
- 1. ¿Compila sin warnings nuevos?
- 2. ¿Las pruebas existentes siguen en verde?
- 3. ¿Hay pruebas nuevas para lo que cambió, incluidos los bordes?
- 4. ¿Usa alguna API, paquete o método que no existe en la versión de .NET del proyecto?
- 5. ¿Cambió el comportamiento en algún caso que no se pidió?
- 6. ¿Introdujo dependencias, permisos o conexiones nuevas?
- 7. ¿Entiendo cada línea lo suficiente para defenderla en revisión de código?
Versión imprimible
Para tener al lado de Visual Studio.
Bloque 2 · práctica I-1
Cuatro pasos sobre un módulo de ChronoSoft
El módulo simulado calcula el consumo real por bache frente a la fórmula. Está escrito en VB.NET, no tiene pruebas y contiene comportamientos que la suite debe descubrir.
Descargar consumo_bache.vb1
Explicar y documentar
Prompt · paso 1
ROL: Actúa como ingeniero senior de .NET que documenta código heredado de una planta de alimentos balanceados. INSTRUCCIÓN: Explica qué hace cada método de la clase ConsumoBache, señala supuestos implícitos y casos en que puede fallar, y genera los comentarios XML de documentación. No cambies el código. INPUT: [pegar consumo_bache.vb] OUTPUT: 1) explicación por método en máximo 3 líneas cada una, 2) lista de riesgos encontrados ordenados por gravedad, 3) el archivo con comentarios XML.Qué debe observar
Si encuentra los riesgos importantes sin que se los pidan. Si no, la lección es que documentar no es revisar.
2
Pruebas antes de tocar
Prompt · paso 2
ROL: Actúa como ingeniero de calidad en .NET. INSTRUCCIÓN: Genera pruebas unitarias con MSTest para la clase ConsumoBache que cubran el caso normal, los bordes (fórmula igual a cero, desviación negativa, lista vacía, material que no existe) y los límites exactos de clasificación (2 y 5). No corrijas el código: las pruebas deben reflejar lo que el código hace HOY y marcar con un comentario TODO las que fallan por un error del código. INPUT: [pegar consumo_bache.vb] OUTPUT: un archivo ConsumoBacheTests.vb compilable, con un método de prueba por caso y nombre descriptivo.Qué debe observar
Deben quedar al menos dos pruebas en rojo: una evidencia del error antes de tocar nada.
3
Refactorizar con red
Prompt · paso 3
ROL: Actúa como ingeniero senior de .NET. INSTRUCCIÓN: Corrige los errores que dejan pruebas en rojo y refactoriza ConsumoBache para que sea más legible, sin cambiar la firma pública de los métodos. Usa Math.Abs para la clasificación y lanza ArgumentException cuando la fórmula sea cero. Explica cada cambio en una línea. INPUT: [código] + [pruebas] OUTPUT: la clase corregida y la lista de cambios.Qué debe observar
Que todas las pruebas pasen y ninguna firma cambie. Si cambió una prueba en vez del código, rechace.
4
Revisión crítica
Prompt · paso 4
ROL: Actúa como revisor de código exigente. INSTRUCCIÓN: Revisa este cambio con la checklist de 7 puntos y responde cada punto con evidencia concreta del código, no con opiniones. Si algún punto no se puede verificar desde el código, dilo. INPUT: [checklist] + [código antes] + [código después] + [pruebas] OUTPUT: tabla punto · veredicto · evidencia.Qué debe observar
El punto 7 lo responde el humano, no la IA. Ahí termina la práctica.
Entregable I-1
Ficha · Flujo de trabajo con IA adoptado
Módulo, herramienta, tiempo antes y después, pruebas que fijan el comportamiento, cambio aceptado, cambio rechazado y revisor humano.
Abrir ficha imprimibleBloque 3 · I-3
Qué es un agente por dentro
Un agente es un modelo que recibe un objetivo, decide qué herramienta pedir, observa el resultado y repite hasta terminar o llegar a un límite.
Modelo
El que decide; se paga por tokens.
Herramientas
Funciones que el modelo puede pedir: consultar SQL Server, enviar correo o leer un log.
Bucle y orquestador
Quien controla pasos, reintentos, límites y presupuesto.
Memoria
Contexto de conversación, resúmenes comprimidos y largo plazo en vectores o tablas propias.
Function calling
Una herramienta real de Tecnimática
Definición de herramienta
{ "name": "consultar_consumo_por_bache", "description": "Devuelve consumo real vs fórmula por material para un bache de ChronoSoft", "parameters": { "type": "object", "properties": { "planta": {"type":"string"}, "bache_id": {"type":"string"}, "fecha": {"type":"string","format":"date"} }, "required": ["planta","bache_id"] } }- 1. El usuario pregunta por un bache.
- 2. El modelo pide llamar la herramienta con argumentos.
- 3. El código valida permisos y consulta SQL Server.
- 4. El modelo recibe el resultado y redacta.
El modelo nunca toca la base de datos. Su código sí. Ahí vive la seguridad.
Tipos de agente
| Tipo | Cómo funciona | Ejemplo | Complejidad |
|---|---|---|---|
| Asistente con herramientas | Una conversación, pocas funciones | Soporte de primera línea | Baja |
| Agente de tarea | Objetivo, plan y varios pasos | Informe mensual de soporte | Media |
| Flujo orquestado | Pasos fijos; modelo solo en algunos nodos | Clasificador y enrutador de tickets | Media; es el más barato |
| Multiagente | Varios agentes se pasan trabajo | Solo cuando un agente ya se quedó corto | Alta; es el más caro |
Regla
Empiece por el flujo orquestado. El multiagente se justifica después, con datos, nunca antes.
Bloque 4 · nube contra propio
Cuatro stacks, una cuenta completa
| Stack | Qué incluye | Encaje .NET | Dónde quedan los datos | Qué se paga | Cuándo tiene sentido |
|---|---|---|---|---|---|
| A · Nube comercial todo incluido | Azure AI Foundry Agent Service, OpenAI Agents/Responses API, Google Vertex AI Agent Builder y Amazon Bedrock Agents. | Alto con Azure | Nube del proveedor; con contrato empresarial no entrenan | Tokens más cargos de servicio | Volumen bajo o medio y nadie mantiene infraestructura |
| B · Orquestador propio con modelo en nube | Semantic Kernel, LangGraph, CrewAI, AutoGen o n8n; modelo por API. | Muy alto; Semantic Kernel es nativo .NET | Solo prompts a nube; base en casa | Tokens | Control del flujo sin operar GPU |
| C · Orquestador propio con modelo local | Semantic Kernel o LangGraph con Ollama, vLLM o LM Studio y modelos abiertos. | Alto | Nada sale de la red | Hardware, energía y mantenimiento | Datos que no pueden salir o volumen alto constante |
| D · Híbrido | Modelo local pequeño para clasificar y resumir; nube grande para pasos difíciles. | Muy alto | Se enruta según sensibilidad | Fijo local más tokens selectivos | Suele ganar en costo por escenario |
Recomendación de arranque
Para Tecnimática hoy: Semantic Kernel dentro de la solución .NET, con Azure OpenAI para empezar y Ollama en un servidor de pruebas para medir qué tanto se puede mover a local.
01
Tokens de entrada = instrucciones + memoria + datos de herramientas
02
Tokens de salida = razonamiento visible + respuesta + argumentos de herramientas
03
Costo por ejecución = suma de cada paso, no solo la respuesta final
04
Costo mensual = costo por ejecución × volumen + infraestructura y operación
Calculadora interactiva
La cuenta de tokens, con sus cifras
| Configuración | Mes USD | Año USD | Mes COP |
|---|---|---|---|
| Modelo grande | US$ 24,30 | US$ 291,60 | $ 99.630 |
| Modelo mediano | US$ 5,71 | US$ 68,54 | $ 23.419 |
| Modelo pequeño | US$ 1,07 | US$ 12,85 | $ 4.391 |
| Modelo local | US$ 350,00 | US$ 4.200,00 | $ 1.435.000 |
| Híbrido · 70 % pequeño / 30 % grande | US$ 358,04 | US$ 4.296,48 | $ 1.467.963 |
Precio de referencia: verifique la tarifa vigente del proveedor. El valor local incluye el costo fijo mensual editable.
Siete palancas para bajar el costo
1
Caché de prompts: el manual y las instrucciones fijas van al inicio y se reutilizan.
2
Enrutar por dificultad: un modelo pequeño resuelve lo simple; el grande solo entra cuando hace falta.
3
Limitar pasos: presupuesto máximo de iteraciones por ejecución.
4
Resumir la memoria: no arrastrar toda la conversación.
5
Herramientas precisas: devuelven solo columnas necesarias, no la tabla entera.
6
Salidas estructuradas y cortas: JSON en vez de prosa cuando consume código.
7
Medir: registrar tokens por ejecución desde el día uno; sin métrica no hay optimización.
Bloque 5
Matriz de decisión por escenario
Puntúe de 1 a 5. El peso dice cuánto importa cada criterio; el puntaje dice qué tan bien responde cada stack. El costo se ajusta al cambiar de escenario.
Matriz de decisión
Una decisión auditable, no una preferencia
| Criterio | Peso | A · Nube comercial | B · Propio + nube | C · Propio + local | D · Híbrido |
|---|---|---|---|---|---|
| Confidencialidad de datos de clientes | |||||
| Costo mensual estimado | |||||
| Encaje con .NET y SQL Server | |||||
| Esfuerzo de puesta en marcha | |||||
| Esfuerzo de operación y mantenimiento | |||||
| Control sobre flujo y herramientas | |||||
| Calidad de respuesta del modelo | |||||
| Riesgo de dependencia del proveedor | |||||
| Total ponderado | 104 | 126 | 118 | 131 |
D · Híbrido obtiene el mayor puntaje para este escenario. Use este resultado como hipótesis y reemplácelo con volumen, restricciones y costos propios.
Encargo
Dos mediciones antes de decidir
Elegir un módulo real de ChronoSoft sin datos de cliente y repetir los cuatro pasos de I-1 con GitHub Copilot en Visual Studio, registrando tiempo y pruebas antes y después.
Elegir uno de los tres escenarios, medir durante una semana el volumen real y recalcular la matriz con datos propios.
Traer a la siguiente sesión la matriz impresa y una decisión provisional: nube, propio o híbrido, y por qué.
Cierre
No adopte una herramienta. Adopte un ciclo de evidencia y una forma de contar el costo.
El entregable no es código generado ni una arquitectura dibujada: es un módulo real con pruebas antes y después, y una decisión de stack que otra persona puede revisar.
Material