AI coding agents, tools that write code on their own, made software cheap to build. Cheap code does not guarantee a product that people keep paying for. A 2026 study of 718 firms found agents raised pull requests, the code changes engineers propose, by 23 percent. Resolved tickets showed no significant gain.
That gap sits under three questions people now tie together. What does "AI archetype" mean? What does planning first buy a team? And what does product-market fit, meaning customers who stay and pay, look like now?
This article draws on material published between August and October 2026. I mark older sources as background, and any source that sells what it measures gets a label.
Subscribe to the newsletter for analysis on AI and engineering.
What does "AI archetype" mean?
Search the phrase and most results describe how companies approach AI or which roles people play. Harvard Business Review sorts companies into four strategy types in a July 2025 piece. OfferZen sorts engineers into five types. Microsoft Learn sorts agent designs, and its own page says it introduces no new concepts.
A smaller group uses the word for types of AI product. That is the sense this article uses.
The clearest version comes from Oxx, a venture firm, in an August 2026 essay. It names six product types and gives each its own test of quality.
| Type | Companies Oxx names | What to measure |
|---|---|---|
| Grid | OpenAI, Anthropic, CoreWeave | How much of the volume they bought each sign-up group uses |
| Watchtower | Dataminr, Chainalysis | Coverage, and how many alerts are real |
| Shield | Darktrace, Vanta | Incidents caught, and how many alerts are real |
| Concierge | Sierra, Decagon, Intercom Fin | Issues resolved without a human, against a pre-AI baseline |
| Intelligence Layer | Glean, AlphaSense, Hebbia | Answer accuracy against known-correct answers |
| Output Engine | Cursor, Harvey, Cognition | How often a human must step in, against a pre-AI baseline |
Oxx argues that "adoption tells you nothing about whether the answers are any good." Oxx is an investor, and no independent dataset compares these types. Treat the table as a way to think, not a measured result.
Strip the labels and three questions do the work. Who owns the result, you or the customer's professional? How deeply does the product sit inside the customer's work? What does one finished outcome cost you?
The table below is my synthesis of those questions, not a published framework.
| Type | You sell | Fit shows up as | Failure to watch for |
|---|---|---|---|
| Assistant | Time saved for one person | Repeat use that survives the novelty | A spike that fades, and low switching cost |
| Agent | A finished outcome | Cost per outcome falls while completion rises | Errors that compound across steps |
| Embedded workflow | Work replaced inside a customer's system | Customer return measured against the cost of the work | Integration breaks on legacy systems |
| Thin wrapper | Access to someone else's model | Retention and margin at real usage | The platform owner ships the same feature |
What does plan-first development look like in 2026?
AWS defined AIDLC, its AI-Driven Development Life Cycle, in July 2025. The AI drafts a plan and asks questions, and a human approves it before the AI writes any code. The AIDLC hub covers the full definition.
The name now covers three things. They are the 2025 method, a set of written rules for AI tools, and a program teams run from the terminal. AWS's roadmap, dated 11 September 2026, says that program is out of preview.
The program's latest release changes the old picture of a human approving every stage. Version 2.11.0, published on 8 October 2026, ships two lighter presets with approval of the code plan switched off. They are express and poc. Only a person, not the AI, can switch approval off.
Proposals inside the project say the same thing. One describes "real human fatigue at the gates" on a full run. Another says fixing a one-line bug takes 12 replies, a figure counted from the written protocol, not measured.
The tools around AIDLC moved the same way. Kiro, AWS's coding tool, added a quick plan mode in May 2026 because its step-by-step flow "can feel like more process than the problem requires". Kiro and GitHub Copilot then launched workflows that chain several AI agents into one run.
Few teams have adopted any of this. A spec is the written description of what to build. An August 2026 census of public GitHub found spec files in about 73,000 repositories, plus about 12,900 that use Kiro's layout. Stack Overflow's 2026 survey found 27.8 percent of respondents use AI for tickets, requirements, plans or updates.
For how the phases shift, read AIDLC vs SDLC. For the spec format itself, read how to write specs for AI agents.
Does planning first make AI-built software better?
As of 10 October 2026, I found no published study that compares spec-first work with prototype-first or improvised work on shipped outcomes.
Benchmarks, which are standard tests for AI tools, give partial answers. Across 21,120 agent runs, a standard plan improved issue resolution, but "a subpar plan hurts performance even more than no plan at all". Across 176 matched setups, planning helped weaker models get answers right and mainly cut cost for stronger ones. A study of 114 repositories linked better specs to fewer bug-fix commits. In the top third of repositories by spec quality, 11.8 percent of code changes were bug fixes, against 20.4 percent in the bottom third. That shows correlation, not cause.
Independent data from real companies points somewhere else. A Harvard working paper on 718 firms found agents raised pull requests by 23 percent and average review time by 49 percent. Resolved tickets showed no clear gain, and the data rules out a rise above 12 percent. Ars Technica covered the paper on 9 October.
JetBrains researchers reach the same place through interviews. They write that "the bottleneck is no longer code generation; it's review." Real-SWE, a vendor's benchmark, reports that missed requirements are the most common way agents fail on private company code. That does not show formal specs fix the problem. For the review side, see the agentic code review verification loop.
AWS's speedups lack a published method. The 2025 AIDLC post renames sprints, the usual short work cycles, as "bolts" measured in hours or days, and gives no data for that shift. The "10 to 15 times" figure appears only in secondary articles. Amazon CEO Andy Jassy's April 2026 shareholder letter credited a six-engineer, 76-day build to Kiro and did not mention AIDLC.
What does product-market fit mean now?
Product-market fit means a market that pulls your product out of you. Marc Andreessen wrote in 2007 that it is "being in a good market with a product that can satisfy that market." Sean Ellis's test asks users how they would feel if the product vanished. Rahul Vohra used it at Superhuman and set the bar at 40 percent of users answering "very disappointed."
Investors rewrote the test for AI in 2026. CRV's August version says a defined customer keeps using the product for real work after the novelty fades, and pays from an operating budget. It adds four checks.
- Retention flattens after month three.
- Outputs ship without heavy edits.
- Renewal comes from an operating budget, not an experiment fund.
- Margin holds at current usage.
CRV is an investor. The popular claim that fit must be re-earned every quarter is a claim, and I found no study that measures how fast fit decays.
Revenue headlines make the test harder to apply, because "annualized revenue" is a method, not a fact. On 8 October 2026, CNBC reported that OpenAI told investors about $50 billion annualized at the end of September. A larger figure had circulated, and CNBC's source said it included gross revenue from OpenAI's partners.
Cognition says it has passed a $1 billion run rate. Lovable says it passed $600 million on 24 September. Both are company-reported run rates, meaning recent revenue projected over a year. Neither company disclosed retention.
User counts mislead in the same way. Menlo's September survey says 55 percent of AI users pay. a16z's October panel puts paid subscriptions to ChatGPT, Gemini or Claude at 4.5 percent of US consumers as of August. The two numbers measure different things. Menlo asks users about any AI product, and its payers include people whose plan a relative, friend or employer covers. a16z counts card receipts for three named products.
Free offers inflate usage too. Perplexity's seven-month free offer in India drew 56 million downloads. Monthly users peaked at 22 million and fell to 14 million by July 2026, according to Sensor Tower data reported by TechCrunch.
Retention data is thin. Gross revenue retention is the share of last year's revenue you keep, ignoring upsell. ChartMogul's December 2025 analysis of 3,500 software companies put the median for AI-native products, meaning products built around AI, at 40 percent. It was 23 percent below 50 dollars a month and 70 percent above 250 dollars. ChartMogul sells analytics and calls the report directional.
Two failure modes showed up in the news this autumn. A supplier can end access. DevOps.com reports that OpenAI will end Cursor's direct model access on 12 November, after SpaceX bought Cursor. Costs also bite. ICONIQ's 2026 State of AI report projects AI companies will keep 53 percent of revenue after delivery costs, up from 45 percent in 2025.
How do archetype, plan and fit connect?
The archetype decides what your plan contains. Software with a known right answer takes a written spec. A product with open-ended output takes an eval set, a list of test cases with known good answers. Anthropic advises starting with 20 to 50 tasks drawn from real failures.
The archetype also decides the proof of fit. An assistant earns fit through repeat use after the novelty fades. An agent earns it through cost per finished outcome. A thin wrapper earns it through retention and margin that survive its supplier.
Practitioners converge on a middle path. Anthropic's Claude Code team says it built dozens of working prototypes before shipping a feature, and that prototypes replaced product requirement documents. Every voice quoted in this debate sells tools, training or advice, so weigh them as claims.
Marty Cagan of SVPG quotes Hilary Gridley that building fast makes it easy to "run 10 times faster in the wrong direction." Engineers inside the labs say the bottleneck is review. Independent data supports review and measures nothing about discovery.
What should you do with this?
- Name your type. Ask who owns the result and how deeply the product sits in the customer's work.
- Prototype to choose a direction, then throw the prototype away.
- Write a one-page contract before agents build anything durable. Cover the user, the goal, the ways it can fail, and 20 to 50 test cases from real failures.
- Scale the ceremony to the risk. Skip the plan for a change you can describe in one sentence, as Claude Code's own docs advise.
- Judge fit by the share of each sign-up group still paying after month three.
- Also track the share of revenue from regular budgets, your margin on the heaviest user, and first-session success.
- Label every revenue number company-reported, and say what it counts.
The product manager role post covers who writes the contract, and the vibe coding platforms post covers the prototype side.
What is still unknown?
- No published outcome study compares spec-first, prototype-first and improvised work on real teams. AIDLC's own evaluator has no comparison run with an agent that follows no method.
- No source links eval scores to retention or revenue. One vendor, Amplitude, reports that for established users they are "basically orthogonal."
- No study measures how quickly product-market fit decays.
- No independent series of retention or margin exists by AI product type.
- No independent median exists for time to $10 million or $100 million in revenue. Every figure at that scale is a company announcement.
The debate has moved from whether to plan to how much ceremony each task earns. AWS now lets teams switch off its own gates.
The product question, whether anyone will pay and stay, sits where it always sat. No published study has shown that planning first or prototyping first answers it faster.