Context engineering for people who aren't engineers yet

If you came to building from business rather than computer science, there's a piece of good news that the jargon hides: the skill that matters most when building with AI agents isn't coding. It's clarity — and you already do clarity for a living.

That skill has a name in this world: context engineering. It sounds technical. It mostly isn't. Let me strip it down to what it actually asks of you.

What context engineering actually means

Context engineering is the practice of writing down what your AI agent needs to know so it acts well — and putting that knowledge where the agent will read it.

That's it. Not prompts, not code. Knowledge. The decisions you've made, the way your project is put together, the things you've learned the hard way. An agent that has this acts like a teammate who's been on the project for months. An agent without it acts like a brilliant contractor on their first morning, guessing at everything.

The engineering part isn't writing software. It's the discipline of capturing the right knowledge, in the right place, in a form the agent can use. Practitioners now treat this as the core craft of working with coding agents — Martin Fowler's team frames the real work as managing what the agent sees, not coaxing it with clever phrasing.

Why the model isn't the bottleneck — clarity is

Here's the thing that trips up newcomers. You assume that when the agent gets something wrong, it's because the AI isn't smart enough. Usually it's the opposite — the AI is plenty smart and you didn't tell it what it needed to know.

Ask an agent to "add a discount to checkout" and it will build a discount — probably not your discount, because it doesn't know your rules. Percentage or fixed amount? Stackable? Who qualifies? You hold all that in your head. The agent holds none of it. So it invents something plausible, and plausible-but-wrong is exactly the failure that costs you a day.

Stuart Leo

The agent didn't fail because it wasn't clever. It failed because the thing in your head never made it onto the page.

This is good news. "Be clearer about what I want" is a problem you can solve. "Wait for a smarter model" isn't.

The three things worth writing down

You don't need a system. Start with the three kinds of knowledge an agent re-asks for constantly:

1. How the project is structured. What it is, what the main pieces are, where things live. The orientation you'd give a new hire on day one.
2. The decisions you've made, and why. "Discounts are percentage-only and never stack." "We use this payment provider because of X." The why stops the agent quietly undoing your choice later.
3. The traps you've hit. The thing that broke, and what fixed it. Write it once so neither you nor the agent rediscovers it cold.

Put each in a plain text file in your project. That's context engineering. No code required.

A worked example from zero

Say you're building a simple booking site. Before touching a feature, you write a short file:

This is a booking site for a yoga studio.
- Classes have a capacity. Never let bookings exceed it.
- Cancellations within 12 hours are non-refundable.
- Payments go through Stripe. Don't add other providers.
- Decision: no user accounts yet — bookings are by email only.

Four lines of plain English. Now when you ask the agent to "build the booking form," it already knows the capacity rule, the refund window, the payment choice, and the no-accounts decision. It builds your booking form, not a generic one. You didn't write code. You wrote clarity — and the agent did the rest.

Where to go next

The instinct from business is to think you need to learn to code before you can build. You don't need to learn to code. You need to learn to write down what you know so the agent can act on it — and then keep doing it as you go.

The bottleneck was never the AI. It was how clearly you told it what you know.

Start here: run your first session, see how to build with AI agents, or read context engineering, explained for the full picture.