What We Learned Shipping an AI-CAD Platform as a Final Year Project
Honest retrospective: what took longer than expected, what we'd sequence differently, and what surprised us about mixing ML research with product work.
Most write-ups of a project like this get written at the end, once everything works, and read like the plan always was the plan. Ours isn't that. This is being written mid-build, with some phases shipped, several still ahead, and at least one honest blocker (a missing local Python 3.12 install) that briefly stalled real work in favor of paperwork. We think the mid-build version is more useful than the polished one, so here it is.
The temptation to build the model first, and why we didn't
The obvious build order for a project whose thesis is "a fine-tuned model writes CAD" is: get the model working, then build a UI for it. We didn't do that, and on reflection it was the right call. A thesis defense rewards something a committee can watch happen live — a prompt going in, a status stream moving, a part coming out. An in-progress Colab training run rewards nothing; it's either finished or it isn't, and there's no partial credit for "the loss curve looked reasonable at hour 12."
So Phase P1 shipped a real Studio interface — a real prompt panel, a real phase-by-phase status stream, a real Three.js viewer, real downloadable files — wired to a small hand-authored catalog of CadQuery-built parts instead of a live model. That's a deliberate substitution, not a shortcut we're hiding: there is no live inference behind it yet, and no /api/generate endpoint exists on the backend as of this writing. What exists is a UI that already knows what a real generation should feel like, so that whenever the real pipeline lands, it drops into a product experience that's already been designed, tested, and refined — not one being improvised under deadline pressure.
The data pipeline is more load-bearing than it looks
The DeepCAD-to-CadQuery transpiler doesn't sound like the hard part of an "AI writes CAD" project — the model does. But a training run built on silently wrong data doesn't fail loudly; it fails as a disappointing eval number weeks later, with no clear signal about whether the model or the data is at fault. That's why the M0 plan insists on validating the transpiler against a 1000-sample slice, with an explicit 85% round-trip pass-rate gate, before ever touching the full 158k-pair corpus.
We've internalized that discipline more than we've finished executing on it. As of now, the IR layer — the typed intermediate representation sitting between the DeepCAD parser and the CadQuery emitter — is built and unit-tested. The parser, the emitter, the round-trip filter itself, and the slice run are still ahead of us, partly because the local environment needs a Python 3.12 install that CadQuery's OpenCascade bindings depend on and the rest of the stack doesn't. That's a small, almost administrative blocker, but it's a real one, and it's a useful reminder that "the model is the hard part" can obscure a dozen smaller dependencies that have to be true first.
Battle-test the sandbox before the model exists
One sequencing decision we're glad we made on paper, even though it hasn't been built yet: the executor and validator — the subprocess sandbox that runs model-generated code, and the checks that decide whether the resulting geometry is watertight and manufacturable — are scoped in Phase P4 to be built and tested against hand-written CadQuery scripts, independent of the model entirely. Executing untrusted, model-generated Python is the single riskiest piece of infrastructure in this whole system, and there's no reason its sandboxing, its resource limits, or its fuzz tests need to wait for a trained model to exist. Proving the sandbox holds against a deliberately malicious hand-written script is a cleaner test than trying to debug sandbox behavior and model behavior at the same time.
What's actually still ahead
In the interest of not overselling a mid-build project: the model has not been fine-tuned yet, there is no live generation endpoint, and nothing has been demonstrated end-to-end with real model output. What's shipped is the product shell — marketing site, auth, admin, and a Studio mock that proves the UX — plus the earliest layer of the data pipeline. What's ahead is the bulk of the actual thesis: finishing the transpiler and round-trip filter, the QLoRA fine-tune itself, the backend executor and validator, wiring the real model into the Studio flow, the image branch's caption-bridge, and eventually the defense itself. Writing that down plainly, rather than rounding it up, is the whole point of a retrospective written before the ending is known.