Agentic Engineering: Be Unreasonable to Your Agent

Working with agents feels like your team suddenly grew. More commits, more reviews, more “wait, who changed that?”. Knowledge has to get out of a few people’s heads and get distributed, processes need to be established, you invest more into onboarding. Classic growing pains, every team that ever doubled in size knows them.

But that’s half of the story. This post is about the other half: the part where an agent behaves nothing like a colleague, and where being a nice, considerate teammate actually holds you back.

Where the team analogy breaks

Ask a colleague for ten variants of the settings page and watch their face change. Ask them to build something you plan to throw away next week, and don’t be surprised if your coffee mug goes missing. Humans pay for discarded work twice: once in hours, once in morale. And whoever built it gets attached, so suddenly you’re defending a design decision because somebody sweated over it.

An agent pays neither. It builds variant #7 at 2am with the same enthusiasm as variant #1, and it won’t bring up in the retro that you binned nine of them, again. Even better: you didn’t build them either, so you can judge them without any sunk cost goggles on.

We do this heavily for UI work. Instead of ping-ponging on one design, we ask for several at once:

Use /design to propose 4 variants for entering time tracking data, leveraging our SaaS UI library and existing SIMPL patterns and components.

Four variants on one comparison page, built from components we already have. Click through, pick one, bin the rest. Nobody sulks. 🎨

Thorsten Ball nailed it in a recent conversation:

You can ask them unreasonable things, and then take your time and do it on your own time.

So stop rationing. Asking for one option, avoiding speculative work, not keeping people busy overnight: great instincts for a teammate, terrible ones for an agent user. Today’s models are good. Be unreasonable with them.

A word on the bill, though. On a flat subscription the math changes completely, while pay-per-token can get really expensive. Skip it for decisions you can make right now, and for ideas way off the charts. You don’t have to token-max: being unreasonable is a tool, not a dogma.

Breadth first, depth first

There’s a great Latent Space piece on AI and mathematics that describes two ways to search for a solution. Mathematicians search breadth-first: sketch several directions, poke at each one a bit, drop most of them and commit to one or two. Fully developing an idea takes months, so it better look promising early.

Models flip this around and go depth-first. One run follows one idea all the way to the end, and nothing stops you from starting ten runs in parallel. Once a checker can verify a result in minutes, chasing long shots suddenly becomes the rational thing to do. Or, as the article puts it:

Humans are good at shrinking branches. Models are good at shrinking the time it takes to prune one branch.

Software engineering isn’t that different. We still start wide: sketch options, discuss them, kill the obviously bad ones in a meeting. But comparing the survivors on paper rarely settles anything. No RFC tells you how the ORM migration feels across 400 queries, or which edge case kicks the beautiful architecture in the shins in week three.

Agile promised that working software reveals those problems along the way. And it did! But you could only afford to walk one path. Now you can walk three.

Here’s a decision we actually faced. We wanted an assistant that answers questions about a customer’s own data. There were five ways to build it, and nobody could agree on one.

Same decision, both ways. Hit play:

Humans are smart and exit early on weak signals. It still takes longer, mostly because gathering the data to judge and staying focused take time. Days made up, and simplified: in reality the agents walked it in rounds (more on that below). Fun fact: our very first knowledge assistant actually did take the RAG lane, and we removed it in February 2026.

Sketch wide, build deep.

Looking into the futures

Remember Doctor Strange in Avengers: Infinity War? He looks into 14,000,605 possible futures to find the single one where they win. He doesn’t plan every future step by step. He looks at how each one ends.

Turns out you don’t need a Time Stone for that, a couple of cloud agents will do.

One catch: this only works so nicely because every future gets its own sandbox. Four agents in one working tree fight over files, ports and the database, and your laptop is ready to take off 🛫. Cloud agents give every branch its own machine, so the futures play out side by side without stepping on each other’s toes and you can go to bed.

Back to the knowledge assistant from the race. Instead of picking in a meeting, agents built the candidates to the end, and an eval scored the leaves. The knowledge graph died on paper: our database’s foreign keys already are the graph. And the agent with tools split once more: should its tools search snapshots, documents we pre-generate from the data, or the live data itself?

Click a node to follow its paths, or let the agents look ahead:

Real scores from the prototype’s eval, on synthetic data, so take them with a grain of salt.

We didn’t walk the whole tree in one go, by the way. We walked it in rounds, and each round’s handoff set up the next. More on that in the handoff below.

Look at the agent that writes its own SQL. The cheapest of the bunch, and on paper a powerful and interesting idea. Then the prototype’s red-team script went at it and got it to read another customer’s data. On fixture data, on a weekend, before a single line shipped, and without a meeting to argue about it. Dead branch for now. 🪦

Would a code review have caught it? Maybe, eventually. That’s exactly why we build prototypes: to find brittle isolation early, while it’s cheap. Finding it in production would be a very different blog post.

That’s my favorite part of this way of working: you don’t have to judge the intermediate steps, just the leaves. You don’t care how each prototype got there. You look at the end state and ask three questions:

• Does it work, and does it fit what we need?
• What broke along the way?
• Would I want to live with this design?

You answer the last one top-down. First the feel: does the result match your expectations? Then the big pieces: are they wired together the way you imagined, and are the numbers on your side? Only then do you zoom in, and with every level your picture of whether you’d want to maintain it gets sharper. You skip the “does this particular file look good?” question. That file is going in the bin anyway. Then building it right with the approved goal in mind worked very smooth for us.

Judging only the leaves stands or falls with the checker. In mathematics, depth-first pays off because a proof checker like Lean verifies the result in minutes. Without one, models happily produce convincing proofs that are plain wrong. Software needs that checker too, and you have to ask for it. In the tree above, the eval set and the red-team script were the checkers, and without them the SQL agent would have looked like the cheapest winner.

Make the agent prove it

Credit where it’s due: this one is Thorsten’s too. He calls one phrase among the biggest changes in how the Amp team works:

Give me irrefutable proof that this works now.

It hit home for us right away. We did the math recently: three people carrying a six-person team’s review load. Agents open more PRs than we can ever read line by line. And reading agent code line by line all day is nobody’s idea of fun.

So we asked ourselves where our judgment actually earns its money. It comes down to two questions:

• Does it nail the issue we actually have?
• Does it solve it the right way?

Checking every line of a CSS tweak isn’t one of them. Agents, tests and review bots are better at that pass anyway. Proof is the fastest way to exercise judgment on the two questions that matter.

Your agent can record a Playwright video of the flow, take screenshots with the changed area highlighted, run a test matrix across browsers or plot a load test. Let it do the convincing, so your precious review time shrinks.

At SIMPL, agent PRs now come with a proof page: a recorded video with step captions, screenshots, the log, and every acceptance criterion marked as shown, test-proven or not shown, with a reason.

Our first proof video was 128 seconds long, 90 of them login and idle time. Riveting stuff. 🍿 So the agent got a script: one take, captions, and a ring around whatever each screenshot is about.

Does that mean we stopped reading code? Of course not. Migrations, rights checks, anything near tenant isolation: those still get read line by line. But only those. And since you didn’t burn your attention on twenty non-critical files first, you read them with a fresh head instead of a tired one. Or in Thorsten’s words: “a CSS error is not the same as a broken database migration.”

One more thing we didn’t expect to matter this much: it just feels nice. A proof page with a short video and two honest “not shown” reasons is something you enjoy opening, 2,000 lines of agent diff on a Friday afternoon is not.

The someday list

Every team has that list: things we always wanted to try, but never found the time for. Ours looked something like this:

• Dark mode. Just for fun, nobody asked for it.
• Replacing the ORM. Not to migrate tomorrow, but to finally know how big the gap really is.
• Traffic we don’t have yet. Simulate new volumes and watch where things fall over. These runs take hours, so they go to cloud agents overnight, and the report is waiting in the morning.

Here’s what came out of it:

🌙 Dark mode was way easier than expected. Shipped.

🗄️ The ORM experiment showed our current one goes quite far, and “should we switch?” now has a trigger instead of a gut feeling.

📈 The load simulation showed enough headroom and three ways to improve (database, queries, caching). One is feasible today, the other two wait until we need them.

Notice that only one of those ended in a merge. Some of these tasks are basically doomed from the start, and that’s totally fine: the knowledge is the deliverable. It finally settles the discussion that comes up in every other retro.

Prototypes are prototypes

A working prototype pulls hard towards deployment. “It’s already done, let’s just merge it.” Don’t - resist. That’s how a fun experiment turns into a feature nobody planned or reviewed. Be prepared to kill your darlings.

We keep our prototypes honest with a setup like this:

---
title: "PoC → Handoff → Rebuild"
---
graph LR
    PoC["🏃 PoC agent
cloud, cuts corners"] -->|writes| H["📄 handoff.md"]
    PoC -.->|code stays behind| X["🗑️ bin"]
    H --> F["🧠 Rebuild for production"]
    F --> C["🔍 Compare"]
    PoC --> C
    C -.- note1["gaps & leaked shortcuts 🚨"]

The PoC agent cuts corners. On purpose. Push it to optimize for speed and learning: hardcode the config, skip error handling, skip tests outside the core question. Our PoCs usually run on cloud agents overnight.

A handoff/result is the real output, not the code. Think of an ADR with a field report attached. The one from the knowledge assistant’s could look like this:

# PoC handoff: How do we build the knowledge assistant?

## Answer
An agent with typed tools on live data, running on our own small loop. No RAG.

## Where to look
The prototype branches, their LESSONS.md, the eval set

## What we learned
- A prompt cache keyed per customer makes every answer ~40% cheaper.

## Shortcuts taken (do not copy!)
- Synthetic fixture data, graded by the same model family.

## Footguns
- Model-written SQL can be talked into reading another customer's data.

## Decisions and rejected alternatives
- Does RAG cut it? No: 60%, can't count or rank. Binned.
- Snapshots, live data or agent-written SQL? Live data, 93%.
  SQL failed the red team. Binned, lessons kept.
- Our own loop or a heavy framework? Own loop: same quality, much more weight.
  15,000 lines binned.

## Open questions
- A search engine for free-text questions, maybe later.

Five prototypes in the bin, nothing shipped, and a build plan. We walked it in rounds, and each binned round set up the next question. That’s the “negative hints” idea from the Latent Space article in practice.

We like to publish the handoff as a shared page instead of a markdown file buried in a branch. Colleagues can comment right on it, so by the time implementation starts, the plan has been through more heads than just yours.

A fresh session builds the real thing from the handoff. E.g. an agent can read the branch’s LESSONS.md and eval data, but it doesn’t build on top of the PoC. It starts fresh, so the shortcuts stay behind. It works under your usual standards: (plan), tests, review, like any other feature.

A third agent compares both. Did the final version address every footgun from the handoff? Does it behave like the PoC where it should? Did a shortcut find its way back in anyway?

Full disclosure: the diagram is tidier than reality. You can exit and compare early or get data only on some branches if you like. 

The gut check

Depth-first tests you as well as the tech. Once you see dark mode running across the whole app, or scroll through the diff of the ORM swap, you know pretty quickly whether you still want it. Do you actually have buy-in? Is it really as cool as you thought?

Some long-held ideas look worse once they’re built, and now you learn that for the price of a night of compute instead of a sprint. Others look way better, and then a working demo convinces the team faster than any ticket ever could.

Doctor Strange checked 14 million futures to find one that works. While you’re not Doctor Strange, you might have something pretty similar, and it’s only a few prompts away.  Use it.🔮

Takeaways

• Agents are a bigger team, partly. Commits, reviews and documentation scale like they would with more people.
• But they don’t have feelings about binned work. Ask for variants, proof and overnight runs you’d never ask a human for.
• Sketch wide, build deep. Prune the obvious branches on paper, then build the survivors to the end.
• Judge the leaves, demand proof. Evidence makes leaf-only review safe. Keep reading the load-bearing code.
• Prototypes are prototypes. Keep the handoff, rebuild with a fresh agent, compare with a third.
• Use the prototype as a gut check. If it doesn’t excite you once it’s built, it won’t excite anyone else.

Questions? Insights? Hit us up at engineering@simpl.de. We’re learning in public.

Resources

• Thorsten Ball on how the Amp team works with agents
• Latent Space: AI is getting good at math