Everything is code — even project management

Most teams keep the project somewhere the code can't see it. Requirements live in a wiki. Decisions live in someone's memory, or in a Slack thread that scrolled away. Tickets live in a tool with its own login, its own data model, and its own quiet incompatibility with the repository the work actually happens in. The result is a project whose history is scattered across five systems, none of which the engineer — or the AI assisting the engineer — can read while doing the work.

We do it differently. The project is code. It lives in the repository, beside the application it describes.

The repo holds the whole project

Open one of our solutions and you'll find a project/ directory next to src/ and infra/. Inside it:

• adr/ — architecture decision records. Every consequential choice, why we made it, and what we traded away.
• specs/ — the specifications a feature was built against, versioned with the feature.
• tickets/ — work items as markdown, mirroring the board.
• meetings/ — summaries and, where useful, full transcripts.
• runbooks/ — how the thing is operated once it's live.

Everything is markdown where markdown can carry it. The format matters more than it looks. Markdown is diffable, reviewable, and greppable. It travels in pull requests. It survives the death of any SaaS vendor. And — this is the part that has quietly changed how we work — it is the native context format for an AI working in the IDE.

Context is the whole game

When the entire project is text in the repo, an agent doesn't have to be told the background. It reads the ADR that explains why we chose the queue over direct invocation. It reads the spec the function was built against before it touches the function. It reads the transcript where the client said the deadline was hard and the scope was soft. The history is right there, beside the code, in a form the model can consume.

We've built tooling on top of this: agents that open tickets on the board from a description, agents that review pull requests against the spec they were supposed to satisfy, agents that draft the meeting summary and file it where the next person — human or model — will find it. None of this is magic. It works because the substrate is right. You cannot ask an AI to reason about a project that lives in five systems it can't see. You can ask it to reason about a project that is a folder of markdown.

PM becomes a function, not a silo

Once the project is code, project management stops being a separate role hovering above the work and becomes a function distributed across the people doing it. The architect owns the decision records because the architect makes the decisions. The engineer who closes the ticket writes the note. The board — we prefer GitHub Projects precisely because it's lightweight and lives next to the repo — reflects reality because reality is committed alongside it.

This is not a claim that project management doesn't matter. It's a claim that, on a well-run engineering program, it is a property of the team rather than a person with a Gantt chart. The status isn't reported up; it's visible in the repo. The schedule isn't defended in a deck; it's an artifact you can read.

There is one honest exception. In a SOC 2 or similar compliance setting, you sometimes need a dedicated person to own the evidence trail and the ceremony auditors expect — and even then it's usually a part-time function, not a full-time seat. Outside of that, a separate full-time PM is often a symptom: it means the project isn't legible enough on its own, so someone is hired to translate it. Make the project legible and the translation layer disappears.

Why this holds under contact with reality

The phrase we use for delivery is that it has to hold under contact with reality, and project-as-code is part of how it does. When a program runs for years and people rotate on and off it, the institutional memory can't live in heads. When an integration breaks at 2 a.m., the runbook can't be in a wiki nobody updated. When a decision gets relitigated six months later, the ADR settles it in thirty seconds. The project, written down beside the code, is what lets a small team carry a large program without dropping its own history.

Everything is code. The project is no exception.

---

Working on a program where the history lives in five systems and nobody can find it? Start a conversation.