Por Thomas Cohen, fundador de Maestro
Beta de Maestro: solicitar acceso y preparar tu primer proyecto
Cómo solicitar una invitación, preparar tu acceso a la IA y elegir una primera prueba útil. Una guía para descubrir Maestro en Mac con un objetivo claro y expectativas realistas.
La beta de Maestro permite descubrir otra forma de crear una aplicación: describes lo que necesitas, un equipo de agentes de IA prepara y realiza el trabajo, y después examinas los resultados. Para aprovecharla, conviene empezar con una pregunta pequeña. «¿Entiendo el brief de mi proyecto y puedo corregirlo?» ya constituye una primera prueba valiosa.
El acceso es por invitación, para macOS 13 o una versión posterior. Maestro es gratuito durante la beta; el uso de la IA depende de tu proveedor y puede facturarse aparte. Las invitaciones llegan por grupos. Esta guía explica qué preparar antes del acceso, qué observar durante la exploración y cómo enviar comentarios que permitan actuar.
Seguiremos un ejemplo ficticio: Camille repara bicicletas. Quiere encontrar las reparaciones pendientes y las piezas que faltan sin revisar varias notas. Su taller, sus clientes y las situaciones siguientes son inventados. Sirven para mostrar cómo probar Maestro sin confiar inmediatamente tu actividad a una aplicación todavía en construcción.
1. Solicitar una invitación y entender qué significa
El formulario de acceso a la beta está en la página de inicio. Indica una dirección que consultes, tu sistema operativo y el idioma preferido para los correos. La inscripción permite solicitar acceso y recibir un aviso cuando se abra tu grupo. No inicia una descarga pública ni una activación inmediata.
No se ha anunciado un plazo garantizado para recibir la invitación. Puedes aprovechar la espera para preparar tu caso de prueba; no hace falta aplazar toda la reflexión hasta obtener acceso. Conserva la dirección utilizada para encontrar la información que recibas. Las instrucciones de tu invitación son la referencia para instalar tu versión.
Una beta es un periodo en el que el producto sigue evolucionando con los comentarios de quienes lo utilizan. Puedes encontrar fallos, expresiones poco claras o comportamientos que cambian entre versiones. Considera tu primer proyecto una prueba delimitada, con una copia de trabajo y datos inventados.
2. Preparar tu Mac y un espacio de prueba
Comprueba la versión de macOS en la información de tu ordenador. Si utilizas Windows, inscribirte puede servir para recibir avisos, pero no hace compatible la beta actual. No prepares una prueba que dependa de un sistema todavía no disponible. En un Mac profesional, comprueba también las normas de instalación de tu organización.
Elige un proyecto cuyo trabajo y resultados esperados comprendas. Camille conoce la diferencia entre una bicicleta que espera una pieza y otra lista para entregar; por eso podrá detectar una confusión. Un tema completamente nuevo te obligaría a aprender a la vez el oficio, el método y la herramienta.
Prepara tres o cuatro ejemplos ficticios: una reparación por empezar, otra bloqueada y otra terminada. Utiliza nombres claramente inventados. Estos ejemplos serán tu pequeño conjunto de datos de prueba, reutilizado después de cada cambio. Podrás comparar versiones sin preguntarte si las diferencias proceden de los datos o del trabajo realizado.
Prepara también una nota personal con tu objetivo, tus preguntas y el resultado de cada prueba. Conserva los documentos importantes fuera de tu único proyecto de exploración. Una copia separada ayuda a recuperar las observaciones si la aplicación presenta un problema. No sustituye una estrategia de copias de seguridad para un futuro uso profesional.
3. Distinguir Maestro, el asistente de IA y el modelo
Maestro organiza el trabajo y las validaciones. El asistente de IA es el servicio al que confías las tareas. El modelo es el motor que utiliza ese asistente para comprender las peticiones y producir respuestas. Estos tres niveles no tienen necesariamente la misma cuenta, configuración o facturación.
Los asistentes anunciados como compatibles son Claude Code, Codex, Cursor y Mistral Vibe. Para empezar, elige un acceso que ya comprendas o dedica tiempo a comprobar sus condiciones. Tener una cuenta con un proveedor no significa que todos sus productos y usos estén incluidos en tu plan.
Localiza dónde consultar el consumo, cómo volver a conectarte y qué límites se aplican. Sigue las indicaciones de conexión de tu versión de Maestro y las instrucciones del proveedor. No necesitas comparar todos los modelos antes de la primera sesión. Basta con saber explicar qué servicio trabaja y quién factura su uso.
Nunca incluyas una contraseña o clave de acceso en la descripción del proyecto, una captura pública o un mensaje de comentarios. Utiliza el proceso de conexión previsto. Si no sabes si una información es un identificador público o un secreto, pide una explicación antes de compartirla.
Preparar un límite de gasto sencillo
Elige un gasto máximo para tu exploración y un momento para revisar el consumo. Ese presupuesto personal no es un precio recomendado ni una estimación del coste de una aplicación completa. Sirve para evitar que continúes una serie de pruebas sin observar lo que consumen.
Separa el coste de tu acceso a la IA, los posibles usos facturados aparte y los futuros gastos de funcionamiento de la aplicación. El alojamiento, un dominio o un servicio de correo pueden resultar necesarios más adelante. No están incluidos automáticamente porque hayas conseguido abrir una primera pantalla en Maestro.
4. Elegir un primer resultado suficientemente pequeño
Camille podría pedir toda la gestión del taller: citas, presupuestos, existencias, facturas, pagos y mensajes a clientes. Después tendría muchas cosas que revisar sin saber cuál comprobar primero. Para descubrir la beta, conserva una pregunta: ¿puede describir y después encontrar la próxima reparación que debe hacer?
Su primer recorrido consiste en añadir una reparación ficticia, asignarle un estado y encontrarla en una lista. El resultado esperado cabe en una frase: «Veo la bicicleta que debo preparar hoy y distingo la que espera una pieza». Los pagos, las notificaciones y el uso compartido con un compañero quedan fuera de esta prueba.
Esta reducción facilita los comentarios. Si el estado mostrado es incorrecto, Camille puede señalar una regla concreta que corregir. Si pide toda su empresa de una vez, quizá solo consiga responder «no es lo que quería». Un alcance pequeño hace más útil la conversación y más fácil examinar el siguiente cambio.
También puedes dedicar la primera sesión a definir el proyecto, sin intentar construir inmediatamente. Una descripción correcta del problema y un brief que sepas corregir son resultados útiles. Decide al principio qué quieres aprender; no añadas un objetivo nuevo con cada propuesta de la IA.
5. Explicar tu necesidad y revisar el brief propuesto
Camille podría preparar esta petición: «Reparo bicicletas en un pequeño taller. Hoy anoto los trabajos y las piezas que faltan en varios sitios. Quiero encontrar las reparaciones pendientes y distinguir las que esperan una pieza. En la primera prueba soy la única usuaria y todos los datos son ficticios».
Añade un límite: «Todavía no quiero gestionar facturas ni avisar a clientes. Empieza por reformular la necesidad y los puntos que debo decidir». Ese texto da una dirección sin imponer una tecnología. La guía para describir tu idea a una IA ofrece una versión todavía más breve que puedes adaptar.
En Maestro, Margaux interviene en la definición inicial para transformar la idea en un brief. Este documento describe, entre otros aspectos, el problema, las personas implicadas, el valor esperado y los riesgos. Revisa lo que afirma sobre tu actividad. Una frase fluida puede contener una suposición que nunca has validado.
Para Camille, «toda bicicleta pendiente debe repararse hoy» sería falso. Algunas esperan una entrega. Una corrección útil sería: «Separa las reparaciones que pueden avanzar de las que esperan una pieza; no les asignes automáticamente una fecha límite». Comprueba después que la corrección aparece en el documento, sin conformarte con un acuerdo en la conversación.
6. Entender qué muestra la demostración Tablée
Tablée es el ejemplo integrado para descubrir cómo se organiza Maestro. Su recorrido está preparado y su vista previa es una maqueta interactiva sin guardado. Ayuda a comprender las distintas perspectivas sobre un proyecto; no demuestra que tu propia aplicación ya funcione.
Utiliza la visita para localizar qué tendrás que revisar, dónde aparecen las tareas y cómo se presenta una vista previa. Las pantallas Tablée de las capturas del Journal muestran el mismo ejemplo. No representan el taller ficticio de Camille ni constituyen el testimonio de un cliente.
Cuando pases a tu proyecto, recupera tu propia lista de comprobaciones. Una pantalla preparada para una visita y una aplicación construida a partir de tu necesidad tienen propósitos distintos. La visita de Maestro permite descubrir el enfoque general antes de la invitación; los resultados de tu prueba deben observarse por separado.
7. Probar un recorrido y anotar lo ocurrido
Prepara el escenario antes de hacer clic. Para Camille: crear «Bicicleta ejemplo A», asignarle «Pendiente de pieza», cerrar y volver a abrir el recorrido, y encontrar el mismo estado. Anota el resultado observado aunque no coincida con lo esperado. Es información de trabajo, no un fracaso personal.
Prueba después una pequeña variación: una reparación sin descripción, un cambio de estado o un nombre bastante largo. Comprueba si la aplicación explica qué falta y si la información sigue siendo comprensible. Estas pruebas no sustituyen una revisión técnica; sirven para comprobar el comportamiento solicitado.
- Inicio: los datos ficticios y la pantalla donde comienza la prueba.
- Acción: lo que haces, en orden.
- Resultado esperado: lo que debería aparecer o conservarse.
- Resultado observado: lo que ocurrió realmente.
- Decisión: continuar, pedir una corrección o suspender la prueba.
Después de una corrección, repite el primer escenario con los mismos datos. Un resultado nuevo no demuestra que el anterior siga funcionando. Si una parte no se puede verificar, indícalo claramente. La guía de riesgos del desarrollo con IA explica cómo ampliar estos controles antes del uso real.
8. Enviar comentarios que ayuden a corregir
Un comentario útil empieza por lo que intentabas hacer. «Quiero cambiar el estado de una reparación» aporta más contexto que «el botón no funciona». Añade la versión de Maestro, la de macOS y el asistente utilizado cuando sean pertinentes. No inventes una causa técnica; describe el síntoma.
Camille podría escribir: «Con tres reparaciones ficticias, abro Bicicleta ejemplo A, elijo Terminada y vuelvo a la lista. Espero leer Terminada. La lista sigue mostrando En curso. La misma prueba da este resultado dos veces». Así, quien lo recibe tiene un punto de partida para investigar y reproducir el problema.
Adjunta una captura solo si aporta información, después de ocultar datos privados, cuentas y secretos. Un mensaje de error exacto suele ayudar más que una interpretación larga. Utiliza el canal indicado en tu invitación o en la versión del producto; esta guía no promete un plazo de respuesta concreto.
Distingue un fallo de una sugerencia. «El estado no se conserva» se refiere al comportamiento esperado. «Me gustaría ordenar por fecha» añade una necesidad. Separarlos evita confundir una corrección necesaria con una mejora que debe debatirse. Anota también las expresiones que te ayudaron a entender: los comentarios positivos concretos también son útiles.
9. Decidir cómo continuar después de explorar
Al terminar la prueba, recupera el objetivo inicial. ¿Has entendido el brief? ¿Puedes explicar qué se ha construido? ¿Has comprobado el pequeño recorrido elegido? Si respondes que no, aclara ese punto antes de ampliar el proyecto. La cantidad de pantallas producidas no mide por sí sola la utilidad de la sesión.
Conserva una nota breve: qué funciona, qué bloquea, qué desconoces todavía y cuál es tu próxima decisión. Camille podría profundizar en los estados de una reparación antes de añadir existencias. También podría descubrir que basta una lista compartida. La prueba debe ayudar a decidir, incluso cuando la decisión sea no construir más.
Antes de confiar datos reales o una actividad diaria a la aplicación, prepara los accesos, las copias de seguridad, el mantenimiento y las condiciones de uso. Guardar el proyecto en tu Mac no significa que la IA funcione sin conexión; los asistentes configurados pueden recibir contexto. Las explicaciones sobre tus datos detallan esta diferencia.
Para continuar, la guía completa para crear sin saber programar sigue el proceso hasta el primer uso real. Para empezar a descubrir Maestro, prepara una necesidad, tres ejemplos ficticios y algo que comprobar, y después solicita tu invitación. Tendrás un punto de partida concreto cuando se abra tu acceso.