Goodbye to the Hard Parts That Never Mattered

Open the original

Short summary

Jake Goldsborough argues that AI coding agents aren't killing software engineering—they're freeing engineers from tedious mechanical work so they can focus on the actual problem-solving that defines the craft. The hard parts that never mattered (regex wrestling, syntax memorization, build system incantations) are disappearing, but the work that requires real judgment and responsibility remains.

  • The difficult parts of coding—parsing edge cases, remembering obscure syntax, navigating unfamiliar codebases—were never the point; they were tolls between understanding a problem and solving it, and removing them doesn't diminish engineering skill.
  • Agents handle syntax and scaffolding faster, which lets engineers explore domains that were previously too expensive (rewriting programs in different languages, understanding unfamiliar systems, testing experimental ideas), actually tightening the learning loop rather than replacing it.
  • The real shift is architectural: engineering moves from "produce every character by hand" to "direction, judgment, verification, and responsibility," and the actual risk isn't that the work disappears but that companies cut people, generated code creates failures at scale, and the junior-to-senior training path collapses.

Full summary

Jake Goldsborough pushes back on the idea that AI coding assistants are killing software engineering. He's responding to Dave Kiss's piece about the "death of the software engineer," but argues Kiss got the framing wrong. The real question isn't whether engineers are disappearing—it's what work we're actually losing. Goldsborough identifies the stuff that's genuinely going away: memorizing regex patterns, wrestling with CSV parsers, hunting through unfamiliar codebases for syntax you forgot, waiting for build systems to cooperate. These were always tollbooths between understanding a problem and actually solving it. If AI agents handle that translation work, engineers haven't become less valuable. They've been freed to do the part that actually required an engineer in the first place. The work shifted rather than vanished. Goldsborough uses coding agents daily and sees exactly where the boundary is now. Agents can generate parsers in seconds and navigate codebases faster than humans, but they also make confident mistakes—using APIs that don't exist, misunderstanding local conventions, declaring victory before anything's tested. The engineering work moved upstream and downstream: you still need to understand the system well enough to spot where to intervene, recognize when a plausible answer is wrong, choose the right architectural layer for a change, and take responsibility for what ships. Learning actually got faster too. Instead of spending a weekend on syntax scaffolding, you can now walk into unfamiliar territory like rewriting TypeScript in Rust or understanding production infrastructure across repositories. The tight feedback loop—ask, inspect, run, break, read, correct—gets you to the edge of your knowledge quicker. Goldsborough acknowledges the real problems: companies will use productivity gains as cover to cut headcount, generated code will fail at scales we're not ready for, and the junior-to-senior progression path is genuinely unclear. Access matters too—if the best tools cost hundreds a month, the profession isn't actually more open. But these are questions about distribution and training, not about whether engineering still exists. If anything, faster code generation makes discipline more critical. A bad assumption can become three thousand lines before lunch. The craft was never the mechanics of typing or memorizing. It was understanding problems deeply, making tradeoffs with incomplete information, noticing what's wrong in systems that technically work, and standing behind the result. That work is still here. There's just more room to apply it.

Ask about this article