4 live 1 building on the bench: Pehra Pro, Snap Receipt last shipped

Muhammad Ahmed

Code Got Cheap. Judgment Didn't.

Notes on building software after the code started writing itself.

And 3 long reads, each working one idea through on a real project.

What's an engineer for, once anyone can generate code?

For thirty years the constraint was throughput: how many lines a team could write, test and ship before the money ran out. That constraint is gone. Code has been commoditised.

What's scarce now was always scarce. We just hid it behind the typing: knowing what to build, how the pieces fit, and when to say no.

1. The harness is the product

Why do smart models still ship dumb software?

Because a model is an engine, and nobody ships an engine. You ship a vehicle.

The harness is the vehicle: the spec the agent reads, the tools it can reach, the permissions it runs under, the memory it keeps, the review it has to pass, and the loop that catches the mistake before it reaches main.

A better model makes a good harness faster. It doesn't make a bad harness safe.

2. Agents need the whole picture

Most harnesses stop at the repository. The work doesn't. The crash is in Sentry. The reason is in the analytics. The decision is in the tracker, and the argument about it is in Slack.

An agent that can read all of those, through the connections the team already uses, knows what the colleague who was in the meeting knows.

That's the bet behind PRCHD's team lane: no integrations of its own, just every tool the agent can already reach.

3. Agents are the new traffic

Who's going to call your API next year?

Not people clicking buttons. Agents: yours, your customers', and ones you haven't met yet. They don't need pretty screens. They need:

  • Contracts. Typed APIs and MCP servers, not a UI to scrape.
  • Idempotency. Agents retry. Your backend must not charge the card twice.
  • Scoped identity. Per agent, per tool, revocable. "The bot has admin" is not a security model.
  • Budgets and rate limits. An agent stuck in a loop is a denial-of-wallet attack you wrote yourself.
  • Audit trails. Who did what, on whose behalf, and who approved it.
  • Errors a machine can read. "Something went wrong" is useless to a person. To an agent, it's an invitation to try everything else.

Frontends get thinner. Backends get heavier. A backend sized for two hundred people a minute will meet callers that run all night, retry on every error, and fan out in parallel.

Most of what I've built this year has a door for agents. Snap Receipt's connector and FieldAudit Pro's MCP server use scoped, revocable credentials, and tools that can't destroy data, because the code that would do it isn't there to call.

4. From reactive to proactive

An agent that only answers when prompted is a very expensive autocomplete. The next step is agents that notice.

  1. Notice. An agent reads product analytics and crash reports, and finds a drop-off in onboarding nobody filed a ticket for.
  2. Propose. It writes a feature proposal in the tracker, with the evidence attached.
  3. Share. It posts the link in the team's Slack channel.
  4. Approve. The product owner approves it, edits it, or kills it. One person, one decision.
  5. Plan. An agent splits the approved feature into tasks.
  6. Build. Coding agents take the tasks, each on its own branch, and open pull requests.
  7. Review. A reviewer agent goes through each pull request alongside a senior engineer. The agent catches the boring mistakes. The engineer catches the wrong ones.
  8. Verify. A QA loop runs the tests and the real app. Failures go back to step 6, not to a meeting.
  9. Ship. The feature lands, the analytics agent starts watching it, and the loop begins again.

Look where the people are: at the approval, at the review, at the ship button. Not at the keyboard.

How much of this runs today? In PRCHD, four of those steps run with no glue at all, and most of the rest is one recipe away. The step-by-step table is on PRCHD's page.

5. What happens to the team

So who do you hire?

People who can write a spec an agent can build from, and can tell when what comes back is wrong.

The senior job becomes designing the harness: the specs, the skills, the gates, the trust boundaries and the review. Juniors don't disappear. They learn faster than we did, because their first reviewer never gets tired.

But someone still has to decide what good looks like, write it down, and say no. That's the job now.

6. What doesn't change

So is engineering over?

No. Most of it matters more than it did:

  • Security still needs a mechanism, not a promise.
  • Somebody still owns the outcome.
  • Taste still matters. Agents will happily build the wrong thing, perfectly.
  • The boring disciplines matter more: tests, observability, rollbacks. There's far more code now, and most of it wasn't written by anyone who'll be there when it breaks.

7. What would change my mind

Where could I be wrong?

  • If models stop needing a harness. If an agent can be trusted on a production branch with nothing but a prompt, the harness becomes a commodity too. I haven't seen it. My own projects show the opposite most weeks.
  • If agent traffic stays a rounding error. If agents are still a small share of the calls to the backends I build by the end of 2027, then "backends get heavier" was early. Early is a cost too.
  • If proactive agents bring more noise than signal. If teams start ignoring agent proposals the way they ignore alert storms, the loop needs a better filter before it needs more autonomy. That's the problem PRCHD's next desktop view is designed around.

8. Long reads

Where's the long version?

Here. Each one takes an idea and works it through on a real project.

  1. Write It Down First

    How I build with coding agents, spec first, and the remote teams that taught me the habit.

    · 8 min read

  2. Conductor vs PRCHD: Move the Agent, or Move the Desk?

    Both run Claude Code and Codex in parallel worktrees. They split the moment you leave the desk.

    · 8 min read

  3. EntrenaPro — From Zero To Flutter

    A 40-screen app for iPhone and Android in four months, on Flutter before 1.0, and what I learned on the way.

    · 9 min read · First published on Medium

I'll update this page when the evidence changes. The Projects page is where it shows up first.