Learning to Build in the Age of AI

AI can write the code. Can you explain it?

Learning to code has become a lot easier in some ways.

A few years ago, if you wanted to build something, you would probably spend hours reading documentation, searching Stack Overflow, watching tutorials, and trying to understand why your code wasn't working.

Now, you can describe what you want to build to an AI assistant and get a working starting point in seconds. Need a React component? Done. Need help with a database query? Just ask. Stuck on an error you've never seen before? Paste it into the chat.

I use these tools too, and they're genuinely useful. They help me move faster, explore unfamiliar technologies, and get past problems that might otherwise take hours to solve.

But there's something I've been thinking about.

When AI does more of the work for us, are we actually learning as much as we think we are?

It's easy to finish a project with AI and feel like you've learned a lot. You have a working application, the UI looks good, and the code seems to make sense. But sometimes, that confidence disappears the moment something breaks and you have to figure out what's happening without simply asking AI for another fix.

That's where the difference between writing code and understanding it starts to show.

The problem with feeling productive

Imagine you're learning React.

You watch a tutorial, follow along, and build a small application. Everything works. You understand the explanation, recognize the code, and feel comfortable with the concepts.

A few days later, you decide to build something similar on your own. Suddenly, you aren't sure how to structure the components, where the state should live, or why updating one value causes other parts of the interface to re-render.

What happened? You understood the tutorial while watching it, but you hadn't necessarily learned how to make those decisions yourself.

AI can make this even harder to notice.

You can ask it to build the entire application, fix every error, and explain each step. The result might be impressive, even if you couldn't reproduce the important parts independently.

There's nothing wrong with getting help. The problem is confusing a completed task with a skill you've developed.

I've started to think about learning in terms of a simple question:

If this code stopped working tomorrow, would I know where to start?

You don't need to remember every line of code or understand every implementation detail immediately. But you should gradually develop the ability to investigate a problem, form a hypothesis, and work towards a solution.

That's a different kind of progress from simply shipping code.

Build something small enough to understand

One thing that helps is choosing projects where you have to make decisions yourself.

You don't need to build another massive SaaS application or spend months working on an ambitious idea. Start with something small that forces you to understand one concept properly.

For example, if you're learning how APIs work, build a small application that fetches data, handles loading and error states, and deals with a failed request.

If you're learning state management, create a task manager where changes need to stay consistent across different components.

If you're exploring offline-first applications, try storing data locally and making sure it remains available after a page refresh or loss of internet connectivity.

These projects become much more useful when something goes wrong.

What happens if the request fails? What if the user clicks a button twice? What if the browser refreshes before the data is saved? What happens when two updates arrive in an unexpected order?

You don't have to solve every possible edge case. The point is to encounter problems that require you to think beyond the happy path.

This is also where reading documentation becomes more valuable. Instead of reading about a concept because you think you should, you're looking for an answer to a problem you've actually encountered.

You're no longer just collecting information. You're using it.

Use AI, but don't skip the thinking

I don't think the answer is to stop using AI or to write every line of code manually.

That would mean ignoring tools that can make development significantly more efficient.

Instead, I think it's worth being more deliberate about when and how we use them.

When I'm learning something unfamiliar, one approach is to spend a little time trying to solve the problem myself before asking AI for help.

Even if my first attempt is wrong, I've had to think about the problem, make a decision, and discover where my understanding falls short.

Then I can use AI to compare approaches, explain concepts I missed, or point out weaknesses in my solution.

Here are a few ways to make that process more useful:

• Try first, ask second. Spend some time understanding the problem before requesting a complete implementation.
• Ask why, not just how. If AI suggests a solution, ask why it works, what alternatives exist, and what trade-offs you're accepting.
• Predict before you run. Before executing a piece of code, try to work out what it will do. Then compare your prediction with the actual result.
• Change something yourself. Once the code works, modify it. Add a requirement, handle an edge case, or change the implementation. See whether you can adapt it without asking AI to rewrite everything.
• Investigate errors instead of immediately replacing the code. Read the error message, inspect the relevant code, and form a possible explanation before asking for help.

You won't need to follow this process for every task. If you're doing something routine that you already understand, letting AI handle more of the implementation makes perfect sense.

The important distinction is whether you're using AI to save time on familiar work or to avoid learning something you actually need to understand.

Understanding code matters more than memorizing it

There's another reason I don't think developers need to compete with AI at writing code.

AI can already generate syntax, suggest common patterns, and produce implementations for many familiar problems. Trying to prove your value by typing faster or memorizing more syntax misses the point.

What matters is knowing what to build, how the pieces fit together, and whether the result actually solves the problem.

Consider a simple feature that fetches data from an API.

Generating the request itself isn't particularly difficult. But a real application might also need to handle authentication, timeouts, retries, stale data, loading states, and unexpected responses.

You need to decide which of these situations matter, how the application should respond, and what trade-offs are reasonable.

AI can help with those decisions, too. But you still need enough understanding to evaluate its suggestions.

For me, that's one of the most interesting parts of software development: going beyond making something work and figuring out how to make it work reliably.

You don't need to become an expert in every part of the stack. You do need to understand the parts that your application depends on and know how to investigate the ones you don't understand yet.

Learn by building things that can break

A useful exercise is to implement a small feature yourself before looking at an AI-generated solution.

For example, imagine you're building an API request helper that retries a request when it fails.

You might start with something like this:

async function fetchWithRetry<T>(
  fn: () => Promise<T>,
  retries = 3,
  delay = 1000
): Promise<T> {
  try {
    return await fn();
  } catch (error) {
    if (retries <= 0) {
      throw error;
    }

    await new Promise((resolve) =>
      setTimeout(resolve, delay)
    );

    return fetchWithRetry(
      fn,
      retries - 1,
      delay * 2
    );
  }
}

At first glance, the implementation looks straightforward. If the request fails, wait a little and try again, doubling the delay each time.

But understanding it means asking a few more questions.

• Does the retry count behave as expected?
• Should every error trigger a retry, or only certain errors?
• What happens if the server is unavailable for a long time?
• Should the function support cancellation?
• How would you test the delays without waiting several seconds?
• Could multiple failing requests create too much traffic?

The example isn't a complete production-ready retry system. It deliberately leaves room for questions.

You can ask AI to explain the implementation or suggest improvements. But try answering some of these questions yourself first. You'll get much more out of the exercise than simply copying the code into a project.

The same approach works for almost anything: a search feature, an authentication flow, a database query, or a background synchronization process.

The goal isn't to write everything from scratch. It's to understand the decisions behind the code you're using.

You don't have to learn everything at once

It's easy to feel behind when new frameworks, models, and development tools keep appearing.

You might start learning one technology and see someone online building an entire product with another. Before you've finished one project, there's already a new tool everyone seems to be talking about.

I've found it useful to remember that exploring something new and actually learning it are two different things.

You can experiment with lots of tools, but depth comes from spending enough time with a problem to understand it properly.

Instead of starting a new project every few days, try taking one project a little further.

Make the error handling better. Understand how the data flows through the application. Write a few tests. Improve the way it behaves when something goes wrong. Revisit an earlier decision and see whether you'd make the same choice today.

You might learn more from improving a small application over several weeks than from building five similar applications that you never revisit.

And you don't need to code every waking hour to make progress. Consistency matters, but so does having enough time to think about what you've learned.

So, what does learning look like now?

I don't think AI makes learning software development pointless. If anything, it changes what we need to pay attention to.

We can spend less time struggling with repetitive syntax and more time exploring ideas, testing assumptions, and understanding how systems behave. But that only happens if we remain involved in the process.

A working application is a good result. Being able to explain how it works, identify its weaknesses, and improve it is an even better one.

The next time you use AI to build something, try going a little further than getting it to work. Ask yourself what you learned, what you still don't understand, and what would happen if you had to change the implementation tomorrow.

You don't need to reject AI to become a better developer. You just need to make sure you're not handing over the part of the process that helps you grow.

Because in the end, the goal isn't to prove that you can write code without assistance.

It's to become someone who can take an idea, understand the problem, use the tools available, and figure out how to build something that works.

And that's still worth learning.