# Semi-autonomous Software Development
> A connected system that keeps useful work moving, asks for human judgment when it matters, and learns how to need less intervention next time
- HTML version: https://robbiepalmer.me/initiatives/semi-autonomous-software-development
- Projects: 8
# Vision
Build software with a standing capacity to improve itself.
People should set direction, supply taste, resolve genuine ambiguity, and own
risk. They should not have to remember every unfinished task, move tickets
between columns, repeatedly prompt an agent to continue, or notice the same
mechanical failure for the fifth time.
The system should track established knowledge, the intended outcome, blockers,
who currently holds the work, and the evidence that would prove completion. It
should keep agents working within the authority its owners grant. When it needs
a person, it should ask through an attention inbox with enough context to make
the decision quickly.
This begins with my personal projects. Once it survives real use, I can pressure
test it with my team, then other teams inside and outside my organisation.
# Why these projects belong together
Agentic development has made producing changes cheap. The surrounding work has
not caught up. Plans still live across Shortcut, GitHub, live agent sessions,
local documents, and people's heads. Agents can generate enough issues, pull
requests, prose, and status updates to make those systems harder for people to
use.
The answer is not another board filled with more detailed tickets. The missing
parts are connected systems with different responsibilities:
* The [Personal Knowledge Graph](/projects/personal-knowledge-graph) records
what is known, why decisions were made, and which ideas, technologies, roles,
and projects relate.
* The [Agent-first Writing Editor](/projects/agent-first-writing) turns the
output of research and agent sessions into writing people can absorb.
* The [Work Graph](/projects/work-graph) records desired outcomes, dependencies,
evidence, leases, and requests for attention.
* The [Agent Coordinator](/projects/agent-coordinator) matches ready work to an
available person or agent without making execution concerns part of the work
model.
* [Agent-friendly Remote Development](/projects/agent-friendly-remote-development)
gives each person a durable, private place to run those agents and answer
requests across devices.
* [Agentic Code Review](/projects/agentic-code-review) supplies the independent
verification needed before more changes can merge without a person reading
every line.
* [Open Collective Development](/projects/open-collective-development) tests
how the same model might coordinate people who contribute their judgment and
agent-assisted effort to public projects they want to exist.
# The bottleneck is already visible
Only four of the eight roles on this site have linked projects. Many technology
pages still lack the detail behind the name. Ideas and useful new workflows sit
in agent sessions or memory instead of becoming posts. The obstacle is rarely a
lack of source material. Turning that material into a bounded project, checking
the evidence, refining the argument, and producing prose worth somebody else's
attention takes too much work.
That content debt exposed the wider problem. The repository already contains
much of the context an agent needs, but it does not yet notice every gap, plan
the work, keep it moving, and ask for review at the right point.
# The operating loop
```mermaid
flowchart TB
Signals["1. Understand and prioritise
Ideas, telemetry, users, code and research"]
Signals --> Knowledge[Knowledge graph]
Signals --> Work[Work graph]
Knowledge -->|informs priorities| Work
Work -->|ready work| Coordinator
Knowledge -->|read directly while working| Execution
Coordinator["2. Assign ready work
Agent coordinator"] -->|lease and starting context| Execution[People and agents execute]
Execution --> Evidence["3. Verify and decide
Evidence"]
Evidence --> Review[Automated checks and agentic review]
Review -->|publish accepted knowledge| Knowledge
Review -->|needs judgment| Attention[Attention inbox]
Attention -->|decision| Execution
Evidence -.-> Analytics
Attention -.-> Analytics
Analytics["4. Remove recurring bottlenecks
Delivery and intervention analytics"] -->|creates work graph change| Work
```
The graphs store different truths. The knowledge graph says what is known. The
work graph says what should happen and in which order. A task can link to useful
knowledge, but it should not copy that knowledge or limit what an actor may
read. People and agents query the knowledge graph directly while working. They
can find requirements, designs, ADRs, prior findings, and domain context as new
questions arise.
The coordinator decides who should attempt ready work and gives them the lease
and enough context to start. Accepted discoveries return to the knowledge graph
through review. Decisions return to the people and agents doing the work.
Analytics creates work graph changes that remove recurring bottlenecks. A data
warehouse retains operational telemetry without filling the public graph with
every model call and retry.
# An adaptive model of the organisation
The initial scope is me and my agents. Model my objectives, the work needed to
reach them, my available attention, and agent capacity. The wider ambition is a
digital twin of an organisation's objectives, plans, and capacity, but the first
test is whether this model helps my own work move forward.
This is an [adaptive planning](/ideas/adaptive-planning) problem. Keep the goal
fixed, expect the plan to be wrong, and revise it as execution creates knowledge.
Agents with equivalent capabilities, access, and starting context can often
substitute for one another. The model should account for differences that affect
delivery, including handoff costs, model limits, and tool access. My judgment and
attention remain constraints that additional agents cannot automatically remove.
The Work Graph stores the plan and its revisions. The knowledge graph holds
accepted findings and their evidence. The Agent Coordinator matches ready work
to actors. Analytics should use delivery results, waiting time, rework, and
human interventions to propose changes across that system.
For example, if review is repeatedly the bottleneck, starting more coding tasks
may make delivery worse. Improving the
[code review solution](/projects/agentic-code-review) may enable faster merges
with greater confidence. Compare that investment with delivering another
feature, limiting work in progress, or reserving review capacity. Use evidence
about the critical path and lead times to decide which work advances the goal.
The knowledge base is another investment choice. Repeated agent mistakes or
reliance on weak ideas may justify correcting an explanation, adding missing
evidence, or replacing outdated guidance. The system should connect those
failures to proposed improvements and check whether the improvements reduce
rework. Feature delivery, tooling, and knowledge maintenance compete for the
same capacity and should be prioritised together.
Begin with a simple policy: regularly replenish and reprioritise the queue,
then pull the highest-priority eligible task when capacity becomes available.
Only tasks in flight are committed. Test refinements against that policy by
measuring lead times, avoidable waits, and rework. Identify what can run in
parallel and what is holding up the critical path. Forecast only the delivery
of an individual task after it is picked up. Historical replay can help reject
weak proposals, but it cannot prove what an untried allocation would have achieved.
Owners choose the outcomes and tradeoffs. Optimisation should account for
delivery risk, cost, learning, and disruption. Neither maximum utilisation nor
ticket throughput is a sufficient objective, as
[Goodhart's Law](/ideas/goodharts-law) would suggest. The system should propose
refinements we can inspect and learn from, with stronger evidence required
before granting it more authority.
## Related research and products
Research and product documentation reviewed on 12 September 2026 show that parts
of this approach already exist. I have reviewed these precedents through their
documentation and have yet to validate the products in use.
| Precedent | What it contributes | What I still need to test |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| [RAND's assumption-based planning](https://www.rand.org/pubs/monograph_reports/MR114.html) | Identify vulnerable assumptions and signals that should trigger adaptation. | Can execution evidence keep assumptions and affected graph branches current at low cost? |
| [Herroelen and Leus, project scheduling under uncertainty, 2005](https://www.sciencedirect.com/science/article/pii/S0377221704002401) | Treat uncertainty, reactive scheduling, and schedule stability as explicit planning concerns. | How should interruption costs and discoveries that change the task graph affect the planning policy? |
| [Autonomous Digital Twin of Enterprise, 2022](https://www.mdpi.com/2227-7390/10/10/1662) | Combine an ontology with multi-agent task and resource allocation, event-driven replanning, and what-if simulation. The paper reports IT service desk validation. | Does the approach transfer to software discovery, where both the tasks and desired solution can change? |
| [Tempo Portfolio Manager, formerly LiquidPlanner](https://help.tempo.io/portfoliomanager/latest/predicting-project-outcomes) | Forecast using ranged estimates, priorities, dependencies, and resource availability; recalculate as inputs change. | How well can it represent invalidated assumptions and changing scope, beyond rescheduling known tasks? |
| [Planview's Outcome Intelligence Graph and Agent Resource Management](https://newsroom.planview.com/planview-closes-the-gap-between-strategic-intent-and-business-outcomes-in-the-age-of-ai/) | Planview describes connected strategy and execution, scenario planning, and joint governance of human and AI agent capacity. | Can its proposed plan changes expose evidence and control disruption in a small team's daily work? |
The enterprise digital twin paper is a close research precedent, and Planview's
stated direction overlaps with this initiative. Neither establishes that this
particular loop works for my projects. The case for building it must rest on
that practical test.
Tempo's portfolio forecasting is adjacent to this initiative's focus on critical
paths, parallel work, and task lead times. The product test is whether a tool can
keep the queue useful as evidence changes and help work in flight finish sooner.
# Principles
## Public by default
The knowledge graph and work DAG should normally be public. Public plans make
collaboration easier and expose abandoned ideas, negative results, and changing
assumptions instead of presenting a false story of effortless progress.
Some information cannot be public. Private notes can live in the Home Lab;
personal financial records belong inside the authenticated Personal Finance
App; product data can sit behind the agent authorization model introduced by
Recipe Site. Private execution logs and cost telemetry belong in the data lake,
not the public DAG.
## Owners set authority
Each owner defines acceptable risk through policy. The system should not bake in
one universal answer to whether an agent may change a plan, spend money, access
production, merge a pull request, or deploy. It should make the active authority
visible and enforce it.
## Evidence closes work
Completion depends on context. It may mean accepted research, a recorded
decision, a merged change, or a healthy deployment. Every executable task needs
acceptance criteria and evidence strong enough for the owning project's risk.
## Plans adapt without constant disruption
Agents must be able to split work, add dependencies, invalidate earlier tasks,
and reshape the critical path as they learn. Owners constrain the allowed
shapes and transitions. Keep queued work provisional and commit only when a task
starts. Reprioritise the queue as evidence arrives; interrupt work in flight only
when the benefit justifies the disruption. Preserve the evidence behind each
change. The Work Graph records that history;
the initiative learns when adaptation improves outcomes and when it merely
creates nervousness.
## Human attention is an exception worth learning from
The attention inbox should receive decisions that require human judgment,
missing authority or access, repeated technical failure, material review, and
discoveries that change scope or priority. Analytics should find recurring
causes. A repeated request for a secret may justify passwordless agent access.
A recurring review failure may justify a test, deterministic check, or stronger
review policy. The system should remove the cause so it does not process the
same exception faster forever.
# Adoption path
## Personal use
Use the system on the projects in this repository. It must reduce the work held
in my head and make it easier to resume across agents, machines, and usage
limits. A public work DAG and a focused attention inbox are the first product
test.
## Team use
Bring it into a small team once the personal loop works. Team use tests whether
the recorded context is legible to somebody who did not create it and whether
owner policies can represent different risk tolerances.
## Wider use
Support other teams and organisations only after the system works under shared
ownership. Open project coordination comes later because governance and
maintainer attention are harder problems than task execution.
# Current evidence
Parts of this already work:
* This repository keeps requirements, designs, ADRs, content, and code together
so agents can find context without a large instruction file.
* The public site renders projects, roles, posts, technologies, and ADRs as a
connected knowledge graph with plain Markdown twins for agents.
* Vale checks changed prose before it reaches readers.
* Agentic Code Review owns durable pull request state and records evidence about
which findings people accept and fix.
* PostHog Self-driving watches telemetry and session replays, then creates work
without waiting for a person to notice and prompt an agent.
* Recipe Site has an authorization flow through which a person can grant an
agent narrow, expiring access.
These parts still fall short of a self-maintaining system. Shortcut, GitHub,
agent sessions, and memory still compete as sources of truth for work.
# Critical path
1. Finish representing initiatives and their projects in the public knowledge
graph.
2. Define the smallest Work Graph that can replace the personal Shortcut and
memory loop for one real project.
3. Give agents a safe interface to propose, claim, update, block, and complete
work with evidence.
4. Build the attention inbox around real exceptions from that loop.
5. Connect one event source, likely GitHub or PostHog, without turning either
into the source of truth.
6. Add the Agent Coordinator after the Work Graph has enough real work to test
matching, leases, expiry, and handoff.
7. Increase automatic merge and deployment only where Agentic Code Review,
deterministic checks, and owner policy provide adequate evidence.
8. Use intervention analytics to create and rank work that removes recurring
human bottlenecks.
9. Test the system with a team before attempting open collective development.
# Success
The initiative succeeds when useful work continues without somebody repeatedly
starting it, the critical path stays visible, and requests for human attention
become fewer and more consequential. Neither task count nor agent use measures
success. The outcome is software delivered with less coordination overhead and
no hidden loss of quality or control.
# What this is not
* A promise to remove people from software development
* A single agent with unlimited authority
* A project board focused on reporting activity
* A data lake exposed as a public knowledge graph
* A model vendor or coding-agent subscription broker
* A claim that every project should build its own permanent platform
The surrounding market should eventually make much of this plumbing redundant.
The bet appears in
[Crossing the Chasm with AI Platform Teams](/blog/2026-08-18-crossing-the-chasm-with-ai-platform-teams).
Waiting costs more than building the temporary system now.
## Projects advancing this goal
- [Personal Knowledge Graph](https://robbiepalmer.me/projects/personal-knowledge-graph.md): The connected source of truth for my work and an incubator for ideas, projects, and products
- [Agentic Code Review](https://robbiepalmer.me/projects/agentic-code-review.md): A stateful, model-agnostic GitHub App for high-signal code review at agentic development velocity
- [Agent Coordinator](https://robbiepalmer.me/projects/agent-coordinator.md): A matching and handoff system that offers ready work to suitable people and agents without owning the work plan
- [Agent-first Writing Editor](https://robbiepalmer.me/projects/agent-first-writing.md): A layered writing system that turns dense agent output into prose people can absorb without erasing the author's voice
- [Open Collective Development](https://robbiepalmer.me/projects/open-collective-development.md): A coordination model for people who contribute judgment and agent-assisted effort to public projects they want to exist
- [Work Graph](https://robbiepalmer.me/projects/work-graph.md): A public source of truth for outcomes, dependencies, evidence, leases, and the human decisions that keep work moving
- [Agent-friendly Remote Development](https://robbiepalmer.me/projects/agent-friendly-remote-development.md): Persistent remote workspaces for directing coding agents across devices, repositories, and harnesses
- [Personal Engineering Platform](https://robbiepalmer.me/projects/personal-engineering-platform.md): An executable developer platform for building and operating personal projects
---
Markdown index of this site: https://robbiepalmer.me/llms.txt