Eight Products in a Quarter: What Agentic Engineering Actually Changed

Most pieces about AI in the editor are about productivity. "We ship 30% faster." "PRs land in half the time." That framing is true and uninteresting. The real change is bigger than that, and it took me from October 2025 through March 2026 — six months of running it daily — to articulate.

Agentic engineering doesn't make engineers faster. It changes the shape of the company. Specifically, it changes the unit of work, the relationship between headcount and output, and the kind of decisions you spend your day making. The productivity number is a side effect.

This is what happened across Q1 2026 at AISOFT — eight products live, real users on each — and what I'd tell anyone trying to figure out whether to invest in this seriously.

What we shipped

Quick inventory. Each of these has paying or near-paying users:

• Undervolt — GPU-accelerated urban data intelligence on Austin permit data. Won NVIDIA DGX AITX. Running locally on a Jetson.
• RefereAI — Cosmos Reason 2 making line calls in tennis. Submitted to NVIDIA Cosmos Cookoff.
• Sideline — Three robots, one inference loop. Built at Nebius.Build SF.
• StudyPal — School inbox triage and homework support for parents.
• CoachClaw — Youth-sports coaching agent on Telegram. Submitted to GTC Hack for Impact.
• HD Research — Autonomous research agent for Huntington's Disease drug discovery.
• Studio Copilot — Local-first AI workspace for photographers. Won GTC Raw to Curated.
• Homenest — Home-network monitoring with AI device detail and analytics.

Eight live products, eight active user bases, between January and March 2026 — roughly thirteen weeks of calendar time. Two engineers, three on the busiest weeks. Some of these are tiny; one of them processes 2.2 million records on every refresh. None of them are throwaway.

For comparison, the last team I ran shipped two production products in six months. Roughly the same headcount.

What changed

Three structural changes drove the difference. None of them are about the IDE.

1. The unit of work shrank to a brief. Before, my day was full of tickets — half-page descriptions of features, with attached implementation guidance. Now my day is full of briefs. A brief is a paragraph. It states the goal, the constraint, the input format, the output format, and the eval. A brief takes thirty seconds to write. The implementation that follows is fifteen to forty minutes of agent work, sometimes parallel across two or three sub-agents.

The key insight: a brief is a contract, not a description. The eval defines done. The agent doesn't return until the eval passes. I'm not reviewing implementation choices; I'm reviewing whether the brief was right and whether the eval caught what I needed it to.

2. Headcount stopped being the lever. With agentic engineering, the team's bottleneck isn't lines per hour. It's orchestration discipline. How many parallel work streams can you keep coherent? How well can you write briefs? How fast can you tell good output from bad? Those are the things that scale, and they scale per-person, not per-engineer.

A 2-person team running parallel agents on three streams beats a 5-person team running serial agents on one stream every time. I've watched this play out at hackathons and at our own product work. The 5-person team feels productive — there are always five people coding. The 2-person team is what actually ships.

3. The decisions moved up. I used to spend my day on implementation choices. Should this be a class or a function? Where does this validation live? Now I spend my day on eval design (what does done look like for this brief?), orchestration design (which agent does which part, in what order?), and taste calls (which of these three implementations is the one we keep?).

That's higher-leverage work. It's also harder. You can't fake your way through eval design — if your evals are bad, your agents produce mediocre code that passes the wrong tests. The discipline that used to be optional is now mandatory.

What this means for hiring

The roles in an agentic team are different.

You need more orchestrators — people who can run three parallel agent threads, hold the architectural picture in their head, and review for taste. You need more eval engineers — people who can specify what "working" means with enough precision that the rest of the team can build against it. And you need senior judgment everywhere, because the cost of a bad brief or a bad eval is far higher than the cost of any single mis-step in the work itself.

The companies that will thrive at this aren't the ones with the most engineers. They're the ones with the right kind of engineers, and a leadership team that understands that "AI in the editor" isn't a productivity tool — it's a re-org.

I'd guess we're maybe 24 months from "agentic-native" being a hireable trait that recruiters screen for. Right now it's still niche enough that the people who are good at it are mostly self-taught and clustered in a small number of teams.

What this doesn't change

It does not change the importance of taste. Anything but. When agents can produce three implementations of the same brief, the question of which one is right becomes the dominant question. Without taste — without a strong opinion about what good code, good UX, and good product feel like — you end up shipping the agentic equivalent of slop. Beautiful, executes correctly, mediocre.

It does not change the importance of distribution. Eight products in a quarter is a lot of building. Most of those eight will need their own marketing, their own user research, their own sales motion. The build accelerates. Everything around the build does not.

It does not eliminate engineering judgment. It moves it. The judgment now lives in the brief, the eval, and the orchestration plan. When those are weak, the system fails — and it fails in ways that look like the AI's fault but are actually the orchestrator's fault.

What I'd tell a CTO considering this

Three things.

You can't dabble. A team running 20% agentic and 80% manual will see 20% of the gains. The orchestration discipline is a different skill from manual coding, and it has to become the team's default mode for the gains to compound. Pick a project, commit a quarter, run the team agent-first, see what happens.

Pick the right project. Not the most important one. The one with the cleanest evals. Greenfield products, well-bounded tooling, internal automation that nobody loved writing — those are agentic engineering's sweet spots. A 250K-line legacy monolith with weak tests is not where you start.

Invest in the eval infrastructure. It's the part everyone wants to skip and the part that defines whether agents ship good work. Spend a week early on getting evals first-class — CI integration, fast feedback, real test data. The compounding starts there.

The first quarter we ran agent-first, the team felt slower for two weeks. We were rebuilding habits and the muscle memory wasn't there yet. By week four it was clearly faster. By week eight it was a different kind of company.

That's the part most pieces about this leave out. It's a transition, not a tool installation. Plan accordingly.