RFCs in the Era of LLMs: Takeaways for Leaders
In RFCs in the Era of LLMs I argued that agents flipped the RFC’s job. The document is no longer where thinking happens and the collaborative review is how a team keeps understanding the system it owns. One consequence lands on leaders. The old pitch - “we slow down to think” - is dead. With a v1-to-v4 loop measured in hours, the process no longer costs speed. It costs focus, and it buys shipping non-random things. Running it well is now the job.
Make someone choose. This is a classic tech-debt decision, made once, at company scale: do we move fast and take on the debt, or do we slow down where it matters and keep the future interest low? In practice it sounds like: are we building something that lasts, or a proof of concept to raise the next round? I asked a founder exactly that, in writing, and I meant it - both answers are legitimate, and only one of them needs RFCs. If the honest answer is the proof of concept, skip the process and ship the swamp; that’s a rational trade. But it has to be chosen, not drifted into. The same choice repeats at a smaller scale every week: if your stack already persists agent plans into the repo (we use superpowers), someone has to call what graduates from plan to RFC - and the bar is the same one: strategic, hard to reverse decisions (i.e. not two-way doors).
Read the drafts yourself. Reviewer attention is the scarcest resource in the process, and the leader is its buffer. My rule with direct reports: send me the ugly version early. I’d rather spend ten minutes on a half-formed draft and tell you whether the direction is right than receive a polished document that is confidently wrong. I can metabolize good slop; five reviewers shouldn’t have to. I’ve had both kinds of managers - one with a high bar who wouldn’t read anything unfinished, and one who read every draft I sent him. I learned more from the second one :) The agent era settles the argument, because polish used to be evidence of effort, so a “no-drafts” bar used to be a good filter. Now the model does polish for free. The only thing left to check early is the direction.
Publish your standing constraints. Some decisions should not be re-arguable by any generated text. Write them down where the team writes RFCs: the constraint, your name, the reason, and the condition under which you’d revisit it. Ours reads, roughly: three clouds plus our own Mac hardware is already the complexity budget; adding a fourth cloud needs a migration that migrates legacy first. A model can out-argue any engineer in the room. It cannot out-argue a published veto. Your team stops burning review cycles on debates you’ve already settled.
Hold the comprehension line. The hardest new question: what do you do when the agent’s design is genuinely better than anything your team currently understands? My rule, for now: the team’s ability to re-explain the architecture is the complexity budget. Not every line - nobody holds every line anymore - the architecture. I’d rather run a team that spends somewhat more time and actually understands its own system than a faster team operating something it has to ask the model about. Human-understandable forces simple and elegant - which, conveniently, is also what survives.
Extract the strategy yourself. Will Larson’s observation predates all of this and survives it: once your team has a handful of RFCs, read them side by side - the constraints and choices they share is your engineering strategy. Agents changed who writes the documents. They didn’t change whose job the synthesis is. That one is yours.