A couple weeks ago I sat in on a private talk from a senior engineering leader at a large tech company. No name, no attribution. Just an hour of genuinely useful thinking about how to use AI well, and what it means for a career if you do. I left with pages of notes that I felt inspired hearing.
The Thesis
AI can produce text that looks like good judgement. it cannot exercise judgement. Your entire career in any knowledge-work field is about acquiring and exercising judgement in a domain. Hand that over to a model and you haven't saved anytime, just disqualified yourself.
The Socratic Loop
He opened with a story about a bad AI-generated report, and traced the failure back to one cause: he'd underspecified what he wanted. This is a normal thing with AI. With simple ideas it's not that much of an issue but for larger decisions, a larger socratic loop has to take place.
Get Interviewed
Tell the AI what you know so far, then explicitly instruct it to interview you and challenge your assumptions until it draws out what you actually need. Let it run for a while. A paragraph of "what I want" turns into three or four pages once the edge cases surface.
Co-design your acceptance criteria
Before asking for the real output, spend another round defining how you'll judge the result. What it should contain, what citations, how you'll know it isn't hallucinated.
Hand it off to a fresh session
Give a new session both documents and ask it to satisfy both. Quality jumps because the model is now working against a real spec instead of a vague ask. You end up with three artifacts instead of one: the requirements, the acceptance criteria, and the output. The first two are reusable, and they're where your judgment actually lives.
Code Is Going to Disappear
He applied the same idea to software specifically, and this was the part I found most useful. His claim was: either code volume per engineer keeps growing 100–1000x, past the point any human can read all of it, or models start producing machine code directly and it stops mattering either way. Either path means your judgment can't live in the code anymore. It has to move into the design process, before anything gets written.
As coding agents developed more and more, I sort of saw this coming. When he said this though it reminded me of what a mentor told me not to long ago, "Read more than anyone in the room, more than those who didn't want to take the time and do the hard part, and you'll be the most competent in the room every time. You'll find that things go your way more than before." It sounds like something obvious, but I think the more you work the more you notice it's a little harder than it sounds. Taking the time to really think about what you're reading.
I was then introduced to a new methodology, Elephants & Goldfish.
Elephant: a long-running session with deep, accumulated context.
Goldfish: a brand-new, zero-context session, used purely to test whether your documentation stands on its own.
The workflow: describe the business requirement and the why to your elephant, let it interview you into a plain-English doc. Hand that doc to a goldfish with no other context and ask it to explain back what you're building. If it hallucinates or drifts, the doc is inefficient, not the goldfish. Fix it, retest. Once that holds, go back to the elephant for the technical conversation. Tech stack, approach, and critically, a section on alternatives considered and why they were ruled out. Skip that section and the AI will "rediscover" the rejected alternative and quietly implement it later.
Then a granular implementation plan, a verification plan, and finally a gauntlet of fresh goldfish sessions each trying to break the doc a different way. Find what's over-engineered, find what's underspecified, decide if it's enough to implement correctly the first time. You keep iterating until the complaints drop to nitpicks.
The payoff is cleaner code and a design-doc layer that captures intent, which compounds: future AI sessions can read just the design docs, which is far fewer tokens than the codebase, and already know where a new feature belongs without reading a line of code (Although I feel coding agents will always double check and read the code anyway, but he is mostly right about this). Onboarding changes shape entirely too: new contributors get a tool pre-loaded with the design docs and are told to learn enough to write a doc that meets the same bar.
The design doc layer is stored in the codebase, slowly converted into a wiki as it grows so agents know where to look. All new features are fresh designs pages long, and when they're done, it gets added as a smaller page to a larger encyclopedia.
What it means for the job itself
A few claims that stuck with me:
The individual-contributor role, as historically defined, is going away. If AI plus a handful of agents makes you meaningfully faster, everyone ends up managing a small number of agents. And managing an agent rhymes with managing a person: you still have to define scope, boundaries, when it should interrupt you, and how you'll judge the output. The point, in both cases, is that you can look away and trust the work gets done.
Don't try to run a hundred agents at once. That's the dumb YouTube/X thing, in his words. Start with two or three and build the muscle of handing off work you don't babysit. You hear a lot about people managing 5 or even 10 agents at once, and thats just BS. Humans are not good at multitasking and never will be.
Protect a few hours a day of genuinely hard, uninterrupted thinking. The kind where it hurts. He framed this as the single most valuable, most at-risk skill in a knowledge-work economy, and I have to agree. I find that in the days where I spend truly dialed in are the most rewarding days for me mentally. These are the moments where I try to read more than anyone in the room.
On the jobs question more broadly, he pointed to Jevons paradox. The ~160-year-old observation that making a resource more efficient to use tends to increase aggregate demand for it, not shrink it. He said that AI-augmented output increases demand for humans with good judgment rather than reducing headcount. The work changes as it always has, but that's not the same as fewer jobs. I feel hearing that from a person in a position of power really does solidify that my career will only grow going forward.
Discover Reality and Align Yourself
He ended by inviting the room to find him afterward and tell him everywhere he was wrong. Not as a politeness, he said he actively likes being wrong, because that's the only way he learns anything. Being right isn't something he optimizes for. The only real goal, in his words, is to discover reality and align yourself to it as fast as possible; everything else like defending a position, needing to have called it correctly, is just ego getting in the way.
It's a fitting note for a talk about AI to end on, because it's the same instinct as the Socratic loop he opened with, just pointed at himself instead of a model: interrogate your own thinking, welcome the challenge, and treat "I was wrong" as progress instead of a loss.
I will be taking these with me forever, and using them across my life. This talk was more than just AI, but a useful talk about how you think about your judgement across all areas. Your judgement is everything. Nurture and protect it. Your life and career is defined off casting judgement not just to yourself but to those your hands will cast over.