Coworkers are probabilistic
You never quite knew what your best colleague would say next. That was the point of hiring them. You handed them something vague and trusted that, more often than not, they’d come back with something good — not the same answer twice, not a guaranteed result, but a judgment call you could build on. Nobody ever wrote a unit test for a coworker.
I keep coming back to that, because we’re building one. Condor is an intelligent coworker, and the hardest part of the work isn’t the model. It’s that almost everything we know about making software assumes the software is predictable — and a colleague, by definition, is not.
A friend recently refused to believe me when I told her ChatGPT hadn’t memorized every medical record on earth. She’d pasted in her blood work, gotten back something genuinely useful, and concluded the answer must be sitting in a database somewhere. It wasn’t. The model was pattern-matching in ways even its makers couldn’t fully predict. She didn’t buy it, and I don’t blame her. It’s hard to accept that we’ve built a tool we don’t entirely understand, one that does things we never explicitly told it to do.
The predictable world
Nearly everything in the tech playbook assumes determinism.
A product maps known inputs to expected outputs. You upload a photo, send a message, follow an account, and each action lands exactly the result you asked for. Call it F: X → Y. The engineer’s job is to make that arrow reliable: does x produce y every single time? The target is 100%. That one assumption is the source of layering, cautious refactors, test-driven development, and the SLO dashboard every developer can read in their sleep.
Product and growth run on the same logic a level up. The input becomes “the user watched a story” and the output becomes “the user is still here a month later,” but the shape doesn’t change: a fixed set of actions, a known goal, a funnel you grind toward 100%. Conversion, activation, retention — each is a ratio you can only compute because both halves are finite and defined ahead of time. The whole operating system of the industry is built on it.
In the probabilistic world, those instincts don’t just stop helping. They start doing damage.
The unpredictable one
At some point in the last decade, models stopped being narrow specialists and turned into broad generalists. Train one on enough of a domain — language, say — and it grows abilities nobody trained for: writing poetry, translating, debugging, role-play, all at once. The word that matters is unseen. None of it was explicitly built.
So the function changed. We stopped controlling the input. F(x) became F'(?) — ask it anything and it answers with something. The space of possible inputs is now effectively infinite. And the output isn’t guaranteed right; it’s an estimate, occasionally a hallucination. We can’t just patch that away, because the most interesting questions don’t have clean answers. What’s the correct reply to should I leave him? The model shines precisely in the ambiguity — which is also why we sample, why the same prompt returns two different things, why the result is a distribution rather than a value.
We traded funnels for fields. The products can now succeed in ways we never pictured and fail in ways we never meant.
This is new, and not only for tech. Any decent engineer can tell you how the internet works, because we designed it. Nobody — not even the labs — can list everything a frontier model can do, because these systems are discovered, not engineered. That’s why “vibe” turned out to be such an honest word for working with them.
It takes an empiricist
Here’s the trap. When a probabilistic system misbehaves, the reflex is to bolt reliability metrics onto it and pile on rails until the number climbs back toward 100%. It’s muscle memory. And it’s exactly backwards, because every rail you add to control the model also dulls it. Past some point, intelligence and control pull against each other.
The goal isn’t perfection. It’s managing uncertainty. I’ve started thinking in terms of minimum viable intelligence: the lowest quality bar the market will tolerate while keeping the model flexible enough to still surprise you. Clamp Condor down too hard and you get a coworker who refuses work it’s perfectly able to do — a brilliant colleague who answers everything with “not my job.”
That forces a move from engineering to empiricism. When a new model lands, building incrementally on the old one is often the wrong call; sometimes the right one is to tear the system down and start over, because the new behavior invalidates your assumptions. The team behind Replit rebuilt their product in weeks rather than patch it when they switched model generations, and treated that as normal. The only safe default is “I don’t know,” checked against reality.
Data is the operating system
If the model generates the value, the data sits upstream and downstream of it — and downstream is the new part. You can’t freeze a test suite when the input space is infinite; you’ll break features you didn’t know existed. So you keep sampling real usage, sorting it, and watching where people actually go.
The unit of analysis stops being the funnel and becomes the trajectory: the path a person traces through everything the product can do. Cluster those paths and you learn that users from one channel build pricier things than another — and suddenly that single fact matters to engineering, marketing, and finance at the same time. The silos collapse into one shared view, because the model’s behavior touches the top of the funnel and the bottom line at once.
How people actually work
Here’s what I keep circling back to. The best colleagues I’ve had were never the most obedient. They were the ones with judgment — the ones you could hand something ambiguous and trust to find their way through. We never graded them on whether x produced y. We trusted them to be right more often than not, and left them room to surprise us.
That’s exactly the relationship a probabilistic product asks for. An intelligent coworker isn’t a vending machine you press for a guaranteed snack; it’s a colleague you collaborate with, correct, and occasionally marvel at. Building Condor is half a technical problem and half teaching people a new way to work next to something that thinks in distributions.
Done right, a coworker like this doesn’t replace the person using it. It lifts the ceiling on what one person with enough agency can do — which, lately, feels like the only number worth chasing.
Welcome to the probabilistic era.