AI can create apps very rapidly - but will they be production ready?

Most likely not, unless there is a human architect in the loop to guide AI through the architecture process.

It is my opinion that the Agile Manifesto ("Working software over comprehensive documentation") significantly contributed to the disintegration of architecture and software design. The consequence is that AI cannot effectively generate or maintain complex systems because we stopped writing down the blueprints 20 years ago.  LLMs train on patterns found in data; because teams no longer produce formal architectural documents, AI models have almost zero quality, modern, end-to-end architectural blueprints to learn from.  So when you ask AI to create an application, it can do so very rapidly, adhering to all of your prompting information and business rules, and it will work. But to do so, it has to average out a chaotic mess of contradictory internet code, leading to hallucinations, architectural bleeding, or generic, low-quality structures.

Architect Review

For my ai-research-blog project, I have a fully functional blog that manages posts, pages, users, categories, and more.  I was waiting for that functionality to be completed so that AI could start writing blogs (via an MCP server) and, more importantly, so we could use it for collaboration.  The workflow is that AI writes code and gives me an overview, I review, we update, I approve, and we start the next task—we work in stages, and I can keep up because of the collaboration posts and, if applicable, blogs.  All of this is fully functional code in this ai-research-blog project.  However, in the following architectural review diagram, you'll see that it has no ability to extend.  I intentionally waited until this point so we could do a red-green refactor and use the collaboration process to clean it all up [no fault of the AI—the architecture is a mess with no reusability or extensibility].

Legacy Overview
zoom image

Those bottom-left ovals are the applications we are going to now create using this amazing framework.  Only problem is we were painted into a corner with this architecture.  I emphasized this with AI in my first request: "Can you change the data layer implementation from NQuad (triple stores) to a SQL Server?"  All you have to do is swap out the IDal (data layer) and create the SQL implementation.  Then I asked it, "Can you use this amazing framework to create a WPF application? All you have to do is swap out the Angular presentation layer for a WPF application."  My real-world questions went on to include multiple client apps—I then told AI that this is the only way this framework can go into beta: when it can be used for more than one app.

I then gave it my architectural gap analysis, the above image of where we are versus the below—where we need to be.  Below, I showed AI how the project dependencies should work to achieve this goal.  I had already created a POC that shows how the MVPVM component works so that with IoC we should only have to change the configuration of the IoC container; everything should be reusable and plug-and-play—particularly when we use the MEF [plugin] components.  This is that major refactor I was alluding to above.  This very cool, amazing framework would have prevented us from doing much else with it outside of a blog application, making future features a risk as they may not be possible [the exact place I am right now].  

Refactor Overview
zoom image

I gave AI the following architectural documents and told AI to read them [do not infer] and from them, knowing the context of the above UML diagrams, to generate an architectural document that will serve as the standard for our code moving forward. I specified that it must reference our architectural document before churning out code and must use it before its own training or any external source.   

Claude generated the following document: Claude-architecture-reference.md (18.84 kb)

Fully functional blog with collaboration features (before refactor)

 

Comments are closed