Why Understanding Still Takes Longer Than Writing Code

AI has dramatically accelerated implementation, but understanding remains the hardest part of software engineering. The more I use AI in production codebases, the more convinced I become that engineering leverage comes from understanding systems, not just generating code.

Why Understanding Still Takes Longer Than Writing Code

AI has fundamentally changed the way I write software.

Today, I can generate boilerplate, refactor code, create tests, build prototypes, and even implement complete features significantly faster than I could just a few years ago.

The productivity gains are real, and in many cases implementation is no longer the slowest part of software development. Understanding is. That's something I've noticed repeatedly while working with AI tools in production codebases.


What I Trust AI to Do

I feel completely comfortable asking AI to:

  • Generate a new component
  • Create tests
  • Refactor a service
  • Implement a feature from a clear specification

These are tasks where the objective is relatively well-defined and the scope is limited.

But I still hesitate when the prompt becomes:

"Review the entire codebase and fix the issues."

Or:

"Analyze the project and implement the best solution."

Not because AI can't write code.

Because I don't yet understand the system.

And if I don't understand it, I can't properly evaluate whether the generated solution is actually correct.


The Bottleneck Has Shifted

Years ago, implementation was often the bottleneck.

You would spend hours writing networking layers, models, view controllers, coordinators, dependency containers, tests, and integrations.

Today, AI can generate much of that in minutes.

What still takes time is answering questions like:

  • Why was this architecture chosen?
  • Which parts of the system are fragile?
  • What business rules exist that aren't documented?
  • What assumptions does this feature depend on?
  • Which behaviors are intentional and which are accidental?

These questions rarely have obvious answers because they require context, and context is still expensive to acquire. AI can help investigate them, but someone still needs to recognize which questions actually matter. That’s where experience comes in.


The Difference Between Generating and Understanding

One pattern I've noticed: junior developers use AI to generate solutions faster, while experienced developers use it to understand systems faster.

That shift changes everything. When I join a new project, I start by asking questions.

For example:

  • How does authentication work?
  • Where does this data originate?
  • What are the dependencies?
  • What happens if this service fails?
  • Which services are critical to the business?
  • Where are the most common failure points?

The goal isn't to generate code.

The goal is to build a mental model of the system.

Once that model exists, AI becomes dramatically more useful.


AI Has Made Understanding More Valuable

One thing that surprised me is that AI has actually made understanding more valuable, not less. When implementation becomes cheaper, engineering leverage shifts toward judgment. The developer who understands the system can move incredibly fast because AI can help execute decisions, while the developer who doesn't understand it can now make mistakes much faster than before.

That's an important distinction. Speed amplifies both good decisions and bad decisions. I've seen AI generate perfectly reasonable solutions that were completely wrong for the specific constraints of a project—not because the model failed, but because the context was incomplete. The bottleneck wasn't code generation; the bottleneck was understanding.


Why I Still Spend Time Reading Code

Despite all the advances in AI-assisted development, I still spend a significant amount of time:

  • Reading code
  • Tracing execution flows
  • Reviewing logs
  • Understanding business rules
  • Exploring dependencies
  • Talking with teammates and stakeholders

Before making major changes, I want to understand why the system behaves the way it does.

Many of the most important decisions in a codebase are not documented in the code itself; they're hidden in historical decisions, business constraints, operational requirements, and lessons learned from previous failures.

AI can help uncover some of that context, but it can't replace the process of understanding it.


Final Thoughts

AI has accelerated implementation, there's no question about that. But software engineering has never been only about implementation.

The more I use AI, the more convinced I become that understanding remains the highest-leverage skill in the profession. Writing code is getting cheaper every year, but understanding why the code exists is still expensive. And for now, that's where the real work continues to be.