He says AI coding is like paying someone to exercise for you. The thread split on whether that's the point

The argument: skipping implementation skips the reps that make a senior

In his essay, Andrew Diamond does not claim AI writes bad code. His objection is what the developer loses by not writing it: "you haven't done any of the hard thinking you would normally do in writing the code yourself." He compares leaning on AI for the creative core to "paying someone else to exercise for me and hoping that gets me in shape" — the work gets done, the capacity never builds.

His sharper point is institutional. Someone has to know whether new code violates a legal requirement or breaks a system it doesn't see, and that judgment is earned only by years of doing the work AI now absorbs. Cut juniors out of the implementation loop, Diamond warns, and there is no one left who grew into the senior who can catch the model's mistakes. He closes by urging readers to keep doing creative, hard things off the clock — in writing, in relationships — rather than outsourcing the imaginative part for a short-term speed-up.

"The creativity was always at the feature step, not the implementation"

The thread did not line up behind him. The most pointed rebuttal came from a 20-year veteran who spent most of his career at Google:

"even before AI the creativity was largely at the feature definition step, not in the implementation … the vast majority of software development is a mapping problem … This has now largely been automated by LLMs" — an ex-Google engineer of 20+ years

He followed it with the sober corollary Diamond would recognize: engineers who only start after requirements are defined are now obsolete.

A developer shipping since 1998 posted a full eight-step loop he runs solo today, ending with a line that reframes the whole anxiety: "I can do in a week what would have taken a month a decade ago." He routes a feature spec through one model, has Claude and Gemini critique the repo, then deploys — work he says he could not have done alone in 2019.

Not everyone found the tools pleasant. One engineer's complaint was not about replacement but about the daily texture of the work:

"It's like working with a sociopath who just doesn't remember anything that happened 5 minutes ago … infuriate me all day long by doing ALMOST what I asked it to do, but just not quite" — a developer on the lived experience of AI agents

A builder of realtime audio systems offered the cleanest version of the optimist case: implementation errors have a poor signal-to-noise ratio, and for someone whose goal is to be an architect, "getting more reps in as an architect is in my best interest."

"the scope of projects I've started taking on has scaled roughly linearly relative to how much work I'm able to delegate, while the mental engagement has stayed constant" — an engineer building a realtime audio compiler

The split is not optimist versus pessimist. It is a disagreement about where the skill actually lived. If the craft was in the typing, Diamond is right that we are atrophying it. If it was in deciding what to build and how the system should behave, the typing was always the part worth deleting — and the open question is whether anyone still learns to spot a wrong decision once they never have to implement one.