i used to write code for a living. find the bug, fix the bug, ship the fix. that job still exists — it just moved downward. agents write the code now. what's scarce isn't the making. it's knowing what to make, why, and what constraints to set.
the work shifted from doing the thing to creating the conditions where the thing gets done well.
aristotle split knowledge into three kinds 2,400 years ago.
**poiesis** — the act of making. the code. the clay on the wheel.
**techne** — knowing *how* to make. your architecture decisions, your system design. the shape of the container before anything gets poured into it.
**phronesis** — practical wisdom. good judgment in messy, context-dependent situations. agents don't have this. they don't know your team, your users, or what you tried last quarter that failed quietly.
our role became techne + phronesis. we delegate poiesis downward. we are no longer the craftsmen. we are the condition-makers.
heidegger made a distinction in 1954 that matters more now: ancient techne was "bringing-forth" — coaxing something into existence. modern technology *challenges forth* — it extracts, demands, optimizes.
AI agents could be either. instruments of extraction, or instruments of bringing-forth. the difference isn't in the tool. it's in the condition-maker.
systems
building for agents is like onboarding a teammate. you don't hand them a task and walk away — you give them context. what we're building, why, what we've tried, where the landmines are. system prompts, memory architecture, folder structure — these aren't configuration. they're onboarding documents.
**the constraints are what enable agents to be proactive.** without boundaries, an agent either waits or drifts into chaos. with clear constraints, it has freedom — it can move fast within the walls you've set. more boundaries, more autonomy. the opposite of what people assume.
and when you limit the variables, you can actually see what's working. an unconstrained agent is a black box. a constrained one you can debug. constraints give agents freedom and give *you* visibility.
scaffolding
vygotsky's "zone of proximal development" — a learner needs temporary structure to cross the gap between where they are and where they need to be. once they've internalized the capability, you remove it.
that's agent architecture. prompts, examples, guardrails — scaffolding that lets an agent perform beyond its baseline. you're not making it smarter. you're creating conditions where its intelligence applies effectively. as models improve, you remove layers that were once necessary.
the inversion: agents scaffold *you* too. they handle the making, which frees you to operate at the level of judgment and taste. the freed time isn't empty — it's filled with higher-leverage thinking. if you design it that way.
leverage
donella meadows identified twelve leverage points in systems, from weak to powerful. weakest: adjusting parameters. strongest: changing the paradigm the system operates under.
most people are adjusting prompts and tweaking temperature. low-leverage. the high-leverage work is structural — architecture decisions, feedback loops, the rules governing what agents can and can't do.
condition-makers operate at the level of the system that *produces* outputs, not the outputs themselves.
the gardening principle
you don't *make* a garden grow. you create conditions — right soil, enough light, protection from what would destroy it — and then you tend. that's what working with agents feels like when it's working well.
the gardener resists pulling the plant up to check the roots. the condition-maker resists micromanaging every output. you trust the process because you designed the process to be trustworthy.
and like gardening, the compound effects take time. by the third month, the system produces things you didn't explicitly plan for. that's when the architecture is working.
the anti-scaling instinct
everyone wants ten agents. i ran ten. it was chaos — couldn't debug, couldn't attribute outcomes, spent more time managing the system than it saved me.
so i scaled back. one agent. clear boundaries. tight feedback loops. once i understood why it worked, *then* i added a second. the discipline isn't building more — it's understanding what's already built.
phronesis isn't just knowing what to build. it's knowing what *not* to build yet.
delegation is not abdication
most people "delegate to AI" by throwing a task over the wall and hoping. that's abdication. real delegation means defining the outcome, setting constraints, establishing a quality bar, designing the feedback loop.
AI saves you from *doing* but demands more from your *thinking*. the condition-maker's skill ceiling is the system's ceiling. the bottleneck is never the agent. it's you.
context as a compounding asset
the context you build over time — memory files, documented decisions, encoded failures — becomes a compounding asset. anyone can spin up an agent. not everyone has six months of context feeding into one.
the new moat isn't the model. it's the accumulated context that makes your system yours. the longer you tend the garden, the richer the soil.
what gets lost
when you delegate poiesis downward, you lose something. a carpenter who never touches wood loses feel. an engineer who never writes code loses the intuition that comes from debugging at 2am.
this isn't a reason to reject the shift. but it's a reason to be intentional. still get your hands dirty sometimes. still write the code yourself — not because it's efficient, but because it keeps your instincts alive.
the condition-maker who has never made anything is just a manager. phronesis stays sharp only if you occasionally practice the poiesis.
three months ago i was running ten agents, managing someone else's company, wondering why i was exhausted. so i shed it. scaled back to one agent. left the job. started building my own architecture.
the first thing i noticed: the silence. not empty silence — *generative* silence. the kind where ideas grow because they finally have space.
we don't write code anymore. we write the conditions where good code emerges. and the best condition-makers remember what it felt like to make.
*the engineer's codebase is no longer functions and classes. it's system prompts, architecture, tool boundaries, constraints. that is the work now. that has always been the work. we just couldn't see it when our hands were full.*