With AI acquiring the skills of the Software Engineer, AI vs Software Engineer has become a question no engineer can ignore.
Understanding the journey of artificial intelligence alongside the evolution of the Software Engineer is the first step to understanding why today’s AI feels different — and why it’s completely normal to feel a little unsettled by it.
AI didn’t arrive with ChatGPT.
AI is the product of more than seventy years of breakthroughs, setbacks, and quiet persistence.
Over the same period, software engineering has continually evolved in response to new technologies — from structured programming and object-oriented design to the internet, agile development, cloud computing, DevOps, and now generative AI.
Every major shift has changed how engineers work, but AI feels different because it can increasingly participate in the engineering process itself.
I’ve spent more than two decades building software in financial services, watching these changes unfold from the front line.
Nothing in that time compares to the acceleration AI has brought to how I work today.
My goal isn’t to convince you that AI is either revolutionary or overhyped. I aim to help you separate genuine transformation from the noise so you can make better decisions about your own career.
This series is for experienced software engineers wondering:
- Whether AI will replace software engineers
- How AI is changing software development
- What skills experienced engineers need to stay relevant
To explore those questions, let’s get some context from how AI and the software engineering profession evolved side by side, and why that history matters.
1. The Theoretical Era (1950s–1970s)
AI could reason in theory; engineers were still coding by hand.
In 1950, Alan Turing asked the question that started it all:
Six years later, the Dartmouth Workshop formally gave the field its name: Artificial Intelligence.
Early progress on neural networks and the first chatbot showed flashes of promise, but computers of the era didn’t have the memory or data to back up the ambition — funding dried up, and the first “AI Winter” set in.
Software engineering itself was barely a discipline yet — no compilers to speak of, no version control, code written directly for the mainframe in front of you.
By 1968 the growing pains had a name: the software crisis.
Computing power was racing ahead of programmers’ ability to use it well, and projects routinely blew their budgets or became unmanageable.
Fred Brooks, reflecting on his own work managing IBM’s OS/360, called skipping a coherent architecture up front a multimillion-dollar mistake.
This era, for both AI and engineering, was about learning the hard way how easily ambition can outrun discipline.
2. The Expert Systems Era (1980s)
AI learned to advise; engineers learned to structure.
With nowhere near enough data or compute to let a machine learn on its own, the only practical path to “intelligence” was to hand-encode a human expert’s rules directly into software.
One of the earliest demonstrations of AI delivering real business value was MYCIN, built to help diagnose bacterial infections.
But the same rigidity that made expert systems useful also made them brittle: rule bases became expensive to maintain and broke the moment real-world cases didn’t fit the script.
Government funding cuts and a collapsing market for specialised “Lisp machines” defined the second AI Winter that followed.
Engineers, meanwhile, were getting their first real tools:
- C brought structure to how software got written
- Waterfall gave large projects a defined (if rigid) process for the first time.
Deploying software still meant physical media or an isolated company mainframe — nothing like the rapid releases we have today.
3. The Data Revolution (1990s–2000s)
AI learned from data; engineers learned to move faster.
IBM’s Deep Blue Supercomputer beating reigning chess world champion Garry Kasparov in 1997 showed machines could out-calculate humans in narrow domains.
More quietly, the rise of the internet gave researchers something they’d never had before:
Enough data to make statistical learning genuinely useful, powering the first generation of search engines and spam filters.
Engineers rode the dot-com wave into Java, the early web and open-source tools like Linux, while the Y2K scramble forced a generation of legacy systems to finally be rewritten.
Version control and the 2001 Agile Manifesto began pulling the industry away from rigid, upfront planning toward iterative delivery.
This is the window I actually entered the industry through — and not by the direct route.
I’d stepped away from the idea of university and was working as a bank teller at Barclays, saving to fund what I thought would be a safer path into accounting.
Then Barclays began computerising cash management, and I was fast-tracked onto the new system, becoming the one person on the floor who knew how to balance the books on it — my first real taste of technology solving a genuine problem.
I remember the last night of 1999 too — staying up with the team past midnight, reassuring management and clients that the transition into 2000 would hold, and watching the systems tick over without incident.
Night shifts at the airport gave me the hours to teach myself word processing, spreadsheets, and databases, and eventually the savings to fund evening classes in computer science.
That path led to a BSc in Information Systems, an MSc in Distributed Computing in the UK, a stint in IT audit at EY, and finally, in 2007, a graduate seat at JPMorgan as a software engineer.
4. The Deep Learning Revolution (2010s)
AI learned to see; engineers learned to own the whole system.
The DeepMind Go Challenge Match of AlphaGo vs world champion Lee Sedol in 2016 in which AlphaGo won 4-1, was the moment AI entered mainstream public consciousness — a game long assumed too intuitive for machines.
A year later, Google’s Transformer architecture gave the field the foundation nearly every AI model today is built on.
Engineering was being remade by two very specific pieces of technology:
- Docker in 2013, which made packaging an application with everything it needed trivial
- Kubernetes a year later, which made running thousands of those containers at scale possible.
Together they turned microservices from a nice idea into something teams could actually ship — and DevOps culture, captured in Amazon’s line “you build it, you run it,” made engineers responsible for systems end to end, not just the code.
This is exactly where I fully embraced real full-stack engineering.
Not just writing code, but:
- Sitting with traders to shape requirements
- Building the pricing systems and the UI on top of them
- Learning how every part had to fit together to deliver the end product.
We built a real-time FX pricing and trade execution platform from scratch for JPMorgan’s London trading desk, then grew it across regions with a small team spanning London and Singapore.
By 2017 I’d moved into OTC Derivatives on a transformative four-year programme migrating 27 products from Java onto JPMorgan’s strategic event-driven Python and React platform — my first real deep dive into Python and its simplicity.
This is where I learnt to own systems end to end, understanding the business domain (the what and why) and how the system actually works.
It’s also the closest thing to a preview of Part 5 in this whole post — ownership, not syntax, is what actually got rewarded.
5. Generative AI Goes Mainstream (2020–2023)
AI learned to create; engineers learned to collaborate with it.
GitHub Copilot quietly arrived in 2021.For many software engineers, that was the real first contact with AI at work.
This was the beginning of AI and Software Engineering Convergence.
In November 2022, ChatGPT put a capable, conversational AI into hundreds of millions of hands almost overnight.
By 2023 models could handle images and increasingly sophisticated reasoning.
For engineers, this is the moment the daily toolkit changed for the first time in over a decade — IDEs went from reactive (autocomplete) to generative (writing whole functions, explaining unfamiliar code).
Around this time I was pulled onto a struggling team at Visa, where the relationship with the business had broken down and delivery had stalled.
The first year was less about code and more about rebuilding trust — growing both the size and confidence of the squad, turning contractors into a stable team of engineers we could actually invest in.
As it happened, the same people I mentored were the first ones pulled onto our early AI adoption projects once they landed — exactly the kind of role reshuffle we’ll dig into properly in Part 4.
My own first contact with Copilot was around then too — limited in what it could reason about, but it was already writing tests and code I hadn’t explicitly asked for.
6. The Agentic Era (2024–2026)
AI learned to act; engineers learned to lead it.
March 2024 brought reasoning models that plan and check their own work rather than just predicting the next word.
A startup called Cognition unveiled Devin, billed as the first “AI software engineer”.
Devin was capable of planning and executing tasks end to end — a genuine cultural flashpoint, even as its real-world performance sparked plenty of debate.
By early 2025, Andrej Karpathy had coined a term for a new way of building software altogether:
“Vibe coding“:
describing what you want in plain language and letting an agent write, test, and ship it.
For engineers, the job split in two directions from there: some work became genuinely “vibe coded” — fast, disposable, low-stakes. Everything else moved toward what practitioners now call:
Agentic Engineering:
supervising an agent that plans, writes, tests, and opens pull requests while you do something else — closer to managing a capable junior engineer than typing alongside one.
By 2026, knowing when to trust an agent’s output, and when not to, had become as core a skill as writing the code ever was.
That judgement call is precisely what Part 3 is about.
Using Cline, I built a personal project I’d wanted to make for years:
My Networth: An application that gives you a single number that represents your net worth consolidating data on all your assets/liabilities.
Not long after that: Claude arrived properly on the terminal.
All those years spent getting comfortable with git and the command line turned out to matter more than I expected.
The tools changed. The value of strong engineering fundamentals didn’t.
Claude on the terminal is, for now, simply how I work by default — and it’s shaping how I’m leading the cross-border payments redesign at Visa today.
The Bigger Picture
The pattern across seventy years looks like this:
Each phase expanded what machines could do — and each phase also reshaped what it meant to be a software engineer.
What’s different now is that AI isn’t just analysing information anymore — it’s acting on our behalf.
And that’s exactly why AI tooling now feels different from every wave of developer tooling that came before it.
The question isn’t whether AI can write code — clearly, it can.
It’s what happens next:
which parts of the engineer’s role are already disappearing, which are being created, and which no agent can touch yet.
That’s exactly where Part 2 picks up. Get it in your inbox when it publishes:
the rest of this series:
- Part 1 - How AI Got Better Over 70 Years (This post)
- Part 2 — What AI Does Better Than Software Engineers: the specific tasks AI already does better, told through the tools actually in use today.
- Part 3 — Where Software Engineers Still Beat AI: the skills that don't show up in a benchmark but decide whether a system survives contact with production.
- Part 4 — How AI Is Redefining Software Engineering Roles: which roles are shrinking, which are being reshaped, and which are brand new.
- Part 5 — How to Future-Proof Your Career: what to actually do about all of this, starting this quarter.
