Jonathon's AI Wiki

The Production Class Ladder — Governing AI-Built Software (Nate B Jones)

5 min read

Source: raw/Cheap_software_made_your_PM_job_harder_not_easier._Here_s_the_new_job..md (Nate B Jones YouTube, youtube.com/watch?v=b6J387xJvHg)

Nate B Jones lays out a concrete, named framework for the problem AI abundance creates inside companies: when generating software is nearly free, the bottleneck stops being “should we build this?” and becomes “how do we classify the software that already exists?” His answer — the “production class ladder” plus a prototype-commons posture and promotion/demotion governance — is a transferable decision framework for the new PM/ops job. It’s a governance-of-AI-output companion to the runtime/policy tooling in Microsoft’s Agent Governance Toolkit: that toolkit governs what agents do; this framework governs what people build with AI.

Key Takeaways

  • The PM job inverted. AI makes generation cheap, so the bottleneck moves from “should we build this?” to classifying software that already exists into market value / useful internal tooling / delete. PMs shift from “rationing scarce engineering” to “classifying software abundance.” Jones: “There is not much room left for the non-technical PM.”
  • The decision rule: stop asking only “can my team build faster?” Ask “what class of software is this?” — then “should this exist, who’s it for, what standard must it meet, what are we willing to rely on?”
  • A ladder needs a down-staircase. “A ladder that only moves upward becomes a junk drawer.” The new tech debt is dead internal software you keep paying support cost on — “the company will pay support cost on dead software faster than it can name it.”
  • Governance is permission-to-build, not a build-ban — the Microsoft Power Platform model: let employees build while protecting the company via inventory, telemetry, permission review, environment controls, and data policy.
  • Faster creation multiplies leak surface — which is why “what data does it touch / who owns it” becomes a product question, backed by the GitGuardian secret-sprawl numbers below.

The production class ladder (4 rungs)

Each rung carries explicit requirements — the ladder is the classification scheme a PM applies to any AI-built tool:

  1. Personal tool — one user, scrappy. Keep it away from sensitive data.
  2. Team beta — a small group depends on it. Needs an owner + backup owner, a short description, a list of systems it touches, and a failure plan.
  3. Supported internal product — the company depends on it. Needs product ownership, platform partnership, access management, monitoring, docs, auditability, and a change process.
  4. Customer-facing product/feature — usual product standards plus AI-specific evals and governance.

Promotion and demotion. PMs now decide what gets promoted out of the prototype commons and what gets intentionally demoted or left as personal software. The down-staircase is the part most orgs skip — and skipping it is what turns the ladder into a junk drawer of unsupported tools.

The prototype commons + “open discovery”

  • The prototype commons is the informal space where tools appear before classification.
  • The recommended posture is open discovery, not gatekeeping: “Show us what you made. What problem does it solve? Who uses it? What data does it touch? What did you learn?” — rather than “the PM is the only prototyper.” Jones: “everybody’s job is to prototype.”

The data spine

  • Microsoft Power Platform internal scale (the proof case): >1M Power Platform assets built inside Microsoft — >18,000 agent environments, 170,000 Power Apps, 50,000 Power Automate flows, 1,200 chatbots — governed by inventory, telemetry, permission review, environment controls, and data policy. Framed as “let employees build while protecting the company,” not a build-ban.
  • GitGuardian 2026 State of Secret Sprawl: AI-service secrets exposed on public GitHub hit 1.2M in 2025, up 81% YoY — used to argue that faster creation multiplies the leak surface, making “what data does it touch / what does it write to / who owns it” a product question, not just an engineering one. ^[inferred — Jones predicts another 80-100% rise this year; that’s his bet, not data]

Try It

  1. Adopt the 4-rung ladder as your classification scheme. For every AI-built tool in your org, assign a rung and attach that rung’s requirements (owner, systems-touched list, failure plan, monitoring, evals as applicable).
  2. Build the down-staircase first. Schedule a recurring demotion review — what gets left as personal software, what gets deleted — before your prototype commons becomes a junk drawer of unsupported tools.
  3. Run open-discovery intake, not gatekeeping: the four questions (problem / users / data touched / lessons) are the cheapest governance you can apply at the prototype-commons stage.
  4. Pair it with runtime governance. Where a tool graduates to rung 3-4, layer in policy/identity/audit enforcement — see Microsoft Agent Governance Toolkit.

Open Questions

  • Jones’s “another 80-100% rise” in secret sprawl is a prediction, not data — track GitGuardian’s next report.
  • The framework is a single-creator synthesis (well-grounded in cited Microsoft/GitGuardian numbers) — no independent org has published results applying the exact 4-rung ladder yet.

Graph View

Backlinks