¿Qué modelo debe dirigir tus ediciones en Object Pascal?
Arraydeck no incluye un cerebro fijo. Conecta un proveedor de IA en la nube mediante un endpoint API estándar, ejecuta un modelo en tu PC o usa el modelo integrado, y cambia la opción cuando una tarea lo requiera.
Tres formas de conectar un modelo
Un proveedor de IA en la nube
Un proveedor de IA en la nube se accede mediante un endpoint API estándar que ingresas en la app, junto con tu clave API. Es ideal para unidades grandes, refactorizaciones extensas y tareas donde un modelo mayor razona mejor. La consecuencia de privacidad es clara: el prompt se envía al proveedor, incluido el texto de cualquier archivo que lea el agente, y se maneja bajo los términos de ese proveedor. Tu clave API permanece en tu PC, y los secretos en la salida de las herramientas se enmascaran antes de llegar al modelo. La facturación del servicio del proveedor es entre tú y el proveedor.
Un modelo ejecutándose localmente en tu PC
Un modelo que se ejecuta localmente en tu PC responde a las solicitudes desde tu propia máquina. Es ideal para código privado, ediciones pequeñas rápidas y trabajo donde nada debe salir de la computadora. Con un modelo local, nada sale del equipo, y los chats, carpetas de trabajo y claves API permanecen en el PC. La limitación es el hardware. Un modelo local pequeño tiene una ventana de contexto menor y puede requerir unidades más cortas o instrucciones más claras, así que lee cada diff con mayor cuidado.
El modelo integrado
El modelo integrado está listo para usar sin necesidad de un endpoint propio. Úsalo cuando quieras probar Arraydeck en un primer proyecto, leer una unidad o solicitar un cambio pequeño. La calidad varía según la tarea, como en cualquier modelo, así que revisa el diff antes de aceptarlo, ejecuta tu comando de compilación y mantén Ask first activado. Puedes conectar un proveedor en la nube o un modelo local más tarde en la misma configuración.
Qué indica el botón Probar
Presiona Probar después de ingresar un endpoint, una clave o un nombre de modelo. El botón verifica el endpoint y muestra el tiempo de respuesta y la ventana de contexto. El tiempo de respuesta indica cuánto tarda una respuesta desde esta conexión, lo cual ayuda al comparar dos modelos en la misma tarea. La ventana de contexto muestra cuánta texto puede procesar el modelo a la vez, lo cual es importante para una unidad larga con muchos procedimientos. Un error en la prueba suele significar una dirección o clave incorrecta, así que corrige la configuración antes de iniciar una tarea.
Elegir un modelo para la tarea
Usa un modelo mayor para refactorizaciones, unidades largas y lógica compleja, y uno menor para ediciones pequeñas como agregar try ... finally o renombrar un procedimiento. Puedes mezclarlos en un chat. run_on_model envía un paso único y complejo a un modelo mayor mientras el resto del trabajo permanece en el modelo que elegiste, y task inicia sub-agentes cuando partes del trabajo pueden ejecutarse en paralelo. Adapta el modelo al paso y verifica la ventana de contexto con el botón Probar antes de pegar una unidad grande.
La calidad varía entre modelos y tareas, y ningún modelo acierta en todas. Lee cada diff, compila el proyecto y ejecuta tus pruebas antes de aceptar un cambio. Ask first pausa antes de acciones que modifican algo, así que una respuesta débil de cualquier modelo solo te costará unos segundos de lectura en lugar de una unidad rota. Rechaza el diff y reformula la solicitud si no es adecuada.
