Identificar el caso de uso adecuado para Devin es clave para maximizar la eficiencia y el retorno de la inversión (ROI). A continuación, se describen las mejores prácticas para seleccionar un caso de uso que se alinee con las fortalezas de Devin.
Mejores casos de uso para Enterprise
| Criterios del caso de uso ideal |
|---|
| Proyectos grandes y de alto valor para el negocio que puedan dividirse en subtareas aisladas y repetitivas. |
| Tareas que requieran menos de 90 minutos de tiempo de ingeniería manual. |
| Tareas compatibles con versiones anteriores que puedan validarse y fusionarse de forma independiente. |
Requisitos ideales para Devin
| Requisito |
|---|
| Alto volumen de subtareas repetitivas (slices) |
| Tareas con complejidad de ingeniero junior |
| Tareas aisladas e incrementales |
| Subtareas objetivas y verificables |
| (Recomendado) Mínimas dependencias con el resto del proyecto |
Si tu tarea cumple la mayoría o la totalidad de estos requisitos, es una candidata ideal para Devin.
Diseñar el trabajo de Devin
Seleccionar el tipo de tarea adecuado es clave para maximizar la fiabilidad de Devin.
| Escenario | Consideración sobre la fiabilidad | Tipo de tarea |
|---|
| Pedir a Devin que desarrolle funcionalidades complejas completamente nuevas (aunque sean repetitivas) | Menor fiabilidad a escala | Tall & Deep |
| Asignar a Devin tareas simples y bien definidas | Muy fiable y eficaz | Wide & Shallow |
Estrecho y profundo vs. ancho y superficial
Un gran backlog de tareas simples, escalables horizontalmente (por ejemplo, resolver incidencias de SonarQube) puede generar un ROI significativo cuando se aplica a lo largo de miles de iteraciones.
Cuanto más simple sea el segmento, más fiable será el proyecto en su conjunto.
Excelentes candidatos para Devin:
- Migraciones
- Refactors
- Modernizaciones
- Backlogs de deuda técnica
Por ejemplo, al trabajar en una migración de código, debe dividirse en segmentos independientes, cada uno gestionado por una sesión individual de Devin.
Una slice debe ser la unidad atómica más pequeña del proyecto.
| Slices de ejemplo |
|---|
| Archivo |
| Notebook |
| Módulo |
| Requisito | Detalles |
|---|
| Límite de tiempo | Cada slice debe requerir menos de 90 minutos de trabajo de ingeniería manual. |
| Verificación | Debe incluir una forma de validar los cambios de código, por ejemplo: - Ejecutar pruebas - Compilar el código - Verificaciones de CI - Un script de verificación personalizado |
Devin debe tener un mecanismo de verificación de éxito o fallo claro.
Evita tareas con dependencias excesivas o sistemas externos. Devin destaca en tareas de programación.
| Requisito | Descripción |
|---|
| Aislamiento | Cada segmento debe ser independiente y compatible con versiones anteriores. |
| Ejecución en paralelo | Usa el paralelismo de Devin para ejecutar los segmentos simultáneamente. |
| Revisión humana | Después de completar cada segmento, debe pasar por una revisión humana antes de fusionarse en main. |
Consideraciones de escalado
| Principio | Descripción |
|---|
| Confiabilidad a nivel de slice | Devin está optimizado para ofrecer la máxima confiabilidad a nivel de cada slice individual. |
| Consideración de escalado | Al escalar a miles de slices, mantener una alta confiabilidad es fundamental. |
| Impacto de errores | Incluso una tasa de error pequeña puede multiplicarse cuando se ejecuta a gran escala. |
Mejores prácticas para la definición de tareas
| Requisito | Descripción |
|---|
| Detalles claros de los pasos | Proporciona instrucciones explícitas para cada subtarea. |
| Referencia de extremo a extremo | Una guía o video detallado ayuda a garantizar la consistencia. |
| Ejemplos de antes/después | Ofrece múltiples ejemplos de código de antes/después (pares de entrada/salida). |
| Acceso a dependencias | Asegúrate de que Devin tenga todas las dependencias necesarias para la tarea. |
Devin sobresale en tareas continuas relacionadas con la deuda técnica (por ejemplo, revisiones de PR, automatización de QA) cuando están correctamente segmentadas y estructuradas.
Las migraciones, modernizaciones y refactorizaciones son casos de uso sólidos si se pueden abordar de forma incremental.
Por ejemplo, una migración de todo el repositorio que requiera todos los cambios a la vez no es recomendable.
Caso de estudio: Caso de estudio de migración de Nubank