The App That Punishes a Single-Runtime Choice
Say you are building a viewer for 3D scans. Users drop in a mesh or a volume — a few hundred megabytes of it — and expect to rotate it in the browser a second later. Somewhere between the upload and the first frame, something has to parse a binary format, decimate the geometry into levels of detail, tile it, and hand the browser something it can stream.
That "somewhere" is the whole architectural decision, and both single-runtime answers are bad. Do the decoding in Node and you spend your life fighting the event loop and a garbage collector that was never designed to hold a 400 MB vertex buffer. Write the UI in Rust and you have given up the entire React ecosystem to avoid a language boundary you were always going to cross.
So you want both: a Next.js front end and a Rust service underneath. Everyone knows that. The reason people don't do it is that "both" costs a week before you write a single line of product code — a monorepo, two toolchains, a build graph that understands both, a contract between them, and a CI pipeline that can compile Rust and run Playwright without either job knowing about the other.
The polyglot decision is easy. The polyglot setup is what makes teams pick one runtime and regret it in month four.
What You Are Actually Asked
The greenfield playbook for this stack opens with a questionnaire in eleven sections: project, architecture, UI, data, auth, state, testing, caching, CI, deploy, and config. Every question is a target decision — something a parser could never work out for you, because the code doesn't exist yet.
For the viewer, the answers that matter are the architectural ones. Does the Rust side want a single layered crate or a Cargo workspace with separate crates? (For a viewer, a workspace: the decoder wants to be its own crate so it can be fuzzed and benchmarked on its own.) Turborepo or Nx over pnpm? Which data layer — sqlx, SeaORM, or Diesel — and does the scene metadata want pgvector alongside it for similarity search across scans? Docker Compose, Kubernetes, or a split Vercel/Fly deployment?
You are picking from block sets, not describing a wish. Each answer selects a scaffold block that has already been written and tested. Nothing is being invented from your prose.
What Exists Before the Model Is Called at All
Answer the questions and the composition runs. What lands on disk is a working polyglot monorepo:
apps/web— Next.js 16 on React 19 and TypeScript, App Router, shadcn/ui on Tailwind v4, TanStack Query with Zustand, BFF route handlers, Vitest and Playwright already wired.services/api— a Rust axum 0.8 service on tokio, withsqlxagainst PostgreSQL 17,figmentfor config,thiserrorfor typed errors, andtracingexporting OpenTelemetry.contracts/openapi/— the OpenAPI 3.1 spec, emitted by the Rust service throughutoipa.packages/api-client/— a typed TypeScript client generated from that spec, which the Next.js route handlers consume.packages/uiandpackages/config— shared design tokens and shared tooling, so the two halves cannot drift on lint rules or on what a button looks like.- Delivery — a distroless, non-root Docker image, Kustomize overlays for Kubernetes, and GitHub Actions that build both runtimes, run both test suites, and produce an SBOM with Syft that Grype then scans.
It also writes the documents nobody writes on day one and everybody wants on day ninety: ARCHITECTURE.md, CALL-GRAPH.md, SEQUENCE-DIAGRAMS.md, STATE-FLOW.md, RUNBOOK.md, SECURITY.md, TESTING.md, PERFORMANCE.md, ACCESSIBILITY.md and a CONTRIBUTING.md, plus a justfile and a Makefile so both toolchains have one entry point.
None of that came out of a model. It is composed from blocks, deterministically, from your answers. Run the same answers twice and you get the same tree.
The Direction of the Contract Is the Whole Trick
One detail in that list carries more weight than the rest: the Rust service owns the OpenAPI spec, and the TypeScript client is generated from it. Not the other way round, and not both sides hand-writing types against a shared document.
This is the failure mode of every polyglot repo that goes bad. The front end adds a field. The back end adds a different field. Both are "correct" against a spec that nobody regenerates, and you find out in staging. Making the service the single author and the client a build artefact means a breaking change in Rust becomes a TypeScript compile error in apps/web on the next build — which is exactly when you want to hear about it.
Where the Model Actually Gets Used
Now there is a scaffold, but not a viewer. This is the point where most tools would have started, and where this one has narrowed the job considerably.
The run analyzes the scaffold it just wrote — a real structural pass over real files, not a memory of what it intended — and builds a planning context from it. Then it plans the application against that context: the upload endpoint, the decode pipeline, the level-of-detail generation, the tile store, the streaming route, the canvas component, the camera controls. The plan is written down at file level before anything is created, and it is yours to read.
The plan is then broken into precise tasks, and the build proceeds one task at a time. Each task compiles — cargo build on the Rust side, tsc on the TypeScript side — before the next one starts, and each passing task is its own commit. When a task fails, the run stays on that task instead of stacking a second broken change on top of the first.
The model was never asked to produce a monorepo, a Dockerfile, a CI pipeline or an OpenAPI client. It was asked to write the decoder and the viewer — the part that is actually your product.
What You Have at the End
The run finishes with a security scan over dependencies and secrets, a second structural analysis over the generated application, a check against the conventions the playbook holds for both runtimes, and a build. Not a claim that it should compile — a compile.
What you review is a branch with one commit per verified task, the file-level plan you approved before any of them, and a report of what ran. The scans, the SBOM and the generated documents sit in the repository next to the code, so the first architecture review has something to read that was not written the night before.
Why This Shape Holds Up
A 3D viewer is a good test of this approach precisely because the hard part is small and specific. The decoder is genuinely difficult and genuinely yours. The monorepo, the contract, the container, the pipeline and the docs are none of those things — they are the same for the viewer as they would be for a mapping service or an audio editor, and paying a model to reinvent them each time is how a build gets both expensive and inconsistent.
Split it the other way. Let the deterministic part be deterministic, and spend the model on the part where judgement is the product.