There is a version of software project management that most engineering teams are living in, and it mostly consists of meetings. Daily standups that are really just status updates. Jira refinement sessions where you spend an hour writing descriptions of work you could have started. Sprint planning ceremonies that produce a board that is outdated by Wednesday.
The whole apparatus is designed to answer a few basic questions: what is everyone working on, what is blocked, what decisions have been made, and what comes next. It takes an enormous amount of meeting time to answer questions that are, at their core, just queries against project state.
We started asking whether the project state could live somewhere else. Somewhere that does not require a scheduled meeting to read.
The Idea
We run our entire development process out of git. Not just the code. Everything.
Requirements live in docs. Architecture decisions get written as Architecture Decision Records (ADRs) and committed. Open design questions go into a tracked file with the relevant context. The build plan with task dependencies and done-when criteria is a markdown file. Assignments are a markdown file. Task status is a YAML file. When something gets decided, it gets written down and pushed. When a task gets started or finished, the status file gets updated.
The docs repo is the command center. It is the source of truth for what the project is, what the plan is, who is doing what, and what decisions have been made and why.
All of it is versioned. All of it has a history. You can pull it and you know where you stand.
What a Work Session Looks Like
You sit down. You pull the latest from all the repos. Then you ask questions.
“What am I currently working on?”
“What work is unblocked and assigned to me today?”
“That task Brian finished yesterday. What did it unblock?”
“What are the open design questions that need a decision before we can move forward?”
These get answered by reading the docs: the build plan, the assignments file, the task status, the ADRs. All of it is structured and in git. You do not have to hold any of it in your head or track it down across multiple systems.
No standup required. No Jira board refresh. You pull and you know.
What’s the Catch?
Your first thought might be that having to read and manage everything in text files is not much better, and is often a higher cognitive load than just having a conversation. This is why SDLC methodologies like this have not taken off in the past.
The way we have made this work is that those questions above, like “what work is unblocked,” are not questions you ask yourself and then go hunt down in a file. They are something you literally ask your AI assistant and it finds the answer for you.
What Keeps This From Turning to Slop?
No offense to the AI writing this blog post for me, but you cannot just slap AI on things and expect it to work cleanly. To get this right, we built a way of treating SDLC artifacts as a typed system with propagation rules. We call this the Codex.
Every file in the workspace belongs to a class: decisions, requirements, plans, config, code, generated artifacts, and so on. Each class has defined rules for how it is created, what must reference it, and what else needs to change when it changes. Add an Architecture Decision Record and it must appear in the decisions index; the open question that prompted it must be closed. Mark a work task as done and the system surfaces which tasks were waiting on it. The types define the blast radius of every change, so when something updates, the system knows exactly what else needs to catch up.
This is what keeps the workspace coherent over time. Without the types, you end up with a pile of markdown that slowly drifts out of sync with reality. With them, changes have predictable consequences and the AI can reason accurately about project state because the structure is consistent and well-defined.
What Works Well
Decisions have a history. When someone asks “wait, why did we structure it that way?”, the answer is a file in the decisions directory with context, alternatives considered, and the rationale. This replaces a lot of tribal knowledge.
Context switching is cheap. You pull, you ask what you were working on, you have a branch name and done-when criteria in front of you. Getting back up to speed after a few days away takes minutes, not a morning.
Meetings are for actual collaboration. We still meet. We meet when we are working through a hard problem together, when someone is blocked and needs eyes on something, or when we need to coordinate on something that genuinely requires real-time discussion. We do not meet because it is Tuesday at 9am and that is when standup is.
Onboarding is faster. A new engineer can pull the workspace, read the onboarding docs, and ask questions. The entire history of why things are the way they are is documented and queryable.
What Does Not Work as Well
The docs have to stay current. This only works if engineers actually write the ADRs, update task status, and keep requirements from going stale. If the team treats docs as optional overhead, the whole system drifts out of sync and you lose the value fast. That takes discipline.
It is not built for non-technical stakeholders. The command center is a git repo full of markdown files. Clients and business partners cannot navigate that, which is why we still have Jira as the external interface.
The setup takes real effort upfront. Writing a proper build plan where every task has dependencies and verifiable acceptance criteria is not a quick job. It pays off, but it is not free. Teams that are used to throwing cards into a board and figuring it out as they go will find this more demanding.
Trust takes time. Engineers habituated to Jira have a strong instinct to go check the Jira board. Until the whole team internalizes that git is authoritative, you get questions about whether the docs and Jira are in sync. The answer is that git is the source of truth, but that takes some adjustment.
Is This Worth Trying?
It depends on the team.
Small teams with strong documentation habits who are already comfortable in git and practicing trunk-based development will adapt quickly. Teams with non-technical project managers running the process, or teams that need a visual board for stakeholder communication, will have a harder time.
What we can say is that the overhead of running this system is lower than the overhead of the meetings it replaces. The need for a morning standup is gone. The sprint ceremony overhead is gone. Time that used to go to process now goes to work.
If your team’s recurring meetings are mostly status updates, try treating them as a data problem.