Saltar al contenido principal
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.
EscenarioConsideración sobre la fiabilidadTipo de tarea
Pedir a Devin que desarrolle funcionalidades complejas completamente nuevas (aunque sean repetitivas)Menor fiabilidad a escalaTall & Deep
Asignar a Devin tareas simples y bien definidasMuy fiable y eficazWide & Shallow

Estrecho y profundo vs. ancho y superficial

Comparación entre estrecho-profundo y superficial-amplio
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. Diagrama de cambios horizontales
Cuanto más simple sea el segmento, más fiable será el proyecto en su conjunto.

Qué dividir

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. Slicing use cases illustration

Verificación

Una slice debe ser la unidad atómica más pequeña del proyecto.
Slices de ejemplo
Archivo
Notebook
Módulo
RequisitoDetalles
Límite de tiempoCada slice debe requerir menos de 90 minutos de trabajo de ingeniería manual.
VerificaciónDebe 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.
Diagrama de retrocompatibilidad

Ejecución en paralelo

RequisitoDescripción
AislamientoCada segmento debe ser independiente y compatible con versiones anteriores.
Ejecución en paraleloUsa el paralelismo de Devin para ejecutar los segmentos simultáneamente.
Revisión humanaDespués de completar cada segmento, debe pasar por una revisión humana antes de fusionarse en main.
Visualización de ejecución en paralelo

Consideraciones de escalado

Diagrama general del modelo
PrincipioDescripción
Confiabilidad a nivel de sliceDevin está optimizado para ofrecer la máxima confiabilidad a nivel de cada slice individual.
Consideración de escaladoAl escalar a miles de slices, mantener una alta confiabilidad es fundamental.
Impacto de erroresIncluso una tasa de error pequeña puede multiplicarse cuando se ejecuta a gran escala.

Mejores prácticas para la definición de tareas

RequisitoDescripción
Detalles claros de los pasosProporciona instrucciones explícitas para cada subtarea.
Referencia de extremo a extremoUna guía o video detallado ayuda a garantizar la consistencia.
Ejemplos de antes/despuésOfrece múltiples ejemplos de código de antes/después (pares de entrada/salida).
Acceso a dependenciasAsegú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