Lately, I've had the same moment more often: I'm looking at a change that works, reads fine, even looks clean yet I'm still asking, do I actually want this in the codebase? Not because it's wrong, but because I can't tell what it's committing us to.
That question used to show up mostly around big decisions. Now it shows up everywhere: helper functions, data models, whole modules. The work isn't just "make it run." It's "make it belong."
This is the part that feels easy to miss in the AI era: producing code is getting smoother, but the engineer's job doesn't end when code appears. If anything, that's when it starts because a codebase isn't a pile of working snippets. It's a system that has to stay coherent under change.
People reach for "code quality" here, but the phrase is too small. You can lint code, type it, test it, format it and still end up with software that feels harder to change every month. What slips first isn't cleanliness. It's shape.
You notice it when you can't tell where logic is supposed to live. When the same idea has three implementations. When naming drifts just enough that you stop trusting what identifiers mean and start rereading everything like it's a riddle. The software still works, but it stops feeling legible.
And legibility is the quiet superpower of good systems. It's the invisible agreement that makes a codebase teachable: there's an obvious place for things, boundaries hold, interfaces mean what they say, conventions exist for a reason. That agreement is hard to write into a prompt, and easy to accidentally dissolve one "reasonable" change at a time.
This is where the "software engineering is a craft" argument becomes more interesting than it sounds.
If craft means authorship the satisfaction of carving every line yourself then it's understandable to feel like something is being lost. Authorship creates a certain kind of accountability: you remember why things are the way they are.
But there's another way to define craft that survives tool changes: the craft of clarity.
Clarity is when the code reads like a decision, not a coincidence. When abstractions remove complexity rather than relocating it. When the system has a voice consistent naming, consistent boundaries, consistent ways of doing common things. And it requires a kind of discipline that doesn't look glamorous: saying no to a "fine" implementation, deleting more than you add, insisting that the codebase stays understandable to a future you who is tired and late and doesn't remember the context.
The new trap is that "fine" becomes sticky.
When something appears quickly and mostly works, it's psychologically harder to reject. It feels picky. It feels like slowing things down for aesthetics. So you keep it. Then other code grows around it. Dependencies attach. Patterns form. The shape of the system quietly shifts to accommodate whatever was easiest to accept in the moment.
Over time you don't just get mess you get internal inconsistency. A codebase where every new feature requires negotiation with the past.
So review stops being "did we miss a bug?" and becomes "are we accidentally creating a new dialect inside our own project?" You start asking questions that feel almost impolite:
Are we introducing a third way to do this? Did we just smear business logic into infrastructure again? Is this abstraction buying simplicity or buying ceremony? Would a new engineer learn the right lesson from this file? What assumptions did we just make permanent?
None of those questions are answered by a green test suite. They're answered by taste, by standards, by attention the unsexy parts of engineering.
One subtle shift underneath all of this is that engineers don't have to live inside implementation details all day. Sometimes you need to be close to the code debugging, performance cliffs, security-sensitive paths there's no substitute for understanding what's actually happening.
But other times the highest-leverage move is to step back and protect the system's shape: decide what's allowed, make constraints explicit, enforce conventions, keep boundaries from dissolving.
That distance isn't laziness. It's a tactic.
And it starts to feel like a dial you turn close when the details matter, farther away when the shape matters, then close again when integration reveals sharp edges.
Maybe the future isn't engineers getting farther from the code or staying close to it. Maybe it's learning to treat distance like a dial and turning it deliberately instead of by habit.