AI coding assistants have changed how I develop software.
Instead of writing every line manually, I can ask an AI model to propose an implementation, generate code, review changes, or help diagnose failing tests.
But as I started using more models and tools, I noticed a different problem.
Writing code was becoming easier. Coordinating the work was not.
A feature might involve several dependent tasks. One model could help design the implementation, another could write code, and another could review the result.
But I still had to answer questions such as:
- Which task should run first?
- Which model is eligible for this task?
- Which agent is responsible?
- Which files may it change?
- What happens when the tests fail?
- How do I know the implementation is actually complete?
- Where do I keep the execution history?
I wanted to connect these activities without introducing another mandatory cloud service.
So I started building Accension.
It's an open-source, local-first AI model-routing and engineering orchestration platform written in Python.
GitHub: https://github.com/Jigsaw777/accension
From model routing to an engineering Workbench
The initial version of Accension focused on selecting AI models based on capabilities, quality evidence, privacy policies, and spending limits.
The idea was straightforward: different tasks may benefit from different models, and routing should be governed by explicit constraints rather than an arbitrary recommendation.
Version 1.1.0 extends that foundation with Accension Workbench.
Workbench introduces persistent projects, structured Product Requirements Documents (PRDs), Work Items, dependencies, agent assignments, execution attempts, and completion review.
The important architectural decision was to reuse the existing execution engine instead of building a separate task executor.
1. Start with requirements, not prompts
Consider a simple feature:
"Create a greeting function that handles named and blank inputs, with tests and documentation."
Instead of executing one large prompt, the requirement can be represented as a structured PRD.
The PRD defines the objective, scope, functional requirements, and acceptance criteria.
After reviewing the PRD, the work can be decomposed into smaller Work Items.
For example:
- Implement the greeting function.
- Add tests covering named and blank inputs.
- Document how to use it.
These tasks can have dependencies.
That matters because code execution should not be scheduled purely by the order in which tasks appear on a screen.
2. Make dependencies explicit
Accension represents executable task plans using its existing AXIR and ExecutionPlan contracts.
The Workbench adds a persistent management layer above those plans.
This distinction is useful.
A Work Item represents an engineering obligation that can survive a restart or multiple execution attempts.
An execution plan represents bounded work that can be carried out by the engine.
The Workbench stores Work Item state and relationships while the existing execution infrastructure performs eligible, approved work.
This avoids making the Kanban board a second execution engine.
3. Separate AI recommendations from authorization
An AI model can propose how to divide a feature and what capabilities a worker should have.
But a recommendation is not authorization.
Accension applies eligibility, privacy, budget, repository permissions and execution-policy checks.
In the Workbench, these concepts remain separate:
Agent: A configured worker.
Model: An inference backend.
Router: The component that determines eligible models.
Execution approval: A human decision authorizing the reviewed scope.
The goal is to make assignments explainable and prevent an AI-generated plan from silently expanding its own permissions.
4. Treat validation as a separate engineering step
One of the most important lessons from working with coding assistants is that a model's final message isn't reliable proof of completion.
An AI can report success even when code fails to compile, tests fail, or the requirements were only partially implemented.
Accension therefore records actual execution attempts and independent host-side validation.
The system can preserve artifacts and execution receipts that describe what happened.
Where human completion review is required, passing checks are necessary evidence but do not independently authorize completion.
The Workbench also distinguishes PRD approval, task import, execution approval, and completion review.
Those are different decisions.
5. Keep the architecture local-first
Accension uses a Python backend, FastAPI, and SQLite with WAL storage.
Its CLI, Workbench UI, and MCP interfaces interact with shared local application state.
This design keeps installation relatively lightweight and avoids requiring a separate hosted database or message broker.
The application can use local models, including through compatible local runtimes such as Ollama.
It can also use configured cloud providers.
That introduces an important privacy distinction: local project storage does not automatically mean all inference is local.
Authorized cloud requests can send permitted context outside the computer.
The application also supports optional secured LAN access through HTTPS, pairing, and workspace grants.
These capabilities are explicit configuration choices rather than a mandatory hosted service.
6. A reproducible demonstration
The repository includes a deterministic Workbench demonstration that does not require paid inference.
From a development installation:
python scripts/demo_workbench.py --feature
The demo creates an isolated repository and profile, constructs dependent greeting tasks, uses mock model output, runs real local checks, and verifies persisted receipts.
The resulting screenshots and metrics illustrate the workflow. They are not production-model benchmarks.
For the full experience, follow the installation instructions in the README and open Workbench.
What I learned
A few architectural decisions stood out while building Accension.
First, a task board should reflect real execution state, not merely move cards around.
Second, model selection and agent assignment are different responsibilities.
Third, permissions and approval boundaries must be enforced by application logic, not by an LLM's instructions.
Fourth, execution history and receipts are useful only when they represent real observed results.
Finally, a developer tool needs to be usable even when every external AI provider is unavailable.
That is why Workbench supports manual project and Work Item management without a model.
What's next?
I'm interested in improving the experience around:
- Local-model workflows.
- Agent adapters.
- Workbench usability.
- Execution verification.
- Documentation and onboarding.
- Contributor-friendly examples.
Accension is open source under the Apache 2.0 license.
Repository: https://github.com/Jigsaw777/accension
The project was built with assistance from Codex Astra.
I'd particularly appreciate feedback from developers using multiple coding assistants or experimenting with local AI models.
If you were designing a local AI engineering Workbench, what would you consider the most important missing feature?
Top comments (0)