Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

Mycelium is an open-source workflow harness designed to make a builder examine a software idea before an AI coding agent starts implementation. Its sequence moves from purpose to strategy, opportunities, and a specification; the project asks who has the problem, what evidence supports it, and which assumption is riskiest. Creator Håvard Bartnes says he ran the process on Mycelium itself—and found that almost all of his logged decisions came after code had already begun.

What Mycelium is—and what it is not

Mycelium is software for structuring product discovery ahead of AI-assisted implementation. It is not a physical device, a code editor, or a general-purpose coding agent. Bartnes describes it as “a harness in front of the coding agent,” intended to keep work focused on the questions that precede code.

The project is aimed at solo builders and small teams creating software, online courses, AI tools, and services. Its public documentation describes project decisions stored in plain YAML and versioned in git. That makes the record part of the project rather than an ephemeral conversation with an agent. The Mycelium README documents the project and its setup.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How the workflow is meant to work

The intended sequence is purpose, strategy, opportunity, specification, then code. In practice, the builder and agent are meant to clarify the audience and problem, identify assumptions, and attach confidence and sources to claims before settling on what to build.

  1. Purpose: Establish why the project should exist and who it is for.
  2. Strategy: Set the direction for addressing that purpose.
  3. Opportunity: Examine possible user problems and identify assumptions that need testing.
  4. Specification: Turn the selected opportunity into a defined scope before implementation.
  5. Code: Begin building after the preceding questions have answers.

The discovery questions at the heart of the workflow are practical: Who has this problem? Have they said so? Which assumption is riskiest? What small step could test it? The repository also describes moving back a stage if implementation exposes a bad assumption. The process is therefore presented as a way to keep decisions inspectable and revisable, not as a guarantee that the original plan will be right.

What happened when Bartnes ran it on Mycelium

In a September 18, 2026 first-person account, Bartnes says he ran the script on the project after 126 sessions. It reported that the first source file was created on May 2, 2026, with 4 of 912 logged decisions made before it; only 1 of those 4 cited outside evidence, and no ideas had been killed before code existed. These are the author’s counts for his own project, not an independent assessment of Mycelium’s effectiveness. Bartnes’s account on DEV Community explains the self-audit.

Those figures make the point of the exercise more concrete: a builder can make hundreds of decisions while still doing little formal discovery before implementation. But the counts do not show whether the decisions were sound or whether an earlier discovery phase would have changed the product. Bartnes notes that the script reads logs and canvas files and counts entries; it cannot judge decision quality.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

The same article reports 124 pre-registered tests in the repository at the time of writing, including 65 added that September, and a correction log with 300 entries. Those figures describe project artifacts as Bartnes reported them; they do not establish product outcomes or independent validation.

Who is likely to benefit—and who may not

Mycelium is most relevant when a builder is uncertain about the user need, the cost of building the wrong thing is meaningful, and discovery decisions need to be made explicit before an AI agent makes implementation fast. It may be less useful when the need is already well understood, the cost of a wrong build is low, or a team has a reliable discovery practice that the harness would duplicate.

  • Consider it if you build alone or in a small team, use an AI coding agent, and want a traceable record of assumptions, evidence, and scope decisions.
  • Be cautious if adding a staged process would slow a low-risk prototype more than it reduces uncertainty.
  • Look for another fit if several roles need to edit shared decisions concurrently: the repository identifies centralized, cross-role workflows with concurrent editing as outside the tool’s current design.

This is a fit assessment, not a head-to-head product comparison. The sources do not provide independent outcome data showing that Mycelium improves software success rates.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Compatibility and setup details

Bartnes says the tool runs in Claude Code, opencode, and Mistral Vibe, while the repository documents a Claude Code setup. Compatibility and installation instructions can change, so check the current README before choosing an agent or following setup steps. The available source material does not establish current setup instructions for the other named agents.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.