Software Engineering Has Changed, But Not How You Think
There’s a lot of noise right now about AI replacing software engineers or making everyone 10x more productive overnight. I want to cut through that noise with an honest account of what has actually changed in my day-to-day work as a Senior Software Engineer who delivers large-scale, mission-critical production systems.
No hype. No bragging. Just what I do now versus what I did three years ago.
What Hasn’t Changed
We still discuss backlog items. We still talk with clients, business analysts, sales teams, product teams, and project managers. We still identify requirements, break them down into Jira tickets, and squeeze in tech debt tasks wherever we can.
This part of the job is exactly the same. If anything, the demand on this front has increased, because our delivery rate is faster now, the pipeline of work flowing in is denser. Stakeholders expect more because they’ve seen what’s possible.
The fundamentals of software engineering: understanding requirements, managing complexity, owning your deliverables, none of that has changed.
What Has Changed: Understanding the Codebase
Three years ago, when I picked up a sprint task, I would go through the code line by line. I’d trace the existing flow, map out dependencies, and check production logs to understand how things behaved in real-time. Then I’d carefully draft my plan and sometimes discuss it with my team before writing a single line of code.
Now, I start by asking Claude Code to summarise the relevant flow and highlight the key areas of the project related to the change I’m about to make. I use the java-pro agent and several other tools that Claude Code provides to build context quickly.
This is a genuine time saver. Instead of spending hours reading through unfamiliar modules, I get a solid mental model in minutes and then verify the parts that matter most.
What Has Changed: Planning and Design
This is where things get interesting. I now have a long back-and-forth discussion with Claude Code about the plan. I ask it to evaluate the approach from different angles, edge cases, failure modes, scalability concerns.
Is it perfect? No. Sometimes Claude Code misses obvious design considerations that any experienced engineer would catch. And when I point these out, it enthusiastically agrees, “You’re absolutely right!” as if it had a sharp-mind-detecting sensor built in.
But here’s the thing: even an imperfect sounding board accelerates your thinking. Having something to react to is faster than starting from a blank page.
What Has Changed: Implementation
Once the plan is solid, I ask Claude Code to implement it, including all the test cases. It generates the models, interfaces, logic, and tests.
And then I go through every line.
Because it is still my responsibility when this change goes to production.
I review each line of code and each test case. I refactor. I clean up. I rename variables to something that actually makes sense. I rewrite log messages. Sometimes I add or remove entire classes or methods to make the code more readable and maintainable.
The AI gives me a strong first draft. I turn it into production-ready code.
The Honest Productivity Take
Is this faster than three years ago? Yes, without question.
Is it 10x faster? Not even close.
I see a lot of claims from the “vibe coding” crowd about massive productivity gains. And I think those claims come from a very specific context, greenfield projects, personal tools, prototypes, or applications where breaking something doesn’t wake anyone up at 3 AM.
When you’re delivering changes to large-scale production systems that real businesses depend on, the equation is different. The coding itself was never the bottleneck. The bottleneck was always understanding the problem, making the right design decisions, and making absolutely sure you don’t break what’s already working.
AI tools have compressed the mechanical parts of the job. But the parts that require judgment, ownership, and accountability? Those are still entirely on you.
What I Actually Think
Software engineering has genuinely changed. AI tools are part of my daily workflow now, and I wouldn’t want to go back. But the change is more like going from a hand drill to a power drill, not from walking to flying.
You still need to know where to drill. You still need to know how deep. And you’re still the one responsible if you drill into a pipe.
The engineers who will thrive are the ones who use these tools to move faster while still owning every line that ships. The ones who treat AI output as a first draft, not a final answer.
That’s the reality from someone who ships to production every day. No 10x. Just a genuinely better workflow, and the same weight of responsibility it’s always been.