3 ms·

AI coding fails because architecture isn't persistent – I built a fix

2 points by danamakes 9mo ago

AI tools generate code fast — but codebases drift, patterns break, and the larger the repo gets, the worse the AI behaves. I think the root problem isn’t the model. It’s that architecture is implicit, disposable, and not machine-readable. The bigger the codebase, more entropy. I tried to fix this. So I built Archeon: - a local architecture layer - a CLI that enforces constraints before code is generated - and a GUI that visualizes intent, relationships, and outcomes This reduces context size, prevents invalid generations, and lets smaller or local models compete with larger ones. Everything runs locally. No SaaS. No training data. It works alongside existing editors and AI tools. Repo + demo video: https://github.com/danaia/archeonGUI https://www.youtube.com/watch?v=YtNKRKn5FEs I’m curious whether others see architecture — not prompting — as the missing layer in AI-assisted development.

cheevly 9mo ago
I like it. You’ve gone a bit too far though. It might be time to dwell on the bitter lesson and scale back.
- danamakes 9mo ago
  Not sure what you mean? Thanks for the comment! I did not think I went far enough!
danamakes 9mo ago
Just to clarify the motivation a bit. This isn’t meant to be a new IDE or a “better prompting” layer. It came out of frustration with how quickly AI-assisted projects drift once they grow beyond a few files. The core idea is that architecture usually lives in people’s heads or in docs, so every generation forces the model to re-infer structure from raw code. That inflates context and increases the chance of subtle breakage. Archeon treats architecture as a small, explicit, machine-readable artifact that exists outside the model and is validated before code is generated. The goal is to reduce degrees of freedom early, not to make the model smarter. Everything runs locally and can be ignored or removed at any time. If it doesn’t help a project stay coherent over time, it’s not worth using. I’m mostly curious whether others have hit the same scaling problems with AI-assisted codebases, and how they’ve tried to address them.

2 points by danamakes 9mo ago

cheevly 9mo ago

I like it. You’ve gone a bit too far though. It might be time to dwell on the bitter lesson and scale back.

danamakes 9mo ago
Not sure what you mean? Thanks for the comment! I did not think I went far enough!

danamakes 9mo ago

Just to clarify the motivation a bit. This isn’t meant to be a new IDE or a “better prompting” layer. It came out of frustration with how quickly AI-assisted projects drift once they grow beyond a few files. The core idea is that architecture usually lives in people’s heads or in docs, so every generation forces the model to re-infer structure from raw code. That inflates context and increases the chance of subtle breakage. Archeon treats architecture as a small, explicit, machine-readable artifact that exists outside the model and is validated before code is generated. The goal is to reduce degrees of freedom early, not to make the model smarter. Everything runs locally and can be ignored or removed at any time. If it doesn’t help a project stay coherent over time, it’s not worth using. I’m mostly curious whether others have hit the same scaling problems with AI-assisted codebases, and how they’ve tried to address them.