Deciding what to build when AI writes the code

Deciding what to build is now the expensive step in software: AI coding tools made code cheap, and choosing what the code should do got no easier. Engineers are right that typing was never the hard part: developers at Microsoft spent about 11% of a workweek writing code, and correct code depends on what the team agreed. So write each decision down while the room is still talking, then hand it to whoever builds, a teammate or a coding agent.

Our product, Chief, works on meetings and what comes out of them, which gives us an interest in where a team's decisions end up.

Key Takeaways

Engineers are right: writing code was never most of the job. Developers report spending 11% to 16% of their week on it (Microsoft Research, Atlassian, 2025).

AI made generating code cheap, and adoption is near universal: DORA counts 90% of software professionals using AI (2025).

Cheaper code makes the wrong decision cheaper to ship, so the choice of what to build carries more weight.

Most of that choosing happens in conversations: customer calls, planning meetings, review threads. Those rarely survive to the build.

A coding agent knows only the decisions someone wrote down. Record them while the room is talking, then hand them on.

Was writing code ever the hard part?#

Typing it wasn't. Writing correct code was, and that depends on knowing what correct means. In August 2026, Senko Rašić published "Code was never the hard part" is an insult to all programmers. The Hacker News thread reached 946 points.

Rašić's case deserves a fair reading: building good software takes real craft and an understanding of the customer. Many replies granted the craft and then located the difficulty somewhere else.

"Writing code is not hard. Writing correct code is. Knowing what is correct in a setting with paying customers generally involves interacting with those customers." (bob1029, Hacker News, 2026-08-08)

"It’s not writing the code that is the hardest part for an organization. It’s getting everyone to understand the problems, working together, gathering requirements, developing specifications…" (agentultra, Hacker News, 2026-08-08)

The surveys agree with them. Microsoft Research studied 484 of its developers for a paper at ICSE 2025. Coding took about 11% of an actual workweek, and communication and meetings about 12%. Asked to describe their ideal week, the same developers put coding near 20%.

Atlassian's State of Developer Experience 2025, a vendor survey of 3,500 developers and managers, reports: "Developers only spend 16% of their time coding."

Not everyone in the thread agreed on where the hard part sits. "Figuring out what to build is definitely not the hard part though." (throwawayffffas, Hacker News, 2026-08-08) For a developer handed a well-defined problem, that's fair.

What changed when code got cheap?#

Generating code became cheap and nearly universal. Trust in the output didn't keep pace.

Google's DORA 2025 report says AI adoption among software professionals "has surged to 90%". Over 80% of respondents say it raised their productivity, while 30% trust its output a little or not at all. The Stack Overflow Developer Survey 2025 found 84% using or planning to use AI tools, and 46% actively distrusting their accuracy.

Felt speed and measured speed can come apart. METR ran a randomized trial in early 2025 with 16 experienced open-source developers working 246 issues in their own large repositories. With AI tools allowed, they took 19% longer. They had expected a 24% speed-up, and afterwards believed they'd been 20% faster.

METR, 2025: experienced developers on their own repositories expected to be faster with AI tools, believed they had been, and measured 19% slower.

It's one study of early-2025 tools on mature codebases, and it measures nothing about deciding. It shows only that more output and more delivered progress aren't the same thing.

Developers report the bottleneck moving to the edges of the code. "Claude writes 90% of my code but the bottlenecks always were and still are: * getting clear requirements from product * getting the damn code reviewed so I can merge it" (throwatdem12311, Hacker News, 2026-08-08)

On dev.to, ale3oula asked What do you build when you can build anything? and wrote: "When everything is possible, every idea starts to feel like an obligation." (2026-09-02, 110 reactions, 63 comments) On Hacker News, mmonaghan put it shorter: "being able to build these features (or separate products) quickly is exactly the trap" (2026-09-18).

When building costs less, a wrong choice costs less to ship and just as much to live with.

Where does deciding what to build happen?#

In conversations. Customer calls, planning meetings, stakeholder reviews and the Slack threads after them are where a team settles what it will build.

"It’s not that coding is easy, it’s more that coding was not the bottleneck in the process at large organizations. It was (and still is) getting agreement on what to build, meeting with stakeholders, and dealing with the ever-changing priorities." (al_borland, Hacker News, 2026-08-08)

The same comment tells a story worth reading in full. Asked to deliver a project in four weeks, al_borland made the detailed decisions alone and had something mostly working in two. Then the formal design caught up. "One such detail was a port list. It took 4+ months of meetings to get that done". Later: "I ended up having to go back and re-write a bunch of stuff to align with the design that was decided on over a year after the deadline the CIO gave me."

Andrew Ng made the same point on the No Priors podcast. As Business Insider reported on 2025-08-22, he said: "The bottleneck is deciding what do we actually want to build".

Saying no is part of deciding, too. Liam Nugent's essay The most important product decision is what you don't build drew 161 points on Hacker News in September 2026. A no only counts if it survives. One product manager in the thread described how it doesn't:

"I can say no, and explain why, but the idea will keep coming back. Brainstorming session? They raise it again. Sales call? They float the idea to the potential new customer. I take a two week vacation? It ends up in the sprint." (ungreased0675, Hacker News, 2026-09-18)

Why don't decisions survive from the meeting to the build?#

Because the decision exists only in the conversation. Afterwards it lives in someone's memory, in a transcript nobody reopens, or in a recap written days later.

The builder has changed too. A coding agent reads the repository, the ticket and the prompt you give it. It knows only what someone wrote down. If the room agreed not to support a feature and nobody recorded it, that decision doesn't exist for the agent.

A decision record that survives the trip has four parts:

The conclusion. What the group agreed, not the options people floated on the way there.
When, and who agreed. So a teammate can ask the right person later.
What the group rejected. The no's are the decisions most likely to leak back in.
Who builds it. A person, or their agent.

Write it during the meeting, while the people who decided can still correct it. Then put it where the builder's work starts: in the ticket, the repository, or the agent's prompt. You can do all of this with a shared doc and some discipline. Our post on when a spec still pays covers what to keep in it. The hard step is capturing the settled point before the meeting ends.

Where does the decision get written down?#

In Chief, during the call. Auto-apply Tags land on every point, and Chief is told to tag a point Decisions only when the group settled it, not when someone floated it.

Every project starts with two tags, To-dos and Decisions, and your team can write its own. In the desktop app, the Decisions view lists every point tagged Decisions in the session, each with the minute it was said. It fills in while the call runs.

The Chief desktop Decisions view mid-call: five product decisions, each with the minute it was said, above the Send to, Copy and Ask Chief buttons. — The Decisions view during a call: each settled point with the minute it was said, and Send to… for your agent.

From the Decisions view you can copy the list, ask Chief what should happen next, or hand just those items to your AI agent with Send to…

Sent from the Decisions view to Claude Code or Codex, the context folder holds only the items tagged Decisions and leaves the transcript out. You can send it while the call is still running.

Chief saves the context in a project folder you pick and starts Claude Code or Codex in your terminal with instructions to read it. For another agent, Chief copies a prompt for you to paste. The agent runs in your own terminal with its own permissions, in the folder you chose. Chief doesn't commit, push or open a pull request.

The limits:

Chief doesn't decide what to build. It keeps what the room decided and hands it on.
The tag is a model's call. If it lands on the wrong point, take the tag off; it stays off, and the model doesn't put it back.
Chief doesn't track whether a decision worked out.
The next meeting doesn't start from the last one's decisions unless a meeting-prep action supplies a brief.
The Decisions view and Send to… are desktop only (macOS and Windows).
If your agent already reads your ADRs, that works.

Walkthroughs: track meeting decisions and action items, and hand a meeting to Claude Code.

Frequently asked questions#

Is coding still a bottleneck with AI tools?

Sometimes, and not always where people expect. METR's experienced developers were 19% slower with AI tools on their own repositories in early 2025. Teams also report review and CI as new chokepoints, as in Linear's post on reworking its CI (Hacker News, September 2026).

How do you decide what to build?

Start from the problem, test the options against evidence, and say out loud what you won't build. PostHog's How we decide what to build and Enterpret's The 5 Ways to Decide What to Build Next both lay out frameworks.

Who should decide what to build: product or engineering?

Both, in the same conversation. As mmonaghan wrote on Hacker News (2026-09-18), knowing what matters is "rarely a single person's decision."

What should a decision record include?

Four parts: the conclusion the group reached, when and who agreed, what the group rejected, and who builds it. The rejected options matter most, since those no's tend to come back.

How do I give a coding agent the context from a meeting?

Write the decisions down and give the agent that record with the task. With Chief, you can send just the items tagged Decisions to Claude Code or Codex, and the agent gets those without the transcript. Chief doesn't commit, push or open a pull request. Hand a meeting to Claude Code walks through it, and how Chief compares covers other tools.