The ambiguity is exactly why a spec has to be runnable. Natural language always leaves room, so what carries the weight is the acceptance check the agent can run and fail against, not the prose. If nothing can fail the output, the ambiguity just moves downstream into the code.

The instinct you described, using the LLM for the regex because you can verify it immediately, is the right line to hold. The trouble starts when the output isn’t cheap to check, that’s where the judgment you’re worried about losing actually goes. For getting back up to speed I’d lean the other way deliberately, let it explain an error or a library you don’t know, but write the thing you’re trying to relearn by hand, because the parts you type are the parts that stay in your head. Git’s worth the hour even for solo projects, the saved-folder backups stop scaling the moment you want to know what changed between two of them.

The ‘who watches the watchers’ line lands. What I’d add is that tests-as-the-gate only works if they could have failed, and a suite written next to the feature tends to certify the behaviour that’s there rather than the behaviour you wanted. The domain knowledge you mentioned is what closes that gap, someone who knows the intended outcome writes the assertion the code can genuinely fail. Agreed it’s a separate skill set, and it’s the one that decides whether a passing gate means anything at all.

Agree most with the audit-fatigue point. A signal that is always red trains everyone to ignore red, and the same failure kills lint warnings and flaky test suites. The other line that stuck was taking a dependency without deciding to. We started listing direct dependencies in review for exactly that reason, adding one became a decision someone makes rather than a side effect of npm install, and the conversation it forces is usually short but occasionally stops a bad one.

The gap between finishing the book and surviving a real project is the normal shape of it, and not just for Rust. A book teaches the rules one at a time, a project makes you hold them all at once while also learning the framework, and Tauri adds its own layer on top. The borrow checker is mostly moving pain you’d have hit at runtime in C up to compile time, so the fights are front-loaded rather than new. From what I’ve seen it settles once the ownership model becomes how you plan a change rather than something you fight afterwards.

Agreed. An agent only multiplies what’s already in the codebase. If you’ve got tests, clear boundaries and the rules written down, it genuinely flies. If it’s the usual undocumented mess, you just get more mess, faster. Which is probably why the shops that dodged that groundwork for years are getting the least out of AI now. There’s nothing solid under it to build on.

What carries over from the old rockstar is that they produced faster than anyone else could follow, and whoever inherited the code paid for it later. An agent does the same without the ego. It’ll turn out a week of plausible-looking code in an afternoon, and the slow part becomes reading and understanding it rather than writing it. What’s worked for us is making the agent meet the standards before the code lands, a linter and a couple of runnable checks in the way, rather than trusting a reviewer to catch every miss when they’re forty files deep and tired.

The limitation is the debug adapter, not VSCodium itself. The FOSS C# adapter, netcoredbg, can’t feed stdin through the integrated terminal. Only Microsoft’s vsdbg does that, and its licence ties it to official VS Code and Visual Studio. The way round it that’s worked for me is to skip launch mode and attach instead: start the program yourself in a normal terminal, then use an attach configuration to hook netcoredbg onto the running process. You get breakpoints and inspection, and since it’s a real terminal the stdin behaves. Not as smooth as launch, but it stays fully FOSS.

The enum is a real improvement over bare integer indices, the call site reads as a name rather than a magic 7. The bit I’d watch is what the enum actually maps to. If it maps to a fixed offset you’ve named the brittleness rather than removed it, since a reordered column still breaks it silently. If it maps to a field identity, and you resolve the offset from a header or a known layout, the name carries the meaning and the position is free to move without taking the parser down.

Claude Code, mostly, but I’m with Scipitie that the tool matters less than the process around it. What’s helped most is writing the project’s rules and conventions into files the agent reads each session, then putting the non-negotiable ones behind a linter or a test so it can’t quietly skip them. Treated that way it behaves a lot like the junior who’s read all the books and understood half of them. Left to its own judgement it drifts, which is the part the guardrails are there to catch.

I’d be a bit careful with the assumption that a good enough overarching doc stops the create feature getting rewritten when bulk-edit turns up. In my experience it usually doesn’t. Trying to design the whole thing up front so the later feature drops in cleanly is the old big-design-up-front problem, you end up guessing about the part you haven’t built. souperk and doo are right that it’s cheaper to expect the refactor and keep the steps small.

What the doc is genuinely useful for is the boundaries. Write down what the create part is allowed to depend on and hold it to that. If create only ever goes through a repo abstraction and never reaches into provisioning internals it doesn’t need, then bulk-edit comes in as a new module against the same boundary instead of a rewrite. When you do find the second feature forcing changes deep in the first, that’s nearly always the first one having coupled to something it never needed, and no amount of spec detail up front would have caught it. So I’d keep the design phase you’re after, just spend it on those boundaries rather than trying to predict the features you haven’t specced.

I wrote the boundaries idea up here if it’s any use: https://prickles.org/tenet/bounded-contexts/A6

There’s a useful split lurking in this. For narrow agentic work like retrieval over internal docs, structured classification, test scaffolding, deterministic refactor passes, a self-hosted 30B-class model can be fine and the inference economics work out at team scale. For multi-step planning and the harder agent loops, the frontier gap still shows up in the number of retries and the time-to-correct-answer.

The honest test is to pick the prompt category that’s costing you the most and benchmark something like Qwen 2.5 Coder 32B or DeepSeek V3 against whatever you’re paying for now. If the gap is small you’ve found your candidate. If it isn’t, you’ve at least costed the gap accurately rather than guessing at it.

The two costs people underestimate are the GPU box (plus a second one for the eval/staging path) and the maintenance overhead. Model picks go stale fast and someone on the team has to own that, or you end up shipping a Llama 3.1 stack into 2026 because nobody rebuilt the harness for whatever’s current.

The networking advice is right, but here’s the part you can actually control while you wait for that to pay off. Most fresh-grad applications look the same from the other side of the desk, a degree and a list of tutorials. What made me put someone through to interview was evidence of judgment: one or two small projects that are genuinely finished, with tests and a readme, ideally deployed somewhere I can poke at. Not a half-built clone of something. And in the cover note, one specific trade-off you made and why you made it. That reads as someone who has actually shipped, which is rarer than it should be.

I’ve used spec-kit and also rolled my own lighter version of the same idea. The framework matters less than the habit it forces, which is writing down what ‘done’ looks like before the agent starts. When I just prompt without that, I get something plausible that I then argue with for an hour. When the spec has acceptance criteria the agent can check itself against, most of that back-and-forth goes away. The caveat is that spec-kit can be heavier than a small change needs, so for quick work I’ll write the criteria in a comment and skip the ceremony. Worth trying. For me the habit of writing the criteria first is what stuck, more than the tooling around it.

squaresinger’s point matches what I’ve found. Once three agents are going, you become the coordination point - you’re holding the plan and reviewing all of it, and that part doesn’t scale the way the generating does. What’s kept it manageable for me is treating each one like an intern on a single, well-specified task I can check before it moves on, rather than running a swarm and hoping it converges. Wrote this up here: https://prickles.org/tenet/the-intern-pattern/AI1