Post
JA EN

Build It, Break It, Learn It — Why Failing Fast Is the Best Way to Learn (and How AI Accelerates the Cycle)

Posted
By
17 min read
Build It, Break It, Learn It — Why Failing Fast Is the Best Way to Learn (and How AI Accelerates the Cycle)
  • Target audience: Software engineers (especially those who have grown through hands-on coding)
  • Prerequisites: Some programming experience (any language)
  • Reading time: ~10 minutes

Overview

“Fools learn from experience; I prefer to learn from the experience of others.” This quote is commonly attributed to Bismarck, though what he actually said was closer to: “Only a fool learns from his own mistakes. I learn from the mistakes of others.” In Japan, the paraphrase Gusha wa keiken ni manabi, kenja wa rekishi ni manabu (愚者は経験に学び、賢者は歴史に学ぶ — “Fools learn from experience; the wise learn from history”) is even more popular. Either way, the message is clear: learning from textbooks and best practices is the smart approach, and learning by failing yourself is the foolish one.

It’s not that I never read the textbooks. I did. But reading alone never gave me the feeling of having actually learned something. Knowledge entered my head, but it never felt like mine. Only after building something with my own hands, watching it break, figuring out why it broke, and rebuilding it — only after that cycle did the “aha, now I get it” moment arrive. Looking back, I’m the kind of person who learns by doing.

I knew the best practices. But knowing them and being able to find the right solution for my own project turned out to be entirely different abilities.

This “build, break, reflect, rebuild” cycle has solid academic backing. Kolb’s experiential learning theory argues that the essence of learning is the repeated interplay of concrete experience and reflection1. Kapur’s “Productive Failure” research, drawing on a meta-analysis of over 12,000 participants, shows that learners who struggle and fail on their own before being taught the correct approach develop significantly deeper conceptual understanding2.

And now AI is accelerating this cycle. Here’s the interesting part: what you fail at has changed. Now that AI writes code for you, you fail less at “how to write code.” Instead, you fail more at upstream decisions — “what to build” and “how to structure it.” The cycle spins faster, and it targets more fundamental judgment skills.

Is this “using AI smartly”? No. I don’t think about token efficiency or prompt design. I just use it relentlessly. Yet multiple large-scale studies show that the more skilled you are, the less you benefit from AI3. While talented engineers optimize how they use AI, the people who just build and break things keep spinning the cycle — this paradox is the theme of this article.

The Distance Between “Knowing” and “Understanding”

Back when I was working with Laravel 6, I understood the framework’s conventions. I had read about MVC and SOLID principles. The problem was that knowing something intellectually and knowing how to apply it in my own project were completely different abilities.

I learned about the Repository Pattern online and applied it to every model. The result: a massively over-engineered CRUD app buried under four layers of abstraction. On my next project, I swung to the opposite extreme and kept things minimal. Only then did the judgment “abstraction has a cost” crystallize inside me. Service class granularity went through the same journey — a bloated God Service, then excessive micro-splitting, and finally the right granularity — three rewrites. Performance tuning was the same story: mechanically applying best practices created new problems.

The pattern is consistent. Learn the best practice, apply it as-is, hit a problem, ask why, find the version that fits your context. Textbooks teach you the “what.” The “when,” “how much,” and “why” only emerge when you try things and watch them break.

Why Breaking Things Teaches You

Productive Failure — Failing Before the Answer Deepens Understanding

Manu Kapur’s (ETH Zurich) “Productive Failure” research is fascinating. Traditional education follows the sequence “teach the correct method, then practice.” Kapur flipped it: “Let learners struggle on their own first (and fail), then teach the correct method.”

Sinha & Kapur’s (2021) meta-analysis, spanning over 12,000 participants across 166 experimental comparisons, found that the productive failure group significantly outperformed on conceptual understanding and transfer2. The effect size was g = 0.36, rising to g = 0.58 when design principles were closely followed. Crucially, the benefit appeared not in procedural knowledge (memorizing how to solve) but in conceptual understanding and transfer — grasping why something works and applying it to new situations.

This matches the experience I described. You can memorize the Repository Pattern from a textbook. But the judgment “how much abstraction is right for this project” only came from suffering through over-engineering.

The Experiential Learning Cycle — Revolutions Determine Learning

Kolb’s experiential learning theory (1984) proposes that learning proceeds in a four-stage cycle1:

flowchart TB
    CE["Concrete Experience<br>Build it — watch it break"]
    RO["Reflective Observation<br>Ask why it broke"]
    AC["Abstract Conceptualization<br>Derive the principle"]
    AE["Active Experimentation<br>Rebuild with the lesson"]

    CE --> RO --> AC --> AE --> CE

What matters is the number of revolutions. A single failure teaches you only so much. Three, five, ten iterations deepen your understanding. Ericsson’s deliberate practice research (1993) similarly shows that the key to skill acquisition is not mere repetition but intentional repetition accompanied by immediate feedback4. The faster the feedback, the faster the cycle spins.

This is where AI enters the picture.

What AI Changed

The Level of Failure Went Up

Once I started using AI, the nature of my failures changed.

My failures used to be about “how to write code.” Which pattern to use, how to implement it, how to squeeze out performance. Now that AI writes the code, those failures have largely disappeared.

What replaced them are failures at a higher level. What should I build in the first place? What architecture should I use? How polished does it need to be? What does the user actually want? The code is correct, but the thing I’m building is wrong.

The interesting part is that these upstream failures can also be learned through the “build and break” cycle. Because AI handles the code implementation, “build it, interact with it, realize it’s wrong, change direction” now happens at the design and requirements level, at high speed. It used to take weeks to try out a single architectural approach. Now I can prototype multiple approaches in a day with AI, compare them, and make a judgment.

The structure of the cycle is the same, but the rotation speed is higher and the failure layer has moved up one level.

The Cost of Failure Went Down

What Kapur’s productive failure research demonstrated is that failure itself is a necessary condition for learning2. Failure is not an obstacle to learning — it is learning’s fuel. AI supplies this fuel cheaply and in bulk.

Borrowing the metaphor from Only the Hot Water You Choose Makes You Stronger: AI doesn’t lower the temperature of the hot water — it increases the number of times you can jump back in. Same temperature, more immersions, faster pace.

The Difference Between “Using It Smartly” and “Using It Relentlessly”

The Paradox: The Better You Are, the Less AI Helps

Multiple large-scale studies have produced a counterintuitive finding. In a Harvard/BCG study, top-performing consultants improved by 17%, while below-average performers improved by 43%. In Brynjolfsson et al.’s customer support study, low-skill workers saw a 34% productivity boost compared to the overall average of 14%3.

Why do skilled people benefit less from AI?

One reason is that highly skilled people already have “the right way” internalized, creating friction with AI’s output. The cost of verifying AI-generated work exceeds the cost of doing it themselves.

But I suspect there’s a deeper issue. The more skilled you are, the more tempted you are to optimize how you use AI. How to minimize token consumption. How to structure prompts for maximum accuracy with minimal back-and-forth. How to manage API costs.

These are genuinely important technical concerns. But from a learning perspective, they miss the point. Time spent optimizing your AI workflow is not time spent building, breaking, and learning. Improving tool efficiency and improving your own judgment are different activities.

What “Using It Relentlessly” Looks Like

People who just build and break things don’t bother optimizing their AI usage. Tokens flying everywhere, prompts rough around the edges — they just throw AI at whatever they want to build. When it breaks, they think about why and move on. Their AI technique may be unrefined, but the learning cycle itself never stops.

“Using AI smartly” is a stance that pursues tool efficiency. “Using AI relentlessly” is a stance that keeps the learning cycle spinning. Which is “smarter” depends on the situation. But from a growth perspective, the number of revolutions is everything.

However, the research highlights an important caveat. Alanazi et al.’s (2025) meta-analysis of 35 controlled studies found that while AI tools significantly reduce task completion time and improve scores, their effect on “depth of understanding” was not statistically significant5. Furthermore, developers who learned a new library with AI assistance scored 17% lower on comprehension tests6.

Even if you use AI relentlessly, the cycle doesn’t spin unless you ask yourself “why.” If your response to something breaking is just telling AI “fix it,” you’re skipping Kolb’s “reflective observation” and “abstract conceptualization” — the very heart of learning.

A cycle that produces learning: Use AI relentlessly to build something, notice a problem, ask yourself “why?”, form a judgment principle, build again

A cycle that doesn’t: Have AI build something, notice a problem, have AI fix it, have AI build more

The difference is one thing only: whether you have a “why?” phase where you do the thinking yourself.

A note: this article is written for people who want to learn but are searching for the right approach. If someone has no intention of learning, or only needs the final answer, this cycle won’t engage at all. That’s a motivation problem, which is outside the scope of this article.

You Can Break Things Because It’s Outside Work

Everything above argues “learn by failing,” but there’s an important prerequisite: you need an environment where failure is safe.

At work, failure isn’t something you can afford casually. Breaking production means harming customers. So you can’t just “build and break” with business-critical code. At work, learning from best practices — from “history” — is the right approach.

But outside work, the story changes entirely. In personal projects, the cost of failure is literally zero. You inconvenience nobody. There are no deadlines. Psychological safety is fully guaranteed, and you can break things to your heart’s content.

Kapur’s research also identifies “a psychologically safe environment” as a condition for productive failure to work2. If failure is punished, people avoid it. If they avoid failure, the cycle doesn’t spin.

However, one clarification is important here. “Safe to fail” does not mean “easy to succeed.”

Psychological safety and cognitive difficulty are independent dimensions. A personal project is “safe” in the sense that failure harms no one, but the difficulty of the problem itself doesn’t change. The frustration of watching your own design fall apart — that nandekounarun (なんでこうなるん — “why is this happening”) feeling — hits you even when nobody’s watching. In the language of Only the Hot Water You Choose Makes You Stronger:

  • Lukewarm water: The problem is too easy. No growth.
  • Hot water in a safe place: The problem is hard, but failure is safe. Growth happens.
  • Boiling water in a dangerous place: The problem is hard, and failure has real consequences. You freeze up.

It’s the environment that’s safe, not the problem that’s easy. The key is to maintain the water temperature (cognitive challenge) while ensuring burns don’t cost you anything (psychological safety).

This is where AI makes a critical difference. In the past, trying to build something outside work meant half a day just on environment setup and days before you had anything working. After an exhausting workday, that was a high bar. AI has dramatically lowered that bar. The cost of having a “fail-as-much-as-you-want experimentation lab” outside work has never been lower.

Follow best practices at work. Build and break things outside work. Take the knowledge you gained from textbooks and convert it to “I get it” with your own hands. This hybrid approach is what fits me best.

Aside: This Article Itself Was “Build and Break”

This article didn’t come together on the first try, either. Writing it with AI, the first draft was a detailed account of beginner-level mistakes — completely off-target. The next version was stuffed with code examples and read like a technical tutorial. Every new perspective added turned it into more of a patchwork, until I eventually scrapped it and started over from scratch.

The content of the article itself went through the “build, break, reflect, rebuild” cycle. Because AI generates drafts quickly, the cost of scrapping and rewriting is low. That makes it easy to say “nah, let’s start over.” This was exactly the phenomenon the article describes: “when the cost of failure drops, the cycle spins faster.”

Summary

“Just build it and break it” is not a dim-witted way to learn. It is an effective learning mechanism backed by learning science.

  • Kapur’s research demonstrated, across over 12,000 participants, that groups who experienced failure before instruction showed significantly deeper conceptual understanding (g = 0.36 to 0.58)2
  • Kolb’s experiential learning theory showed that the cycle of concrete experience, reflection, conceptualization, and experimentation is the essence of learning1
  • Ericsson’s research showed that intentional repetition with immediate feedback is the key to skill acquisition4

AI accelerates this cycle. It lowers the cost of failure, makes feedback instantaneous, and increases the number of revolutions. Moreover, by shifting failures from the code level to the design and requirements level, it trains more fundamental judgment skills.

You don’t need to optimize how you use AI. If you have time to worry about token efficiency, you’re better off breaking something one more time and thinking about why. But there is one condition: you must think about “why it broke” yourself. That “why” is the one thing you cannot outsource.

For me, AI isn’t a device that lowers the temperature of the hot water. It’s a springboard that lets me jump back into the same hot water faster. Use it relentlessly. You’re going to break it anyway.

Only the Hot Water You Choose Makes You Stronger examined the conditions for growth-promoting hardship through the lens of Self-Determination Theory and stress science. This article explores what happens when you put those conditions into practice in real-world programming — a point where lived experience meets scientific evidence.

Explore more on this theme:

References

References listed below correspond to the citation numbers in the text.

Additional References (Not Cited by Number in Text)

  1. Experiential Learning: Experience as the Source of Learning and Development - Kolb, D. A., Prentice Hall (1984; 2nd ed. 2015). The foundational work on experiential learning theory. Proposes the four-stage cycle: concrete experience, reflective observation, abstract conceptualization, and active experimentation. [Reliability: High] ↩︎ ↩︎2 ↩︎3

  2. When Problem Solving Followed by Instruction Works: Evidence for Productive Failure - Sinha, T. & Kapur, M., Review of Educational Research, Vol.91, No.5, pp.761-798 (2021). DOI: 10.3102/00346543211019105. Peer-reviewed. Meta-analysis of 12,000+ participants across 166 experimental comparisons. The productive failure group showed significant advantages in conceptual understanding and transfer at g = 0.36 (g = 0.58 when design principles were closely followed). Kapur’s research framework positions psychological safety as one of the design conditions for productive failure. [Reliability: High] ↩︎ ↩︎2 ↩︎3 ↩︎4 ↩︎5

  3. Combined citation of two AI skill-gap studies. (1) Generative AI at Work - Brynjolfsson, E., Li, D. & Raymond, L. R., The Quarterly Journal of Economics, Vol.140, No.2, pp.889-942 (2025). Peer-reviewed. Study of 5,179 customer support agents. Low-skill workers’ productivity improved by 34% (overall average 14%). (2) Navigating the Jagged Technological Frontier - Dell’Acqua, F. et al., Harvard Business School Working Paper (2023). Study of 758 consultants. Below-average performers improved by 43% (top performers by 17%). [Reliability: High] ↩︎ ↩︎2

  4. The Role of Deliberate Practice in the Acquisition of Expert Performance - Ericsson, K. A., Krampe, R. T., & Tesch-Romer, C., Psychological Review, Vol.100, No.3, pp.363-406 (1993). DOI: 10.1037/0033-295X.100.3.363. Peer-reviewed. 9,000+ citations. The seminal paper establishing the definition of deliberate practice: immediate feedback, well-defined tasks, opportunities for repetition, and exploitation of errors. Note: Macnamara’s meta-analysis (2014, DOI: 10.1177/0956797614535810) shows that the proportion of performance variance explained by deliberate practice varies by domain (games 26%, music 21%, education 4%), indicating it is not the sole factor. [Reliability: High] ↩︎ ↩︎2

  5. The Influence of Artificial Intelligence Tools on Learning Outcomes in Computer Programming: A Systematic Review and Meta-Analysis - Alanazi, M., Soh, B., Samra, H. E., & Li, A., Computers, Vol.14, No.5, p.185 (2025). DOI: 10.3390/computers14050185. Peer-reviewed. 35 controlled studies. AI tools significantly reduced task completion time (SMD = -0.69) and improved scores (SMD = 0.86), but the effect on “learning success” was non-significant (SMD = 0.16, p = 0.41). [Reliability: High] ↩︎

  6. AI Coding and Skill Formation — Developers who learned a new coding library with AI assistance scored 17% lower on comprehension tests. High scorers used AI as “a dialogue partner to deepen understanding,” while low scorers followed a “complete delegation of code generation” pattern. Coverage: InfoQ (2026). [Reliability: Medium-High] (Detailed methodology of the original study is not fully available from public sources) ↩︎

Career
Learning Programming AI Experiential-Learning Failure Growth
This post is licensed under CC BY 4.0 by the author.