ExpertsFM“Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu
Lenny's Podcast: Product | Career | Growth · February 12, 2026
5 Selected Lessons:
framework · 3 heuristic · 1 priority · 1
Spend majority of management time on top performers
Source
Lenny's Podcast: Product | Career | Growth — “Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu (February 12, 2026) · at 19:29 ▸ · at 31:41 ▸ · at 41:56 ▸
When this applies
when allocating a manager's scarce time across a team whose top performers can be massively leveraged by tools
The takeaway
When a new capability multiplies the output of your best people more than your average people, concentrate scarce management attention there rather than spreading it evenly.
Why it works
AI tools disproportionately amplify high-agency, high-skill individuals, widening the productivity spread between top and average performers; unblocking the top performers yields outsized returns because their output scales with attention given.
One level up
Resource allocation should follow where marginal leverage is highest, not where it is most evenly distributed.
Where it stops holding
This stops working when underperformers are blocked by something only the manager can fix and neglecting them causes team-wide breakdowns, or when the tool does not actually differentiate top vs. average performer output.
Detail
hierarchy:
- Top ~10% performers (50%+ of manager's time)
- Unblocking and amplifying them via tools and organizational knowledge
- Broader team knowledge-sharing of best practices discovered by top performers
rationale: Mark Andreessen's framing cited approvingly: AI makes good people better and great people exceptional, so doubling down on top performers compounds under AI.
In their words
One thing that I've always done as a management philosophy is to spend actually the majority of my time with top performers, just like make sure they're unblocked, make sure they're happy, make sure they feel productive and they feel heard.
Engineer-as-tech-lead / fleet-manager role shift
Source
Lenny's Podcast: Product | Career | Growth — “Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu (February 12, 2026) · at 0:00 ▸ · at 5:07 ▸
When this applies
when an automation layer can execute most of the tactical work in a profession
The takeaway
When execution is automated, the human role upgrades from doer to orchestrator/manager of many parallel automated workstreams.
Why it works
As execution becomes automatable, the human's value shifts from doing the work to directing, reviewing, and steering many parallel streams of work simultaneously — a managerial function even at the individual-contributor level.
One level up
Automation doesn't eliminate the need for judgment; it relocates judgment to a higher, more parallel level of oversight.
Where it stops holding
This stops working when the automation is unreliable enough that oversight burden exceeds the time saved, or when tasks require continuous hands-on execution rather than periodic steering.
Detail
procedure:
- Delegate code-writing to agents
- Run many parallel agent threads/jobs
- Periodically check in, steer, and give feedback to each
- Review and merge outputs rather than author them
benchmarks: {"parallel_threads_per_engineer":"10 to 20"}
rationale: The engineer's job becomes managing fleets of agents like a tech lead manages a team, not writing code line by line.
In their words
I know many of the engineers on my team basically have like 10 to 20 threads kind of being pulled on at the same time.
Diagnosing why AI deployments fail: top-down vs. bottom-up adoption
Source
Lenny's Podcast: Product | Career | Growth — “Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu (February 12, 2026) · at 37:29 ▸ · at 41:56 ▸
When this applies
when rolling out any new technology/tool mandate across a non-technical organization
The takeaway
Successful technology adoption requires both executive buy-in AND organic bottom-up champions who adapt the tool to their specific workflow and evangelize it internally; either alone is insufficient.
Why it works
Top-down mandates without grassroots champions leave employees aware they're 'supposed to use' a tool but without peer models or tailored best practices for their specific, idiosyncratic work, since every function's 'last mile' use case differs too much for generic top-down guidance to cover.
One level up
Durable organizational change requires aligning authority (top-down resourcing) with practice (bottom-up expertise), not substituting one for the other.
Where it stops holding
This stops working when the task is so standardized across the whole org that no local tailoring is needed, making a pure top-down rollout sufficient.
Detail
procedure:
- Secure executive buy-in and resourcing (top-down)
- Identify technical-adjacent (not necessarily engineer) employees who get excited about the tools
- Empower them to run hackathons, seminars, and knowledge-sharing to build bottom-up best practices
- Avoid relying on mandate alone without grassroots champions
rationale: OpenAI's own internal Codex adoption 'really started taking off' once employees themselves could apply it to their specific work, not just via top-down push.
In their words
The companies where I think it started to work really well have a combination of both top-down buy-in
Layered API abstraction stack for building agents
Source
Lenny's Podcast: Product | Career | Growth — “Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu (February 12, 2026) · at 1:05:22 ▸
When this applies
when designing a platform offering for developers with varying needs for control versus speed
The takeaway
Structure a developer platform as layered abstractions from low-level/unopinionated to high-level/opinionated, so both power users and speed-seekers are served from the same core primitives.
Why it works
Offering progressively higher levels of abstraction (raw endpoint → SDK with orchestration primitives → pre-built UI/eval components) lets developers trade off flexibility for speed depending on their need, maximizing the addressable range of use cases from a single platform.
One level up
Platforms scale their usefulness by offering multiple entry points at different abstraction levels rather than one fixed interface.
Where it stops holding
This stops working when the layers diverge too much in semantics, creating maintenance burden or confusing developers about which layer to use.
Detail
procedure:
- Lowest level: Responses API — raw text in/out, unopinionated, for long-running agents
- Next layer: Agents SDK — orchestration, sub-agents, guardrails, swarms
- Top layer: Agent Kit/Widgets (UI components) and Evals API — pre-built components for common needs
rationale: Each layer increases ease-of-use and opinionation while still being built on the same lower-level primitives.
In their words
I view it as these various layers. They're all kind of helping you build what you want with our AI, with our models, and with increasing levels of abstraction and how opinionated it is.
Build for where the models are going, not where they are
Source
Lenny's Podcast: Product | Career | Growth — “Engineers are becoming sorcerers” | The future of software development with OpenAI’s Sherwin Wu (February 12, 2026) · at 0:00 ▸ · at 44:04 ▸ · at 48:57 ▸
When this applies
when building on top of any fast-improving underlying technology or platform
The takeaway
Design products around the anticipated trajectory of your core enabling technology, not its current limitations, because the gap closes faster than expected.
Why it works
Because capability curves improve predictably and quickly, a product designed for near-future capability will 'click' into greatness once the underlying tech catches up, whereas a product designed only for today's capability becomes obsolete or mediocre.
One level up
In fast-moving technology waves, positioning for the future state beats optimizing for the present state.
Where it stops holding
This stops working when the underlying technology's improvement trajectory stalls or reverses, or when the time lag before the capability arrives is too long for the business to survive.
Detail
rule: Build a product for an ideal capability ~80% there today, anticipating the model will close the gap soon.
threshold: Models often close the remaining 20% within a short window (e.g., one model generation), per Wu's framing (o3 to 5.1/5.2).
rationale: Companies that build with model-improvement trajectory in mind end up with products that suddenly 'unlock' into excellence, versus those that assume static capability.
In their words
My general advice, and I've been giving this to people for a while, and I think it's still true today, is make sure you're building for where the models are going and not where they are today.