The Gods Shipped an API
What a 2003 programming book taught me about surviving the AI era
I recently reopened an old Korean programming book published in 2003: 프로그래머 그들만의 이야기 — roughly, Stories Only Programmers Tell.
I expected nostalgia.
Java. .NET. Open source. Mobile. Databases.
The archaeological layers of software engineering.
Instead, I found a discussion that felt strangely relevant in 2026.
The author wondered what would happen if technology eventually made writing software dramatically easier.
His conclusion was that individual programming tasks might become simpler while software systems themselves continued becoming larger and more complicated.
Therefore, simply being good at coding would eventually not be enough.
Engineers would need to understand the bigger picture:
systems, design, architecture, and technical decision-making.
That was written before modern cloud computing.
Before smartphones took over daily life.
Before Kubernetes.
Before large language models.
Before coding agents.
The author also suggested that full software automation probably wouldn't happen anytime soon.
Possibly not for a very long time.
Well.
Twenty-three years later, apparently the gods shipped an API.
We've Seen This Movie Before
Software engineers have repeatedly been told that some new abstraction would make programmers unnecessary.
Higher-level languages.
Object-oriented programming.
Visual development tools.
Open source.
Offshore development.
Cloud computing.
Low-code.
And now AI.
Usually something funny happens.
The new abstraction really does make one layer easier.
And then we use the saved productivity to build something three times more complicated.
A database application once needed a database.
Then it needed a server.
Then a web application.
Then authentication.
Then caching.
Then containers.
Then orchestration.
Then telemetry.
Then security policies.
Then compliance.
Then multi-region deployment.
Then someone joins the meeting and asks:
“Can we make this active-active across regions?”
And somewhere, an engineer quietly closes LinkedIn.
The abstraction simplified one layer. We promptly used the spare capacity to create twelve more.
The 2003 book noticed this pattern surprisingly early.
New technologies simplify individual programming tasks, while the total scope of software keeps expanding.
But AI feels different from many previous abstractions.
It doesn't merely hide memory management or automate deployment.
AI can increasingly:
- read unfamiliar code
- write code
- generate tests
- explain repositories
- inspect logs
- summarize failures
- draft documentation
- propose migrations
- review changes
- execute multi-step engineering tasks
So I don't think the right response is:
“Relax. AI is just another tool.”
It is another tool.
It's just a rather large one.
My Old Model of Software Engineering
For much of my career, software engineering looked approximately like this:
Understand problem
↓
Design solution
↓
Write code
↓
Debug
↓
Test
↓
Ship
↓
Operate
A huge amount of professional identity lived in the middle:
Write code.
That made sense.
Implementation was expensive.
Turning complicated ideas into reliable software was difficult.
Good engineers were valuable partly because they could do that consistently.
AI is beginning to compress that middle section.
The workflow increasingly looks more like this:
Understand the problem
↓
Define intent and constraints
↓
Design the system
↓
Delegate implementation
↙ AI Human ↘
↓
Verify aggressively
↓
Integrate
↓
Operate
↓
Own the outcome
That changes where engineering value sits.
And at this stage of my career, that question interests me much more than whether AI can generate another thousand lines of code.
The Book Also Talks About Programmers After 50
One of my favorite sections discusses career longevity.
The author says he hoped to remain a programmer after age 50.
But his image of an experienced programmer was not someone desperately trying to type faster than a 25-year-old.
Instead, he imagined someone who could:
- review code
- improve architecture
- help younger engineers
- participate in design
- make good technical decisions when projects became difficult
That seems even more relevant in the AI era.
Experience isn't valuable because older engineers remember more syntax.
Search engines already reduced the value of memorizing syntax.
AI reduces it further.
Experience becomes valuable because you've seen things fail.
You begin asking different questions.
An earlier version of me might ask:
“How should I implement this?”
A more experienced version increasingly asks:
“Should this exist?”
“Who owns this state?”
“What happens when this partially fails?”
“How will we detect corruption?”
“What's the rollback strategy?”
“Which assumption are we making without realizing it?”
“How do we know the AI-generated answer is actually correct?”
Those questions are annoyingly resistant to autocomplete.
So I'm Changing My Own Job Description
The evolution I have in mind now looks something like:
Software Engineer
↓
Senior Software Engineer
↓
System Owner
↓
AI-Native Technical Owner
That last role is the interesting one.
I don't mean “prompt engineer.”
I don't mean someone who memorizes every new agent framework.
I definitely don't mean someone posting:
“AI wrote 14,000 lines of code before lunch 🔥”
without mentioning that nobody has read line 8,421.
Fourteen thousand lines before lunch. Verification is apparently the afternoon shift.
I mean an engineer capable of understanding a complicated system deeply enough to determine:
What should the machine do?
What should remain a human decision?
What does “correct” actually mean?
How will we verify the result?
Where should humans approve or intervene?
Who is accountable when reality disagrees with the demo?
That last question matters.
Reality has an unfair advantage over demos.
Reality has users.
AI Changes the Value of Implementation
Over the years I've worked on large software systems involving data, services, reliability, performance, and production operations.
Imagine a generic production environment where an engineering agent could:
read architecture documentation
↓
inspect telemetry
↓
investigate a failure
↓
generate diagnostic queries
↓
correlate resource pressure with runtime behavior
↓
propose several root-cause hypotheses
↓
suggest tests
↓
draft an incident summary
That would be extremely useful.
But I wouldn't initially want this:
AI thinks something is wrong
↓
AI changes production
↓
Everyone discovers what "something" meant
I'd rather begin with:
AI:
"I think this failure resulted from resource pressure
causing execution time to exceed a safety threshold."
Engineer:
"Show me the evidence."
AI:
"Here."
Engineer:
"Now show me three plausible reasons you might be wrong."
Now we're getting somewhere.
Eventually, for sufficiently understood operations:
AI proposes
↓
Human approves
↓
System executes
↓
Telemetry verifies
At that point, the engineer's role changes.
Instead of simply operating a system, an experienced engineer begins encoding how experienced engineers reason about operating systems safely.
That can scale much farther than a keyboard.
The Surprisingly Important Skill: Verification
For decades, software engineering emphasized creation.
Can you build it?
AI makes creation cheaper.
And when creation becomes cheaper, something else becomes expensive:
trust.
Tests.
Invariants.
Observability.
Evals.
Canaries.
Rollback.
Security boundaries.
Data validation.
Failure isolation.
These may stop looking like supporting engineering activities.
They may become central engineering skills.
The 2003 book repeatedly emphasizes fundamentals, logical thinking, testing, and reducing bugs instead of endlessly chasing new technologies.
That advice aged remarkably well.
Possibly better than some of the technology predictions.
I Don't Think the Answer Is “Become an AI Engineer”
It's tempting to look at 2026 and conclude:
AI is the future
↓
I should become an AI engineer
But that skips an important question.
What exactly would I throw away?
Years of experience with:
- distributed systems
- production failures
- data platforms
- performance
- reliability
- operations
- technical trade-offs
- business context
Those things don't become obsolete because a model can generate Python.
They may actually become more useful when combined with AI.
So my personal equation looks more like:
Distributed Systems
+
Data / Domain Knowledge
+
Agentic AI
=
A useful place to be
Rather than:
Decades of engineering experience
↓
rm -rf
↓
Hello World with NewAgentFramework.js
I've restarted enough software projects.
I don't need to restart myself.
I have restarted enough software projects. I do not need to reinstall my career.
The Old Book Had Another Good Idea: “Me Inc.”
One of the final chapters of the book is titled:
“IT 전문가의 미래 — Me Inc.”
I like the framing.
Think of yourself as a tiny company.
Your employer matters.
But your employer is not your entire career.
Your technical skills are assets.
Your experience is intellectual capital.
Your professional network is optionality.
Your writing is distribution.
Your experiments are R&D.
Your reputation is brand.
Your salary is currently the largest customer contract.
That last sentence sounds slightly ridiculous.
Which means I'll probably remember it.
The important point is not that everyone should quit and become independent.
Quite the opposite.
The goal is to become increasingly valuable where you are while not allowing one organization to completely define your professional value.
That means continuing to invest in:
- technical depth
- architecture
- communication
- writing
- system design
- AI-assisted engineering
- external learning
- the ability to explain complicated things clearly
A resilient distributed system shouldn't depend completely on one node.
Maybe a career shouldn't either.
What I'm Changing Now
My strategy for the next several years is becoming fairly simple.
1. Use AI Heavily — But Don't Outsource Judgment
I want agents doing more:
- exploration
- synthesis
- implementation
- testing
- investigation
But humans still need to define what “good” means.
AI usage itself isn't the metric.
Better engineering outcomes are.
2. Move From Code Ownership Toward System Ownership
The smaller and more isolated a coding task is, the easier it becomes to automate.
The interesting problems increasingly live across boundaries:
software
data
infrastructure
operations
security
cost
reliability
users
Those boundaries are where I want to spend more time.
3. Get Unusually Good at Verification
If AI generates more implementation, engineers need to become excellent at determining whether generated work is correct.
This means testing not only code.
It means testing assumptions.
4. Keep Writing
Architecture notes.
Technical journals.
Design explanations.
Postmortem thinking.
Public engineering notes when appropriate.
Writing forces fuzzy thoughts to become explicit.
It also turns personal knowledge into reusable knowledge.
And reusable knowledge is leverage.
5. Compound Existing Expertise Instead of Chasing Every Trend
The book gives another piece of advice that still feels right:
Understand the broad technology landscape, but don't deeply learn every technology simply because it is new.
Go deep when it becomes relevant to an actual problem.
In 2003 that might have meant not learning every Java or .NET framework.
In 2026 it means I probably don't need to become an expert in every:
model
agent SDK
vector database
orchestration framework
protocol
Models will change.
Frameworks will change.
The durable ability is:
Understand an unfamiliar complex system, identify the real problem, design a robust solution, use AI to accelerate implementation, verify the result, explain the trade-offs, and take responsibility when it fails.
That's a career skill.
And Then There Is Physical AI
I'm also increasingly interested in robotics and Physical AI.
For now, I see that as a second lane rather than a complete career reset.
The progression is interesting:
Distributed Systems
↓
AI Agents
↓
Agents connected to physical systems
↓
Robots
↓
Software bugs can now hit furniture
This is exciting.
Software bugs with wheels also add cardio.
The software bug now has wheels, mass, and a small head start.
But the same principles carry over:
- architecture
- observability
- safety
- failure recovery
- human oversight
- system integration
The physical world is less forgiving than a cloud environment.
It has fewer rollback buttons.
Maybe the Programmer Was Never the Code
For most of my career, “programmer” and “writing programs” were almost synonymous.
That was reasonable.
Code was the primary medium through which we told computers what to do.
But maybe the deeper job was always:
Understand a problem deeply enough to make machines reliably do something useful.
For decades, manually writing code was the dominant way to accomplish that.
Now another abstraction layer is appearing.
AI increasingly writes some of the code.
That doesn't necessarily mean engineers disappear.
It means engineers have to move toward:
intent, architecture, verification, integration, judgment, and responsibility.
The old book ends up making a surprisingly modern point:
Software engineers eventually become people responsible for important parts of society's infrastructure.
That feels considerably more true in 2026 than it probably did in 2003.
I'm not planning to stop coding.
I still enjoy it.
I just don't want to measure my engineering value by the amount of code I personally produce.
That distinction feels increasingly important.
For the next five years.
Maybe ten.
I'll report back.
Assuming my agent hasn't taken over the blog by then.
About This Post
This essay was inspired by the 2003 Korean book 프로그래머 그들만의 이야기 and by my personal experience and observations as a software engineer.
It reflects my own views on software engineering, AI, career longevity, and the changing role of experienced engineers.
Examples are intentionally generalized and do not describe any particular employer, customer, proprietary system, or confidential project.