Lo que he visto cambiar al subir de modelo
En mis pruebas, un modelo de gama alta me ha rendido mejor en trabajo largo y autónomo. Eso no significa que sea la elección adecuada para todas las tareas. Estos son los aspectos que reviso al compararlos:
- Continuidad: si mantiene el objetivo y las restricciones durante una sesión larga.
- Criterio: si distingue cuándo puede avanzar y cuándo necesita una decisión mía.
- Coordinación: si lo que encarga a otros agentes ayuda a cerrar el trabajo y no crea más trabajo repetido.
- Verificación: si comprueba el comportamiento que importa. Ejecutar tests no basta si esos tests están mal elegidos.
- Comunicación: si explica lo que hizo, lo que falta y lo que todavía no puede afirmar.
Sigo encontrando problemas de criterio al elegir pruebas, también con modelos de frontera. Por eso no tomo una lista de tests en verde como una conclusión sobre todo el proyecto.
Mi criterio es usar el modelo donde el problema lo amerita y revisar si el resultado compensa su costo. Para eso comparo el esfuerzo humano de resolver una tarea con el trabajo asistido por IA, incluyendo dirección, revisión y correcciones. Lo estoy desarrollando en las notas sobre costos y avance real.
Dos casos de mi sistema
Estos casos muestran el tipo de trabajo que estoy observando: sesiones remotas y workflows con varios agentes.
Levantar y publicar esta web desde otra PC
DelpaQQ corre en una máquina que no es la de trabajo. Con un runner remoto conectado al sistema, el modelo encontró el repo buscando en los discos de esa PC, se instaló ripgrep para buscar más rápido, levantó el servidor Node, detectó que el proxy de IIS apuntaba a un puerto equivocado, lo corrigió y dejó el certificado HTTPS emitido. Cada paso quedó registrado: qué comando corrió, qué falló y cómo lo resolvió.
Dirigir workflows de varios agentes
Para renovar el contenido de este sitio, el flujo fue auditar el texto, reescribir en paralelo por grupos de páginas, pasar un crítico que busca lo que falta y cerrar con un validador. Cada parte puede usar un modelo distinto según lo que necesite.
La coordinación también sigue cambiando. Antes usaba una pizarra compartida; ahora estoy probando mensajes después de ciertas acciones. Es una prueba en curso, no una mejora que ya dé por demostrada.
Lo que no debería depender del modelo
El modelo aporta razonamiento; los runners ejecutan con permisos y registros; y el conductor reparte el trabajo y reúne los resultados. Cambiar de modelo no debería obligarme a rehacer esos límites.
En los cambios que he hecho, la capa de ejecución se ha mantenido. Aun así, tengo que revisar el comportamiento del modelo nuevo: que pueda usar las mismas herramientas no garantiza que tome las mismas decisiones.
Prácticas que estoy priorizando
- Conocer el trabajo antes de elegir el modelo. Qué se necesita resolver, qué resultado sirve y cuánto esfuerzo tiene sentido dedicarle.
- Elegir por tarea. Probar dónde alcanza un modelo menor y dónde el más capaz aporta una diferencia que puedo comprobar.
- Medir el costo completo. Consumo, dirección humana, revisión y retrabajo frente a la alternativa de hacerlo sin IA.
- Mantener documentación viva. Dejar claras las decisiones vigentes y actualizar lo que cambió para que el siguiente agente no parta de una versión vieja.
- Usar reglas con criterio. Ser estricto con permisos y condiciones de entrega, y dejar flexibilidad para explorar cuando la tarea lo permite.
- Pedir pruebas que respondan a una pregunta. Qué fallo intentan detectar y qué parte del resultado realmente permiten dar por comprobada.
- Revisar si el uso se sostiene. Una tarea que salió bien una vez no demuestra que el flujo sea útil de forma habitual.
Un modelo más capaz puede ayudar a aclarar un proceso, pero no lo arregla por sí solo. Sigue haciendo falta definir qué se quiere conseguir, reconocer las decisiones que corresponden al negocio y comprobar que el resultado sirve.
Con qué criterio lo estoy eligiendo
En mis pruebas, el modelo más capaz aporta en trabajo largo y autónomo. La decisión es entender dónde lo necesita el negocio, medir el avance real y convertirlo en una herramienta que se pueda sostener. Si el proceso o las reglas siguen confusos, subir de modelo no resuelve esa parte por sí solo.