# AI agents make small companies bigger 5/10/26 My brother recently visited me in San Francisco. He and his friends – first-year medical students – were [invited](https://www.acponline.org/) to speak about a study they'd conducted. They'd gone deep on AI use in med school, the absence of clear standards, and the anxiety the combination produces. I was just happy to host them: I’d recently moved to SF for my next role. ![[bcm-in-sf.png|Baylor College of Medicine takes Mission Bay.|700]] Having _just_ wrapped my time at [[Ramp]] – known for cutting-edge AI eng via [[Ramp#^9f3029|Inspect]], [Labs](https://labs.ramp.com/), etc – I didn't think too hard about their premise. Sure, it made sense. Medicine lags on technology, and is still "figuring out" what to do with the latest. Software, on the other hand, has found its *groove*, and is chugging forward. Tokenmaxxing and the like. That's certainly how it felt at Ramp. Claude Code at home has also been fun: it’s fun helping my closest non-technical friends ship their most ambitious ideas. And in these cases – as solo, friend-fractional-CTO – I can really just rip, rip, rip, and if it works, it works! Importantly: no *social*, *organizational* dimension to my code. ![[Pasted image 20260510152858.png|]] **It's different at a new job!** I took for _granted_ how deftly I could surf the tide with these tools at Ramp. I started there several years before any of these tools hit the market. I'd either written so many of the primitives by hand; or I spent time in incidents, projects, manually, _slowly_ tracing through them. So an assistant that could take my crisp, informed intent – and produce the exact output I was looking for – felt like magic. And it is! At a new job – especially one at an early-stage company where foundations are still being laid – there are all sorts of challenges that come into sharper relief. I'm envious that my brother and his peers in medicine get to think more formally about it. ## AI-forward cos are "big cos" on day one Alice is a micro-manager, Bob is a slop cannon, and I'm the perfect middleground. Or so the confident among us would say. Personally, I go from feeling like I'm gripping the steering wheel of a self-driving Tesla too tightly; to feeling like I'm doing "no hands" in a Prius. %% ![[steve-and-krish.png|]] %% 1. There aren't strong idioms or standards re: workflow. You think I'm a slop cannon; I think you're a micro-manager. We both produce results, so it's not easy to figure out who's right. 2. You know my stuff was co-written with an agent; I know yours was. Which parts, neither of us do. How much of the overarching design? Who even remembers. This is inherently "low-trust" in the narrow scope of the software development lifecycle (everyone *gets along* great and is having fun, of course). But we're all intern managers now, tasked with the combination of: * Getting results from our respective teams * Defending these teams when they've earned our defense * Absorbing the blame for these teams when they screw up Management is more unpleasant when you're not defending humans, and when the blame you're absorbing is not on *behalf* of humans. Leadership is more fun. You have a vision, and you're comfortable going angry-Steve-Jobs on your team until they produce the Apple iMac. The Apple iMac shows up, and it's all worth it. But *management* – which is a distinct discipline, overlooked at your own peril – is no fun when you take out the *people*. ![[angry-steve.png|]] Just as [[AI code is legacy code from day one]]: AI-forward companies are “big companies" from day one. Lots of defense to play, lots of blame to absorb. Lots of triage, orchestration, tradeoffs, prioritization. You now become a big tech engineering manager the moment your engineering org scales from one person to two. ## Founding interns You manage a team of interns (or staff engineers, whatever you believe). If you're working in a codebase that has only ever existed post-Claude Code (etc): there is a risk that these agents have more tenure than you. They wrote a lot of this code – more than you – and you're expected to measure its quality against outcomes & tests rather than by the letter. You're also expected – with a team as powerful & well-staffed as the one you have - to move everything along faster. Even if not explicitly: everyone *else* is moving that fast, so you have to keep up. The agents are (really, *[[AI code is legacy code from day one#^b32d89|were]]*) the SMEs, and you're continuously using them as a resource to *catch up*. You simultaneously want to *design* independently of them – having them be executors of your design – but also *consult* with them given that they know the machinery or can internalize it very quickly. There's conflict between those things: is mere *exposure* to Claude's initial opinion — while consulting with it — enough to hijack your design? Do you even remember what you wanted before Claude told you? How much of it? ![[dario-and-krish.png|]] And how much do you really *trust* that consultation? If you give it high-level context re: the business problem, do you risk being filled with "empty calories” re: a satisfactory solution? Are you filled enough to prevent you from thinking more deeply about the problem - but not enough to durably *solve* the problem the way *you* would have? And if you limit it to only the factual sub-components of the problem, do you prevent it from giving you the best – right – advice? Neither of these options play out *great,* though the job does get *done* on the other end of a lot of conversation (and some cursing: `npx devrage`). [Maybe](https://x.com/krrishd/status/1952882914636775905?s=46) faster? Certainly in a way that is irresistible. I never had to handhold staff engineers like this: so I tend to think I’m still an intern manager with Claude. Today’s interns (especially “founding” interns) are tech leads tomorrow — [[Ramp#^adb135|seriously]] — so I don’t say this to sound like a downer about it. These tools get better so fast. But it adds new work (that you may or may not realize you need to do). ## I actually want to raise the speed limit As a kid two decades ago, I moved with my family from the US to India (before we moved back three years later). I remember being horrified, even just as a passenger, at how it looks when rules of the road are treated as suggestions to disregard, when it comes to driving. The irony I'd discover later as an adult: average road speed + limits in India are dramatically *lower* than they are in the US. How are Indian roads both slower but also scarier? They're slower *because* they're scarier. I think this captures the current-day situation exactly. ![[waymo-in-india 1.png|]] The rules and regulations around driving – and their meaningful *enforcement* – make the American road a much *higher-trust* environment. And it turns out that in such an environment - you can actually *go faster,* and are in many ways *freer* on the road! The lack of enforcement in India, comparatively (not educated enough to explain "why"), means it's every man for himself. And when it's every man for himself: you're just not going to practically go faster on the road. You can't take for granted a red or green light, you can't take for granted that people stay in their lanes, you can't even take for granted the direction of the road. Indian drivers tend to be *higher* in their dexterity & capability as drivers – but far more limited and conservative at a zoomed out level, because they have to internalize the risk management. We will need frameworks if we want to go faster. This is not to say we need frameworks to curb the speed we go at: we need frameworks for everyone to have the *psychological comfort* to go as fast as they're *actually* capable of – if they weren't in an uncoordinated molasses. I'll make some more formal proposals. **Make everyone on the road legible to everyone else.** It's important to have clarity on how _everyone_ else is driving. Whatever the default workflow is: it ought to converge on the *same* one for most people. Tobi Lütke's [*Learning on the Shop floor*](https://x.com/tobi/status/2053121182044451016?s=46) – from Shopify – also describes what I think was *Ramp Inspect's* most underrated innovation: everything happening in public (visibly), and the best workflow at the company constantly being reified as everyone else's. Being too *strict* about this would also be wrong – you want the tinkerers to experiment and push the edge – but the lazy "default," at least, should be uniform. This is really a "theory of mind" problem, where everyone's theory of mind re: everyone else on the road needs to be extremely crisp, for fast cars to work. (If everyone was "quirky" on the road – you'd be in India). **Clearer delineation of human responsibility.** I miss having a clear compass on which parts of the problem should be fleshed out – fully committed to – before an agent has any say at all. Even if I write my specs by hand, an agent *eventually* enters the loop, and can quite persuasively (knowledgeable as it is) convince me in a certain direction on technical design, or even implicitly decide on and implement with it. I think everyone would feel a stronger grip if it were clearer what *specific* acts – rituals, even, I'll call them – were *always* going to be a component of their work (until the protocol is updated relative to new models, of course). It's choose-your-own-adventure right now: and no answer is truly *obvious* as the correct one. I think it would help to simply *pick* one, and iterate on it. Waymos are nice because you're expected not to touch the wheel at all; Priuses are nice because you're expected to keep your hands on the wheel at all time. The in-between sketches me out. **Acknowledge the fuzziness, at a leadership level.** I think the previous section – "clear delineation of human responsibility" – would annoy *so many* leaders; for different and potentially opposed reasons! Some reject the premise: your job is to automate your job! You're on _notice_ if you're not on top of this. Our *company* will be on notice in the *market* if *we* aren't! Others think the answer is so obvious it's scary you're even asking: you should *know* what you're responsible for in this broad workflow, and if you don't, you're putting us all at risk! Everyone *else* keeps their opinions to themselves, and/or in narrow circles of trust, and does what they were always going to do. Not the best place for things to land. ## A Big Little Idea Called Legibility A hero of mine – blogger Venkatesh Rao – wrote the now-seminal [*A Big Little Idea Called Legibility*](https://ribbonfarm.com/2010/07/26/a-big-little-idea-called-legibility/). All the good stuff lives in the *illegible*, *outside* of micro-management, *outside* of overly-controlling governance. What you *really* want to do in engineering management, is hire people for whom this stuff is no longer necessary. I hope I'm not letting him down, pushing so hard for the big bad *legibility*. But he's also a [protocols](https://protocolized.summerofprotocols.com/) guy! ![[let-vgr-down.png|I wish someone would convince him to re-download Twitter.|400]] I rescind my characterization of these agents as interns – sorry agents! – and call them really fast *cars* instead. Hell, they're Ferraris. And it really sucks driving a powerful, beautiful, car in a place where you don't know how the drivers operate, you don't know how little or how much you're expected to do. They're large, killer hunks of metal that *could* safely(!) careen through space at 100+ miles-per-hour: only if you solve "how not to kill a lot of people in the process" or even just "how not to *feel* like you might." You need a real, serious _protocol_. Give me, the human, bundle of divine illegibility – a modicum of control over the fast car, and just enough *mutual* rules with everyone else – so I can buy a car that fits my quirky personality, go faster on the rightmost lane or slower in the leftmost one of the highway, and we all feel good about it. ![[krish-in-waymo.png|]] I don't mean to sound like a Luddite. I want to use my Ferrari. I'm actually quite optimistic that the answers will emerge, tooling will form, and we'll be just fine! We're solving for this stuff at my new role: both in terms of our working style *and* at a product level. After all, we build payment rails for agents to inspire trust – and therefore velocity! – re: the [virtual heavy machinery](https://www.natural.co/blog/why-krish-joined-natural#:~:text=virtual%20heavy%20machinery) that is money itself. The point is – at an industrial-scale – this actually gets "harder" in subtler ways before it ends up becoming truly, reliably, easier. And it's tricky to *admit* that anything got harder; but admitting is the first step. *Special gratitude to my engineering colleagues at [Natural](https://natural.co) and at [Ramp](https://ramp.com) for the long conversations whose breadcrumbs have landed in this piece.* %% There is an [[Time & space arbitrages#^d7fd0b|arbitrage]] in being religious about writing your own tech specs, for example, to the furthest extent. *Ensuring* that your inexperienced interns are not simultaneously *tenured* with the work product, over you. You don't want them to explain *their* code to you; you want them to write *your* code. The slop cannons would tell me "for now," and they very well may be right. %%