Loom

Inspiration

Loom began with a Prism-inspired layout for scientific writing. The idea was to keep LaTeX source, an AI assistant, and the compiled paper in one workspace.

Research into LaTeX workflows pointed to problems beyond writing text: moving between source and PDF, fixing build errors, setting up local tools, managing citations, and checking AI edits. Loom was built to bring those tasks together while keeping authors in control.

What Loom does

Loom is a desktop app for writing and compiling scientific papers. It includes a multi-file LaTeX editor, PDF preview with SyncTeX navigation, local PDF builds, bibliography and research search, and Git tools.

Users can connect OpenCode or Codex to help edit project files or diagnose build errors. Those connections are optional. A Loom project remains an ordinary folder of .tex, .bib, and asset files, so it can also be opened in another editor.

How we built it

The app uses Electron, TypeScript, SolidJS, and CodeMirror 6. Local services handle project files, builds, language features, research search, Git, and agent connections. Typed contracts define how those services communicate with the desktop UI.

We made several choices to protect users’ work:

Manuscript files stay in the project folder. Loom keeps recovery data and workspace metadata separately.
Saves and external edits must not overwrite newer typing.
Each PDF build records which source it used. If a build fails, Loom keeps the last successful PDF and reports the failure.
Loom connects to existing OpenCode and Codex installations rather than providing its own model or authentication system. Challenges A major challenge was keeping live writing safe while Loom saves files and agents or external tools make changes. Reloading a file can erase newer edits, so Loom needs to track changes and recover conflicts.

We also found gaps between development and packaged behavior. Source tests did not catch a problem in the generated Linux launcher. Folder and ZIP imports handled Git metadata differently. Release checks also uncovered issues with saved data during upgrades, runtime version metadata, and notices missing from the packaged app.

Accomplishments

Loom brings editing, PDF builds, build feedback, references, Git, and optional AI help into one desktop workspace. Its projects remain portable, and users can connect their own OpenCode or Codex setup.

The Linux beta is another concrete achievement. The published AppImage passed its recorded Electron suite, upgrade checks, and supervised live Codex and OpenCode workflows on the developer’s Omarchy host. The download checksum was also verified.

A part worth being proud of is the care taken to protect the author’s work. Loom keeps recovery data separate from Git history, relies on the connected agent’s permission prompts, and documents exactly which release checks have and have not passed.

What we learned AI chat alone does not solve the problems researchers face while writing papers. The app also has to help with builds, source and PDF navigation, references, and review.

Recovery needs to be part of the design from the start. Saves, agent edits, and external changes all need to preserve newer author work.

Testing the source code is not enough for a desktop release. The packaged app and its target environments need their own checks. A test on one Linux machine only provides evidence for that machine, not every Linux setup.

We also learned to treat early research as a starting point. The original research brief drew on public reports and framed its findings as hypotheses, not as a representative survey.