Yet I'm Building More Software Than Ever.
Artificial Intelligence didn't reduce the amount of engineering I do.
It changed what engineering looks like.
Introduction
Five years ago, I measured my productivity the same way many software engineers did.
How many pull requests did I merge?
How many features did I finish?
How many lines of code did I write?
How many bugs did I fix?
The assumption seemed obvious.
Writing more code meant creating more value.
Looking back, I don't think that assumption was ever completely true.
It was simply the easiest thing to measure.
Today, my workday looks completely different.
I spend significantly less time writing implementations.
Instead, I spend most of my time reviewing AI-generated code, designing architectures, defining business rules, modeling data, validating assumptions, creating evaluation pipelines, and thinking about how systems should evolve over the next several years.
Ironically...
I'm shipping more software than ever before.
That observation completely changed how I think about software engineering in the age of AI.
The Industry Is Measuring The Wrong Thing
Whenever a new coding model is released, the conversation almost always follows the same pattern.
Can it solve LeetCode?
Can it build a CRUD application?
Can it generate a React frontend?
Can it create a REST API?
Can it write unit tests?
These are interesting benchmarks.
They're also increasingly irrelevant.
Because production software has never been limited by typing speed.
The bottleneck has always been something much harder.
Understanding.
Understanding users.
Understanding businesses.
Understanding systems.
Understanding trade-offs.
Those are the activities that determine whether software survives long after the demo.
Software Engineering Has Always Been About Decisions
One misconception I frequently see is the idea that software engineering is fundamentally the act of writing code.
Code is important.
But code is the output.
Engineering is the decision-making process that produces that output.
Every production system is the result of thousands of decisions.
Should this service own the data?
Where should validation happen?
How do we recover from failures?
Who owns this business rule?
How should permissions evolve?
How do we audit automated decisions?
These questions exist long before the first function is written.
AI has become remarkably good at generating implementations.
It has not eliminated the need to answer those questions.
If anything, it has made them more important.
The Economics Of Software Development Have Changed
Economists often describe technological progress as reducing the cost of production.
The same principle applies to software engineering.
For decades, writing software was expensive.
Developers spent countless hours implementing boilerplate code.
Authentication.
Validation.
Database models.
Configuration.
Documentation.
Infrastructure.
Much of that work can now be generated in minutes.
The cost of implementation has fallen dramatically.
Whenever the cost of one activity decreases, another activity becomes relatively more valuable.
In software engineering, that activity is judgment.
AI Didn't Eliminate Engineering
It Eliminated Friction
This distinction is incredibly important.
Many headlines suggest that AI is replacing software engineers.
I think something much more interesting is happening.
AI is replacing friction.
The repetitive friction of implementation.
Generating another API endpoint.
Writing another serializer.
Creating another migration.
Formatting another configuration file.
These tasks still matter.
But they no longer dominate the engineering process.
The result is that engineers can spend more time solving problems rather than translating solutions into syntax.
That shift is subtle.
It is also profound.
A Personal Observation
Over the past several months, I have been building a Transaction Intelligence System designed for enterprise financial automation.
Initially, I assumed that the AI model would be the most difficult part of the project.
I was wrong.
Training the Named Entity Recognition model was relatively straightforward.
The difficult work happened before training ever began.
Designing canonical data structures.
Creating synthetic enterprise datasets.
Defining business taxonomies.
Building entity resolution pipelines.
Designing evaluation frameworks.
Understanding reconciliation workflows.
Those tasks consumed far more time than writing Python.
Interestingly, AI accelerated almost every implementation step.
It never removed the need to understand the business.
That realization fundamentally changed how I use AI.
Instead of asking:
"Can AI write this code?"
I began asking:
"What problem should this system actually solve?"
The second question consistently produced better software.
The New Bottleneck
Today, generating software is relatively inexpensive.
Understanding complexity is not.
When an engineer receives a feature request, the challenge is rarely implementing it.
The challenge is interpreting everything that wasn't written down.
Hidden business rules.
Historical decisions.
Regulatory constraints.
Security requirements.
Data ownership.
Failure scenarios.
These forms of organizational knowledge rarely exist inside documentation.
They exist inside conversations, experience, and institutional memory.
No language model can infer knowledge that has never been explicitly represented.
That means the engineer's role is shifting.
Not away from software.
Toward understanding.
Architecture Has Become A Multiplier
One insight continues to surprise me.
AI rewards good architecture.
It doesn't replace it.
When systems have:
- clear ownership
- consistent domain models
- explicit business rules
- modular services
- reliable interfaces
AI becomes dramatically more productive.
When those foundations are missing, AI simply generates complexity faster.
This is why architecture is becoming more—not less—valuable.
AI amplifies the quality of the system it operates within.
It doesn't compensate for its absence.
The Shift I Didn't Expect
When I first started using AI coding assistants, I thought they would help me write code faster.
They did.
But that wasn't the biggest change.
The biggest change was where my attention moved.
Less time typing.
More time reviewing.
Less time implementing.
More time designing.
Less time debugging syntax.
More time validating assumptions.
Less time memorizing APIs.
More time understanding organizations.
I didn't stop engineering.
I simply started engineering at a higher level of abstraction.
And I suspect this is where the profession is heading.
Top comments (0)