Bolt.diy architecture, components, responsibilities

Dear @Bolt-diy-core-team ,

it’s been a while since I’ve been writing here and even longer than I’ve been contributing. But as I wrote earlier, the current structure, architecture and mixed responsibilities makes it tricky for me to identify where to add features.

Added the lack of of automated testing, the project currently lacks easy extensibility (at least from my PoV).

I addressed the most critical aspect of files management earlier, but basically got no response.

So in order to illustrate what I thought would be a suitable, extensible base architecture, I started to implement a full workbench which utilizes the awesome web containers from scratch.

I have now reached a point where I can interact with LLMs and provide them tools (internally exposed via MCP with in-memory transports) that write to a synchronized file-system-infrastructure (browser, web container, local FS) and issue commands in the runtime environment.

This is actually no big deal (feature-wise), but I tried to focus on architecture, components, automated testing, documentation and responsibilities right from the beginning. This results in a much more maintainable develop-ability, particularly in having AI code editors do major parts of the work without blowing up the whole project :wink:

You can find the architecture docs at Piddie: Prompt-Driven Development Environment | Project Documentation and see how I structured it.

I don’t know how/whether the currently active devs (majorly @xKevIsDev and @private.winters.bf3 ? ) may be interested in re-vamping the base architecture (I recall that @thecodacus wanted to approach it step by step), but if there was a willingness to do that, I’d be very happy to contribute.

Let me know, what you think.

Cheers,
Oliver

5 Likes