The Stack is Collapsing

████████╗██╗  ██╗███████╗    ███████╗████████╗ █████╗  ██████╗██╗  ██╗
╚══██╔══╝██║  ██║██╔════╝    ██╔════╝╚══██╔══╝██╔══██╗██╔════╝██║ ██╔╝
   ██║   ███████║█████╗      ███████╗   ██║   ███████║██║     █████╔╝ 
   ██║   ██╔══██║██╔══╝      ╚════██║   ██║   ██╔══██║██║     ██╔═██╗ 
   ██║   ██║  ██║███████╗    ███████║   ██║   ██║  ██║╚██████╗██║  ██╗
   ╚═╝   ╚═╝  ╚═╝╚══════╝    ╚══════╝   ╚═╝   ╚═╝  ╚═╝ ╚═════╝╚═╝  ╚═╝

██╗███████╗     ██████╗ ██████╗ ██╗     ██╗      █████╗ ██████╗ ███████╗██╗███╗   ██╗ ██████╗ 
██║██╔════╝    ██╔════╝██╔═══██╗██║     ██║     ██╔══██╗██╔══██╗██╔════╝██║████╗  ██║██╔════╝ 
██║███████╗    ██║     ██║   ██║██║     ██║     ███████║██████╔╝███████╗██║██╔██╗ ██║██║  ███╗
██║╚════██║    ██║     ██║   ██║██║     ██║     ██╔══██║██╔═══╝ ╚════██║██║██║╚██╗██║██║   ██║
██║███████║    ╚██████╗╚██████╔╝███████╗███████╗██║  ██║██║     ███████║██║██║ ╚████║╚██████╔╝
╚═╝╚══════╝     ╚═════╝ ╚═════╝ ╚══════╝╚══════╝╚═╝  ╚═╝╚═╝     ╚══════╝╚═╝╚═╝  ╚═══╝ ╚═════╝

██╗███████╗     ██████╗ ██████╗ ██╗     ██╗      █████╗ ██████╗ ███████╗██╗███╗   ██╗ ██████╗ 
██║██╔════╝    ██╔════╝██╔═══██╗██║     ██║     ██╔══██╗██╔══██╗██╔════╝██║████╗  ██║██╔════╝ 
██║███████╗    ██║     ██║   ██║██║     ██║     ███████║██████╔╝███████╗██║██╔██╗ ██║██║  ███╗
██║╚════██║    ██║     ██║   ██║██║     ██║     ██╔══██║██╔═══╝ ╚════██║██║██║╚██╗██║██║   ██║
██║███████║    ╚██████╗╚██████╔╝███████╗███████╗██║  ██║██║     ███████║██║██║ ╚████║╚██████╔╝
╚═╝╚══════╝     ╚═════╝ ╚═════╝ ╚══════╝╚══════╝╚═╝  ╚═╝╚═╝     ╚══════╝╚═╝╚═╝  ╚═══╝ ╚═════╝

an interactive essay · trevor hinkle

LLMs don’t just speed up execution—they multiply decisions. We need to think about who’s best positioned to make these decisions in software teams.

Software teams used to be organized around division of labor and handoffs. The teams of the future will be built around managing agents and decision-making.

LLM technology is advancing at a blistering pace, and two things are clear:

LLMs are really good at making software, fast.
LLMs give pseudo-expert superpowers to someone with decent foundational knowledge in a given discipline

As a result, output is going up 10x, and more members of the team can play in more domains. This means we need to rethink how teams are structured and how they build.

123

##The new software development team - managing agents, making decisions

If LLMs make building software faster, we suddenly have a lot more output to “process”. When we can create outputs an order of magnitude faster, we have an order of magnitude more decisions to make, and it can get exhausting.

In an afternoon, I can have an agent generate 3 variants of an onboarding flow, 5 copy variants, and two plans for implementation to choose from. I used to spend a lot of time creating options. Now, the work is evaluating them.

▶Your turn. stop creating, start evaluating — make the calls below.

your agent generated 3 onboarding flows

select one · ↑↓ / click · ⏎

decisions [░░░░░░░░░░░░░░░░] 0

Particularly for those of us coming from an IC background, we’re not used to spending more and more of our days evaluating output and giving feedback - in essence, we’re turning into managers of agents.

This leads to an interesting phenomenon - many members of software development teams used to deferring to managers or other job functions to make decisions now have to make these decisions themselves, at least as an initial call before sharing the output with others.

While most teams hope that any developer or designer can make executive decisions and be relatively autonomous, the reality I’ve seen across the many teams I’ve worked with over the years is that these functions are often conditioned to optimize for presenting options, and executing on someone else’s (the PM, tech lead, executives, etc) decision.

Sometimes this “assembly line” approach is the way they prefer to operate, and sometimes it’s because decision makers consciously or subconsciously hoard decision-making power for themselves (aka micromanaging). But to keep up in this age of LLMs accelerating software development, we all need to start exercising our decision-making muscles as we increasingly become managers of agents. Ultimately, the bottleneck of software development becomes decision making.

##How will (or should) roles change?

Which brings us to the implications of LLMs giving folks pseudo-expert superpowers: the traditional developer/designer/PM triad no longer holds up. We no longer need to gatekeep certain tasks within these roles, because many generalists can now handle tasks across all three. The “stack” of software development disciplines will (and should) collapse.

How do we maintain quality of output when non-experts are using agents to make contributions beyond their traditional disciplines? If roles are blurring, where is the most/least overlap?

The answer will be different for each team, and we’re too early for conclusive best practices. But my general belief is that the product manager role is best suited for spilling over into other disciplines, and that the modern product manager should be a “Full-Stack PM”, working across designer, development, strategy, research, and prioritization tasks. Other roles should still utilize AI to speed up their work and operate beyond the traditional borders of their responsibilities, but PM role should change the most.

##The Full-Stack PM

Why highlight the PM role? Because of the decision-making bottleneck I outlined above. Decision-making is now the bottleneck of software development in a more acute way than before, and PMs typically are used to making decisions on behalf of their team. Therefore, PMs should take on a disproportionate amount of agent management (and decision-making) in disciplines beyond their own, relative to developers and designers.

A few other reasons why the PM’s role should expand with the use of LLMs:

PMs typically already have the generalist background that lets them have pseudo-superpowers in a number of disciplines using LLMs
LLMs let them more easily pair with experts (designers, developers) and create great outputs together
In addition to being great at software development, LLMs are increasingly great at some of the biggest time-sucks in a PM’s day to day - data analysis, artifact making, organizing and processing company knowledge to aid in decision making, etc.

from the traditional PM's plate to the full-stack PM's

work that was manual, skipped, or another discipline's gets pulled into the role

Traditional PM domain

✋ done manually

◔ high-level only

✗ not done by anyone

▼ pulled into the role ▼

Full-Stack PM domain

⟳ automate

↧ go deeper

↗ expand into

This is not to say that PMs should be building for and pushing to production unilaterally; developer and designer expertise are critical filters and for PMs. While there are some arguments for merging the designer and PM roles (and to be fair, I’ve played a hybrid designer/PM role for years now), I think most teams are best served with those disciplines preserving focus. If someone is going to spill over the edges of their role, it should first be the PM.

A fair contention to this argument: “Won’t this just create more decisions for developers and designers to make when reviewing PM output in these areas?” This is true risk, but I think all teams will be forced to contend with more decisions to make, as I outlined above. I’d rather confine the type of decisions that designers and developers make to be more within their discipline. For the average team I’ve worked with, this approach has seemed to work best.

##Being a Full-Stack PM, Responsibly

As I’ve tried to practice this “Full-Stack PM” idea on teams I work with, here’s the approach that’s worked:

Do: Where to lean in

Prototype in code (with designers) once the direction is chosen; but remember to keep fidelity appropriate to the decision

Go upstream on research (recruiting, scripts, synthesis): let AI compress analysis so you can spend more time on the human parts of the job

Automate analytics + reporting workflows: no need to spend time on manual analysis for routine checks - save your energy for deep dives when the top-line results are intriguing

Get deeper technically (architecture, tradeoffs) so you can participate meaningfully in “how” conversations, not just “what/why”

Take on small-to-medium dev tasks where speed matters and downsides are low (with appropriate review processes)

Think at a meta-level about how the team can create more automations and workflows to abstract away tasks where it makes sense. Build internal tools to do this, but be cognizant of the maintenance tax - what you build, the team has to maintain

Automate the grunt work in competitive research: It’s now cheap and simple to keep up to date on the competition by automating the most time-consuming parts of landscape analysis

Spend more time on long-term thinking and synthesis: this where you can make the most valuable contributions to the team, and where you should resist the temptation to let AI think for you. Ultimately, your job is to make decisions, and preserve your executive function whenever possible.

Don’t: the guardrails

Don’t ship unreviewed design work: designers still set and own the quality bar here

Don’t disregard engineering standards: your output has the same standards as any engineer on the team

Don’t expose the team to all your decision-making: With more intermediate decisions to make, being too transparent and seeking too much input can create team-wide decision-fatigue (everyone reviewing everything)

Don’t abandon the fundamentals: Just because we can ship faster doesn’t mean we shouldn’t be building what users want, that we shouldn’t have clear success metrics and a plan for measurement, etc.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

##The Stack is Collapsing

I believe the most effective teams moving forward won’t be the ones with that simply stick AI on top of their “assembly line” of research → design → dev. What matters is how the team handles judgement: who makes the calls, how quickly, and with appropriate guardrails.

I’d welcome your perspectives on this essay - what rings true, what doesn’t for you? This is an inherently messy and fast-moving subject, and there aren’t clear answers. I’d love to hear what you think.