Method (YC Spring 2025): teardown vs XMarts

In one line: Method is an open-source workflow file plus a command-line tool. A coding agent (Claude Code or Codex) writes a repeated task as a "Method" with checks, runs it, and edits it when a step fails [site] [docs]. Threat: 2, because it attacks the same problem as W8 (skills that need upkeep) but it is one person, has no named customer, and stops at one layer [yc] [site].

1. Fact file

2. Their proposition, reverse engineered

3. Positioning

• Category they claim: "Agents that improve"; workflows with checks for coding agents [yc] [site].
• Category a YC partner would put them in: developer tooling for agent reliability, next to skills and eval tools (inference).
• What they want to be known for: the file format and runner that make an agent workflow editable, checkable and versioned.
• Where they sit on the map: layers L1/L2/L3 = 1/1/2. Buyer = unknown size, developer.

4. Three layers vs ours

5. Same and different

6. Wedge overlap

7. Whitespace (where they stop)

• Layer gap: one workflow, no company memory and no approval flow in the guide [docs]. To own it we need a rule-change log tied to checked runs on a real team, with rework falling.
• Buyer gap: the tool needs a person who works in a coding agent and a terminal [docs]. A services firm or a product manager cannot use it as is (inference). To own it we need one non-engineer buyer who gets a result without touching a terminal.
• Number gap: their only public numbers come from a game test and the founder's own use [blog]. To own it we need one before/after number from a customer workflow run for 4+ weeks.
• Price gap: none; $200 a month is cheap [site]. Speed gap: none; install is one command and a first run takes minutes [docs]. We should not claim either.

8. For the YC application

• Proven today: Marton's logs show his system turns each failure into a written record and an automatic check: about 160 records, plus about 370 automatic checks, and offer feedback lines fell from 44 to 18 as 22 rules were added. Method's public proof is a game test and one founder's own workflows [blog].
• Draft answer to "how are you different from Method?": DRAFT. "Method makes one workflow editable and checkable, and a person asks the agent to fix it. Our system already turns every failure into an automatic check across a whole business, and asks people only the few questions that need them." Founders say it their own way.
• Future claim (needs proof): "Our skills improve from accepted and rejected work without anyone asking." Needs one team's skills run for 4+ weeks, with the rule-change log and a falling rework count.
• What we understand that they don't: the repair should come from checked outcomes and a few human answers, not from a user prompting the agent each time. needs proof on a second team; Marton's logs show it on his own work only.
• Copyability (M3): medium. They already have checks, versions, run records and a plugin for both big coding agents [docs]. Adding automatic improvement from run records fits their roadmap and their buyer, so it is a few months of work, not a pivot (inference). Adding company memory, approvals and non-engineer users would pull a one-person, terminal-first tool toward a different buyer. Not hard, so M3 can not score above 3 against Method alone.
• Why now (M4): None found in this teardown. Their own story (coding agents patching output, not workflow) is the same general AI progress.
• Do not claim: "nobody improves skills from real use" (Method and Nessie say it). "Our loop is automatic and measured" (anneal loops show 1 to 4 weekly runs, per the inventory). Any customer result.

9. Ideas worth taking

1. An open file format with a validator and a public spec. It lets agents and people read the same workflow, and it builds trust.
2. Save a version with a short reason on every change, and keep old runs for comparison [docs]. Easy to explain to a buyer.
3. A test that is honest about limits: they say model-based checks can also be wrong, so keep the evidence [docs]. A good tone for our own proof.

10. Unknowns

• Whether "self-improvement" on the Startup plan is automatic or a prompt to the coding agent. Look at the dashboard docs or sign up for the free tier.
• Real usage: GitHub shows 0 stars on both repos and the install count is not public. Look at npm and PyPI downloads.
• Funding and the date of the switch from Alpha Research to Method. Look at the founder's X posts.
• Whether any of the 10 team spots in the launch essay were filled. Look at the case studies page for new entries.
• Pages were read through a summarising fetch tool, not word for word. Spot-check the pricing and the claimed Factorio figure on the originals.

Sources

• withmethod.ai [site]
• YC company page [yc]
• Method blog index [blog]
• Method: Agents that improve, 18 Sep 2026 [blog]
• Your AI agent prompt is becoming an incident log, 10 Aug 2026 [blog]
• What did you actually change?, 10 Sep 2026 [blog]
• Turn a prompt into an agent, 9 Sep 2026 [docs]
• Quickstart [docs]
• Case studies [site]
• method-ai-hq on GitHub [docs]
• method-spec [docs]
• method-sdk [docs]
• YC: Dolphin [yc]
• YC: Alpha Research [yc]
• YC launch: Zenobia Pay [press]
• Zenobia Pay launch note (Fondo) [press]
• Founder site [press]