AI Collapses Good vs Cheap Hiring
When it comes to building a software engineering team, it seems like there are generally two strategies: pay top dollar for "the best" talent or look down the market for roles tailored to a narrower scope. These strategies aren't a simple tradeoff between "good" and "cheap". Instead, they are built around different assumptions of the ambiguity the role handles. And in the world of AI agents, these two strategies collapse into one.
"Good vs Cheap" is About Judgment Under Uncertainty
How do we compare a growth-stage startup hiring at the top of the market to a private-equity-owned organization hiring in the bottom 50% of market percentiles? Is the startup simply overpaying for interchangeable software engineers, or is the PE-owned org short-sightedly pinching pennies? The reality is that both organizations are following different strategies based around:
- How much ambiguity there is in the role, and
- Whose job it is to clarify that ambiguity day to day.
The "Good" Strategy
In a startup context, the organization is fighting for survival in an uncertain landscape. You're building 0 to 1, looking for product-market fit, pivoting and iterating, and deciding which of five plausible approaches will still be right in six months. To hire into this, you're looking for candidates with:
- Taste - A compressed model of what "good" looks like in a domain, so you reject fast options without enumerating them.
- Slope - How fast you learn and update your mental models. This looks like low ego attachment to being wrong, combined with enough awareness to notice when your model failed.
- Autonomy - The ability to work without a defined problem, to decompose ambiguity into tractable pieces.
These skills are built from compounding experience, which drives them up-market. Good judgment puts you into hard situations that build more judgment. And so when you do hire these folks, they can wear many hats and generally adapt to the demands of a startup.
The "Cheap" Strategy
The private-equity-owned organization looks different first and foremost because it is more mature. The product is stable, and we're moving from an exploration phase to an exploitation phase. (And boy do I have feelings about that! But that's for another time.) Predictable returns are valued more highly than risky, lumpier returns. Ambiguity is chased out early, with detailed requirements documents and strict processes before anything is handed to an engineering team for execution.
The result is that the work is more well defined. There is less value placed on engineers being able to decompose ambiguity, because there is simply less ambiguity coming into the pipeline.
So, these companies don't put out money for the skills they don't need. Instead, they target more narrowly scoped roles (e.g. Rails engineer, C# engineer, DBA) which command lower salaries. The ambiguity that they do have is funneled to tech leads or architects, or pushed upstream to Product and Design.
Neither approach is wrong; they are simply built on different assumptions and different organizational needs.
How AI Changes This
In the "good" strategy, we have high-judgment engineers constantly breaking down ambiguous problems. These engineers are not easily replaced by AI. In fact, they are highly capable of driving AI agents to help them iterate through the ambiguity. Agents help them research, clarify, and eventually execute. They expand the reach of a single high-judgment engineer.
In the "cheap" strategy, things look different. Agents can take a well-defined requirements document and execute against it with minimal supervision. This further reduces the responsibilities of the already narrowly scoped engineering hires. Their roles are threatened. The organization can go one of two ways:
- Downsize the headcount. The folks who are already decomposing ambiguity start handing requirements to AI agents instead of human colleagues. You're left with only high-judgment roles.
- Let ICs drive more ambiguous work. Stop investing so much in upfront requirements, and 10x your available "ambiguity decomposers". The only problem: you didn't hire with this skill in mind. Your team is missing the compounded experience that leads to good judgment, so get ready for some hard lessons along the way.
Two Strategies Become One
In either case, the long-term hiring for "cheap" roles evaporates; you need folks who can handle ambiguity. And if they can handle ambiguity, they may as well work iteratively with the agents to decompose ambiguous problems into tractable pieces, rather than waiting to hand off highly detailed requirements documents. The "cheap" strategy and the "good" strategy have merged:
A single high-judgment individual driving a team of AI agents to deliver software, scaled to your desired team size and velocity.
Cheers!