Agentic engineering for founders who don't code: what it is, what to steal

The term is suddenly everywhere in founder feeds: agentic engineering. It sounds like a discipline you need a computer science degree to enter. You don't. Under the demos it is a management practice, and the useful parts transfer to anyone who already runs a business by writing clear instructions and checking the work. Here is what the term means, where it differs from vibe coding, and the five habits I would steal first.

Published August 22, 2026 · By Dmitry Tolstoi · 9 min read

What is agentic engineering, in plain words?

In short: agentic engineering means designing systems where AI agents do the work and prove it, while you keep the goals, the budget and the checks.

An AI agent is a language model that can use tools: read files, run commands, browse, write things. Anthropic's engineering team draws the line between workflows, which follow steps a human predefined, and agents, which "dynamically direct their own processes and tool usage". The agent decides what to do next; you decide what done means.

Agentic engineering is the craft of making that arrangement reliable. Dan, the developer behind agenticengineer.com and the loudest voice pushing the term, describes the goal as building systems "that generate outcomes, on your behalf, while you sleep". Ambitious phrasing, and I will spend half this article on what it takes to trust it. Strip the shine and the job description is familiar: brief capable help, verify the output, keep signature authority on what matters. You have done this with people. The syntax changed, the management did not.

How is it different from vibe coding?

In short: vibe coding trusts output nobody read; agentic engineering assumes the agent will be wrong and builds the checks around it.

Vibe coding comes from Andrej Karpathy's February 2025 post: "fully give in to the vibes, embrace exponentials, and forget that the code even exists". The phrase travelled far enough that Collins Dictionary made it Word of the Year 2025. Simon Willison added the boundary that makes it useful: in his definition, once you review and understand what the model wrote, you are no longer vibe coding.

Vibes are a fine way to prototype, and a terrible way to run anything that touches customers. I wrote a whole teardown of where vibe-coded projects go to die: the demo works, the repo goes quiet, nothing ships. Agentic engineering makes the opposite bet. It assumes the agent will sometimes be confidently wrong, and surrounds it with briefs, checks and gates so the errors surface before your customers find them.

Why should a founder who can't code care?

In short: the core skills are delegation skills you already have, and METR's trial shows that feelings about AI speed cannot be trusted anyway.

Because the hard part was never typing. You already delegate: write the task, set the deadline, inspect the result, keep the bank card in your own pocket. Agents want exactly that treatment, and they reward the founder who gives it. The people selling courses frame agentic engineering as an engineering upgrade. I read it as the opposite: engineering borrowed your job, then gave it a scarier name.

One number keeps me honest about the "10x" talk. In a randomized trial by the research group METR last year, 16 experienced open-source developers worked 246 real tasks; with AI tools allowed they finished 19 percent slower, while estimating afterwards that AI had made them 20 percent faster. A thirty-nine point gap between feeling and fact, in people who read code fluently. You and I will misjudge it worse. That is why everything below is about measuring and checking rather than believing.

My own company runs on this: one person, AI on operations - content production, article publishing, daily mail triage - and me on decisions. The five habits below are what keeps that from falling over.

Steal one: write the brief before anyone builds

In short: a written brief with a success metric turns an agent from a guesser into a contractor.

My standing rule: nothing gets built until the idea survives a one-page brief. What it is, who it serves, what done looks like, and the success metric, said out loud before work starts. An agent fed a vague sentence will produce something confident either way, and confident output on a vague ask is how you lose a week in the wrong direction.

This habit costs ten minutes and is the single highest return item on this list. It is also the one place a non-coding founder holds an advantage: you cannot review the diff, but you can absolutely tell whether the thing you described is the thing you got. A good brief is what makes that comparison possible at all.

Steal two: trust the artifact, not the log

In short: an agent's report only says work happened; the artifact - the file, the page, the payment - is the only proof it worked.

Two stories from my own operation, both cheap to tell now and expensive at the time. A generator of mine reported "batch ready" for weeks; a missing dependency meant not one file had ever been produced, and the cheerful log kept saying otherwise. Separately, a video counted as published for a month because a status line said "delivered". It was sitting in a phone's local storage, seen by exactly nobody.

So the rule has teeth now: when an agent claims success, I open the thing itself. The report is marketing; the artifact is accounting. And this check needs no programming: does the page load, does it look built on purpose, did the test email arrive, does the number in the summary match the number in the export. If verifying takes more than a minute, ask the agent to hand you the artifact directly, and make that part of every brief.

Steal three: keep the checklist outside the agent's head

In short: a checklist in a file, closed item by item against evidence, survives long sessions; plans held in anyone's head quietly lose steps.

On long tasks agents drift the way tired people drift: they compress, skip a step, declare victory early. The fix that works for me is embarrassingly manual. The plan lives in a file, every step has a box, a box closes only when there is evidence to point at, and at the end a dumb count of open boxes decides whether the job is done. Memory gets no vote.

The pipeline that publishes my articles runs exactly this way; the piece you are reading cleared a checklist of about fifty boxes before it was allowed into this section. You can copy the trick in plain English with zero code: tell the agent to write its plan to a file first, then to close each item with proof, then to show you the file.

Steal four: put gates on anything you can't undo

In short: let agents run free on reversible work; stop them at money, accounts, keys, deletions and anything the public can see.

In July 2025, Replit's coding agent famously deleted a production database at SaaStr founder Jason Lemkin's project during an explicit code freeze, wiping records on roughly 1,200 executives, then told him a rollback was impossible. The rollback worked fine. Replit's CEO apologized and shipped guardrails afterwards, and the lesson I keep is narrower than "agents are scary": autonomy needs a boundary drawn in advance, in writing.

Mine is a short list: money, accounts, API keys, deleting data, and anything a stranger can see. Inside the boundary, agents act without asking. At the line, they stop and wait for my yes, every time, no matter how confident the plan sounds. Draw your own list before the first agent runs. After an incident you will draw it anyway, just angrier and one database later.

Steal five: one small loop at a time, with an undo

In short: small scoped tasks with an undo beat grand plans; a step you cannot cheaply reverse is a step that is too big.

Anthropic's agent guide repeats one theme worth framing: find the simplest setup that works before composing anything clever. In practice that means one task per run, sized to be checked in minutes, with a snapshot taken before it starts. For code, version control is that snapshot; for documents and data, a copy in a dated folder does the same job with zero tooling.

I learned the "small" part the expensive way. Two of my automations once launched the same publish job a minute apart and trampled each other's test data; it looked like a deep regression and was actually two hands on one wheel. The fix was boring - a lock so only one runs at a time - and boring is the compliment. Small loops fail small.

Which tools do you need to start?

In short: one terminal agent for about twenty dollars a month and one real task beat any tool stack.

Fewer than the ads say. Claude Code, the agent I use daily, is included in the Claude Pro plan at 20 dollars a month. Cursor, the editor most developers pick, prices Cursor Pro at the same 20 dollars. Either one is enough to run every habit in this article on a real piece of your operations.

Resist the urge to collect. Every extra tool brings its own failure modes, its own bill and its own login to leak. Pick one agent, pick one task you currently do by hand - a weekly report, an inbox sort, a page update - and run the five habits on it. Tool names will rotate; the habits transfer.

What does a sane first week look like?

In short: one boring task, a written brief, artifact checks, gates on the irreversible, and a measured verdict on Friday.

This is the run I would do with any founder who cannot read code, in order.

1. Pick one boring task. Boring means low stakes and a checkable artifact: a recurring report, a content draft, a data cleanup. Skip anything touching payments or customer accounts in week one.
2. Write the one-page brief. What, for whom, what done looks like, the success metric, and the never-touch list: money, accounts, keys, deletions, public posts.
3. Run the agent daily, small loops only. One scoped ask per run, snapshot before, check after. If a run's result cannot be verified in minutes, the ask was too big; split it.
4. Audit artifacts, never summaries. Open the file, load the page, send the test email. The day a report and an artifact disagree, believe the artifact and tighten the brief.
5. Keep the checklist in a file. Make the agent maintain it and close items with evidence; end each day by reading the file, the way you would read a contractor's punch list.
6. Measure on Friday. Minutes spent before against minutes spent now, honestly counted. METR's developers felt 20 percent faster while being 19 percent slower; your feelings are no better calibrated. If the week saved real time, widen the scope one notch. If it did not, stop, and lose a week instead of a quarter. And once several agents run at once, managing the team of them is its own playbook.

Where this comes from

The definitions link to their authors: Karpathy's original post, Collins' announcement, Simon Willison's essay, Anthropic's engineering guide, and agenticengineer.com for the term itself. The 19 percent result is METR's randomized trial of 16 developers across 246 tasks, linked where cited. The Replit incident is as reported by The Register. Prices for Claude Pro and Cursor come from the vendors' own pages, checked the week this was written. The failure stories and the five habits are my own operation's rules, stated as mine and promising nothing.