Eight AI Builds in a Quarter: What the Reps Taught Me

Most pieces about AI in the editor are about speed. That framing misses the useful part. After a quarter of building with agents every day, the real lesson was not "more code faster." It was better problem decomposition: smaller briefs, tighter evals, faster prototypes, and more deliberate review.

Agentic engineering is a problem-solving method. It changes the unit of work from a large ticket to a precise brief. It makes the eval as important as the implementation. It forces the builder to decide what good looks like before the agent starts producing code.

Across Q1 2026, I used that loop on eight AI builds. Some were hackathon projects. Some were product experiments. Some became useful tools. The common thread was the same: start with a concrete problem, make the technical path explicit, and keep the review bar high.

The builds

Quick inventory. Each one taught a different technical lesson:

• Undervolt: local inference and GPU-accelerated civic data on Austin permits.
• RefereAI: vision reasoning for tennis line-call analysis.
• Sideline: simulation-first coordination across three virtual bodies.
• StudyPal: school inbox triage and homework support for parents.
• CoachClaw: a youth-sports coaching assistant inside Telegram.
• HD Research: an autonomous research workflow for Huntington's Disease drug discovery.
• Studio Copilot: a local-first AI workspace for photographers.
• Homenest: home-network monitoring with AI device detail and analytics.

Eight builds reached a real surface between January and March 2026, roughly thirteen weeks of calendar time. Some were tiny. One processed 2.2 million records on every refresh. The point was not the count. The point was the repetition: different domains, same disciplined loop.

That many reps made the patterns obvious in a way one big project would not have.

The problem-solving loop

Three habits mattered more than the tool choice.

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. Parallel work only helps when the seams are clean. Agents can run in parallel, but parallelism creates review pressure. The hard part is deciding which work stream gets which context, which eval defines done, and where outputs need to meet.

The useful lesson for other builders: do not parallelize everything. Split only where the interfaces are clear. Data ingest, UI, and eval design can often run separately. A tangled feature with unclear state usually cannot.

3. Review became the main skill. The agent can produce options quickly. The builder still has to decide which option is correct, which one is maintainable, and which one quietly misses the point.

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 others can reuse

A few lessons held across all eight builds.

Write the eval before the implementation. Even a rough eval changes the quality of the work. It gives the agent a target and gives you a way to reject plausible-looking output.

Keep briefs small. A good brief has a goal, constraints, inputs, outputs, and a definition of done. If the brief needs a page of background, the work probably needs to be split.

Preserve the decision log. The context you write down becomes reusable leverage. The context you keep in your head has to be re-explained every time.

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. It fails in ways that look like the AI's fault but are actually the orchestrator's fault.

Where the opportunity is

Three places stood out.

Local and edge AI are becoming practical. A Jetson under a desk can serve useful workloads. A GB10 can support creative tooling. Small models are good enough for more tasks than people assume.

Applied AI beats generic demos. The strongest builds had a real data source, a real user workflow, or a real constraint. Generic chat wrappers did not teach much. Systems with specific friction did.

Agentic engineering is strongest around bounded systems. Data tools, edge inference, research workflows, and internal automation all have clear inputs and outputs. That makes them good places to practice.

The first few weeks felt slower because the habits were new. Then the loop got clearer: brief, eval, build, review, write down what changed, repeat.

That is the part most pieces about this leave out. The tool is easy to install. The problem-solving discipline is the work.