Building Conslabs with Claude Code

Conslabs didn't start as a finished design. It started as a single sentence: a request to turn a blank Next.js install into a portfolio and knowledge base for electrical and computer engineering. Everything that followed — the header, the dark mode toggle, the lesson hierarchy, the single RISC-V project, this blog post — happened through a series of conversations with Claude Code rather than hand-written line by line in an editor.

That's not a gimmick. It changed how the site got built.

Iteration replaced up-front planning

The original request was broad: home, projects, roadmaps, lessons, good SEO, clean architecture. What it didn't specify — slug structure for nested lessons, how dark mode should persist, whether a single project deserves a three-column grid — got worked out turn by turn, as actual problems showed up. "Add a dark/light toggle" became a real constraint once the toggle existed and looked wrong sitting in the wrong place in the header. "Delete all projects but one" surfaced a grid that suddenly looked sparse with only one card in it, which became a small cn()-based fix applied everywhere a list could legitimately contain just one item.

None of that was planned on day one. It was planned on the day it became visible.

The agent does the boring parts correctly, every time

A surprising amount of the value wasn't the code itself — it was the verification loop around it. Every non-trivial change in this project went through the same sequence: typecheck, lint, a full production build, then a real HTTP request against a locally running server to confirm the actual rendered output, not just that the build didn't error. That sequence is tedious to run by hand after every small edit, which is exactly why it tends to get skipped under deadline pressure. An agent doesn't get tired of it.

It also doesn't quietly leave dead code behind. When a roadmap got deleted, the lesson entries that referenced it had to lose a field; when a section got deleted from the homepage, its now-unused imports had to go too. Both were caught by grepping for the old reference before treating the deletion as complete — a habit that's easy to state as a rule and easy to skip under time pressure.

Where it actually got hard

Two things didn't go smoothly. The first project URL provided turned out to 404 — the agent checked it with a real HTTP request before writing it into the codebase, reported the dead link instead of inventing plausible-looking project details to fill the gap, and waited for a corrected URL. The second was a sitemap that Google Search Console reported as "couldn't fetch" — which turned out to be a domain mismatch: the site's canonical URL pointed at the bare apex domain, but the actual hosting redirected apex traffic to www, so every sitemap entry was quietly redirecting under search engines' feet.

Neither of those was a coding problem in the usual sense. Both needed someone — human or agent — to go check the real, live behavior instead of trusting what the code implied should happen.

What this means in practice

If you're evaluating whether to build something this way, the honest answer is that it doesn't remove the need to think about architecture, naming, or what the site is actually for. It removes the friction between deciding something and having it exist, which means decisions get revisited more often and more cheaply than they would if every change cost an afternoon. The Claude Code guide goes into how the tool itself works, end to end, if you want the mechanics rather than the retrospective.