El costo de verificación es el verdadero costo de la programación con IA
Solía hacer una pregunta al elegir un modelo de IA para programar.
¿Qué modelo es lo suficientemente potente para esta tarea?
Esa pregunta está bien. Pero ya no es mi primera pregunta.
La mejor pregunta es: ¿Qué tan rápido puedo verificar el resultado?
Esta mentalidad cambia la forma en que utilizas los modelos de bajo costo. No los veas como versiones débiles de los modelos grandes. Vélos como trabajadores para tareas con rutas de verificación cortas.
Algunas tareas son baratas de revisar porque puedes ver los resultados de inmediato.
• Limpieza de README • Ejemplos de uso • Comentarios de código • Notas del changelog • Pequeños scripts de formato • Plantillas de issues
Si un modelo escribe un mal párrafo en el README, lo notarás. Borras la parte incorrecta. El error es molesto, pero no te cuesta casi nada. Este es el mejor uso para los modelos económicos.
La siguiente categoría es el trabajo que se puede probar.
Si puedes definir el comportamiento esperado y ejecutar una suite de pruebas, utiliza un modelo más económico para el primer borrador. Debes darle al modelo límites claros.
No digas: Añade pruebas para esta función auxiliar.
Di: Añade pruebas para entrada vacía, entrada nula, valores duplicados, configuración inválida, configuración por defecto y entrada normal. No cambies el código de ejecución (runtime).
Esto obliga al modelo a trabajar dentro de un marco de verificación.
Algunas tareas carecen de pruebas automatizadas pero permiten comprobaciones manuales claras.
• Formateo de la salida de la CLI • Ejemplos de configuración • Notas de ejecución de prueba (dry run) de migración • Pequeños scripts de conversión de datos
Para estas, pide al modelo que incluya:
- Cómo ejecutar el código
- Qué entrada utilizar
- Qué resultado esperar
- Qué casos límite (edge cases) comprobar
Si un modelo no puede explicar cómo verificar su propio trabajo, no confíes en el código.
Las refactorizaciones pequeñas son peligrosas. Un diff puede parecer corto y limpio. Pero el comportamiento podría cambiar en una ruta oculta, un valor por defecto o una comprobación de permisos.
Aumenta tu nivel de riesgo cuando una tarea afecte a:
- Fallbacks
- Valores por defecto
- Enrutamiento
- Permisos
- Facturación
- Rate limits
- Migraciones
- Compatibilidad con versiones anteriores
Estos errores son difíciles de ver en una revisión de código estándar. Requieren un contexto profundo.
Organiza tu trabajo según el costo de verificación:
- Bajo costo de verificación: Usa un modelo de bajo costo para el borrador.
- Costo de verificación medio: Usa un modelo de bajo costo y luego realiza ediciones humanas.
- Alto costo de verificación: Usa un modelo potente con pruebas y revisión humana.
El tamaño no importa. Una tarea pequeña es costosa si es difícil de verificar.
La parte costosa de la programación con IA no es la generación. Es la confianza.
Fuente: https://dev.to/zephyrelabs369/verification-cost-is-the-real-ai-coding-cost-1354
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi