As developers, we often talk about AI making mistakes.
Wrong functions.
Broken logic.
Hallucinated APIs.
But honestly?
Those aren’t the most annoying problems.
The most annoying problem is having to repeat yourself.
Again.
And again.
And again.
You explain your project.
The architecture.
The folder structure.
The current task.
The previous decisions.
Then the next day, you start over.
For small experiments, that’s fine.
For real projects, it’s frustrating.
AI can generate code quickly.
But software development isn’t just code generation.
It’s a process.
A long-running process.
Projects evolve.
Requirements change.
Tasks build on top of previous tasks.
Developers remember these things naturally.
AI usually doesn’t.
That’s why I started working on Contorium.
The idea is simple:
Help AI maintain awareness of what has already happened inside a project.
Not because developers need more code generation.
But because developers need continuity.
Especially beginners.
When you’re learning, context matters.
You don’t want to spend half your time reminding an AI what you’re working on.
You want to keep moving forward.
That’s the problem I’m trying to solve.
Not making AI write more code.
Making AI stop forgetting.
Top comments (4)
Agreed, and my candidate for the most annoying part is the review tax: the model produces plausible code fast, but now YOU'RE the bottleneck, reading and verifying output you didn't write, in a style that isn't yours, hunting for the one subtly-wrong line hidden in 200 confident ones. The generation got 10x faster and the reviewing didn't, so the work just shifted from writing to verifying - and verifying someone else's plausible-looking code is genuinely harder and more tiring than writing your own. The other contender is the context tax: re-explaining your project every session because the model has no memory of your decisions.
Whichever you meant, the through-line is the same and it's the thing I build around - the bottleneck moved from generation to verification, so the leverage is in automating the verification, not generating more. That's the core of Moonshift, the thing I work on: a multi-agent pipeline that takes a prompt to a deployed SaaS, where a verify layer checks the output so you're not the one manually reviewing every line for the subtle break. Multi-model routing keeps a build ~$3 flat, first run free no card. Really curious which annoyance you landed on - the review burden, the context-reloading, or the confidently-wrong-in-a-plausible-way problem? They need different fixes and I'd bet on the one you picked being the review tax.
Great breakdown.
I’d say Contorium is primarily focused on the context tax.
The review tax is very real too, but I see it as a downstream problem. If an AI system keeps losing project context, it tends to generate more irrelevant changes, which increases the review burden even further.
My bet is that continuity comes first: if the system actually understands the project history, decisions, and current state, we can reduce a significant portion of unnecessary review before tackling verification itself.
Moonshift seems to be taking the opposite angle — reducing the review burden directly through verification layers. I think both directions are complementary rather than competing.
That causal chain is the sharp part: context tax is upstream of review tax. If the model never lost project context it would generate fewer irrelevant changes, and the review burden shrinks on its own. So fixing context isn't only its own win, it deflates the downstream review problem too. The nuance I'd add: even with perfect context you still owe a verify pass on the genuinely hard changes, because correct-in-context still isn't the same as correct. Context gets you most of the way; the residual review tax is irreducible but small. That split (kill context loss, then verify the remainder) is basically how I structure Moonshift. How does Contorium hold context across a long session, a persistent index or re-injection per task?
Contorium doesn’t rely on long context windows.
We maintain a persistent project-level state built from code structure + semantic indexing + interaction history.
For each task, we rehydrate only the relevant context into the model instead of passing full session history.
This keeps context stable across tools (VS Code / Cursor / CLI) while avoiding noise and token waste.
It’s essentially “context reconstruction per task”, not “context accumulation”.