AI is helping us write code faster.
But the interesting part for me is not the amount of code it can generate.
It’s how much the job around the code is changing.
After 15+ years working in tech, I’ve seen a lot of tools promise to make developers faster.
Better IDEs. Better frameworks. Better cloud platforms. Better libraries.
AI feels different because it can actually do part of the implementation.
And because of that, I notice something interesting:
the less time we spend typing every line ourselves, the more time we need to spend thinking about whether those lines make sense.
That sounds obvious.
But I think it changes the job more than people realize.
Writing code was never the whole job
Software engineering has never been only about writing code.
Even before AI, a lot of the work was already outside the editor.
Understanding the requirement.
Finding the real problem.
Reading old code.
Talking to product.
Looking at logs.
Reviewing a pull request.
Trying to understand why someone made a weird decision three years ago.
Deciding if something should be fixed now or left alone.
The code is important, of course.
But it’s just one part of the process.
AI makes that easier to see because it can now handle more of the part we used to associate directly with being a developer.
You can describe what you want and get a first implementation.
You can generate tests.
Ask for a refactor.
Generate SQL.
Create documentation.
Explain an unfamiliar part of the codebase.
Sometimes it works really well.
Sometimes it confidently gives you something that looks perfectly reasonable and is completely wrong.
And that second part is where engineering still matters a lot.
Fast code can still be bad software
One thing I think we need to be careful about is confusing faster coding with faster software development.
They’re not exactly the same thing.
Imagine AI gives you a feature in ten minutes.
Nice.
But then you still need to ask:
Does this fit the existing architecture?
Does it handle the important edge cases?
Is the database query going to become a problem with real traffic?
Did it copy logic that already exists somewhere else?
Did it introduce another dependency we don’t really need?
What happens when this fails?
Does the feature even solve the problem the user has?
Generating the implementation faster doesn't remove those questions.
Sometimes it gives you more of them.
That’s why I think the more AI writes code, the more important context becomes.
The model sees the prompt.
The engineer needs to see the system.
The skill is moving from typing to judging
I don't think coding skills are becoming useless.
Far from it.
You need technical knowledge to know when generated code is bad.
If you don't understand the system, it's very easy to accept something because it looks correct.
Good variable names.
Clean functions.
Tests passing.
Everything looks nice.
But maybe the design is wrong.
Maybe the abstraction shouldn't exist.
Maybe the test is proving the wrong thing.
Maybe there is already a simpler solution in the codebase.
This is why I keep coming back to judgment.
Not “is this code valid?”
More like:
is this a good decision for this system?
That question is much harder to automate.
Good prompts help. Good context helps more.
There’s a lot of discussion about prompt engineering.
I think prompts matter.
But in software development, context matters much more.
A coding agent needs to understand things like:
- how the project is structured
- which patterns the team uses
- what should not be changed
- where the important business rules live
- how tests are written
- what “done” actually means
Without that, you can get perfectly reasonable code that doesn’t belong in the project.
This is also why working with an existing codebase is much harder than generating a demo from scratch.
A new project has almost no history.
A real product has years of decisions inside it.
Some good.
Some bad.
Some nobody remembers.
And a lot of engineering is understanding those decisions before touching anything.
AI can help you explore that faster.
But someone still has to understand the context well enough to know what matters.
I think code review becomes even more important
When generating code is cheap, generating more code becomes easy.
That’s both useful and dangerous.
A developer can now produce a much bigger change in the same amount of time.
That means reviewing changes becomes more important, not less.
And I don’t mean reviewing whether the syntax is correct.
I mean reviewing the decision.
Why are we changing this?
Why this approach?
Why these files?
What assumptions did the agent make?
What did it not understand?
Is the change bigger than it needs to be?
Personally, I’d rather review a small boring change I understand than a beautiful 40-file refactor nobody can explain.
AI can make large changes look cheap.
Maintaining them later is still very real.
Knowing what not to build matters more
This might be the biggest change for me.
When implementation becomes easier, saying “yes” to ideas also becomes easier.
Can we add this?
Sure.
Can we automate that?
Probably.
Can we build an internal tool for it?
Give the agent a few minutes.
But every feature still creates something we need to maintain.
More code.
More states.
More bugs.
More support.
More things users can depend on.
AI makes the cost of creating software smaller.
It doesn’t make the cost of owning software disappear.
So I think product thinking becomes even more important for engineers.
Before asking how quickly we can build something, we still need to ask:
should this exist at all?
The engineers I think will do well with AI
I don’t think it will simply be “the people who use the most AI.”
It will probably be the engineers who combine AI with strong fundamentals.
People who can understand a system.
Break a vague problem into smaller pieces.
Give useful context.
Spot when the output doesn’t make sense.
Think about tradeoffs.
Communicate clearly.
Understand the product.
And know when to ignore what the model suggests.
That last one matters.
A tool can be very good and still be wrong.
Experience helps you know when something feels off.
I’m still learning how this changes the job
We’re early.
I don’t think anybody knows exactly what software engineering looks like five years from now.
And I’m suspicious of anyone who says they do.
But one thing already feels clear to me.
Writing code is becoming cheaper.
Good judgment isn’t.
If anything, when we can build more things faster, choosing the right things becomes more important.
The job might involve less typing.
But I don’t think it involves less thinking.
Probably the opposite.
I’ve been working in tech for 15+ years and write about software engineering, AI, product thinking, and working internationally.
I’m also on X as @justanderson if you want to connect there.
Top comments (0)