Para equipos de ingeniería · IA en la práctica
Mida una tarea de IA hasta su aceptación
Un registro práctico del uso de modelos, las correcciones y la revisión ayuda a un equipo de ingeniería a comparar flujos de trabajo con agentes de programación e identificar lagunas en su visión de los costes.
Una tarea de programación puede consumir llamadas a modelos durante la implementación, en otro intento tras una comprobación fallida y en trabajos adicionales durante la revisión. El primer mensaje de finalización solo refleja un punto de ese recorrido. Una comparación útil sigue el trabajo hasta conocer su resultado.
Empiece por una tarea cuyo resultado alguien pueda evaluar. En un cambio ilustrativo de una API, exija un campo de entrada y pruebe valores válidos y ausentes. Acuerde las respuestas esperadas antes de comparar enfoques, manteniendo fijos los límites de la tarea y las comprobaciones de aceptación. El ejemplo siguiente no contiene cifras de rendimiento comparativo.
Figura 1 en texto
Registre el uso durante la implementación. Las comprobaciones y la revisión independiente evalúan el trabajo. Si la revisión detecta un problema, registre su corrección y la decisión humana final; una tarea que no da resultado permanece dentro del alcance de la comparación.
Siga el trabajo, incluidas las correcciones
En la práctica interna de desarrollo de Devmojos, un operador prepara un encargo acotado con el contexto pertinente y las comprobaciones de aceptación. Unas comprobaciones automatizadas examinan el encargo antes de que empiece un agente de ejecución. Este implementa el cambio asignado en una copia aislada del proyecto e informa de lo que ha cambiado y comprobado.
La revisión independiente y la verificación del operador aportan información para la aceptación. Si una comprobación o revisión detecta un problema, su corrección sigue formando parte del mismo registro de la tarea. Registre el hallazgo, el siguiente intento y el resultado final. Una tarea rechazada, detenida o abandonada también pertenece al alcance declarado de la comparación.
Esta estructura que rodea a un agente es un entorno de coordinación: las instrucciones de la tarea, las herramientas, el contexto, los traspasos y la revisión que respaldan su trabajo. Una prueba superada aporta evidencias sobre el comportamiento que ha comprobado. Las personas siguen decidiendo si el trabajo acordado es aceptable y si debe ponerse en marcha.
Figura 2 en texto
Acuerde la tarea, reúna el contexto pertinente, elija un enfoque, implemente el trabajo definido, compruebe y revise de forma independiente y, después, tome la decisión humana de aceptación. Las observaciones pueden devolver el trabajo a implementación; un resultado no aceptado puede volver a la definición de la tarea.
Cree un registro con medidas diferenciadas
Lo que sigue es una propuesta de hoja de registro para el cambio ilustrativo de la API. No es un panel de mediciones ya recopiladas por Devmojos. Deje un campo como desconocido cuando falte su fuente.
Figura 3 en texto
Lea por separado el uso de modelos, las herramientas e infraestructura, el tiempo transcurrido, la revisión y trabajo de corrección y el resultado. La hoja de registro del artículo propone un registro de costes más completo; no es un informe de todas las mediciones que se recopilan actualmente.
| Registro de la tarea | Unidad o formato | Qué incluir |
|---|---|---|
| Resultado y comprobaciones de aceptación | Estado y hallazgos registrados | Aceptada, rechazada o abandonada; las comprobaciones y la revisión que sustentan ese estado |
| Uso de modelos | Categorías de uso notificadas por el proveedor | Llamadas de implementación, corrección y revisión; identifique las categorías de caché cuando se notifiquen |
| Coste monetario | Moneda, con base de facturación o imputación | Cargos conocidos de proveedores y herramientas y coste de infraestructura imputable; señale las exclusiones |
| Tiempo transcurrido | Tiempo desde la asignación hasta el resultado declarado | Esperas, intentos y revisión, con definiciones coherentes de inicio y fin |
| Trabajo humano | Tiempo y actividad registrados | Preparación, revisión, verificación y apoyo a las correcciones |
| Trabajo de corrección | Intentos y motivos | Comprobaciones fallidas, hallazgos de revisión, continuaciones y trabajo reabierto |
Los tókenes, los minutos y los estados describen cosas distintas. Convierta los componentes monetarios utilizando una base explícita de precios o imputación antes de sumarlos y evite contabilizar el mismo cargo dos veces. Las suscripciones a planes o el hardware local requieren decidir su imputación; la falta de datos de coste no demuestra que el coste sea cero.
Cambie una parte de una tarea comparable
El contexto debe proporcionar al agente los requisitos, el código pertinente y las comprobaciones que necesita. Un encargo que omite una restricción puede generar trabajo de corrección. El material adicional debe justificar su presencia ayudando a la tarea. Anthropic, en su guía de ingeniería de contexto, aborda este problema de selección.
La elección del modelo también forma parte de la tarea. Importan la capacidad, el tiempo de respuesta, las restricciones operativas y la dificultad del trabajo. Compare los intentos resultantes y los hallazgos de la revisión junto con el uso. El uso de caché debe figurar en el registro de uso cuando esté disponible; un porcentaje de aciertos de caché por sí solo no demuestra el cambio en una factura.
Para hacer una comparación, declare qué tareas completadas y sin resultado se incluyen, qué se mantuvo comparable y qué cambió. Registre los costes excluidos o desconocidos. Si un enfoque produce un resultado utilizable pero necesita más revisión, el registro debe hacer visible ese compromiso en lugar de reducirlo a un total de tókenes.
Qué demuestra nuestra práctica interna
Nuestro informe interno de enrutamiento incluye tiempos verificados hasta la aceptación, verificaciones fallidas y trabajo de corrección. No demuestra el coste monetario completo por funcionalidad aceptada ni ahorros repetibles para clientes. La hoja de registro más completa presentada antes es una recomendación de medición. La investigación de Anthropic sobre entornos de coordinación es una lectura complementaria útil, no una evidencia de resultados de Devmojos.
Traiga una tarea recurrente de ingeniería, sus herramientas y comprobaciones de aceptación actuales y el punto en el que la revisión o las correcciones se complican. La propuesta AI Engineering de Devmojos puede empezar con una evaluación del proceso y un experimento de adopción con alcance definido, que ayude a su equipo a decidir qué conservar.