Markplane hit 100 stars on GitHub.
First real signal that people want AI assistants that actually understand what they're building, not just how to write code.
Thanks to everyone who's tried it, filed issues, or sent it to a friend. We'll keep building and making it better.
https://t.co/qEZSu36fUN
Two ways to scale AI. One: add billions of identical components and a nuclear plant. Two: make each component carry more information.
We chose option one. The brain chose option two.
Silicon scales by copying. Billions of transistors, all the same, stamped onto rigid chips. Need more power? Add more of them. Need to cool them? Add water. Need to power the cooling? Add a reactor.
The brain scales by differentiating. Each neuron does something different. The networks reshape themselves. The whole system runs on 20 watts.
Northwestern just printed artificial neurons — on a flexible polymer, with ink — that generate signals complex enough to trigger responses from living brain cells. Not simplified pulses. Actual spiking patterns. Bursts, single fires, continuous signals. One component encoding what would take a network of silicon devices to replicate.
That's the part worth paying attention to. Not that artificial neurons can talk to biology (though that's wild). It's that each printed neuron carries more information per component. That's a different scaling philosophy than anything the AI hardware industry is currently building toward.
The current trajectory has a ceiling measured in gigawatts and nuclear plants. The alternative might be weirder materials doing more per unit.
The brain figured this out a while ago. We're just starting to print our way toward the same conclusion.
https://t.co/XLPohMHyCb
Code is being generated faster than teams can understand it. That's not an argument against AI — it's an argument for better tools for shared understanding. We think project context that lives alongside the code, structured for both humans and AI to read, is part of the answer. That's what we're building.
The hardest problem in AI-assisted development isn't making the AI write better code. It's making sure the AI knows what code to write.
Most tools give agents access to the codebase and hope context emerges. We think context should be explicit, structured, and version-controlled alongside the code it describes.
The multi-agent/org-design parallel is real and we keep bumping into it. When you structure agent collaboration, you're doing organizational design whether you call it that or not.
We think the missing piece is the same one that's missing in most organizations: shared context. Agents need institutional memory the same way teams do. That's been our thesis from the start.
This is what we think about every day. It doesn't matter how many agents you run if none of them understand what the project actually needs. That's the problem we're building around.
The multi-agent pitch is always "more agents, more speed." Sometimes that's true. But every agent you add without giving it real understanding of the project just creates more confident wrong output, faster. The bottleneck was never how many agents you could run. It's how much each one knows about what it's supposed to be doing.
Markplane now works as structured agent memory for OpenClaw.
We originally built it as a project management layer that lives in your git repo — markdown files, YAML frontmatter, compressed context summaries designed for AI coding workflows.
Turns out that's also what agent memory looks like when you do it right.
Open source. OpenClaw plugin included.
https://t.co/lju3Ixvu5P
Intent debt is a problem statement we keep coming back to. If the reasons behind decisions aren't externalized, in a form humans and agents can both access, every autonomous change carries risk that code review can miss.
There's a new paper formalizing something I've been thinking about: "intent debt."
Technical debt is in the code. Cognitive debt is in people's heads. Intent debt is what happens when the reasons behind design decisions aren't captured anywhere, not in comments, not in docs, not in any form an AI agent can access.
It's the most dangerous of the three in an agentic world, because an agent with no access to design rationale will make changes that are locally correct and globally wrong.
The first version of Markplane was embarrassingly simple. Markdown files in a git repo.
Turns out that's also what the current version is. We just got better at being simple.
Core differentiators:
- Your PM data is markdown files, version controlled in your repo. Git is your changelog.
- AI agents get structured MCP tools for project management, and because the data lives with your code, they also have direct read/write access for real collaboration and context. Built for AI, not "AI bolted on".
- A generated context layer gives AI a token-efficient understanding of your project. Persistent project memory that stays current.
- Everything runs from a single binary, locally on your machine. CLI, MCP server, web UI. No accounts, no database, no SaaS, no context-switching.
We just open sourced Markplane — AI-native, markdown-first project management where your repo is the project manager.
Here's why we built it and what makes it different 🧵
https://t.co/0qPEcOEnAl
"Human in the loop" shouldn't mean "human babysitting the AI."
It should mean: the AI knows enough about the project to do real work, and the human has enough visibility to make real decisions.
That's collaboration. Everything else is just autocomplete with anxiety.
@gregisenberg Yes. Loving cowork right now. Basically claude code for stuff that's not code. Here's the missing piece for the code side - open source:
https://t.co/0qPEcOEVpT
Vibe coding works until it doesn't. The failure mode isn't bad code — it's amnesiac code.
Every session starts from zero. No memory of yesterday's decisions. No awareness of what's blocked or why. Prompt-and-pray.
Agentic engineering is the other thing. Same model, but with structured context — tasks, dependencies, intent — living alongside the code. The AI doesn't guess what you're building. It knows.
One treats AI as a talented stranger you brief from scratch every morning. The other treats it as a collaborator with access to the project's memory.
Coding agents are phenomenal inside a single small repo. Hand them a microservices architecture and they fall apart. The discourse says this proves agents aren't ready for "real" systems.
Wrong diagnosis. The problem isn't agent intelligence — it's that we spent a decade deliberately fragmenting context across service boundaries. Microservices are designed so no single human needs the full picture. Agents need exactly the full picture we optimized away.
The fix isn't a smarter model. It's making project context — what's being built, why, what depends on what, what's blocked — explicitly available where agents can consume it. Not buried in Jira tickets and Slack threads and someone's head. Structured, version-controlled, living next to the code.
That's the thesis behind Markplane: project state as structured markdown files in your repo, right next to the code, where agents can read them directly. The MCP server gives agents tools to understand project context and manage it — create tasks, update status, track dependencies across services. When the agent knows which service owns which behavior and why the current sprint prioritizes this boundary over that one, it stops guessing.
Agents don't suck at microservices. They suck at working without context. So does everyone else.
This is v0.1.0. It works — rough edges and all.
Looking for developers to try it and tell us what's broken, confusing, or missing.
Star it if it's useful. Break it if you can. We're all ears.
https://t.co/0qPEcOEnAl
#opensource#buildinpublic#ai#rust#developertools#mcp
Getting started:
→ brew install zerowand01/markplane/markplane
→ markplane init
→ plug in your AI assistant (MCP)
→ rock and roll
One binary. Zero infrastructure.