I talked with Ben Ilegbodu about AI enablement, internal tooling, and what product engineering looks like when the people using your product are other engineers.
Ben and I go way back from the React community days. These days he is on Netflix's TV UI productivity team, helping engineers get faster with agents, skills, and better feedback loops. That might sound like "infra work," not "product work." One of the reasons I wanted him on the show is that I keep meeting people who assume Become an Epic Product Engineer is only for folks shipping the consumer-facing thing.
Ben made the counterpoint really clear: the product is what you deliver to developers. And in some ways that is harder, because your customers Slack you when something is broken.
Product judgment still applies to internal tools
If you ship a paid product, revenue is a blunt feedback loop. Internal tooling does not get that.
Ben's version of success still sounds like product work: watch usage, instrument observability, notice where people get stuck, and treat silence carefully. Sometimes silence means things are fine. Sometimes it means nobody found the tool in the first place.
That framing matters if you build platform, productivity, or AI enablement work. You still need customers. They just happen to sit a few desks away.
Close the loop the agent cannot close itself
A big chunk of Ben's day-to-day is helping engineers use agents well across the whole software lifecycle: implementation, review, production issues, and the context the agent needs to do cheap work well.
The tricky part on TV UI is that models are mostly trained on web development. TV development can look similar without actually being a browser with CSS and the usual tooling. Cursor can "see" a web page more easily than it can see a TV app. So Ben's team has to build the missing infrastructure that closes the agent loop: run something, observe the result, decide what to do next, continue.
That is a product problem disguised as tooling. If the agent cannot verify its own output, humans stay in the middle of every iteration.
The durable skills are still the human ones
Ben's answer for what lasts as harnesses change was almost exactly the thesis of this show.
Deciding what to build. Writing specs. Verification.
Agents are not talking to customers. They can generate a lot of code, but they do not magically know which work is worth doing. And as code gets cheaper, verification moves up a level: not only "does this TypeScript look right?" but "does this change do the thing we said it should do in the system?"
He also pointed at a second career path with longevity: the people building the harnesses. Skills, evals, code-review agents, connections across the software development lifecycle. When teams start shipping three times as much code, humans cannot review three times as much code by staring harder. Somebody has to build the system that makes that throughput safe.
Faster shipping is not an excuse for feature spam
I asked Ben what happens to the end-user experience when development gets that much faster.
His answer was one of my favorite moments: do users actually want three times more features?
Maybe that throughput goes into more A/B variants so you have a better chance of shipping the right one. Maybe it goes into tech debt cleanup. Dumping change on users every day because you can is a good way to create churn.
That is product engineering in one sentence. Throughput is leverage. Judgment decides where the leverage goes.
The homework
Ben's homework is simple and immediately useful.
While you develop with an agent, notice the prompts and workflows you keep repeating. Turn one of those into a skill. Skills may get replaced in six months. Right now they are one of the best ways to stop retyping the same guidance and to give the agent richer, reusable context.
If all you keep is a folder of markdown that describes how you want the agent to work, that still transfers when the harness changes.
