---
title: "Discussion on \"AI can build anything except an understanding of what you are building\" | Hashnode"
description: "Discussion on \"AI can build anything except an understanding of what you are building\". There is a distinction in software development that the industry has spent twenty years pretending doesn't exist. It is the distinction between building software and understanding what you are buildin"
url: "https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [AI can build anything except an understanding of what you are building](https://blog.leonpennings.com/ai-can-build-anything-except-an-understanding-of-what-you-are-building?utm_source=hashnode&utm_medium=feed)

There is a distinction in software development that the industry has spent twenty years pretending doesn't exist. It is the distinction between building software and understanding what you are buildin

May 4 · 17 min read · blog.leonpennings.com  
Read the article

-   [#software-engineering](https://hashnode.com/tag/software-engineering)
-   [#software-development](https://hashnode.com/tag/software-development)
-   [#ai](https://hashnode.com/tag/ai)
-   [#rich-domain-model](https://hashnode.com/tag/rich-domain-model)

## Written by

[Leon Pennings](https://hashnode.com/@leon74)

@leon74 · Zoetermeer, The Netherlands

  
[View profile](https://hashnode.com/@leon74)

Trying to put engineering back into software development

I specialize in developing object-oriented java applications that aligns with business objectives, using Domain-Driven Design principles to ensure technical decisions drive tangible value. By focussing on a deep understanding of the business domain, I craft solutions that solve real problems while maximizing ROI. My approach evaluates the cost/profit ratio of every decision—only implementing technologies when the benefits outweigh the costs. I’ve been called in to revive stalled projects and address challenges where others have struggled. My focus is on creating software that not only meets but exceeds business expectations. Whether working with legacy systems or modern frameworks, I select the right technologies to maximize value—not just follow trends. I believe software should be a strategic asset, and this mindset guides every decision I make in development.

## Responses 15

Markdown supported · ⌘↵ to post

[CapeStart](https://hashnode.com/@capestart)

[May 6](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69faf0f3a386d7f1212e076c)

The rich domain model examples make the argument much more concrete. Good abstractions usually emerge from wrestling with the domain, not from generating code faster.

[Varsha Ojha](https://hashnode.com/@varsha014)

[May 6](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69fae06ba386d7f1211f4c1d)

This is exactly the gap with AI-built products. AI can generate screens, code, and flows quickly, but it still doesn’t understand the business context, user pain, or tradeoffs behind the product. That’s why product judgment matters more now, not less.

[Sam Rivera](https://hashnode.com/@samrivera)

[May 6](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69faa225a386d7f121f912be)

as someone in marketing who's been watching ai tools reshape our workflows, this hits home. we keep getting tools that can "do" the work but miss the context of why we're doing it. the gap between output and understanding is real even outside engineering.

[YES](https://hashnode.com/@jeenim)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69fa63c5a386d7f121dd3130)

True

[Laura Ashaley](https://hashnode.com/@laura-ashaley)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69fa3de4a386d7f121c9c3d1)

Feels true AI can generate impressive outputs, but it still lacks real self-awareness or lived experience, so it doesn’t _understand_ in the human sense.

[Jame ssmite](https://hashnode.com/@jamessmite68)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69fa3615a386d7f121c44561)

Strong piece it really nails the gap between “shipping code” and actually understanding the system you’re shaping. The part about domain modelling as a discovery tool and contradiction detector is especially on point; that’s where most real systems either stay coherent or slowly rot. Also interesting how AI is framed not as a breakthrough in engineering, but as an acceleration of the same template-driven weaknesses we already had

[Chisomo Chiweza](https://hashnode.com/@mwprogrammer)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f9d643a386d7f1217bf81a)

Good day.

I am a programmer just starting out in my career (nearing 3 years now including internships). I've seen the DDD label added to so many LinkedIn profiles but never really wrapped my head around what it was conceptually or what problems it attempted to alleviate.

Ironically, this was a beautiful introduction to the motivation behind domain modelling and why it matters when working on large software systems. I came to learn about the limitations of AI but left curious about this aspect of software engineering I know so little about.

Was a delight to read.

What literature do you recommend for individuals like me looking to begin exploring this type of thinking within their day to day programming work? It might be a bit too early in my career to consider formal approaches but at least philosophically, I could get started with having it shape how I approach my work.

[Leon Pennings](https://hashnode.com/@leon74)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f9d643a386d7f1217bf81a#reply-69f9dbfca386d7f12181b638)

Hi Chisomo,

really appreciate the kind words, glad it resonated.

You’re asking the right question, and also a slightly dangerous one 🙂. That's because it’s tempting to answer it with a reading list, while the thing you’re trying to learn is not primarily learned from books.

Domain modelling is much closer to a craft (like pottery, or architecture) than it is to something you can absorb passively. Books can give you vocabulary and examples, but the actual skill develops when you try to structure something yourself and feel where it resists.

That said, a few things are worth reading, just not in the way people usually recommend them:

Domain-Driven Design: Tackling Complexity in the Heart of Software — mainly for the idea of ubiquitous language. That chapter is foundational. The rest is useful as reference, but I wouldn’t try to “apply DDD” as a method. Design Patterns: Elements of Reusable Object-Oriented Software — not because patterns make you a good modeller, but because they give you a vocabulary for expressing structure once you start seeing it. The Mythical Man-Month — older, but still one of the clearest explanations of why conceptual integrity matters.

More important than reading is how you approach your day-to-day work. A few practical starting points:

Try to avoid “fat services” that orchestrate everything. Ask yourself: which object actually owns this behaviour? Then move it there. Let objects own both state and behaviour. If something has behaviour but no state, that’s fine — it can still be an object that owns that responsibility. When something feels awkward to implement, don’t immediately work around it. Treat that friction as a signal that your model might be off.

If you want something more hands-on, there’s an old exercise that still works surprisingly well: take a simple domain (orders, invoices, etc.), assign each concept to a person (or even just objects on a table), and “play through” a scenario. Each participant is only allowed to act within their responsibility. It sounds simplistic, but it forces you to think about boundaries in a very concrete way.

The goal at this stage isn’t to “do DDD correctly”. It’s to start noticing the difference between:

putting code where it’s needed, and putting behaviour where it actually belongs.

Once you see that difference, you’ll start seeing it everywhere.

If this way of thinking clicks for you, I write more about it here as well: [https://blog.leonpennings.com](https://blog.leonpennings.com/) It’s essentially an extension of the same ideas from the article, just explored from different angles.

[Chisomo Chiweza](https://hashnode.com/@mwprogrammer)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f9d643a386d7f1217bf81a#reply-69f9e7caa386d7f1218b9aa2)

Thank you. Will be sure to check out the list and your blog too :)

[Abdul Qadeer](https://hashnode.com/@abdulqadeer254)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f951c846610fd6064f4019)

This really hits on something a lot of people miss when they hype AI as “able to build anything.”

It can generate code, systems, even entire products—but that doesn’t mean it understands why those things should exist or how they behave outside the patterns it’s seen. In a way, it feels like we’ve optimized for output before truly solving understanding.

What stood out to me is how similar this is to how modern AI is trained—more like “growing” something than engineering it step by step, which explains why it can be incredibly capable yet still unpredictable in deeper reasoning.

I think the real edge right now isn’t just using AI to build faster, but pairing it with strong human judgment—especially in defining problems, not just solving them.

Curious how others see this: do you think better tooling will close this “understanding gap,” or is it something fundamentally different from how current AI works?

[Leon Pennings](https://hashnode.com/@leon74)

[May 5](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f951c846610fd6064f4019#reply-69f97ead46610fd606684691)

The real question is whether better tooling / future AI will close this “understanding gap.” I believe the answer depends on the scale of the application:

For small, relatively simple applications (roughly up to 20-30 user stories), tooling and current AI can already replace most traditional development. The domain is shallow enough that deep modeling isn’t critical. For larger, long-lived enterprise systems, I don’t think better tooling alone will be enough. The gap isn’t just a matter of more context or better prompts. Building a good domain model requires imagination, conceptual invention, and iterative discovery through friction, the very process that current AI architectures bypass. AI generates structure quickly, but it doesn’t hold intent or accumulate nuanced understanding the way evolutionary modeling does.

Until AI can actively perform real domain modeling (discovering natural concepts, responsibilities, and boundaries), the most effective approach remains strong human engineering judgment paired with AI as a powerful accelerator for implementation. So yes, tooling helps a lot. But it hasn’t replaced engineering in complex domains, and I’m not convinced it will anytime soon.

[Suny Choudhary](https://hashnode.com/@sunychoudhary)

[May 4](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f8898d46610fd606d84b6a)

This hits the core issue. AI can generate structure fast, but it doesn’t hold intent. So you get something that “works,” but doesn’t always align with why it exists or how it should evolve. That’s why the bottleneck shifts from building to guiding.

[Leon Pennings](https://hashnode.com/@leon74)

[May 4](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f8898d46610fd606d84b6a#reply-69f88c8546610fd606dab276)

For smaller applications, AI can often handle the full cycle effectively. For larger, long-lived systems, though, a coherent domain model and deep context become critical. In the evolutionary modelling approach, building the code is the learning process. The friction, the failed attempts, the moments when a concept doesn’t fit, these aren’t obstacles. They are the essential feedback mechanism that refines your understanding of the domain. The code becomes both the map and the territory. AI breaks that loop. It’s like having someone else read War and Peace for you and then giving you a detailed summary. You might grasp the broad plot, the Napoleonic wars, the fates of Pierre, Natasha, and Andrei, but you miss the emotional depth, the evolving character arcs, the philosophical layers, and the subtle interconnections that give the story its real power. In small applications, those nuances often don’t matter much. In complex systems, they are everything. The accumulated understanding of why things exist, how responsibilities truly relate, and how the domain behaves under pressure lives in those details. When you outsource the building, you also outsource the learning. That’s why the 85%; the structuring, naming, and boundary finding, cannot be fully delegated. It’s not just design. It’s domain acquisition through the act of building.

[Suny Choudhary](https://hashnode.com/@sunychoudhary)

[May 4](https://hashnode.com/posts/ai-can-build-anything-except-an-understanding-of-what-you-are-building/69f8587146610fd606afcbc1/comment/69f8898d46610fd606d84b6a#reply-69f88d8646610fd606db68e4)

The “code as learning” point resonates. AI gives you the result, but skips the iterations that normally shape your understanding. That tradeoff is fine for small systems, but becomes risky as complexity grows.