LinkedIn's full stack builder model: AI-powered product teams without functional silos

Executive overview

At scale, the product development process fragments into dozens of sub-steps spread across dozens of specialised roles. What was once one builder taking an idea to market becomes ten functions, ten codebases, and ten sprints for a single feature.

LinkedIn's full stack builder model collapses that stack. The goal: any builder, regardless of function, takes an idea end to end. AI handles everything outside vision, empathy, communication, creativity, and judgment.

The core insight: the process isn't complex — we made it complex. AI gives us a chance to undo that.

Why the model is broken

• By 2030, 70% of the skills required for current jobs will change
• The fastest-growing jobs today didn't exist on the list a year ago
• Change is now happening faster than organisations can respond
• Micro-specialisation created bloated teams for even small features
• Process complexity became organisational complexity; the diagram of both together is "mind-blowing"

What full stack builders own

• Vision — a compelling stance on the future
• Empathy — deep understanding of an unmet need
• Communication — ability to align and rally others
• Creativity — possibilities beyond the obvious; AI is not yet strong here
• Judgment — high-quality decisions in ambiguous situations; the most important trait

Everything outside these five is being automated.

The three components of the model

• Platform — re-architecting core codebases so AI can reason over them; off-the-shelf tools never work on LinkedIn's stack without deep customisation
• Tools and agents — purpose-built internal agents trained on LinkedIn-specific context
• Culture — the hardest and most important part; tools alone are not sufficient

Internal agents built so far

• Trust agent — reviews specs for harm vectors and vulnerabilities; found holes in past specs that weren't caught until later
• Growth agent — critiques ideas against LinkedIn's unique loops and funnels; used by the UXR team to prioritise highest-impact opportunities
• Research agent — trained on LinkedIn member personas, past research, and support tickets; redirected one team's product spec toward higher-value integrations
• Analyst agent — queries the LinkedIn graph in natural language, removing dependency on SQL or data science teams
• Maintenance agent — handles failed builds; ~50% of broken builds now fixed automatically
• Product jammer agent — orchestrates the other agents in a single product jam workflow; users may not know which underlying agents run

What LinkedIn learned building agents

• Off-the-shelf tools never work on a complex existing codebase — deep co-development with vendors is required
• Giving agents access to everything (entire Drive, entire codebase) produces poor results and hallucination
• Curating "golden examples" — high-quality, weighted data — matters more than raw access
• Different teams gravitate to different tools; convergence on a standard is harder than expected
• The idea-to-design phase had been under-invested compared to code-to-launch; that's now the priority area

Team structure and rollout

• Teams reorganise into pods — small groups assembled around a mission for a quarter, then reassembled differently
• The APM program ends; replaced by the associate product builder (APB) program — new entrants trained across coding, design, and PM
• A formal full stack builder career ladder now exists; people can hold that title from any prior function
• Pilot runs in two ways: top-down (product execs do 360 reviews across functions) and bottom-up (pods of early adopters build and give feedback)
• One user researcher transitioned directly into a growth PM role using the FSB tools
• Designers pushing PRs and PMs building their own dashboards — things that hadn't happened before

Change management: what actually works

• Performance signals — AI fluency is now part of hiring criteria and biannual performance evaluation
• Visible success stories — wins shared in all-hands; individuals highlighted by name
• Exclusivity to create pull — limited access with a feedback obligation creates demand
• Top-down declaration — announce the direction early, even before tools are ready; don't wait for a reorg
• Over-communicate progress — share KPIs and OKRs with the team, not just the vision
• The early-adopter 5% will self-select; the rest need deliberate change management

Key lessons for other organisations

• Start with platform investment — without it, agents won't work; don't expect ROI in a week
• Customise agents for your unique context; vanilla agents from outside deliver generic value
• Invest time upfront building golden examples before expecting quality output
• Make the tool better with early adopters before GA rollout to the whole organisation
• Specialisation still has a place — not everyone needs to be a full stack builder; but fewer specialists are needed than before
• If you're waiting for a formal reorg to start building differently, you're waiting too long