5 publicaciones etiquetados con "Engineering Leadership"

Imagina un equipo de finanzas esperando un espacio para gestionar reclamaciones de facturas: una cola, documentos justificativos, reglas de asignación y conexión con el sistema contable. En este escenario ilustrativo, la funcionalidad antes consumía semanas de capacidad de desarrollo. Ahora una persona de ingeniería coordina agentes que generan la estructura de implementación, pruebas y configuración de despliegue en horas, utilizando componentes y contratos establecidos.

No es una publicación en producción sin supervisión. Esa misma tarde, ingeniería y los responsables del dominio ya han revisado el comportamiento, validado los supuestos de integración y aprobado y publicado un piloto acotado en producción. Pero el cambio económico es claro: crear una versión creíble de una funcionalidad conocida exige mucho menos esfuerzo de implementación. Un competidor con herramientas similares puede hacer lo mismo.

La pregunta difícil ya no es si alguien puede crear la cola y sus botones. Es si ese espacio ayuda a resolver las reclamaciones que bloquean dinero, decisiones y relaciones con clientes. Cuando construir deja de ser la ventaja competitiva, ¿qué la sustituye?

Imagina a un ingeniero revisando un pull request generado por un agente. Modifica el cliente de pagos, la configuración de reintentos, las pruebas y la documentación del despliegue. El ingeniero aprendió a trabajar de otra forma: seguir la solicitud fallida en los registros, reproducir el problema, editar cada archivo y ganar confianza paso a paso, de manera deliberada. Ahora la solución propuesta ya está en la pantalla.

La primera reacción no es necesariamente entusiasmo ni desconfianza. Puede ser simplemente: "Así no es como yo solía hacer esta tarea". En esta escena ilustrativa, la incomodidad no tiene que ver con si el ingeniero sabe leer el código. Tiene que ver con no haber vivido la experiencia de construirlo. Se ha acortado una ruta conocida hacia la comprensión, pero comprender sigue siendo necesario.

Esa tensión va mucho más allá del software. Cuando una herramienta produce el trabajo que antes demostraba nuestra experiencia, tenemos que separar el método de la responsabilidad. El cambio útil no es "hazlo todo tú mismo" ni "deja que el agente se encargue de todo". Es un principio más exigente y duradero: aprovecha la capacidad que te ofrece, hazte cargo de la verificación.

Por qué el próximo capítulo de FinOps no consiste en encontrar un modelo más barato. Se trata de diseñar sistemas que no desperdicien los tokens que ya tienen.

Un líder financiero abre la factura mensual de la plataforma de IA de la empresa y encuentra un número que no coincide con ninguna historia que alguien pueda contar. El uso creció de forma moderada. La factura creció de forma marcada. Nadie cambió a un modelo más caro. Nadie aprobó una nueva integración que alguien recuerde. La partida simplemente creció por sí sola, de la misma manera en que solían crecer las facturas de la nube antes de que alguien construyera una disciplina para vigilarlas.

Pregúntale al equipo de ingeniería qué pasó y la respuesta rara vez tiene una sola causa. Son cien pequeñas decisiones: un prompt de sistema que creció cada vez que alguien añadió una nueva regla, un paso de recuperación que trae diez documentos cuando dos bastarían, un agente que reintenta una llamada a una herramienta fallida cinco veces antes de rendirse, un flujo de trabajo que pasa una conversación entre tres agentes especializados y reenvía todo el historial en cada traspaso. Ninguna de estas decisiones parecía costosa por separado. Juntas, son la factura.

El cuello de botella se movió y la mayoría de los equipos no lo ha notado​

Durante décadas, escribir código fue la parte cara. Leerlo era casi gratis en comparación. Un desarrollador pasaba horas produciendo un cambio y un revisor pasaba minutos confirmándolo. Esa proporción dio forma a todo: nuestras herramientas, nuestros procesos y nuestra idea de quién estaba ocupado y quién esperaba.

Los agentes invirtieron esa proporción. Un agente capaz ahora produce una rama completa con código, pruebas y documentación en el tiempo que toma escribir una buena descripción de la tarea. Escribir se volvió barato. Leer no.

Cuando las Métricas Tradicionales Dejan de Funcionar​

El desarrollo asistido por IA ya no es un experimento. Es parte del trabajo diario de ingeniería en organizaciones de todos los tamaños. Las herramientas impulsadas por modelos de lenguaje grandes generan código, proponen refactorizaciones, escriben pruebas, resumen pull requests y coordinan tareas de ingeniería de múltiples pasos.

Esto crea un desafío fascinante e incómodo: la productividad claramente está mejorando, pero se ha vuelto mucho más difícil medirla con precisión.