Using Rust + Bazel + AI for shipping fullstack apps
Three years ago I started using AI for coding, and last year I started writing these up as guides for myself and some of the people that I've worked with. Now it's a couple of books, a video course (75% done),
30+ guides plus 50+ reusable skills, and I'm turning it into a
cohort instead of letting it rot in my repo.
The launch strategy is simple. 10 of the guides go free at
guides.compoundcoders.com (live now). The remaining 20+ plus all
the skills, articles, and live group calls sit behind the paid
cohort. Soft launch this week and with a free webinar July 2.
But that's not what I want to talk about. I want to talk about the
weird technical choices I made building the platform itself,
because every single one was an argument with myself - feel free to grill me for these.
1. The frontend is in Rust.
Yew, compiled to WASM, server-side rendered. Course platforms in
Rust isn't a thing anyone does — the obvious choice is Next.js with React or just plain html rendered with Django. I picked Rust because of the high signal: make a tiny mistake and nothing compiles. It makes relatively certain that the code does not run because the agent casted everything to unknown and back to whatever type is needed.
The cost: every "easy" frontend feature is 3x the work of the
React equivalent, mostly because of the missing ecosystem (its growing though). The win: Rust provides so much more feedback to the agent, errors are super clear and if something breaks, I am working in single language not having to switch context.
I want to say this was the right choice and I believe it is, but who knows?
2. The build system is Bazel.
For a one-person shop. With rules_rust, NativeLink as the remote
cache, the whole 776-target monorepo. People hear "Bazel" and think
"Google-scale infrastructure," which is fair — the learning curve
is real.
Here's why I did it anyway: I run multiple AI agents in parallel
git worktrees. Without Bazel's shared cache, each agent rebuilds
everything from scratch in its own worktree. With Bazel +
NativeLink, an agent that touches one crate triggers a 4-second
rebuild instead of a 19-minute one. The cache makes parallel agent
workstreams economically viable.
Cargo can't do this. Cargo's caching is per-worktree by default.
For solo + AI work, Bazel is actually the small-team tool now —
the agents absorb the configuration complexity that historically
required a build engineering team.
This one I'm sure about.
3. The entire marketing site is written by agents.
compoundcoders.com — the lead pages, the brand consistency, the
copy on every section — is authored by Claude, Codex and QWEN through a custom MCP
admin layer I built. I review and approve every change. I don't
write the HTML/CSS anymore.
This sounds insane and it is, slightly. The MCP layer enforces the
brand kit (typography, color tokens, component library), validates
every page against the design system, and gives Claude the same
admin surface I have. When I want to ship a new lead page, I
describe it in a sentence and review the diff.
The risk: I'm one tool-config-mistake away from shipping garbage
publicly or having my production lead pages taken down by an AI that misunderstood what I meant. The mitigation: every page goes through a preview step
before publish, and the brand kit is strict enough that off-brand
output usually fails the validation before I see it.
It feels like this piece deserves more work from a reliability perspective. The trust I'm placing in this
workflow is non-trivial and I don't pretend otherwise.
4. The brand identity is dark-mode terminal, not pastel-SaaS.
Near-black background, four neon accent stripes (green, cyan,
purple, pink), Inter + Space Mono typography, terminal panels and
file trees as visual motifs. Operational rather than decorative.
The default playbook for course platforms is the opposite — bright,
gradient-heavy, "AI magic" energy. I went the other direction just because I am sucker for the 80s/90s.
This may coast me on first-impression friendliness, although I believe it feels more unique and honest.
Feel free to roast my site and the choices I made, or provide any other useful feedback! It’s highly appreciated
The Bazel point is probably the sharpest part of this.
Most “AI coding” content still talks about prompts and editors, but your argument is really about infrastructure for running multiple agents without the workflow collapsing. Rust, Bazel, shared cache, MCP admin surface, strict brand kit — those choices make the course feel less like another AI coding tutorial and more like an operating model for AI-native software teams.
That is the angle I’d make more obvious.
Compound Coders works for the cohort/community side, but if this starts becoming a broader system of reusable skills, build patterns, agent workflows, and production guardrails, the name may keep it feeling like education instead of infrastructure.
A harder technical brand like Davoq .com would fit that deeper layer if you ever separate the methodology/tooling from the course itself. The course teaches the workflow, but the bigger asset may be the system behind it: reliable AI-assisted shipping without turning the codebase into chaos.
The technical choices are unusual, but that is also what makes the story memorable. I’d just make sure the brand matches the seriousness of the engineering philosophy, not only the teaching format.
Thank you — "operating model for AI-native software teams" is a sharper version of what I was trying to say, and I'm going to steal it.
You're right that the system behind the course may be the larger asset. The brand question I've been chewing on: my instinct is to keep CompoundCoders as the front door while the methodology evolves, but the Team Training tier is the first commercial acknowledgement that the infrastructure layer might want to exist independently eventually.
The detail I'd add: the failure modes in this stack are organizational, not technical. Bazel doesn't fail because the build graph is wrong — it fails because nobody on the team is empowered to maintain it. The "operating model" framing matters because the choice points are about human practice as much as tooling.
Appreciate the thoughtful read.
That makes sense, and the “organizational, not technical” point actually strengthens the separate-layer argument.
CompoundCoders is a good front door for the course/community because it tells people what they are joining. But if the Team Training tier starts becoming a repeatable operating system for how engineering teams adopt AI safely, that layer probably needs a name that does not feel like a course brand.
That is where Davoq came to mind for me. It sounds more like the underlying technical system than the teaching wrapper.
I would not force a rename now. But if you already feel the methodology may separate from CompoundCoders later, the smart question is whether you want to secure that stronger infrastructure identity before the team-training offer gets too baked into the current name.
25 AI engineering guides and no way to tell anyone a new one dropped. I ran it through our engine and the specific thing that stood out: zero form elements anywhere on the page. Not a weak form — literally no HTML form in the DOM.
That's a quiet leak for a content library. Every time a reader finishes a guide they found useful, they have no "get the next one" option. They'd have to remember to come back. Most won't. You're building an audience that exists only inside their browser history.
The straightforward fix is an inline form at the bottom of each guide — "Enjoyed this? Get the next one by email." Two fields, email and submit. If you're on Next.js, there are 5-line implementations for this. The content quality is clearly there — the missing piece is just the mechanism to keep people attached to it.
Full breakdown with prioritized issues: outboundautonomy.com/grade?ref=ih-compoundcoders-20260605