Cómo elegir un asistente y un modelo de IA en Maestro

Distingue asistentes, modelos y agentes, compara dos opciones con una tarea pequeña y prepara un cambio sin perder las decisiones del proyecto.

Abres Maestro y aparecen varios nombres: el de un agente, el de un asistente y el de un modelo. Es tentador buscar enseguida el mejor. Sin embargo, esas tres elecciones responden a preguntas distintas. Entenderlas te permite empezar con un acceso que ya tienes y cambiar de modelo después por una razón concreta.

Imaginemos un ejemplo ficticio: Léa dirige un pequeño taller de reparación. Quiere crear una aplicación para seguir los objetos recibidos, los presupuestos y las recogidas. No necesita comparar toda la industria de la IA. Quiere saber qué opción le permitirá definir una regla, construir una pantalla y comprobar el resultado sin perder el hilo.

Agente, asistente y modelo: tres funciones diferentes

En Maestro, el agente representa una función dentro del trabajo: aclarar la necesidad, definir el producto, diseñar pantallas, desarrollar o verificar. Esa función aporta una misión y un marco. Cuando Léa comenta qué información necesita para recibir un objeto, está definiendo requisitos, aunque el modelo también pueda escribir código.

El asistente es el programa que realiza el trabajo con la IA. Claude Code, Codex, Cursor y Mistral Vibe son los cuatro asistentes anunciados públicamente como compatibles con Maestro. El modelo es el motor de razonamiento y generación que utiliza el asistente. Un mismo asistente puede ofrecer varios modelos.

Esta diferencia evita una confusión habitual: los nueve agentes de Maestro no equivalen a nueve suscripciones distintas. Son funciones organizadas dentro del producto. Las condiciones de consumo dependen del asistente, la cuenta y el plan utilizados. Asignar una tarea a otra función no implica cambiar automáticamente de proveedor.

Qué comprobar en los cuatro asistentes

Ser compatible con Maestro no significa que todas las funciones de un asistente se reproduzcan dentro de Maestro. Una herramienta también puede existir como editor, extensión, aplicación o servicio en línea. Para tu proyecto, comprueba la cuenta conectada y las opciones disponibles en tu versión de Maestro.

Claude Code y Codex

Claude Code ofrece familias de modelos y versiones cuyo acceso puede variar. Su documentación sobre modelos distingue nombres de familia y versiones concretas. Anota la opción mostrada durante una prueba: el nombre de una familia no identifica permanentemente una versión.

Codex permite conectarse con ChatGPT o mediante una clave API, con condiciones de facturación diferentes, según su documentación de acceso. Identifica la conexión activa antes de comparar el consumo. Tener una suscripción no demuestra por sí solo que la sesión la esté utilizando.

Cursor y Mistral Vibe

Cursor también ofrece un asistente de línea de comandos que trabaja con archivos. Esto ayuda a entender por qué Maestro puede utilizar Cursor sin obligarte a trabajar en su editor. No significa que todas las funciones del editor Cursor se conviertan en funciones de Maestro.

La configuración de Mistral Vibe permite elegir un modelo y puede incluir ajustes administrados por una organización. Una opción ausente o no disponible no implica necesariamente un fallo del proyecto. Comprueba primero el acceso de la cuenta y la configuración permitida.

Estas referencias explican diferencias de funcionamiento, no una clasificación de calidad. Ninguna marca garantiza que una regla de negocio sea correcta. Para Léa, la prueba útil será un objeto registrado correctamente, un presupuesto calculado como corresponde y una recogida que conserve el historial.

Empieza por una cuenta a la que ya tengas acceso

La primera elección razonable suele ser el asistente que ya puedes utilizar en condiciones adecuadas. Comprueba la conexión, los modelos disponibles, las reglas de tu organización y la facturación antes de contratar otra suscripción. Cambiar tiene sentido si resuelve una dificultad observada o permite una prueba útil.

En nuestro ejemplo, Léa dispone de una cuenta autorizada para el proyecto. Empieza con una descripción que no contiene datos reales de clientes. Así comprueba que el asistente responde, entiende la petición y entrega algo que puede revisar. Deja los datos reales para una fase preparada expresamente.

• Comprueba la identidad de la cuenta conectada y, si corresponde, la organización seleccionada.
• Identifica si el uso consume una suscripción, créditos o facturación API.
• Confirma que el modelo deseado está disponible para esa cuenta.
• Decide qué información autorizas a transmitir en la primera prueba.

Guardar el proyecto en tu ordenador e intercambiar información con el proveedor de IA son asuntos distintos. Trabajar localmente con Maestro no hace que el razonamiento del asistente se ejecute automáticamente sin conexión. Si tienes requisitos especiales de confidencialidad, revisa el recorrido de los datos y las condiciones del proveedor antes de probarlo.

Elige en función de una tarea concreta

«Construir mi aplicación» es una petición demasiado amplia para comparar modelos. Separa lo que necesitas ahora: reformular un requisito, analizar una regla compleja, modificar una pantalla o investigar un fallo. Después podrás valorar la respuesta con criterios observables.

En el taller ficticio, reformular «tu objeto está listo» es un pequeño cambio. Definir qué ocurre cuando se modifica un presupuesto aceptado implica varias reglas. Corregir un cálculo utilizado en varias pantallas requiere otro trabajo diferente. No necesitas aplicar a ciegas la misma preferencia de modelo a las tres tareas.

Antes de elegir, describe la tarea en pocas palabras: un pequeño cambio, un documento que revisar o una modificación que afecta a varias reglas. Esta clasificación te da una razón para comparar opciones. No es una prueba de calidad del modelo ni una promesa sobre el precio final de la petición.

Un modelo más capaz puede ayudar cuando hay que conciliar varias restricciones. No sustituye una necesidad bien explicada. Si Léa olvida indicar que un presupuesto aceptado debe seguir disponible después de una modificación, ningún ajuste convierte esa intención no expresada en una regla conocida.

Selección automática o modelo fijo: cuándo elegir

Comprueba las opciones que ofrecen tu versión de Maestro y el asistente conectado. Si hay un modo automático, evita elegir un motor antes de cada petición. Si puedes fijar un modelo, elige uno al que tu cuenta tenga acceso. Su disponibilidad puede cambiar.

Cuando está disponible, el modo automático puede servir como punto de partida para descubrir el producto. Un modelo identificado es más útil para comparar resultados. Anota su nombre, la fecha y los ajustes visibles que puedan influir en el trabajo. Tendrás una referencia si el comportamiento cambia.

Evita cambiar al mismo tiempo el modelo, la petición y los documentos aportados. Si la respuesta mejora, no sabrás qué produjo la mejora. Empieza aclarando la petición. Después cambia un solo elemento cuando quieras entender su efecto.

Compara dos opciones con un ejercicio pequeño

Prepara un ejercicio lo bastante pequeño para comprobar todas las respuestas. En el taller de Léa, trata sobre recoger un objeto: el cliente presenta su número de referencia, debe comprobarse el pago pendiente y hay que conservar la fecha de recogida. El ejercicio utiliza nombres y datos inventados.

Antes de iniciar las dos pruebas, escribe el resultado esperado como una serie de comprobaciones. El objetivo no es preferir el texto más convincente. Se trata de observar qué opción respeta las mismas restricciones, detecta la información que falta y evita cambios innecesarios en el resto del funcionamiento.

• Proporciona la misma necesidad, los mismos documentos y el mismo estado inicial.
• Solicita el mismo resultado, por ejemplo una regla detallada y los casos que verificar.
• Limita el ejercicio a un alcance que puedas revisar por completo.
• Guarda cada resultado antes de probar la otra opción.
• Anota las preguntas útiles, los errores y las correcciones necesarias.

Un resultado esperado, no una impresión

Léa espera que el objeto solo se marque como recogido después de las comprobaciones acordadas. Quiere conservar el registro del importe pendiente y saber cómo corregir una recogida anotada por error. Si una propuesta omite ese último caso, lo registra como una carencia, aunque el texto parezca muy profesional.

Si la prueba modifica código, utiliza copias separadas del mismo estado o pide a una persona competente que prepare esa separación. Dos asistentes trabajando simultáneamente en los mismos archivos dificultarían la comparación. Para una primera prueba, comparar propuestas escritas evita ese problema.

Mide el trabajo que te queda por hacer

El tiempo de respuesta se ve enseguida. El tiempo necesario para conseguir un resultado correcto es menos evidente. Cuenta las aclaraciones, las correcciones y las comprobaciones. Una respuesta rápida que exige tres revisiones puede resultar menos práctica que una propuesta más lenta aprovechable después de una lectura breve.

Tomemos una comparación totalmente ficticia: la opción A entrega una propuesta en dos minutos y necesita diez minutos de corrección. La opción B tarda cinco minutos y necesita cuatro de corrección. A responde antes; B requiere nueve minutos en total frente a doce. El ejemplo explica un método de medición, no el rendimiento de dos productos.

Añade el resultado de las comprobaciones y el consumo realmente disponible en tus registros. No conviertas una medida desconocida en cero. Si no puedes comparar costes sobre la misma base, escribe «no comparable» y explica por qué. Nuestra guía para entender el consumo de IA detalla cómo leer esas cifras.

Un ejercicio pequeño no basta para elegir el mejor modelo para todo un proyecto. Sí permite justificar una decisión limitada: mantener una opción para aclarar reglas, probar otra en una corrección compleja y revisar la elección si cambian los resultados.

Cambia de modelo por una razón identificable

Cambiar resulta útil cuando puedes nombrar la dificultad: se olvidan las mismas restricciones pese a una petición clara, el modelo no puede tratar los elementos necesarios o el tiempo y el consumo parecen inadecuados. Comprueba primero que la necesidad y el resultado esperado sean suficientemente precisos.

Cambiar después de cada respuesta decepcionante puede ocultar el verdadero problema. Si tres modelos proponen tres organizaciones distintas para una pantalla, quizá Léa necesita decidir qué acción importa más a su equipo. Mientras esa prioridad falte en el encargo, cambiar multiplicará las variantes sin resolver la decisión.

Tampoco insistas indefinidamente cuando una prueba deja de avanzar. Guarda la última versión correcta, describe el fallo y prepara un relevo breve con otra opción. Fija una pregunta concreta: por ejemplo, por qué una recogida anulada sigue apareciendo en las estadísticas.

Prepara la continuidad antes de cambiar

Elegir otro modelo no debería borrar las decisiones del proyecto. Antes del cambio, reúne la necesidad, las reglas aprobadas, la última versión utilizable, las comprobaciones realizadas y el problema pendiente. Esos elementos son más fiables que suponer que el siguiente asistente sabrá todo automáticamente.

Cambiar de modelo dentro de un asistente y cambiar de asistente son operaciones distintas. El nuevo programa puede no recibir las mismas conversaciones, permisos o servicios conectados. Comprueba qué recibe realmente. Los archivos del proyecto pueden seguir disponibles sin que se transfiera todo el historial de razonamiento.

• Objetivo: permitir la recogida después de comprobar el pago pendiente.
• Decisión aprobada: conservar los presupuestos anteriores y la fecha de recogida.
• Estado actual: la pantalla funciona con los datos ficticios previstos.
• Problema pendiente: anular una recogida no corrige las estadísticas.
• Próxima acción: explicar la causa antes de proponer una modificación concreta.

Esta ficha ficticia ocupa pocas líneas, pero conserva el sentido del trabajo. Pide a la nueva opción que reformule la próxima acción y lo que debe mantenerse. Revisa esa reformulación antes de una modificación importante. Puede revelar un malentendido antes de que se convierta en un cambio de código.

Si falta un modelo o deja de responder

Una opción no disponible puede tener varias causas: conexión caducada, acceso distinto según la cuenta, versión del asistente, ajustes de la organización o incidencia del proveedor. Empieza anotando el mensaje exacto y comprobando la cuenta. Evita modificar el proyecto para corregir un problema de acceso al servicio.

Si una lista parece antigua, comprueba las actualizaciones disponibles y la documentación del asistente. Un nombre en un selector no garantiza acceso ilimitado. La ejecución y el mensaje recibido aportan información adicional. Anota la fecha del problema para que una solicitud de ayuda sea más fácil de investigar.

Mientras tanto, puedes realizar tareas útiles: revisar reglas, preparar datos de prueba o examinar una captura. Si utilizas otra opción, mantén el mismo proceso de relevo. La urgencia no elimina la necesidad de saber qué cuenta trabaja, qué información recibe y cómo se factura el uso.

Una decisión sencilla para tu próxima prueba

No necesitas una clasificación universal para avanzar. Elige un asistente accesible, comprueba su cuenta, prepara una tarea pequeña y define cómo sabrás que se ha resuelto. Empieza con un ajuste disponible que puedas identificar y observa el resultado y las revisiones necesarias.

Para preparar la primera tarea, utiliza la guía de requisitos sin tecnicismos. Para organizar el proyecto completo, la guía para crear una aplicación sin saber programar explica cómo pasar de una idea a una versión que puedes probar y verificar.

Maestro está disponible en beta por invitación para Mac, a partir de macOS 13. La aplicación es gratuita durante la beta y el uso de IA se paga por separado; Windows está en desarrollo. Puedes descubrir el proceso y solicitar una invitación con una necesidad concreta. La elección del modelo servirá a esa necesidad, tarea a tarea.

Volver al índice