Start simple

I spent a whole night designing an ambitious visualization for a knowledge graph. Living, animated, a "brain" that lit up as it thought. It was going to be beautiful. Then I looked at what was actually shipped and it was nothing, because I'd been building the impressive version of a thing whose boring version didn't exist yet. I pulled the plug on the fancy one and shipped the boring one. The boring one is what's live and working right now.

That's the whole lesson, and I have to relearn it constantly: reach for the simplest thing that could work, and add complexity only when the simple thing has demonstrably failed. Not when the complex thing sounds cooler. When the simple thing has failed, with evidence.

When do you actually need an agent?

Less often than it feels like. A lot of what people reach for a multi-step agent to do is really one well-written model call with a clear instruction. The moment you add autonomy, loops, and tools, you also add failure surface, cost, and a debugging job that's an order of magnitude harder. Complexity isn't free and it isn't neutral. It's a tax you pay on every run and every 2am debugging session forever.

Anthropic's guidance on building agents is blunt about this: start with the simplest solution possible, and only increase complexity when a simpler approach falls short. They point out that for many use cases, a single optimized model call with retrieval or good examples is all you need, no agent required. (Anthropic, "Building Effective Agents") OpenAI's guide lands the same way: get a baseline working with a capable model and a simple setup first, then optimize, rather than architecting the cathedral before you've proven the shed. (OpenAI, "A practical guide to building agents")

The failure mode: building the thing you haven't earned

The trap isn't laziness. It's ambition. You can see the full system in your head, so you start building the full system, including the parts nothing is asking for yet. Then you're maintaining an orchestration layer to solve a problem a single prompt would have handled, and every future change has to route through machinery you built on spec.

The tell is when you're building infrastructure for a load you don't have and a use case you can't point to. If you can't name the specific thing that broke to justify the complexity, you're building on spec, and building on spec is how you end up with a beautiful system that does nothing.

The takeaway: simple until it hurts, then complex exactly where it hurt. The pattern has a name, YAGNI, you aren't gonna need it, and it's older than AI. AI just makes it cheaper than ever to build the thing you didn't need.

Questions that keep coming up

How do I know if I've over-built? Count the moving parts you can't tie to a real requirement. If a piece exists because it "might be useful later," it's speculative, and speculative complexity is the kind that rots.

Isn't starting simple just going to mean rebuilding later? Sometimes, and that's fine. Rebuilding a simple thing you understand is cheap. Untangling a complex thing you built prematurely is not. You almost always come out ahead starting simple, because the simple version teaches you what the complex version actually needs to be.

Next: Lesson 3, verify, don't trust. The review is the work now.

If you're formalizing your methodology after the messy phase and want to compare notes on what holds at production scale, /work-with-us.