Automations Aren't Designed, They Grow: From One Sentence to a Production Line

This is the third post in the getting-started-with-AI series. Part 1 covered how to set it up, and Part 2 covered how to talk to it and set up guardrails.

At the end of Part 2, I said: the hard part is never “how to ask,” it’s “how to design the workflow.”

This post will wrap up that statement. The answer might be the opposite of what you think: workflows aren’t designed, they grow.

The most common bottleneck: “I don’t know how to start planning”

I’ve been asked similar questions many times: “Your automation setup is amazing, how do I plan my own?”

Honestly, I’ve never planned it. Back in March, I only did one thing: I picked a small task I repeated every week, and told it to do it once.

Looking back today, my rules file, a dozen or so skills, a bunch of scheduled jobs—not a single one was designed in advance. Every single one of them only “upgraded” into its current form after I repeated the same task a few times.

So if you’re stuck on “not knowing how to start,” the good news is: you don’t need to figure it all out before you start, you just need to start small enough.

The opening move: be clear about these five things, skip the rest

Once you’ve picked that small task, be clear about these five things when you assign it. I didn’t invent this; it’s the official best practices condensed into a non-engineer version:

① Make your goal clear: what you want, who it’s for, what it will be used for. “Help me organize this transcript” isn’t as good as “Organize this into SOAP format, this is going into the EMR.”

② Only supply what it doesn’t know: your department’s conventions, your unit’s formats, the nuances only you know. Don’t teach the model what it already knows: you don’t need to explain what SOAP is, only what your department’s SOAP looks like. Every sentence of fluff dilutes its attention (the reasons are in the “Why it gets dumber the more you chat” section of Part 2).

③ State your boundaries upfront: which files it can’t touch, what things it needs to ask you about first. And don’t just state your real red lines verbally; the three-layer mechanism (hooks / permissions / CLAUDE.md) from Part 2 is exactly where these go.

④ Define “what counts as done”: this is the official number one recommendation, and the one I think has the highest ROI. Give it a check it can run itself:

• ❌ “Help me organize these transcripts”
• ✅ “After you organize them, check them yourself: every note must have four sections, every section must have content. Highlight what’s missing for me.”

⑤ Run a crappy version first: if you aren’t happy, change it with a single sentence. Iteration is always faster than trying to write it perfectly the first time.

That’s it. No need to draw flowcharts, no need to write specs.

How workflows grow: repeat it a third time, upgrade a level

Here’s the real point. Your “workflow” isn’t something you sit down and design one day; it grows according to a very simple rule:

When you repeat the same thing for a third time, move it up a level.

The difference between the three layers was covered in Part 2, I’ll just add one sentence here: putting it in rules makes it a suggestion; building it into a mechanism makes it a guarantee. The more important the boundary, the lower the layer it should live in.

This ladder has a hidden benefit too: every level is something you’ve already validated. You aren’t designing a skill out of thin air; you’re just saving a workflow you’ve “already successfully run manually three times.” Designs can be wrong; repetitions aren’t.

The habit of testing: the most important section of this post

Point 4 of the opening move (define “what counts as done”) is worth pulling out on its own, because it isn’t just one of the five things. It is the only habit in this entire method where “doing it or not doing it dictates how far you can go.”

Testing has three levels; build these habits in order:

Level 1: Single-run testing. Attach a checking method when you assign every task, letting it check its own work when done (“every note must have four sections, highlight what’s missing for me”). This is what the opening move taught.

Level 2: Re-runnable testing. Save the checks, turning them into a button you can press again anytime. The difference is huge: a single-run test guarantees “it did it right this time,” while a re-runnable test guarantees “changing things later won’t break it.” Engineers call this regression testing, but the concept itself has nothing to do with code: even if your check is just “count that every note has four sections,” as long as it’s re-runnable, it qualifies as testing.

Level 3: Test-driven. This is the workflow explicitly stated in the official best practices: write the check first, confirm that it currently fails, and then ask the AI to make it pass. It sounds like an engineering ritual, but translated into plain language it’s this: before starting work, show it a concrete example of “this is what it looks like when it’s done right.” It gets a goal it can iterate toward itself, and you won’t get to the end only to realize you had different things in mind.

Then there are three behavioral disciplines, just as important as the levels:

• A workflow without testing isn’t finished. Even if the check is bare-bones, you need one.
• “It says it’s done” doesn’t count, it only counts when the check passes. The AI’s tone when reporting success looks exactly identical to real success.
• Test failures must be stated loudly, they cannot be silently skipped. A check that didn’t run reads exactly the same as “checked and found no issues”; this is the most insidious kind of error.

Those of us working in hospitals should relate to this strongly: we’ve never relied on “everyone just being very careful”; we rely on checklists, dual-verification, and machine alarms. It’s the same for AI; you aren’t supervising, you are designing a workflow.

And re-runnable testing has an even bigger use. It’s your admission ticket to the next section.

The cost of growing: your project will become a patchwork house

Starting early, running crappy versions first, upgrading when repeated—this method has an inevitable side effect that will catch up to you sooner or later: your project grows by being patched together.

Every time you just ask the AI to “add a feature” or “fix one spot,” it really does just patch that one piece. Months later you look back, and there’s a chunk here and a chunk there, the same logic scattered across three places, and the whole thing doesn’t look like something that was planned; it looks like a house covered in patches.

Let’s be clear upfront: this isn’t a flaw in AI, this is the natural cost of “just getting it working first.” The software engineering world even has a specific term for this called technical debt: to go fast, you borrow time from your future self, and eventually you have to pay it back with interest. Human engineers have been writing code like this for decades; AI just amplifies the “building it fast” part, so the debt accumulates fast too.

The point isn’t to avoid debt (you can’t, that’s the price of starting fast), it’s knowing when you should pay it back. If any two of these signals appear, it’s time to pay off the debt:

• Changing A breaks B, and you can’t guess beforehand where it will break.
• The same chunk of logic appears in three places, so changing one spot means remembering to change all three.
• You start being “afraid” to touch a certain piece, stepping around it.
• The AI struggles more and more to patch it: every time it makes a fix, it has to spend a ton of time figuring out the previous patches first.

The way to pay back the debt isn’t to “ask it to tidy things up”; that’ll just add another layer of patching. You have to rebuild, in three specific steps:

1. Draw a map of the current state first: ask it to read the entire project and write an inventory of “what features are in here, how the data flows, where it’s messiest.” Don’t rush to make changes; see things clearly first.
2. Redesign based on the map, open a new version and migrate: don’t do massive rewrites in place (a massive rewrite in place = the biggest patch of all). Set up a new structure, and move the features over piece by piece.
3. Move one piece, run a round of testing, then move the next piece: this is the admission ticket mentioned in the previous section. Without re-runnable testing, rebuilding is a gamble; with it, you know at every step whether you broke anything.

I also have a very practical piece of advice: the moment of rebuilding is worth using the strongest model you have on hand. For everyday patching, a regular model is fine; but if you get structural decisions wrong, every subsequent step is built on a bad foundation. My own approach is: give the daily chores to the fast and cheap ones, and only bring out the strongest ones when touching the skeleton. This is also the most reasonable way to allocate your usage limits.

So, should you give it a map from the start?

Getting to this point you might think: since patching is inevitable, if I just plan the architecture out from the beginning, wouldn’t that solve the problem?

The problem is: the you on day one of a project is the you who understands this project the least. You don’t yet know which features will stay and which you’ll find useless three days later. The detailed designs you make at this point will mostly be wrong, and then you won’t want to throw them away (you spent so long drawing them, after all). This is exactly the trap that “run a crappy version first” is trying to avoid; don’t let it sneak back in through the back door.

The official workflow takes this stance too: split complex tasks into “explore → plan → execute,” but that “plan” is about confirming direction, not detailed design. Let it tell you what it intends to do first, you review it, and then it gets to work. Just at that level.

So my answer is a compromise: give it a light map, just one page, answering only three things:

• What this project exists for, and who it’s for.
• Roughly how many blocks it’s split into (e.g., data fetching, organizing, outputting).
• What things can absolutely never be mixed (e.g., patient data and code are always kept separate; source files and output files are separated).

Draw hard boundaries upfront, let the details grow. To summarize this section in one sentence: maps should be coarse, testing should be granular. Manage direction with a coarse map, manage quality with granular testing, and leave the middle for it to freestyle. That’s the most effortless balance I’ve found so far.

Instructions expire: deleting regularly is just as important as adding regularly

This final section is the one thing I wanted to talk about most in this entire series, and the thing least talked about by others.

“It gets one thing wrong, I add one line of rule”—this habit is completely correct in the short term (it’s exactly what Part 2 taught), but it has a second half that very few people mention: an AI’s instructions will expire.

Models get noticeably smarter about every six months. The rules you wrote half a year ago for idiot-proofing are very likely not only useless now, but actively holding things back:

• The official docs explicitly state: the longer the rules file, the lower the chance of any single rule being followed. Every idiot-proofing rule you add dilutes the few rules that actually matter.
• Newer generation models interpret instructions more literally. Those old-school safety phrases like “if in doubt, you must use X tool” will now just make it overuse the tool. The safety nets of the past become the bugs of today.
• Remember those tutorials from 2023? Assigning personas, anti-hallucination spells, manually pasting data. The three tricks I busted at the start of Part 2 were all “best practices” back then.

So you need to build a habit that mirrors “adding rules”: regularly go back and delete rules. The criteria for judging, in one sentence:

Does this rule exist because it can’t do it, or because I got burned in the past?

Keep the former. The latter? Take it out and try it once, nine times out of ten you’ll find it hasn’t been needed for a long time.

(Claude Code even has a built-in tool to help you do this: /doctor will proactively suggest deleting sections that “it can figure out just by looking at it.”)

By the way, it isn’t just your instructions that need regular slimming down, it’s your hard drive too. Agents generate a bunch of intermediate products while working: half-finished file conversions, downloaded caches, old versions from failed runs. If you ignore them, they’ll expand endlessly. One day when you find your computer inexplicably full, don’t dig through it yourself, just tell it directly: “My computer is too full, help me find things I can delete, list them out so I can review them before clearing.” Two key points: let it list them, you make the call; don’t let it decide what to delete on its own. And then write “where to put cache files, how often to clear them” into the rules file, and it will keep to it itself from then on.

Wrapping up

Stringing this post together, you get a complete lifecycle:

1. Start small enough: pick a small task repeated every week, be clear about the five things.
2. Upgrade repeated tasks a level: things said three times go into rules, things done three times get packaged into skills, things that can’t be wrong get handed to mechanisms.
3. Pair every workflow with re-runnable testing: it saying it’s done doesn’t count, checks passing counts.
4. Rebuild when it grows crooked: when signals appear, draw a current state map, start a new version and migrate, moving and testing piece by piece, and only bust out the strongest model at this point.
5. Go back and delete every six months: slash the rules added just because you “got burned in the past.”

Maps should be coarse, testing should be granular, and instructions should be slimmed down regularly.

What your workflow looks like in half a year isn’t designed today—it grows by writing an extra line each time, and deleting a few lines every six months.

That “small task” of mine in March was taking a folder of transcripts and organizing them into notes. Just a one-sentence thing.

What’s yours?

—