I spent 25 years trying to convince people that writing code was the least interesting part of our job. That the real work – understanding business problems, modeling domains, designing systems that actually fit how organizations work – that’s where we should be spending our time. Code was always just the expensive translation layer we had to deal with.
Most of my peers went the other direction. They got really good at frameworks, languages, design patterns. They optimized for technical mastery. And for two decades, that’s what the market rewarded. I always felt slightly out of step.
Now, watching AI handle implementation, I feel something I didn’t expect: vindication. Not “I told you so” vindication – something deeper. Like finally being able to go home to where our profession should have been all along.
What I often see right now is something between denial and panic. Developers with impressive résumés are suddenly uncertain. The knowledge they spent years accumulating – the intricate understanding of language semantics, framework patterns, debugging techniques – feels less valuable when a language model can generate syntactically correct code faster than you can type. And they’re right to feel something. The skill we collectively decided to optimize for the last three decades is being commoditized in real time. But what they’re not seeing yet is the elevation happening beneath that disruption.
What’s Actually Happening
Here’s what’s genuinely shifting: AI isn’t replacing developers. It’s freeing developers from the implementation tax that was always unrelated to the actual problem-solving work we love. Code wasn’t the end state. It was always the means. But for so long, writing code was so expensive and time-consuming that we couldn’t afford to separate the two. You needed the same person who understood the business problem to also be fluent in C#, Java, Python, JavaScript, SQL, CSS, and whatever framework was fashionable that month. That person rarely existed. We settled for close enough.
Now we can afford to be precise about this separation. AI handles the translation from intent to implementation. That’s not a threat to developers. It’s liberation from a job we were never really hired to do in the first place.
Think about what actually creates value in software development – and I mean real, durable, competitive value. It’s not the ability to write clean code. It’s never been that. It’s understanding what problem you’re actually solving. It’s knowing your business domain so deeply that you can see connections others miss. It’s architectural thinking – knowing how to decompose complexity, how systems interact, where to invest in flexibility versus where to optimize for simplicity. It’s recognizing when your organization’s structure is about to break under the weight of success. It’s understanding that every technical decision is a business decision wearing a different hat.
That’s the work that was always valuable. We just had to be really good at code syntax to get access to it. Now we don’t. That’s not disruption. That’s clarification.
What This Feels Like for the People Living It
In my experience, watching this unfold is fascinating. The developers handling it best aren’t panicking about AI replacing them. They’re getting slightly angry about the time they wasted on details they never cared about. They’re remembering why they got into this in the first place – to build things that matter, to solve interesting problems, to understand how organizations work.
For me, this moment feels different. I spent years being the person in meetings who kept asking “But what’s the actual business problem?” while everyone else wanted to discuss which framework to use. I built domain models on whiteboards while my peers optimized database queries. The market told me I was doing it wrong – that real developers wrote code, not business specifications.
I’ve been in conversations with CTOs and senior architects over the past few months, and there’s a peculiar emotional pattern. First comes recognition: “Oh, this is actually changing what we do.” Then comes a strange mix of relief and loss. Relief because the grind of debugging syntax errors in production at 3 AM feels less like a necessary badge of honor. Loss because, ironically enough, mastering that grind became how we proved our worth to the organization.
But for those of us who always believed the business problem was the real work? This doesn’t feel like loss. It feels like validation. Like the profession is finally catching up to where it should have been.
The Uncomfortable Truth We’re Avoiding
Here’s what nobody’s saying clearly enough: this shift has been necessary for 20 years. The moment we could have separated the “understanding what to build” work from the “translating that into code” work, we should have. We didn’t, mostly because it was economically convenient not to. One person doing both jobs, despite being inefficient, was simpler than managing interfaces between roles.
It’s funny, returning to disciplined specification and domain-driven design – approaches that were state-of-the-art in the era before we all became cowboys with text editors – feels innovative now. We’re not discovering something new. We’re recovering something we abandoned because we got distracted by the technical complexity we created for ourselves.
The developers thriving in this transition aren’t the ones who stayed narrowly focused on becoming deeper experts in their chosen language. They’re the ones who always spent half their time in meetings understanding business requirements, pushing back on vague specifications, asking uncomfortable questions about why we were building what we were building. Those people suddenly find their skills are what organizations actually need, and they can finally spend less time proving they understand Python and more time proving they understand the business.
What Becomes Valuable Now
The practical skills that matter are shifting with startling clarity. Domain knowledge – understanding your industry, your market, your competitors, your regulatory environment – moves from “nice to have context” to essential. Business modeling becomes a first-class engineering discipline rather than something we squeezed into requirements documents. Systems thinking – the ability to see how components interact, where bottlenecks will emerge, how changes propagate – becomes more central than ever.
And this is crucial: the developers who understand how to work effectively across organizational boundaries become disproportionately valuable. That means collaboration, communication, the ability to explain technical implications in business terms. It means understanding how your technology decisions shape organizational culture and capability. It means seeing technology strategy as inseparable from business strategy.
These aren’t new ideas. Anyone familiar with TOGAF frameworks, domain-driven design, or even the original systems thinking approach from the 1970s already knows this territory. What’s new is that now we can actually invest in developing these capabilities without sacrificing our ability to deliver working code. AI handles the code. We finally get to focus on the architecture, the design, the strategy. The actual thinking.
The Question For You
This series will explore where our profession is headed as this shift accelerates. We’ll look at what this means for hiring, for career development, for organizational structure, and for what it actually means to be a “senior” developer in 2026 and beyond. We’ll also confront some uncomfortable truths about where we took a wrong turn and what it means to find our way back.
But before we go further, I’m curious: where do you fall in this? Have you always felt that code was the burden and the business problem was the interesting part? Or are you realizing this for the first time as AI changes the economics?
And more importantly, if you didn’t have to prove your worth by mastering syntax, what would you actually focus on? Because that’s the real question hiding beneath all of this. Not “will AI replace me?” but “what do I actually want to do now that I finally can?”
—
Series Overview: This is Part 1 of 8 in “The Future of Our Profession: Back to the Future,” exploring how AI is returning developers to their true strategic role – business and domain modeling – and what that means for how we work, build organizations, and think about our careers.
Coming Next: Post 2: “We Were Information Systems Professionals First” – exploring the historical roots of where we’re headed, and why this shift is really a return.
Recent Comments