Stop Asking AI to Write Code: Ask It to Teach Instead

ChatGPT Use cases and examples
1

Over the past year, I’ve realized that the biggest value I’ve gotten from AI wasn’t code generation—it was learning.

When I first started using AI, my prompts looked something like:

“Write an Angular authentication service.”

or

“Generate a NestJS module.”

The responses were impressive, but after a few days I noticed a problem.

I could use the code, but I couldn’t confidently explain why it worked.

That made me change the way I interacted with AI.

Instead of asking it to build something for me, I started asking it to teach me.

For example, instead of asking:

“Generate OAuth authentication.”

I began asking questions like:

  • Why is OAuth preferred over session-based authentication for SPAs?
  • Why do we need both access tokens and refresh tokens?
  • Why are refresh tokens treated differently?
  • What problems does OAuth actually solve?

Those conversations helped me understand authentication instead of simply implementing it.

The same thing happened while learning dependency injection.

Earlier, I would ask AI to generate Angular services.

Now I ask questions like:

  • Why does Angular even need dependency injection?
  • What problem does it solve compared to creating objects manually?
  • When should I use providedIn : ‘root’
  • How does Angular’s injector decide which instance to provide?

Understanding those concepts made debugging much easier than copying another generated service ever could.

2

Like many developers, I initially started using AI to save time.

I asked it to generate code, explain syntax, and fix compiler errors. It certainly helped, but after a while I realized that wasn’t the biggest benefit.

The biggest shift happened when I stopped asking “What is this?” and started asking “Why does this exist?”

That one change completely transformed the way I learned software engineering.

From memorizing services to understanding systems

A few months ago, I started preparing for the AWS Solutions Architect certification.

The AWS ecosystem has dozens of services, and my initial approach was to learn each one individually.

  • What is CloudFront?
  • What is Route 53?
  • What is Global Accelerator?
  • What is an Application Load Balancer?
  • What is a VPC?

I quickly found myself memorizing definitions instead of understanding the architecture.

The problem wasn’t that the documentation was bad—it was that I wasn’t asking the right questions.

Instead of asking:

What is AWS Global Accelerator?

I started asking:

Why did AWS build Global Accelerator when CloudFront already existed?

That single question opened an entirely different discussion.

Instead of receiving another service definition, I learned about:

  • Anycast routing
  • AWS’s private global backbone
  • Static IP addresses
  • Regional failover
  • TCP/UDP acceleration
  • Why CloudFront and Global Accelerator solve completely different problems

I wasn’t learning a service anymore.

I was learning the problem AWS was trying to solve.

Once I understood the problem, remembering the service became effortless.

The same thing happened with networking

Networking used to feel like a collection of unrelated concepts.

DNS.

Load Balancers.

Reverse Proxies.

Private IPs.

Public IPs.

VPCs.

NAT Gateways.

Each topic felt isolated.

Then I started asking questions like:

Why do private IP addresses even exist?

Why can’t every machine simply have a public IP?

That naturally led to discussions about:

  • Network isolation
  • IPv4 exhaustion
  • Security
  • NAT
  • Corporate networks
  • AWS VPCs

Suddenly, these weren’t separate topics anymore.

They became parts of one larger system.

Authentication became much easier to understand

Authentication was another area where changing the question made a huge difference.

Originally I asked:

Explain JWT.

The response was useful, but it still felt like another technology to memorize.

Then I changed the question.

Instead I asked:

Why was JWT created when session-based authentication already existed?

That led to discussions about:

  • Stateless applications
  • Horizontal scaling
  • Load balancers
  • Microservices
  • Token verification
  • OAuth
  • Identity Providers

JWT stopped being “a token format.”

It became a solution to a scaling problem.

That perspective made the entire authentication ecosystem much easier to understand.

Documentation tells you what. AI helped me understand why.

One realization has stayed with me throughout this journey.

Official documentation is excellent at explaining:

  • APIs
  • Configuration
  • Features
  • Limitations
  • Best practices

But documentation usually assumes you already understand the bigger picture.

AI helped me connect those pieces together.

Instead of reading ten separate documents, I could ask:

How does this service fit into the overall architecture?

or

What would happen if this component didn’t exist?

Those conversations helped me build mental models instead of memorizing isolated facts.

Better questions led to better learning

Looking back, the biggest improvement wasn’t in AI.

It was in the questions I asked.

I’ve found that prompts like:

  • Why does this exist?
  • What problem is it solving?
  • What came before this?
  • What would happen if we removed it?
  • What are the trade-offs?
  • Why would I choose this over another approach?

consistently produce answers that are far more valuable than asking for a definition or code sample.

My takeaway

Today I still use AI to explain syntax when I need it.

But I use it much more often to understand systems, architecture, and design decisions.

That change has helped me move beyond memorizing technologies and toward understanding how they fit together.

For me, that has been the most valuable use of AI so far.

I’m curious how others approach learning with AI.

Do you mostly ask it what a technology does, or have you found that asking why it exists leads to a deeper understanding?

3

When people talk about AI in software engineering, the discussion usually revolves around speed.

  • “I generated 500 lines of code.”
  • “I built a CRUD application in 20 minutes.”
  • “I reduced development time by 50%.”

Those are interesting benchmarks, but I don’t think they’re the most important impact AI is having.

After watching experienced engineers around me—and changing my own workflow—I’ve started to notice something different.

AI doesn’t just reduce development time.

It changes where developers invest their time.

Before AI

A significant part of software development involved repetitive work.

Searching documentation.

Finding the right syntax.

Looking up framework APIs.

Remembering command-line options.

Checking configuration files.

Most of these tasks weren’t intellectually difficult.

They were simply interruptions.

After AI

Many of those interruptions disappeared.

Instead of spending twenty minutes searching documentation, I could ask one question and immediately continue thinking about the actual problem.

The time saved wasn’t spent writing more code.

It was spent making better decisions.

Questions like:

  • Is this architecture maintainable?
  • Will this scale?
  • What happens six months from now?
  • Is this introducing unnecessary complexity?
  • Is there a simpler solution?

Those are questions AI doesn’t answer for us.

They’re questions we finally have time to think about.

Coding became a smaller part of engineering

One thing I didn’t expect was realizing that writing code occupies only a fraction of software engineering.

The larger challenges usually involve:

  • understanding business requirements
  • evaluating trade-offs
  • reviewing designs
  • debugging production issues
  • communicating with teammates
  • maintaining systems over time

AI reduced friction around implementation.

It didn’t remove the responsibility of engineering judgment.

Faster doesn’t always mean better

AI can generate an implementation almost instantly.

But implementation is rarely the hardest part.

Choosing between two designs can take much longer than writing either one.

I’ve found myself spending more time asking questions like:

  • Which approach will future developers understand?
  • Which design is easier to test?
  • What assumptions am I making?
  • What happens if requirements change?

Those conversations happen before any code is written.

Engineering judgment is becoming more valuable

As AI becomes better at producing code, I think one skill becomes even more important:

Making good decisions.

Understanding context.

Recognizing trade-offs.

Knowing when not to use a particular solution.

Those skills aren’t replaced by code generation.

If anything, they’re becoming more valuable.

The productivity metric I care about

I don’t measure AI by:

  • Lines of code generated.
  • Number of prompts.
  • Development speed.

Instead I ask myself:

Did AI help me make a better engineering decision today?

If the answer is yes, then it provided value—even if it didn’t generate a single line of code.

Final thoughts

I think we’re entering a phase where AI isn’t simply a coding assistant.

It’s becoming a thinking assistant.

The biggest productivity gain isn’t typing faster.

It’s having more time to focus on the parts of software engineering that actually require human judgment.

I’m curious whether others have noticed the same shift.

Has AI changed how fast you code, or has it changed how you spend your engineering time?