I've been experimenting with tools like Bolt and Lovable.ai recently. The a16z article (https://a16z.com/ai-web-app-builders/) calls what they do "nothing short of magic" - and for simple apps, I agree!
But I've hit the exact limitations the article describes: "comparable to working with a junior developer who knows the basics but can easily get stuck in a 'doom loop' of bugs, especially as a project gets more meaty or complex."
The article mentions that "debugging is hard for site-generating agents" because of issues like:
- Finding the right code to debug is a "reasoning and search problem"
- Code has deep dependencies where "changes in one part of the system can cascade unpredictably"
My experience exactly. These tools are fantastic for quick prototypes, but fall apart when implementing real business logic - especially for enterprise applications where rules are complex and interconnected.
This got me thinking about Domain-Driven Design (DDD) as a possible solution. What if, instead of generating UI-first code, we used AI to help model the business domain and then generated an application from that model?
We've been building a tool called Swoft that takes this approach. It uses AI to help define your domain model (entities, value objects, aggregates), then generates a complete application that follows DDD/CQRS patterns.
The early results have been surprising even to us - technical debt ratio of just 0.2% (compared to industry average >10%), and time-to-market reduced by 95%. We've opened a waitlist for developers interested in trying this approach (already at 3000+ signups, which I didn't expect).
The key difference: instead of generating raw code, we're generating a configuration for a framework that enforces clean architecture.
I'm curious if others have run into similar limitations with these tools when trying to build apps with complex business rules? Or if anyone's tried applying DDD principles to AI-generated code?
ossm1db•9mo ago
DDD is just the beginning. A successful architecture for AI app generation will apply DDD using data-context-iteraction (DCI) in conjunction with Data-Oriented Programming as described by
Yehonathan Sharvit: https://blog.klipse.tech/dop/2022/06/22/principles-of-dop.ht... Note that the "DOP" espoused by Brian Goetz and others complicates AI app generation. It stipulates strong typing, that when combined with "making illegal states unrepresentable" (a concept borrowed from functional programming), makes change -- which is inevitable -- more difficult.
Uigatai•9mo ago
But I've hit the exact limitations the article describes: "comparable to working with a junior developer who knows the basics but can easily get stuck in a 'doom loop' of bugs, especially as a project gets more meaty or complex."
The article mentions that "debugging is hard for site-generating agents" because of issues like: - Finding the right code to debug is a "reasoning and search problem" - Code has deep dependencies where "changes in one part of the system can cascade unpredictably"
My experience exactly. These tools are fantastic for quick prototypes, but fall apart when implementing real business logic - especially for enterprise applications where rules are complex and interconnected.
This got me thinking about Domain-Driven Design (DDD) as a possible solution. What if, instead of generating UI-first code, we used AI to help model the business domain and then generated an application from that model?
We've been building a tool called Swoft that takes this approach. It uses AI to help define your domain model (entities, value objects, aggregates), then generates a complete application that follows DDD/CQRS patterns.
The early results have been surprising even to us - technical debt ratio of just 0.2% (compared to industry average >10%), and time-to-market reduced by 95%. We've opened a waitlist for developers interested in trying this approach (already at 3000+ signups, which I didn't expect).
The key difference: instead of generating raw code, we're generating a configuration for a framework that enforces clean architecture.
I'm curious if others have run into similar limitations with these tools when trying to build apps with complex business rules? Or if anyone's tried applying DDD principles to AI-generated code?