How far can AI take an infinite canvas?

The idea

A drawing usually has a fixed page and a practical limit on detail. bound.less explores another possibility: a city can contain buildings, a window can contain a room, and a tiny object in that room can become another place to draw.

The product challenge is to make that freedom usable. People still need ordinary drawing tools, a way to find their way back, understandable scale and confidence that their work can be saved.

A practical way to find out what AI can do

I wanted to find out how far AI could take a large, technically demanding project. For this AI-led version of bound.less, I have deliberately not written or edited a line of code. I set the goals, discuss architecture, review what agents propose and test the experience; the agents write and change the code.

Working with Claude Code, Codex, Cursor and Lovable has shown me how much AI can now accomplish: a drawing engine, tools and selection, real-world scale, Scenes navigation, local files, account sync and a custom renderer. Some agents have handled very large engineering tasks well, including weeks of review and performance work on the renderer.

The project gives me a continuing way to stay current with frontier AI models. As their capabilities change, I can try them on a substantial existing codebase and see how they handle architecture, unfamiliar bugs, testing and sustained work. The useful question is what an agent can carry through to a working, reviewable result.

The hard parts, in plain language

Keep tiny details accurate while zooming. A browser eventually runs out of numerical precision if one drawing uses a single enormous set of coordinates. I built a system of small local coordinate spaces—like an atlas with a more detailed map inside each region. A detail stays at the scale where it was drawn, rather than being repeatedly stretched and rounded.

Make Chrome draw what the geometry says. Correct curve calculations do not always produce the right picture in the browser. At extreme scales, thin lines can disappear and curves can shift. I built a custom rasterizer: code that turns the curve data into screen pixels itself, with more precise calculations than the browser’s normal drawing path. The labs isolate these differences so I can compare the actual picture.

Keep large drawings responsive. Redrawing every object whenever the view changes is too much work. The new renderer divides the view into small image tiles, prepares them in background workers and reuses finished tiles. It updates the areas that need work and keeps a usable picture on screen while finer detail is prepared.

Move a whole drawing without disturbing its hidden detail. A large selection may contain thousands of tiny shapes at different depths. I changed how groups are addressed so moving a region does not require rewriting every point inside it. That preserves the relationships between large shapes and their smallest details while reducing repeated work.

Try it

Open bound.less ↗

1. Start a local drawing. No account is required.
2. Draw at two scales. Sketch a large shape, zoom into a detail and add something smaller.
3. Save a place. Use Scenes to return to a different part of the drawing, or set a real-world length and inspect the scale bar.
4. Keep a copy. Export a .boundless.json file. Optional Google sign-in enables account sync.

Letting an agent stay with a difficult problem

The custom rasterizer had already been built, but its first implementation was brittle. I used the self-compaction workflow to let an agent keep working for weeks: first reviewing and hardening that renderer, then analyzing performance, researching possible improvements and implementing them.

The agent chose sensible moments to compact, preserved its findings and next steps, and resumed without my having to watch its context window. That made sustained engineering work possible across many sessions. The renderer is still being tested before deployment to the live app.

The small experiments behind the app

The most useful labs let me compare the choices behind the drawing engine directly:

Other focused studies explore disappearing thin SVG lines, curves at extreme scales and selection feedback across scales.

AI helped build the experiments. I used them to inspect real browser behavior and compare tradeoffs before choosing an approach for the app.

The source also includes full-app browser performance scenarios, rasterizer benchmarks and a memory census. These are measurement scripts rather than standalone pages; some need a running app or private drawing fixtures.

Roadmap

1. Deploy the custom rasterizer when tested and ready.

   The next release focuses on correct display in Chrome, stable zoom transitions without jumping, and better loading, drawing and movement performance. The renderer is built; deployment follows the remaining browser checks.

2. Make the experience easier to learn and use.

   Priorities include a clearer Scenes panel with useful thumbnails and simple navigation, a phone layout that leaves more room for the drawing, better first-run guidance, visible loading feedback, and stronger keyboard and selection affordances. Rotation and measurement tools, plus simple move-to-front and move-to-back controls, are also planned.

3. Let people share and create together.

   Add public read-only drawing links and a public gallery, share canvases with view or edit access, then support collaborative drawing with concurrent edits merged safely across people and devices.