Inspiration
I am a researcher with a severe physical disability. I work from bed and operate an iPad with a single switch beside my head. Research software assumes a normate body: two hands on a keyboard, precise mouse use, fast shortcuts, and the stamina to move among an editor, a terminal, a bibliography, downloaded papers, notes, and submission systems. With one switch, every character and every transition has a physical and temporal cost — and a workflow doesn't just become slow. It can cross the boundary from possible to impossible.
For many people, LLMs make research faster. For me, they changed whether participation was possible at all. Codex can carry the typing, file operations, and code work that are physically expensive for me. But a console alone is hard for me to inspect, and full automation is not what I want either: I must remain responsible for the judgments that make the research mine. TailorTeX is the workspace I built to hold that middle ground.
The conceptual foundation of TailorTeX is Reconfiguration of Ability, my paper accepted to ASSETS ’26. The paper argues that LLM collaboration can transform participation without curing an impairment or removing every existing barrier: it can change which capacities are sufficient for an activity. TailorTeX puts that argument into practice by delegating physical and syntactic execution to Codex while keeping intention, evaluation, authorship, and direction with the researcher.
What it does
TailorTeX is a visual collaboration layer around real LaTeX projects:
- Select a passage or a note and send it to Codex as situated context; the reply streams back into the same workspace, in persistent per-project sessions, from a Mac or an iPad.
- The agent can point back — to the manuscript, a note, a file, a URL, or a specific PDF page — and everything linked stays visible in one vertically scrollable research stream, next to document-anchored comments and the project tree.
- Draft branches separate the original, revision, and camera-ready versions; frozen submission records preserve exactly the files submitted, with timestamps and SHA-256 manifests.
- Recovery backups and a guard against catastrophic replacement of a substantial
main.texprotect the manuscript itself. - Publication-safety checks keep research-process links and agent conversations out of the publication-ready LaTeX.
TailorTeX is open source (Apache-2.0) because access needs differ. Researchers are encouraged to fork it and ask Codex to reshape the interface around their own bodies and assistive technologies, while a small documented core keeps forks interoperable: document fidelity, collaboration, agent protocols, recovery, privacy, and exchange.
How I built it
During Build Week, I used Codex (GPT-5.6) as a sustained design and implementation partner, directing the work through natural-language judgments about what made research possible or difficult. Codex inspected my existing private prototype, implemented and revised features, tested them against my real workflows, diagnosed failures, and prepared the open-source release.
Without Codex, TailorTeX would likely have remained a private tool shaped only around my own workflow. Codex made it possible to turn that prototype into a tested, documented, cross-platform public beta that other researchers can inspect, adapt, and build on. It did not merely help me develop faster; it changed who the tool could be for.
Together, we built the browser-to-Mac agent bridge with streamed replies, persistent sessions, and slash commands; selection-based “point here” context from manuscript text and notes; agent-to-document, note, file, URL, and PDF-page pointing; the linked-research stream with lightweight PDF previews; draft branches and frozen submission evidence; automatic recovery and data-loss tests; and touch, dark-mode, keyboard, and screen-reader improvements.
The workspace can also route requests to other coding agents such as Claude Code, but the Build Week development itself was carried out through my sustained collaboration with Codex.
Challenges
The hardest problems were not features but design failures surfaced by lived use. An early bug blanked my manuscript — and a blank editor can conceal total loss. We treated it as a core design failure: TailorTeX now creates recovery copies, rejects catastrophic replacement of a substantial main file with near-empty content, and tests rollback when a multi-file save fails.
Other boundaries came from the same kind of evaluation: a console was not inspectable enough; full automation would remove agency; open folders created navigation burden; research-process links must never leak into publication output; and personal accessibility forks must remain interoperable with collaborators.
What I learned
This is not an efficiency story, and it is not an "overcoming disability" story. My impairment has not disappeared, and conventional interfaces remain inaccessible. What changed is which capacities can constitute research practice. When an agent carries the mechanical text and code production, articulating intent, evaluating evidence, recognizing errors, and directing the next iteration become sufficient for meaningful participation.
What's next
TailorTeX is a beta; the reference setup is a Mac hosting the project and the agent, used from desktop or iPad browsers. Next steps are hardening the documented interoperable core, adding safe sample projects, and supporting the first accessibility forks.
The goal is not one exceptional success story. It is a future in which more people with significant disabilities can enter research without first conforming to the bodily assumptions embedded in current tools.
Participation, not just productivity.
Log in or sign up for Devpost to join the conversation.