Fair, but I want to push on this one. Modal editing and a config you maintain yourself teach you to think in composable commands, sure, but plenty of people arrive at that thinking from a debugger or a shell and never touch vim. So once the novelty wears off and it’s just the tool you happen to open, what then?

deleted by creator

deleted by creator

The Google-versus-AI point in there is the one I’d hold onto. Searching made you read three wrong answers before the right one, and the wrong ones were where you learned what the problem actually was. Getting the answer straight away skips that without it feeling like anything is missing.

What I’d say to a junior is to keep reviewing the diff properly rather than reading the summary of it. Reading code you didn’t write is worth getting good at either way, and reviewing agent output gives you more practice at it than any job I’ve had before.

The same blindness sets in inside a team. Standing lint warnings and a flaky test stop registering after a few weeks, and every new person calibrates to whatever is already there. The only cure I’ve found is making the check mechanical, so the build fails and nobody has to keep noticing on purpose.

The workspace one holds up better. On diminishing returns, I only tidy what I was already in the file to change, which gives it a natural stopping point and saves me judging the whole codebase every time. Cleaning without a boundary is how a refactor nobody asked for ends up in a feature branch.

I’m in the group being described here and the rustiness is real, but it isn’t the part that decides whether the code is any good. What I lost in the years of meetings was the current detail, which library does what this year and where the sharp edges are. What I didn’t lose was knowing what to ask for and being able to tell when an answer is wrong, which is what you’re doing most of when something else is typing. I’d be more worried about a leader who hasn’t reviewed a diff in five years than one who hasn’t written one.

This looks useful for keeping a long change reviewable without leaving a branch open for a fortnight. Most of my pain with big PRs was never the size of the diff, it was that it had been diverging from main for two weeks before anyone opened it.

The discipline doesn’t go away though, it just moves. If the bottom of the stack sits unmerged you still have a long-lived branch, with everything else stacked on top of it.

The metaphor never quite works for me because debt is something you decide to take on, and most of what I’ve inherited nobody decided, it just piled up. What I do in practice is smaller than the metaphor suggests. I tidy the code I came in to touch and leave the rest for its own change, mostly because a refactor bundled into a feature branch makes the review harder and the bisect painful later. Agents have made that harder to stick to. Ask one to read a file and it’ll often come back having rewritten half of it. https://prickles.org/tenet/leave-it-better/P6

I’ve worked on both kinds of codebase and on the big ones nobody ever had the full picture anyway. The understanding got rebuilt when it was needed, from the tests, the docs and the commit history. Agents make that rebuilding much quicker, so partial understanding doesn’t worry me too much, as long as the team keeps writing those things down. If they stop bothering because the agent seems to cope without them, that’s where I’d expect the trouble to start. I’ve written up the tests side of this here: https://prickles.org/tenet/living-documentation/TS1

Whether this goes wrong comes down to the review bar rather than the tool. A standard library is the last place you want code nobody on the team can explain, and if maintainers hold review to that standard it matters much less who or what typed the first draft. The rejected-volunteers detail would worry me more, that’s a maintainer bandwidth problem no tool fixes.

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.