Son las 4 de la tarde y tres agentes de código llevan desde el mediodía trabajando en el mismo repositorio. Uno corrigió el redondeo del total del carrito, otro añadió un código de descuento y el tercero escribió tests. Los tres dicen "done". Antes de que nada toque main, quieres saber dos cosas: ¿dos de ellos reescribieron la misma función? ¿Y los tres cambios siguen pasando los tests cuando se juntan?
Tres pantallas para un mismo código
osFoundry es una app de escritorio que reúne chat, agentes, archivos y herramientas en una sola ventana, y para el código ofrece tres pantallas relacionadas. Code es donde repartes tareas entre varios agentes a la vez: cada ejecución tiene su propia rama de Git y su propia carpeta de trabajo (un worktree), y tú revisas, pruebas y previsualizas el merge antes de decidir nada. Nada se fusiona solo. El IDE es un editor de código para una carpeta local, con explorador, control de versiones, terminal, paneles de problemas y tests, y una columna de asistente que ve el archivo en el que estás. Wiki lee un repositorio de tu máquina y escribe páginas de documentación que citan path:line, y luego marca la página cuando cambia el código que cita. Code y Wiki aparecen como pestañas junto a Maestro, Model chat, Multi chat y Research; el IDE tiene su propia entrada en la barra lateral. Si conoces VS Code con su panel de Git, el IDE te resultará familiar. Code se parece más a una bandeja de pull requests, solo que los autores son tus agentes y las ramas nunca salieron de tu portátil.
Un vistazo a la pestaña Code
Lo que ves en esta pantalla (las ejecuciones son datos de ejemplo):
- El aviso en la parte superior de la columna. "3 agents finished · they disagree on 1 file" nombra el archivo, aquí
src/cart.js, antes de que abras un solo diff. El botón Review together inicia una revisión conjunta. - La columna de ejecuciones. Se agrupan según lo que necesitan de ti: Ready to review, Needs attention y un History plegado. Cada fila muestra la tarea, las líneas añadidas y eliminadas, cuánto tiempo trabajó y su rama.
- La conversación en el centro. Haz clic en una ejecución y lees qué se le pidió al agente y qué fue diciendo mientras trabajaba.
- El panel derecho. Las pestañas Changes, Files, Commits, Review y PR muestran el diff real de cada ejecución: primero el trabajo sin commit y después lo que ya está en su rama.
- La Merge station abajo a la derecha. Seleccionas las ejecuciones terminadas y aquí las pruebas y previsualizas cómo quedaría fusionarlas juntas.
Caso de uso: una tech lead con tres agentes en un repo
Dana lidera un pequeño equipo web y reparte un sprint de checkout en tres ejecuciones de agentes: corregir el redondeo en los totales del carrito, añadir un código de descuento al checkout y añadir tests para el formateador de precios. Cada ejecución empezó desde New run con una tarea de una línea y un agente elegido para ella, así que cada una tiene su propia rama y carpeta, y ninguna puede pisar los archivos de las otras mientras trabaja.
Cuando el aviso dice que no coinciden, marca las tres ejecuciones y pulsa Review together. El panel Merge muestra "3 runs · conflicts not checked yet · 3 not yet tested", un "todavía no lo sabemos" honesto en lugar de una luz verde. Debajo, src/cart.js aparece marcado como contested y los hunks de cada rama se listan uno al lado del otro: tanto la corrección del redondeo como el código de descuento reescribieron total().
Luego pulsa test en cada ejecución. Los tests corren dentro del worktree de esa ejecución, así que su propio checkout no se toca nunca. Por defecto, "Tests must pass before a branch can merge", y esa regla se puede cambiar en Settings. Los tres pasan, pero pasar por separado no es lo mismo que pasar juntos, así que pulsa Preview combined merge. La app fusiona primero las ramas en una copia desechable y devuelve el resultado: dos se fusionan limpiamente y una tiene conflicto.
Fusiona las dos ramas limpias en su rama actual. Solo en ese momento cambia su rama. La rama del código de descuento se queda donde está, para que el agente rehaga su cambio sobre la corrección del redondeo. Si hubiera querido la mejor parte de cada intento en vez de ramas enteras, Combine into a branch le permite marcar hunks sueltos y crear una rama nueva con ellos.
Un detalle más que importa en los días largos: si la app se cierra mientras una ejecución está trabajando, la ejecución vuelve como Interrupted, no como "running", con la nota de que su rama se conserva.
Caso de uso: un desarrollador en solitario refactorizando con un asistente
Kenji mantiene él solo el front end de una tienda. Esta mañana tiene que cambiar formatPrice y no está seguro de quién la llama. Abre la carpeta del proyecto en el IDE desde la barra lateral. La disposición del editor es la de siempre: Explorer y Source Control a la izquierda, pestañas en el centro, Terminal, Output, Problems y Tests abajo, y el Assistant a la derecha, donde puede iniciar un chat sincronizado o un chat local que se queda en el dispositivo.
Hace clic derecho en formatPrice y elige Show Code Graph. El panel lista Callers y Calls. Un punto relleno significa que la llamada se leyó del propio código; un punto hueco significa que se infirió, así que esa merece una revisión manual. Impact of change sigue a los llamadores de los llamadores y, en este ejemplo, muestra "15 symbols · 14 files · 3 tests". Al hacer clic en una fila salta a esa línea, y Send to chat le pasa el grafo entero al asistente como contexto.
Más tarde, el asistente le edita un archivo de configuración. En Source Control el archivo aparece como modificado y, al abrirlo, una pequeña marca de robot y la barra de estado indican que lo escribió por última vez la IA, con el modelo y el motivo que dio. Review abre un diff lado a lado contra la copia guardada justo antes de esa escritura, así que ve solo ese cambio. Aquí muestra un timeout recortado de 30 segundos a 3, justo debajo de un comentario que dice que las subidas grandes tardan 20 segundos o más. Lo detecta antes de hacer commit.
Si un agente escribe en un archivo mientras él todavía tiene cambios sin guardar, el editor avisa de que el archivo cambió en disco mientras lo editaba y ofrece Keep mine o Use the disk version, en lugar de elegir uno en silencio.
Caso de uso: una ingeniera de soporte que necesita entender el código, no cambiarlo
Priya trabaja en atención al cliente y a menudo le preguntan cómo se comporta una parte del producto. Sabe leer código, pero no quiere ponerse a hacer grep en un repositorio que no es suyo. En Wiki usa Open a folder (o Clone a public repository con una URL https o git@), y la app lee la estructura del proyecto en su máquina.
Antes de escribir nada dentro del proyecto, Wiki pregunta. Un diálogo nombra la carpeta exacta que va a crear dentro del repo y, si pulsa Not now, no se escribe nada. Cuando acepta, usa Generate pages o Write a page para un tema concreto. Los ajustes deciden a partir de cuánto código fuente se escribe cada página (Depth: Quick, Standard o Deep) y cuántas afirmaciones se comprueban (Verification: Off, Sample o Full, donde Full duplica aproximadamente el coste). El coste se muestra antes de generar una página.
Cada página cita path:line, y al hacer clic en una cita se abre esa línea en el IDE. Un mes después, una página de la columna aparece marcada porque "a file this page cites has changed since it was written", lo que le indica que debe regenerarla antes de fiarse de ella. Para una pregunta rápida y puntual usa el chat junto a las páginas, cuyas respuestas también citan path:line de ese proyecto, y donde además puede pedir una página nueva con palabras normales, como "write a page about the retry policy". Las páginas en sí son archivos markdown dentro del repositorio, así que el equipo puede revisarlas en los mismos pull requests que el código.
Dónde se pasan el trabajo Code, el IDE y Wiki
Estas tres pantallas se pasan trabajo entre sí y con el resto de la app. Una cita de Wiki abre el IDE en la línea citada, y el IDE tiene un botón Wiki for this folder para el camino inverso. El Assistant del IDE y el chat junto a las páginas de Wiki están construidos sobre Maestro, el mismo asistente que usas en el resto de osFoundry, así que preguntar ahí funciona igual que en cualquier chat de Maestro. Para buscar en un código por significado y no por palabras exactas, Indexes crea un índice de búsqueda local que Maestro puede usar. Y cuando una ejecución de Code está lista para salir de tu portátil, Open PR abre un pull request para su rama.
Las páginas del producto muestran demos interactivas de cada uno: Code y el IDE.
Lo primero que pregunta la gente
¿Necesito la app de escritorio?
Sí. Code, el IDE y Wiki trabajan con carpetas locales, worktrees de Git, una shell y servidores de lenguaje, así que funcionan en la app de escritorio de osFoundry.
¿Un agente puede fusionar en mi rama por su cuenta?
No. Las ejecuciones trabajan en sus propias ramas y en sus propias carpetas. Tu rama actual solo cambia cuando pulsas merge y, por defecto, solo para ramas cuyos tests pasaron.
¿Wiki es una wiki de equipo como Notion?
No. Escribe documentación a partir de un repositorio de código, citando archivo y línea, y marca las páginas cuando ese código cambia. Está pensada para documentación del código, como una visión general de la arquitectura o notas de onboarding.
¿Qué pasa con una rama que tiene conflicto?
Se queda donde está. Puedes fusionar ya las ramas limpias y dejar que el agente rehaga la conflictiva encima de ellas, o elegir hunks sueltos con Combine into a branch.
La app de escritorio se descarga gratis en osfoundry.io/es/download.
Top comments (0)