BiGGi

BiGGi: an accessible AI coding assistant that builds apps module-by-module on a live canvas, not endless chat—keeping context lean and quasilinear, so work stays legible, low-load, and low-cost. Eleva is the orchestration layer that powers BiGGi.

Inspiration

Chat interfaces quietly replicate the hardest parts of a conversation: staying verbally fluent every turn, filtering signal from an ever-growing wall of text, and holding the whole thread in your head. For autistic, ADHD, and sensory-sensitive people, that friction is designed in. At the same time, the dominant "give me the full code" habit is wasteful—re-sending the entire history each turn makes token cost pile up, and it lets people offload thinking instead of building understanding. Technology is optimized for what we produce, not for how we learn. We wanted to flip that: an assistant shaped around attention, memory, and neurodiversity.

What it does

BiGGi is an accessible AI coding assistant. Instead of a scrolling chat, you build on a live canvas, one small piece at a time, through the BiGGi loop: prompt a piece → only the affected module regenerates → test it live on the canvas → accept or reject the edit (reject loops back to modules). The canvas state—not the transcript—becomes the context for the next prompt. That means content arrives in WCAG-style chunks, visualization stands in for sustained reading, and you never carry the whole thread yourself. Under the hood it sends only the current code/module state as context, so token growth stays roughly linear as the project grows instead of climbing quadratically.

How we built it

BiGGi is a web app with a canvas front end and an orchestration backend—the "working-memory" layer we call Eleva. Rather than appending every message to the prompt, the backend keeps structured memory objects that hold the current modules and the minimal relevant slice of context, and passes that to the LLM each turn. Around that we built the module system (so a single piece can be regenerated in isolation), the accept/reject loop, and lightweight data-visualizations of what's in context and how tokens are being spent, so the state is legible instead of hidden.

Challenges we ran into

The core tension was giving the model enough context to make a correct edit while keeping that context bounded—defining the "minimal relevant slice" is harder than it sounds. Regenerating only the affected module without breaking its neighbors meant thinking carefully about module boundaries and dependencies. On the design side, building an interface that's genuinely low-load and visual—rather than just prettier chat—took iteration, as did measuring token savings honestly (our 8,050-vs-12,950 comparison is an illustrative single-task sample, not a rigorous benchmark). And we had to make the loop feel guided, not restrictive.

Accomplishments that we're proud of

We got the BiGGi loop working end to end, with real module-level regeneration instead of full rewrites. We showed the context staying quasilinear where a naive chat approach grows every turn. And we're proud that the accessibility-first choices—chunking, visualization over verbosity, externalized state—aren't a niche add-on: they're the curb-cut effect in action, lowering cognitive load and cost for everyone while being built from neurodivergent needs first. Mostly, we turned a philosophy (externalize working memory) into something you can actually use.

What we learned

We learned how much of an LLM's cost and friction comes from how we feed it context, not just the model itself—re-sending history is expensive, and targeted prompts beat "give me everything." We learned that designing for the edges genuinely widens the audience, and that accessibility and efficiency are the same lever: fewer tokens mean lower cognitive load, lower cost, and lower energy use. And we got a much sharper sense of the difference between per-turn cost and cumulative conversation cost, which reshaped how we talk about the problem.

What's next for BiGGi

Next we want to generalize the working-memory layer beyond code to other knowledge work—writing, research, study—since the core idea isn't code-specific. On the product side: a dependency-aware module graph for smarter partial regeneration, support for more languages and frameworks, and inspectable "memory traces" you can revisit and replay. We also want to do real user testing with neurodivergent users and formal WCAG validation, run rigorous token/energy benchmarks to replace our illustrative sample, and eventually offer Eleva as infrastructure other accessible AI tools can build on.

Built With

• chatgpt-api
• codemirror
• css
• html
• javascript
• node.js
• sqlite