Product and Engineering Are Becoming One Job

I spent part of last week watching a working session that would have looked strange five years ago and now looks like Tuesday.

A terminal coding agent was pointed at a real repository. Not a browser chat tab inventing a function from a vibe. A tool that could walk the tree, open the files that mattered, draft a plan, and later edit with a diff someone could refuse. The people in the room asked it product-shaped questions: what are the risks if we merge as-is, what staging checks does this feature actually need, what happens to the product if we remove this tomorrow, can you put that in language a PM can take to a meeting.

The answers were useful. The keystrokes were not the point. The scarce skill sitting in the room was the brief.

That is the compaction I cannot unsee. Product and engineering are becoming one job.

The old wall was a queue

For a long time we pretended the wall between product and engineering was a feature. Product wrote tickets. Engineering burned them down. QA arrived after the shape was already frozen. The handoff was the process. The ticket was the contract. Everyone could point at their lane when something broke.

That wall only worked while the expensive part was producing the change. Typing, wiring, searching the tree, drafting the test, chasing the lint failure — that labor was scarce enough that you could afford a specialty for “what” and a specialty for “how.”

Agents that act on a codebase compress the how. They do not erase judgment. They move it. Once the mechanical path from question to candidate change is cheap, the valuable work is naming the question, packing the context, and deciding whether the answer is allowed to touch production. That work does not care which title was on your Slack profile when the hour started.

I have been writing around this from adjacent angles. Shipping code is not the job. The scarce IP is leaving the code artifact. Forward deployed is a product, not a staffing label. This one is narrower: inside a single week, I watched the job titles blur because the agent made the old division of labor look theatrical.

What I actually watched

The useful hour was not “write me a feature.” It was plan mode first.

Summarize this branch versus main. List the risks. Name the critical path a user still has to survive. Draft the staging manual checks, including the config and data the feature depends on. Give the PM a one-pager on impact if we cut the thing tomorrow.

Those are product questions asked against engineering truth — or engineering questions that only make sense if you care about the product. The agent could answer them because it could read the repo. A human still had to know which questions mattered, which context was missing, and which “done” would be a lie.

When they switched to build mode, the same pattern held. Implement the missing tests. Tighten the docs. Fix the gaps the plan called out. Open the PR. Chase CI without turning every red check into a ceremony. Someone still reviewed. Someone still owned the merge. The person who could do that well was not “the engineer who types fastest.” They were the person who could hold product intent and delivery craft in the same breath.

I keep coming back to a simple line from that room: the scarce skill is the question, not the ticket burn. PMs and QA already understand large parts of the product. A terminal agent that can act on the tree opens a door they used to need an engineer to walk through for them. That does not make engineers optional. It changes what “engineer” has to mean, and what “product” has to mean, until the useful version of both is closer to one job than two org charts.

What compaction is not

It is not “fire the PMs” or “fire the engineers.” That fantasy is how you get confident diffs nobody can defend and product decks nobody can ship.

It is not “everyone becomes a prompt jockey.” Prompting without product taste and delivery accountability is just a faster way to generate review debt.

It is not staff aug with an AI sticker. Renting seats to close tickets was already the wrong product. Renting seats to close tickets through an agent is the same mistake with a higher token bill.

It is also not a claim that titles disappear tomorrow. Companies will keep printing “Product Manager” and “Software Engineer” on LinkedIn. Compaction is about the work that actually moves the system: one person (or a tiny pod) who can ask the product question, give the repo context, review the plan, and stand behind the ship. The org chart can lag. Reality will not wait for the reorg.

What I am changing

I write this from Omarchy, which has been my daily driver for about eight months. Mail still lives in Gmail in the browser across a few accounts. Calendar still lives in Notion Calendar. The boring substrate is not the thesis. It is a reminder that I will change the defaults when they stop matching the job. Role compaction is the same kind of default change, just for how teams divide labor.

What I am holding myself and my teams to:

1. Treat the brief as the deliverable. A vague ticket is no longer “good enough for engineering to figure out.” If an agent can act on the repo, a fuzzy brief becomes a fuzzy commit at machine speed. Write the problem, the constraints, the risks you care about, and how we will know we are done — before anyone asks for keystrokes.

2. Prefer product-shaped questions against the real tree. Risks, staging checks, customer impact, critical path, “what if we remove this.” Those questions used to require a meeting and a specialist. Now they can start as an agent pass against the branch, reviewed by a human who still owns the answer.

3. Keep review as the human job. Tests got cheaper. Blind trust did not. Plan mode then build mode is not ceremony. It is how you stop confident nonsense from becoming main.

4. Hire and promote for the compacted job. People who can hold customer reality and delivery craft. People who can brief an agent without abdicating ownership. People who multiply capacity instead of protecting a lane.

5. Stop scoring the week on ticket volume. That metric always lied a little. With agents it lies loudly. Score whether the system got clearer, whether the next change is safer, and whether the brief that started the work would still make sense to the person who has to operate it next month.

The brief is the job now

I used to think the hard part was getting the change written. Then I thought the hard part was getting the change reviewed. Last week reminded me the hard part is upstream of both: knowing what to ask, packing enough truth into the ask, and having the spine to reject a beautiful plan that solves the wrong problem.

Product and engineering are not merging because of a manifesto. They are merging because the agent made the old handoff look expensive. The titles can stay for a while. The job that matters is already one job. Write the brief. Give the context. Review the plan. Ship. That is the work. Everything else is costume.