Build First, Learn Later: How AI Changed the Way I Approach Software

There’s a rule I followed for most of my career: understand before you build. Read the docs, map the architecture, form a mental model — then start coding. Skip that step and you’d pay for it later in technical debt, wrong abstractions, and late-night debugging sessions.

That rule is changing. Not because understanding doesn’t matter, but because AI lets you get to understanding through a completely different path.

The old sequence: research, then build

Traditional software development is fundamentally bottom-up. You learn the fundamentals first. You evaluate frameworks before picking one. You design the data model before writing the schema. You have to have a reasonably complete picture before you start, because the cost of being wrong — of building on a misunderstanding — is high.

This made sense. Software is a precision craft. If you don’t understand what your tools are doing underneath, problems surface in the worst places. Understanding first wasn’t just discipline, it was risk management.

The new sequence: build first, then understand

With AI, something different is possible now. You can describe a goal — sometimes vaguely — and get working software back. The AI picks a reasonable stack, scaffolds the structure, fills in the implementation. You didn’t research first. You didn’t design upfront. You said what you wanted, and something real came back.

And here’s the key shift: you can then read what was built and learn from it.

The blueprint already exists. You can trace through the code, ask the AI to explain its choices, understand why it structured things the way it did. The learning is still there — it just comes after the building, not before. And because you have something real to look at, something that already works, the learning is often more concrete and more meaningful than it would have been from docs alone.

The old way was: research, then build.

The new way is: imagine, then build, then understand if you want to go deeper.

What this means for developers

This changes the experience of being a developer in ways I find genuinely exciting.

You can start with the goal, not the prerequisite. Before, if you wanted to build something in a domain you didn’t know well — say, a data pipeline, or a mobile app, or a WebSocket server — you’d have to spend time learning the domain before you could begin. Now you can begin first. You describe the outcome. You get a working starting point. You understand it as you go.

The feedback loop tightens. The gap between “I have an idea” and “I have something running” has collapsed dramatically. That matters for motivation, for learning, and for iteration speed. You can test assumptions against something real, not just against a mental model.

Rebuilding is cheap. If the first attempt isn’t quite right — wrong structure, wrong approach — you describe the delta and iterate. Or you throw it away and try again. The cost is minutes, not days. This fundamentally changes the risk calculus of starting. You don’t need a complete picture up front because the cost of adjusting is so low.

AI gives you a blueprint, and blueprints are good teachers. Reading AI-generated code — and questioning it, asking why it made certain choices, pushing back when something looks off — is itself a form of learning. It’s more active than reading documentation because you’re always looking at something specific to your problem.

The barrier to entry drops, dramatically. Someone who has a clear picture of what they want to build can now begin building it, even without deep expertise in the tools required. They’ll develop that expertise through the process. That’s a meaningful change in who gets to build software.

Anthropic has noted that the vast majority of their own code is now AI-generated. This isn’t fringe behavior anymore — it’s the direction the industry is moving, quickly.

This is especially true for greenfield projects

The “build first, learn later” mode works best when you’re starting from scratch. Greenfield projects — new web apps, new APIs, new tools — are squarely in the zone where AI shines. You’re not fighting against existing decisions or accumulated context. You can let the AI propose an approach, evaluate it, refine it, and get moving.

Brownfield codebases are harder. Existing systems have constraints, conventions, and context that aren’t in the AI’s training data. The approach still helps — AI is a valuable assistant in existing codebases too — but the pure “build first, understand later” mode works best when you’re starting fresh.

Similarly, highly specialized domains require more upfront understanding. If your project involves proprietary protocols or cutting-edge research areas, the AI may not have enough grounding to give you reliable output. Know your context.

The learning doesn’t disappear — it just resequences

I want to be clear about something: this isn’t about skipping understanding. It’s about when understanding happens.

Curiosity still matters. Going deep still matters. In the old way, you went broad before going deep. In the new way, you build something first, then go deep in response to what you actually have — which is often more efficient because you’re learning things that are relevant right now, in this context.

The developers who thrive with AI tools aren’t the ones who stop caring about how things work. They’re the ones who engage with the AI output critically, understand what was built and why, and can move fluidly between “describe the goal” and “understand the implementation.”

AI doesn’t make understanding obsolete. It makes understanding something you earn through building, rather than a prerequisite you have to pay before you start.

What I do differently now

For new projects, I start with imagination more than research. I describe what I want to build, let the AI propose a structure, and evaluate that proposal with the same critical eye I’d apply to a colleague’s design. I might accept it as-is, or push back on specific choices.

The research phase didn’t disappear — it got more targeted. Instead of reading broadly before building, I read specifically in response to what was built. I understand the things that matter in this project, not everything that might matter abstractly.

And when I’m curious about something in the AI’s output, I ask. The AI is both builder and teacher. That combination is new, and it’s powerful.

The shift from “research, then build” to “build first, learn later” is one of the more meaningful changes I’ve seen in how software development actually feels day-to-day. It doesn’t make engineering judgment less important — if anything, the ability to evaluate what was built matters more now than ever. But it removes the steep upfront toll that used to separate having an idea from having something real to work with.

That’s good for developers. And it’s good for the software that gets built.