I pulled up my own GitHub history recently, looking for something unrelated, and got distracted by how much custom tooling is sitting in there going back over a decade: deployment scripts, small CLI wrappers, home lab provisioning tools, one-off utilities that solved a problem and never got replaced. All of it built the slow way, one evening at a time, long before Claude Code existed.

Claude Code did not change what I was capable of. It changed what that capability costs. A tool that used to take a weekend of evenings now takes an afternoon, so the utilities I used to talk myself out of building, because the payoff was not worth the time, now get built. The barrier was never knowledge, it was friction, and friction is the one thing an agentic coding tool is built to remove.

But if you do not understand software development, you are now producing bad software faster than you used to, and nothing about the tool warns you that is happening.

An assistant will hand you a script with no tests and no error handling because you never asked for either. Ask for a feature without asking it to break the problem down first, and you get one function doing six unrelated jobs. Speed and structure are not the same axis. A fast model makes structure easier to skip, not more likely to happen on its own. The result is vibe-coded junk, produced at a pace that used to take a team, and it looks fine until someone has to change it.

Issue tracking, code review, testing, and breaking a problem into pieces someone else can reason about decide whether a tool holds up once someone besides you has to touch it, not how fast the model that built it was. The scaffolding post I wrote a few weeks ago made the case that the model is a runtime, not the tool, and the same logic applies here: knowing SDLC is on the person driving the tool, and Claude Code did not teach me any of it. It removed the excuse for never having started.