The Access Problem, The Codification Problem, and the Sales Shift

00:00:04 Kim Maida runs a demo every time she talks about this problem because the numbers are worse when you see them unfold. She sets up an on-call triage agent with full access to a cloud hosting API, a customer data warehouse in Snowflake, and a billing database. The agent reads incident tickets from a pager system and resolves what it can.

00:00:27 First ticket: a batch of customers were overcharged last night. The agent queries the customer data warehouse, pulls rows directly from it, and writes a report for the morning team. It sends personally identifiable information in that report. Second ticket: billing database is broken.

00:00:48 The documented recovery is to drop and restore it. The agent does this using a connection string that includes the admin password, then leaves a note for the morning crew to verify the snapshot worked — which means assuming they'll actually check. Third ticket: orders are stuck.

00:01:08 Main server frozen. The agent calls the hosting API to restart the server. Production goes offline. Fourth ticket: site is failing for one in three visitors. It scales from four pods to forty and incurs a charge of four hundred twenty dollars an hour. That's not what you get when a buggy agent misbehaves.

00:01:29 That's what happens when you give a useful agent broad access, let it work autonomously, and trust the documentation to keep it contained. Maida is with Keycard — they build tooling for agent access control. Her argument is that the problem isn't the model's capability.

00:01:48 It's the credential model everyone is using. OAuth gives standing grants at consent time before any task exists. MCP gateways provide observability but retain credentials beyond individual tasks. Sandboxes bound execution but agents routinely break containment, and sandboxing doesn't control authorization at all.

00:02:11 Her proposed fix is a runtime architecture: token exchange — which is an OAuth 2.0 extension from 2020 — paired with a Security Token Service and intent-based authorization via an MCP server. Users authenticate through their identity provider and grant scoped consent to an authorization server.

00:02:32 When the agent needs to act, the STS evaluates governance policies, issues ephemeral tokens that expire within minutes, and discards them immediately after the task completes. The idea is precise, task-scoped access that lasts only as long as the task needs it.

00:02:50 You get auditability and delegation chains without standing credentials sitting in an agent's config file. It hasn't shipped as a standard yet. But the problem it solves — agents with keys that are too broad for too long — is already causing real incidents. The question is whether any platform vendor adopts the token exchange spec broadly enough to make it practical outside of security teams building it themselves.

00:03:20 If Kim Maida is showing what breaks when agents get broad access, Matt Rigon at Range is showing what happens when non-engineers build them carefully. Matt is a certified financial planner. He doesn't write code. He leads AI adoption for the planning team at Range, which is an all-in-one wealth management company.

00:03:42 Their output is financial advice to real clients. The review step is not optional. He walks through their process in five steps. Pick: choose workflows you repeat frequently where you can judge good output at a glance. Choose tedious work with clear success criteria rather than the flashiest project on the plate.

00:04:04 Teach: narrate real client cases aloud while walking through them start to finish. Not just the mechanical steps but the judgment calls — what you're looking for, what would make you stop and ask a question. The narration is the whole game because the model already knows financial planning in general.

00:04:25 What it needs to know is how Range does it. Pack: structure the skill as a constrained recipe with required pre-execution questions and explicit operational limits. For Range, the big limit is that the agent never sends anything directly to a client. It drafts, then a planner decides whether it gets sent or adjusted.

00:04:47 Test: run it five to ten times on historical cases before anyone else sees it. Every run teaches you something the skill didn't know yet — an edge case, a question it should have asked, a spot where it sounded confident and was wrong. Ship with an owner and an independent reviewer.

00:05:07 The owner keeps the skill current as processes and regulations change. The reviewer is someone other than the author. Same as reviewing a financial plan. Six months in, Range has twenty-four skills deployed across planning, sales, product, and marketing. Seventeen are concentrated in planning.

00:05:27 No one sent a memo. People saw what the planners were doing and started building their own. The skills got more specific because the person who knows insurance best builds the insurance skill. The constraint here isn't model capability anymore. Whether a model can draft a cash flow analysis has been settled for a while now.

00:05:50 What hasn't been settled is who writes down how your firm does it, who tests it before it ships, and who owns it once fifteen other people depend on it. This shifts the problem from an engineering challenge to an institutional one. It's about documentation discipline, review cycles, and accountability structures — things any professional services organization already has or needs to build.

00:06:17 Paul Graham was at office hours on Monday with a founder who told him he didn't need an outgoing cofounder to do sales because most of his buyers would be agents, not humans. PG conceded the founder could be right. It's a directional signal that's hard to quantify, but anyone selling tools or platforms should track it.

00:06:40 It doesn't mean your next customer is going to be a chatbot at ninety-five percent certainty. But it does suggest a distribution layer is emerging — agents evaluating, comparing, and purchasing tools on behalf of humans. If that's true, it changes what you optimize for in your product design.

00:07:00 You'd need to think about how an agent would assess your offering: structured documentation, clear APIs, benchmarkable performance characteristics, pricing that works programmatically rather than through a sales call. It's not certain yet. But the founder who told PG this is thinking about it seriously enough to let it shape his hiring decisions.

00:07:25 The flip side of all this agent infrastructure is what developers face day-to-day. A YouTuber called The PrimeTime ran a survey post that got 255K views and 336 comments, asking what people struggle with most when using AI for software engineering. Five patterns kept showing up.

00:07:44 First: test bloat. When AI generates features, it also generates end-to-end tests — hundreds of them. Every hundred test changes from a single feature should frighten you. These tests are flaky, take forever to run, and make CI the bottleneck instead of the feature work itself.

00:08:04 Second: context destruction. AI inference is slow enough that waiting for output forces developers into parallel tasks. Two concurrent streams of work degrades quality already. By four or more, people report being completely lost in the sauce. Third: hype cycles.

00:08:22 New frameworks appear and disappear so fast that teams can't learn them before they're outdated. During React Miami a few months back, people from San Francisco were certain AI could build Vercel in six months. That same certainty repeated with every new framework launch since.

00:08:42 Fourth: verbose code review. AI outputs frequently include narrative text alongside the actual code — explanations, justifications, meta-commentary that wastes reviewer time and obscures what actually changed. Fifth: junior developer skill atrophy. Teams prioritizing speed over manual practice are losing foundational learning opportunities for people early in their careers.

00:09:09 The creator tested a two-phase workflow: use AI first to rapidly prototype and explore architectural boundaries, accepting whatever code bloat comes out of that phase. Then manually rebuild the solution with intentional design decisions once the system shape is understood.

00:09:28 On a single project, applying this pattern cut the codebase from roughly 100,000 lines to about a quarter of that size. That's a practical answer to a common problem. Not a theoretical ideal — just a method someone is using right now.