Korva is a scroll of the internet’s best ideas.
Blurring roles
AI lets product managers, designers, and data scientists get further before engineering has to take the lead: prototyping, writing code, and building something testable for a hypothesis. That works when the problem matters to the business and the engineering partners know it is being worked on. Thousands of prototypes aimed at nothing in particular is the failure to avoid, and everyone shipping code to production is probably not the right outcome either.
Where each discipline leads
Each discipline keeps a comparative strength. Data scientists remain the experts on whether data can be trusted, whether it is being read correctly, and where judgment has to come in. Product managers remain exceptional at framing the what, the problem being solved. Engineers keep the craft of the how: how something scales, what high quality looks like, and what problems it will create given how it is built and deployed.
Responsibility stays
Prototypes still go back to engineering partners to work out how to productize them, scale them, and guard them. A person who used an agent to write code or help with an analysis still carries the responsibility that comes with what they created. Netflix wants clarity on source-of-truth data, guardrails on shipping to production, and review wherever AI output cannot simply be trusted.
Why does the how of engineering stay hard?
Fred Brooks argued in his 1986 essay No Silver Bullet that software has two kinds of difficulty. Accidental difficulty comes from the tools, such as clumsy languages and slow compilers. Essential difficulty comes from the problem itself, which includes deciding what to build and how the pieces interact. Brooks predicted that no single tool would deliver an order-of-magnitude gain, because better tools only attack the accidental kind.
Why do prototypes struggle in production?
Google researchers led by D. Sculley published a 2015 paper called Hidden Technical Debt in Machine Learning Systems. They pointed out that only a small fraction of the code in a real machine learning system is the model itself. The rest covers data collection, monitoring, serving, and configuration. Brooks made a related point in 1975 when he advised teams to plan to throw one away, since the first version teaches what the real one needs.
Has a tool ever blurred job roles like this before?
VisiCalc, released in 1979 for the Apple II by Dan Bricklin and Bob Frankston, was the first widely used spreadsheet program. It let accountants and analysts build financial models that previously required a programmer. Spreadsheets did not eliminate programmers, who moved on to larger systems. They did make quantitative modeling a routine part of office work.
More from Lenny's Podcast: Product | Growth | Career
