We’re entering an era where producing code is becoming easier. Understanding what we produce may be the harder and more valuable skill.
A few months ago, I was reviewing content for a SaaS client after their engineering team shipped a new feature much faster than expected.
On paper, everything looked great.
The pull request was clean.
The tests passed.
The feature worked exactly as it was supposed to during the demo.
And, understandably, the founder was pleased.
Then someone asked a fairly ordinary question during the handoff:
“Why did you choose this approach instead of the alternative?”
There was a pause.
Not the kind of pause where someone is searching for the best way to explain a complicated technical decision.
The kind where you realize the answer isn’t immediately there.
Eventually, the developer said something along the lines of:
“The AI suggested this approach. It worked, so I went with it.”
Nobody made a big deal out of it.
The conversation moved on.
But I kept thinking about that moment.
Because the problem wasn’t that the developer had used AI.
Of course he had.
Developers use AI every day now. Founders use it. Writers use it. Designers use it. Marketers use it. Entire teams are reorganizing their workflows around tools that can produce in seconds what once took hours.
The interesting part was something else.
The developer had working code.
But he didn’t completely own the reasoning behind it.
And I think that distinction is going to matter much more than we currently realize.
We’ve Solved Part of the Coding Problem
For a long time, one of the biggest barriers to software development was simply knowing how to make the computer do what you wanted.
You had to understand syntax.
You had to remember APIs.
You had to know which library to reach for.
You had to search documentation, dig through Stack Overflow threads, test different implementations, break things, fix them, and occasionally spend three hours discovering that the entire problem came from one character in the wrong place.
That process could be frustrating.
But something important happened while developers were struggling through it:
They built mental models.
You learned why certain approaches failed because you watched them fail.
You learned what bad architecture looked like because eventually you had to maintain it.
You learned to recognize suspicious code because you had already written enough suspicious code yourself.
Experience wasn’t only teaching you how to produce software.
It was teaching you how software behaves.
AI has changed that learning loop.
Today, you can describe what you want in ordinary language and get surprisingly competent code back.
Need an authentication flow?
Generate one.
Need a database query optimized?
Ask.
Need to refactor a messy function?
Paste it in.
Need tests?
Generate those too.
Need help understanding an unfamiliar repository?
AI can walk you through that as well.
This is an enormous productivity gain, and pretending otherwise would be pointless.
Small engineering teams can move faster.
Solo founders can prototype ideas without assembling a full technical team.
Junior developers can get unstuck without waiting hours for someone senior to become available.
Experienced engineers can offload repetitive work and spend more time on higher-level decisions.
There’s a lot to like here.
But there’s also a question we don’t ask often enough:
What happens when our ability to produce software starts growing faster than our ability to understand it?
That’s where things become interesting.
Working Code Can Create a False Sense of Confidence
One of the easiest traps in software is assuming that because something works, it must be understood.
Those are not the same thing.
Working code tells you:
“Under these conditions, this produced the expected result.”
Understanding tells you:
“I know why it produced that result, what assumptions it depends on, where it could fail, and what I would change if the conditions changed.”
That difference may not matter much when everything is going well.
It matters enormously when something goes wrong.
Imagine AI generates a function for you.
You run it.
The output looks right.
You add a few tests.
They pass.
You commit the code and move on.
Three months later, traffic increases dramatically.
Now the function that behaved perfectly with a few thousand records is becoming a bottleneck with several million.
Where do you start?
If you understood the implementation when you shipped it, you already have a mental map.
You know where the expensive operations are.
You know what compromises were made.
You know which assumptions were reasonable at the time.
You know where you’d begin investigating.
But if your relationship with the code was essentially:
«“The AI generated it, the tests passed, and nothing exploded,”»
you’re starting the debugging process almost like a stranger.
The code belongs to your repository.
But the reasoning behind it doesn’t fully belong to you.
That’s a dangerous position to be in.
AI Can Give You the Answer Without Giving You the Experience
This is one of the stranger things about AI-assisted development.
It can compress the distance between a question and an answer.
But it cannot automatically compress the distance between an answer and understanding.
Those are different journeys.
Think about how developers traditionally learned.
You tried something.
It failed.
You searched for an explanation.
You tried another approach.
That failed differently.
Someone more experienced reviewed your code and pointed out something you hadn’t considered.
You changed it.
Six months later, you encountered a similar problem and recognized it almost immediately.
That frustrating process was doing more than helping you finish a ticket.
It was building judgment.
AI can sometimes remove the struggle that created that judgment.
That isn’t necessarily bad.
We don’t need to romanticize wasting an afternoon debugging something an AI assistant could identify in ten seconds.
But removing unnecessary struggle means we need to become more intentional about preserving the learning that used to happen inside that struggle.
Otherwise, it becomes very easy to confuse access to expertise with having expertise.
They’re not the same.
I Notice This in Technical Writing Too
I’m a writer, not an engineer.
My work with technical companies often puts me in an interesting position: I have to understand a product, technical decision, workflow, or system well enough to explain it clearly to someone who wasn’t in the room when it was built.
That means I ask a lot of questions.
Sometimes irritatingly simple ones.
Why does it work this way?
What happens before this step?
Why did you choose this architecture?
What would happen if a customer did something unexpected here?
What makes your approach different from the obvious alternative?
Where does this process fail?
Those questions matter because strong technical content cannot survive on terminology alone.
You can fill an article with APIs, frameworks, infrastructure language, and architecture diagrams and still fail to explain anything meaningful.
The same thing happens in software.
I’ve had conversations where someone can tell me exactly what a product does but struggles when I ask why it works that way.
Sometimes the explanation becomes:
“The system handles it.”
Or:
“That part is automated.”
Or increasingly:
“The AI generated most of that.”
Those answers aren't useless.
But they usually tell me there’s another layer we haven’t reached yet.
Because if I’m going to turn someone’s knowledge into an article that developers will trust, I need the layer underneath the feature description.
I need the trade-offs.
The constraints.
The decision.
The reasoning.
The thing that made one implementation better for this particular product than five other technically valid implementations.
That’s usually where the interesting story is.
And increasingly, it’s also where I think the real value of technical professionals will live.
The Real Skill Gap May Be Moving
For years, we talked about the “developer skills gap” mostly in terms of production.
Could you code?
Did you know JavaScript?
Could you work with Python?
Did you understand SQL?
Could you build an API?
Could you deploy an application?
Those skills still matter.
But AI is lowering the cost of producing technically plausible answers to many of those questions.
That means another skill becomes more visible:
Can you evaluate what has been produced?
That includes questions like:
- Is this actually the right architecture for our use case?
- Is this secure?
- What assumptions is this implementation making?
- What happens under unusual inputs?
- Where are the performance bottlenecks likely to appear?
- Is this unnecessarily complicated?
- What happens when usage grows 10x?
- Is this dependency appropriate for something business-critical?
- Could another engineer maintain this six months from now?
- Are the tests checking meaningful behavior or merely confirming the happy path?
- What would make me reject this implementation even though it technically works?
Those aren’t primarily syntax questions.
They’re judgment questions.
And judgment is much harder to automate.
“The AI Said So” Won’t Survive Serious Scrutiny
There’s another reason this matters beyond engineering itself.
Technical decisions eventually have to be explained to other humans.
A senior engineer asks why you made an architectural choice.
A security reviewer asks how user input is being validated.
A customer wants to know how their data is handled.
An enterprise prospect asks about reliability.
An investor asks whether the system can support ten times the current usage.
A new developer joins the team and wants to understand why something was built in a particular way.
“The AI recommended it” is not a useful answer to any of those questions.
AI can be part of the decision-making process.
But it cannot be the final justification.
At some point, a human has to be able to say:
“We considered A and B. We chose B because of these constraints. Here are the trade-offs. Here’s what we’re monitoring. And if this assumption changes, we’ll reconsider the decision.”
That answer builds confidence.
Not because the engineer knows everything.
Good engineers rarely pretend they do.
It builds confidence because there is visible reasoning behind the decision.
And visible reasoning creates trust.
This Becomes a Business Problem Faster Than You Think
It’s tempting to treat this as an engineering concern.
It isn’t.
A lack of technical understanding eventually leaks into the rest of the business.
It shows up when customer support cannot get a clear explanation from engineering.
It shows up when marketing publishes inaccurate claims because nobody can explain the feature precisely.
It shows up when sales promises something the product architecture cannot comfortably support.
It shows up when documentation describes behavior that nobody fully verified.
It shows up when a founder struggles through a technical due-diligence conversation.
And it shows up when a company needs to explain its product publicly but realizes that much of the knowledge exists only in code, scattered Slack conversations, and AI-generated implementation decisions.
I once observed a technical due-diligence conversation where questions moved from the product itself to how the underlying system would behave as usage increased.
The product worked.
That wasn’t the problem.
The problem was that the answers became increasingly vague as the questions became more specific.
And once technical confidence disappears from a conversation like that, it is difficult to recover with a polished demo.
Because people aren’t only evaluating the software.
They’re evaluating whether the people responsible for that software understand what they’ve built.
That’s why explanation isn’t merely a communication skill.
In technical businesses, explanation is evidence of understanding.
So What Does It Mean to Actually “Own” AI-Generated Code?
I don’t think ownership means refusing to use AI.
That would be like refusing to use an IDE because “real developers” should write everything in a basic text editor.
Tools change.
Good professionals adapt.
The question is whether the tool expands your capability or quietly replaces your thinking.
A useful test is whether you can answer a few questions after accepting AI-generated code.
Can you explain what the code does without simply reading it back?
Not line-by-line translation.
Actual explanation.
What goes in?
What happens to it?
What comes out?
Where does state change?
What external systems are involved?
What assumptions are being made?
Can you explain why this implementation was chosen?
There are usually multiple ways to solve a software problem.
Why this one?
Was it simpler?
Faster?
More maintainable?
Better supported?
Easier for your team to understand?
More appropriate for your expected scale?
Can you identify how it might fail?
What happens with malformed input?
What happens when a dependency is unavailable?
What happens when two requests arrive simultaneously?
What happens when the database gets large?
What happens when a user behaves in a way nobody expected?
Could you change it without asking the AI to regenerate the whole thing?
This is an underrated test.
If a requirement changes slightly, can you reason through the change yourself?
Or do you immediately need another prompt because you don’t know where the modification belongs?
And perhaps the hardest one:
Could you defend this decision in front of someone more experienced than you?
Not because you need to win the argument.
But because defending a decision forces you to expose your reasoning.
If your entire explanation collapses into “that’s what the AI suggested,” you probably haven’t finished the work yet.
Five Habits That Make AI-Assisted Developers Better, Not More Dependent
The goal isn’t to slow yourself down until AI becomes pointless.
It’s to add small checkpoints that prevent speed from replacing understanding.
- Read the code before you run it
This sounds obvious.
It’s also surprisingly easy to skip.
AI makes execution frictionless:
Prompt → copy → paste → run.
Break that pattern.
Read the code first.
Try to predict what it will do.
Look for unfamiliar methods.
Check dependencies.
Look at how errors are handled.
Notice what the model assumed without being told.
You’re not merely reviewing the AI.
You’re building the mental model you’ll need later.
- Ask “Why this approach?”
Don’t stop at:
“Explain this code.”
That often produces a description.
Ask:
“Why did you choose this implementation instead of the main alternatives?”
Then ask:
“Under what circumstances would this be the wrong approach?”
Now you’re getting closer to engineering reasoning.
And importantly, don’t assume the AI’s explanation is correct just because it sounds polished.
Check documentation.
Verify claims.
Challenge assumptions.
AI confidence and technical correctness are not synonyms.
- Change something yourself
Take a generated implementation and modify part of it without asking AI for the answer immediately.
Add an edge case.
Change the data structure.
Replace one dependency.
Rewrite a small function.
If you understand the code, you should be able to manipulate it.
If touching one piece makes the whole thing feel mysterious, you’ve discovered exactly where you need to learn more.
- Explain it to another person
This is one of the oldest learning techniques for a reason.
Try explaining the implementation without hiding behind jargon.
If your explanation sounds like:
“The service basically interfaces with the abstraction layer to optimize the asynchronous process…”
stop.
What actually happens?
What calls what?
What data moves where?
What decision is being made?
Clear explanation exposes fuzzy thinking quickly.
- Keep track of what you’re outsourcing mentally
This may be the most important habit.
Every time AI gives you something you couldn’t have produced or explained yourself, notice it.
You don’t have to immediately stop working and take a three-hour course.
Write it down.
Maybe today it’s database indexing.
Tomorrow it’s authentication tokens.
Next week it’s concurrency.
After a month, you have something incredibly useful:
a curriculum built from the actual gaps in your work.
That is far more relevant than randomly consuming tutorials because someone online said every developer needs to learn a particular technology.
Junior Developers May Feel This Shift the Most
There’s an uncomfortable question underneath all of this.
If AI handles more of the simple tasks that junior developers traditionally used to learn, where does experience come from?
A lot of senior-level intuition was built through low-level work.
Small bugs.
Simple endpoints.
Basic refactoring.
Writing repetitive tests.
Reading other people’s code.
Getting code-review comments that made you slightly embarrassed.
Then making the same mistake again six weeks later.
Then eventually never making it again.
If AI removes more of those tasks, teams may become more productive in the short term while accidentally weakening one of the pathways through which junior developers become senior developers.
That doesn’t mean we should preserve boring work for the sake of suffering.
It means mentorship has to become more intentional.
Code review has to focus more on reasoning.
Instead of only asking:
“Does this work?”
teams may need to ask:
“Why does this work?”
“What alternatives did you consider?”
“What could break?”
“What did the AI contribute?”
“What did you verify yourself?”
Those questions turn AI-generated code back into a learning opportunity.
Senior Developers Aren’t Exempt Either
Experience doesn’t make someone immune to automation bias.
In some ways, experienced developers may trust generated output more quickly because they’re better at recognizing familiar patterns.
And most of the time, that instinct is useful.
The danger comes when familiarity becomes assumption.
“This looks like the standard implementation” can easily become “I don’t need to inspect this closely.”
But production failures often live in the details that looked ordinary.
The wrong default.
An unexpected permission.
A subtle race condition.
An outdated library behavior.
An edge case nobody tested.
A dependency that becomes a bottleneck under real traffic.
AI makes generating standard-looking code extremely easy.
That makes careful evaluation more valuable, not less.
The Developers Who Win Won’t Be the Ones Who Avoid AI
I don’t think the future belongs to developers who refuse AI tools.
And I don’t think it belongs to developers who outsource every difficult thought to them either.
It belongs somewhere in the middle.
To developers who can use AI aggressively without surrendering judgment.
People who can generate a first draft in seconds and still recognize that it’s a first draft.
People who know when the AI has produced something elegant.
People who know when it has produced something unnecessarily clever.
People who can catch a confident mistake.
People who can ask better questions because they understand the system well enough to know where uncertainty lives.
People who can explain their decisions to engineers, founders, customers, investors, and the person who inherits their code six months later.
That’s a very different skill from typing code quickly.
And I suspect it’s going to become much more valuable.
We’re Not Running Out of Reasons to Understand Code
Every major productivity tool creates the same temptation:
If the machine can do the task, maybe humans no longer need to understand the task deeply.
But software doesn’t disappear after it’s generated.
It has to be maintained.
Scaled.
Secured.
Integrated.
Explained.
Debugged.
Audited.
Rewritten.
And eventually replaced.
AI can participate in every one of those steps.
But somebody still owns the consequences.
That’s the part I think gets lost when conversations about AI development focus entirely on how many lines of code someone generated or how quickly they shipped an MVP.
Speed is useful.
Shipping matters.
But neither is a substitute for knowing what you put into production.
The developer from that handoff call wasn’t incompetent.
He was using the tools available to him to move faster.
And the code worked.
But that one simple question exposed the difference between producing an implementation and owning a technical decision.
That difference may become one of the defining skill gaps of the AI era.
Because when generating code becomes cheap, reasoning becomes expensive.
When answers become abundant, judgment becomes scarce.
And when almost anyone can ask a machine to produce something that looks technically impressive, the people who stand out will be the ones who can look at the result and say:
“I understand exactly what this is doing. I know why we chose it. I know where it can fail. And if the assumptions change, I know what we need to change with them.”
That’s not anti-AI.
That’s what good AI-assisted development should look like.
The tool can help you write the code.
Understanding it is still your job.
A Note for SaaS Founders and Developer-Tool Teams
There’s another side to this conversation.
A company can build genuinely impressive technology and still struggle to explain why it matters.
Your engineers understand the product.
Your founder understands the decisions behind it.
Your team has months—or years—of context sitting inside meetings, documentation, product discussions, changelogs, code reviews, and internal conversations.
But your audience doesn’t have any of that context.
They only have what you publish.
That’s where I come in.
I work with SaaS founders, AI companies, developer-tool teams, and technical businesses to turn internal knowledge into clear, credible content people actually want to read.
That can include:
- Technical thought-leadership articles
- Developer-focused blog content
- SaaS product explainers
- Founder-led articles
- AI and software content
- Feature and product narratives
- Technical educational content
- Long-form articles built from founder or engineering interviews
I’m not interested in taking a keyword, producing 1,500 generic words around it, and calling that technical content.
I prefer starting with the knowledge already inside your company.
Give me the founder interview.
Give me the engineering conversation.
Give me the documentation.
Give me the product notes.
Give me the complicated explanation someone on your team can deliver perfectly in a 20-minute call but never has time to turn into an article.
My job is to find the story, ask the questions a reader would ask, preserve the technical meaning, and turn that knowledge into content that sounds like it came from people who actually understand what they’re building.
Because good technical writing shouldn't simply make a company sound knowledgeable.
It should make its knowledge visible.
If your team is building something worth understanding, I can help you explain it.
I’m currently available for technical and SaaS writing projects.
For collaborations, ghostwriting, developer-focused content, or long-form SaaS articles:
Top comments (0)