El equipo de desarrollo se encontró recientemente con un caso que no había sido documentado en ninguna parte. No figuraba en la memoria, no estaba definido en ningún skill ni había sido mapeado durante la fase de diseño. Era uno de esos escenarios de borde que, en un proyecto tradicional, suelen aparecer tres meses después del go-live y cuestan dos sprints de refactor.

Sin embargo, el agente lo resolvió solo, correctamente, y dejó un log limpio de su ejecución. Este episodio ocurrió durante el QA de uno de los últimos agentes desarrollados por el equipo. El resultado generó una mezcla de sorpresa y alegría; no por ser un milagro, sino porque la escena concentra lo que está cambiando en el oficio de desarrollar producto: un momento en el que parte del razonamiento de un sistema ya no vive en las líneas de código, sino encapsulado en redes neuronales.

‍

¿Qué es un caso de borde en el mundo real?

En cualquier sistema financiero coexisten dos capas:

1. La documentada: Aquella que vive en manuales, pantallas de SAP y políticas internas.
2. La humana: La que reside en la experiencia de quien lleva años ejecutando el proceso y sabe, por ejemplo, que una factura de cierto proveedor con retención municipal emitida después del día veinte requiere una imputación distinta.

En esa segunda capa es donde se define el éxito del proceso. Latinoamérica, en particular, se caracteriza por una heterogeneidad regulatoria aguda. Las reglas de factura electrónica cambian por combinaciones de rubro, régimen fiscal y canal de emisión. En operaciones transnacionales, el número de permutaciones supera lo que cualquier software genérico puede enumerar. Cuando un equipo de finanzas describe un proceso como "complejo", se refiere a que el mapa de casos de borde supera a la parte estándar del proceso.

‍

El aprendizaje en QA

El agente construido no hizo magia; cuenta con un harness estricto: gates de aprobación humana, observabilidad, memoria estructurada y protocolos claros. Sin embargo, existe un margen cada vez más relevante entre lo que se estructura y lo que el modelo resuelve por fuera de ella.

En este caso, el agente tomó el contexto disponible (tipo de documento, proveedor, política general) y compuso una respuesta consistente. Como sugiere un paper reciente de Shanghai Jiao Tong y Carnegie Mellon, las capacidades de un agente ya no residen exclusivamente en los pesos del modelo, sino en su combinación con el andamiaje externo (harness, memoria, skills). El trabajo del ingeniero moderno se desplaza así de entrenar modelos a diseñar mejores entornos operativos. La tesis que se desprende de esta experiencia es que el andamiaje no necesita capturar el cien por ciento del dominio, sino lo suficiente para que el modelo componga con sensatez sobre el resto.

‍

La nueva ecuación del back-office

Hace tres años, un proyecto de automatización en una empresa de mil empleados implicaba meses de consultoría y desarrollo con una inversión de siete cifras y un ROI incierto. Gran parte del conflicto nacía de la imposibilidad del cliente para recordar todos los casos de borde de su operación.

Hoy, la misma empresa puede tener un agente productivo en un plazo de ocho a doce semanas gracias a tres cambios fundamentales:

• El nuevo trabajo consultivo: El análisis de flujos ya no es input para escribir código línea por línea, sino para diseñar el harness y los skills del agente.
• El Forward Deploy Engineer (FDE): Profesionales con experiencia vertical que traducen la intuición humana y los atajos no documentados directamente a la arquitectura del agente.
• Velocidad de respuesta: Lo que antes requería esperar a un nuevo sprint, hoy se resuelve con iteraciones de minutos en QA.

‍

El valor liberado y el rigor necesario

Esta evolución desplaza la relación costo-valor, permitiendo que procesos medianos que antes no justificaban la inversión ahora sean automatizables. Para un CFO, esto significa que iniciativas antes "cajoneadas" vuelven a ser viables. Para un Product Manager, implica que el costo unitario de una nueva funcionalidad ha bajado drásticamente.

No obstante, se advierte que esto no es un argumento para relajar el diseño. El agente resolvió el caso precisamente porque el sistema estaba armado con rigor. Un detalle innegociable en este desarrollo es que toda llamada a una herramienta crítica debe llevar un rationale asociado. Este mecanismo permite reconstruir el porqué de cada acción y detectar dónde falta un skill o dónde el modelo está improvisando.

‍

Conclusión

El aprendizaje es claro: se ha producido un cambio de equilibrio que permite ejecutar tecnología con menos fricción. Las empresas que comprendan esta transición tendrán una ventaja competitiva sobre las que sigan viendo el back-office como un problema de volumen de personal o software enlatado.

En Payana, el enfoque se mantiene en bajar el costo de llegar al valor y aumentar la densidad de procesos resueltos sin sacrificar el rigor. Aquel log de QA es, en última instancia, una evidencia de que el desarrollo de producto en Latinoamérica se encamina hacia esa dirección.

‍

‍