Senior developers have spent a lot of time figuring out, the hard way, how to work well with AI. Most of that learning has nothing to do with code. It’s about how any knowledge worker should think before handing a task to a model. Here are six of those practices, translated for marketers, writers, and anyone else who delegates work to AI.
Don’t always use all of them. Learn them, then cherry-pick whichever one fits the task in front of you.
Lingo
Before we jump in, since this post is written for a wide audience, let’s agree on the meaning of a few terms used below.
LLM / Model - LLM and Model mean the same thing here: Large Language Models, trained at real cost in power-intensive labs. That cost is exactly what makes them capable of tasks a human would otherwise do.
Agent and Agentic workflow - Chat means you send a prompt and get a reply. An Agent goes further: it can run commands, edit files, and search the web. It doesn’t just answer, it acts. Give it a goal and let it run on its own, and that’s an agentic workflow.
Context - everything the model sees in one request: your prompt, the conversation so far, and any files you feed in. It has a fixed size limit, once full, older content gets dropped to make room. Nothing carries into a new session unless something, like a memory file, re-adds it.
Session - one continuous conversation with its own context, independent of other chats. Nothing carries from one session to the next unless you bring it yourself: a memory file, a pasted summary, a re-stated spec.
1. Build fundamentals and understanding first
The shift is clear: we’re moving from doing the labor ourselves to overseeing it. To oversee something, you really have to know what you’re building. You need the fundamentals in whatever you do. If you have them, the model works as a force multiplier: delegation goes smoothly, and any gaps in the spec that get filled with nonsense or hallucination are less costly, because you catch them early.
Eroding fundamentals works against you. The model will sound smart and convince you, every time, to go in the wrong direction.
Equally important: before you ask the model to do anything, sketch your own guess of what the answer should look like. Drawing a diagram on paper is a good starting point. Then compare it to what the model actually produces: for a programming task, ask it for a sequence diagram of how the code works right now; for a marketing task, ask it to map out how your email campaign works today. The gap between your sketch and its diagram is exactly where your understanding is thin, and now you know where to focus.
This is the most important step. It has given me a lot of benefit in the past, and caused a lot of problems whenever I ignored it. Every practice below depends on it. Because it matters so much, I start every task from an empty note with the same recurring sections: “How it works right now,” “Architecture,” “Goals,” “What I need to learn.”
A marketer who always starts from an AI-drafted campaign never builds the instinct for what a good campaign structure looks like. They lose the ability to catch a subtly wrong offer or an off-brand tone, and that instinct is exactly what their oversight role depends on. We’re overseeing the model every single day, so it’s a core responsibility, not a one-off check.
For the same reason, a developer who never writes code loses the ability to spot a subtly wrong abstraction, an overcomplicated decision, or a silly fallback that makes the code more expensive to run, harder to maintain long-term, and more error-prone.
2. Spec driven work
Once you trust your own understanding, the next step is putting it into words the model can act on. Before an interaction with an LLM or Agent, especially when the task is complex or multi-step, it’s a healthy habit to write down what you actually aim for.
In a software development context, here’s a small example:
# Split view
## GOAL
I see a unified view of my strong deadlines (tasks with due dates), **together with** softer notes with bullets or
checkboxes which are adequate for the chosen day
## CONSTRAINTS
- Relevant things for a day in terms of notes, maybe current week, current month, current year (stacked view)
- Must look good on mobile
- We must not reinvent the wheel
## AC
- No tasks, today note
- Today tasks, no today note or anything else
- Today tasks + today note
- Today tasks + today note + this week note + this month + this quarter + this year note
- All of them on mobile, small screen
It can be easily translated to other professions. Let’s take marketing:
# q3-customer-win-back-email.md
## Goal
Draft a win-back email campaign for customers who churned in the last 90 days.
## Constraints
- Must use existing brand voice guide (see `brand/tone-guide.md`)
- Offer: 20% discount, valid 14 days, no other discount structures
- Must reference GDPR-compliant unsubscribe language (see `legal/email-footer.md`)
- Max 150 words body copy, one clear CTA
- Do not reference competitor names or pricing
## Acceptance criteria
- Subject line A/B variants (2), each under 50 characters
- Body copy passes brand tone check (no exclamation-heavy, no "hey there!")
- CTA links to /reactivate landing page, not homepage
- Includes required legal footer verbatim
There are several reasons behind this technique. We often don’t know exactly what we want. We leave gaps. When we delegate to a human, that’s not a big deal, because a human will follow up and ask. In the AI world, leaving gaps means the agent guesses and fills them itself, which can be a terrible choice.
Without a spec, you only spot that something’s off once the agent finishes. That means more back-and-forth, and some frustration.
Writing the spec also gives you a broader view of things you never thought about before, which can itself trigger improvements to what you’re building.
The path from spec to execution gets standardized too. Over time, a good spec and a bad spec become obvious. Other people on the team can learn from them, learn how to write their own. If something didn’t work well, you can always go back to the spec and improve it for next time.
And that’s exactly where you get differentiation. Different people using the same tool can produce wildly different results, because more experienced people know what to specify and what not to leave for the model to guess. A strong spec turns the model into a real force multiplier. A weak one just makes a mediocre brief sound smarter while staying useless.
A lot of the AI slop out there comes from a mediocre “we just need to use AI and push it to users” attitude, with no UI/UX or user thinking behind it. It all comes down to a broken spec, or no spec at all.
Personally, I’ve always regretted skipping the spec on a complex feature. The things that came up as I went could have been thought through beforehand, saving me a lot of time and frustration.
3. Context engineering
A good spec tells the model what to build. Context tells it how to think about the problem. Before delegating, it’s often a good idea to warm up the agent. Picture an infinitely long knowledge tree with lots of branches to different concepts. By asking questions or giving instructions first, you climb toward the cluster of expert knowledge you need to complete the task.
Example:
read spec/sqs-retry-backoff.md, common/retry/RetryPolicy.scala, and SqsConsumer.scala. Don't touch anything else yet -
summarise the integration points you'd touch.
Or, in the marketing context:
Read spec/q3-customer-win-back-email.md, brand/tone-guide.md, and the last two win-back campaigns in
campaigns/2026-q1-winback.md and campaigns/2025-q4-winback.md. Don't draft anything yet, summarise the tone patterns and
offer structures you'd follow, and flag anything in the spec that conflicts with what worked before.
Just like with spec-driven work, gaps get filled in silently by the model. Here, the gaps are about how the model reasons through, or thinks about, the problem.
Without curation, the model guesses which parts of a document matter. The key difference comes from cherry-picking the highest-signal information and feeding only that to the model.
Reading and summarizing is bread and butter for what models do best. It’s a cheap step that gives a lot of benefit before the expensive one.
Context sets boundaries. If you don’t specify them here, you just push the problem to a later stage, where it takes more time to fix, because the model can already have “turned” toward the wrong assumption.
4. Delegation over autocomplete
With a spec and context in place, you can finally hand over real work instead of babysitting autocomplete. Current models can chain more tool calls in a row without derailing than they used to, which is what makes multi-step, automated work realistic now, not just a longer chat reply. That doesn’t mean you switch off, though. The more freedom you give the agent, the more oversight the outcome needs, especially while you and the model are still figuring out what “done” looks like for this specific task.
Example:
fix BUG-123 per AGENTS.md bug-fix workflow:
write a failing test that reproduces it, implement the fix, run the full test suite, create branch fix/BUG-123 locally.
Don't push. Report back once green, or sooner if you hit something that needs a judgment call.
Or a non-dev example:
Draft the win-back campaign per spec/q3-customer-win-back-email.md and marketing/AGENTS.md: two subject line variants,
body copy, checked against the brand tone guide and required legal footer. Save as a draft in the shared folder. Don't
send. Flag anything that doesn't meet the acceptance criteria before I look at it.
Models are good at following multi-step instructions. This step should come after you’ve defined the spec and the context, because you’re giving the model a lot of freedom here. Curation happens at this stage: filtering and reformatting the output.
The reasoning behind this practice is that you’re the most expensive resource. Stop switching context, and stop being the bottleneck.
Just like in code, you can build in iteration: specify KPIs for the task, let the model try a few approaches, run them against your criteria, and only report back once it finds a winner. This forces the model to check its own output, which is always a good idea, because it learns from that feedback where the right solution is.
Try three different subject line styles for the win-back email: urgency, curiosity, and plain benefit-led.
Score each against the brand tone guide and predicted open rate. Only show me the highest-scoring one,
with your reasoning for why it beat the other two.
5. Multi-agent orchestration
Once delegation feels safe on one task, the next step is running several at once. You can also do work in parallel, as long as it can be split into independent pieces.
# Agent 1: worktree A
review spec/sqs-retry-backoff.md PR against acceptance criteria, flag anything missed
# Agent 2: worktree B
add CloudWatch alarm for DLQ depth > 0 to terraform/cdp-ingestion, follow existing alarm module pattern
# Agent 3: worktree C
investigate flaky test KafkaConsumerSpec.scala line 84, find root cause, don't fix yet, report back
And a non-dev example:
# Task A: campaign review
review the win-back email draft against spec/q3-customer-win-back-email.md acceptance criteria, flag anything missed.
Don't send.
# Task B: new content, context-first (same fix as Thursday's Agent 2)
read hr/careers-page-style-guide.md and two recent job posts in postings/2026-*.md. Summarise tone and structure
conventions before drafting anything.
# Task C: investigate, don't fix
look into why the Q2 churn number in last week's board deck doesn't match this week's dashboard. Find the discrepancy,
don't correct either document yet. Report back.
As long as the tasks are independent, there’s no reason to run them one after another. In an agentic workflow, the human is the bottleneck. Multi-agent orchestration pushes that bottleneck as far downstream as possible. This is especially useful when the tasks are mundane, boring, and simple to verify.
There is a limit to this practice. If your tasks aren’t independent, or they’re involved and need multiple iterations, it’s much better to focus on one and do it well than to jump back and forth.
Another place this method shines: tag tasks as candidates the moment you spot them, a #parallel-ok label in your task
tracker, a comment on the ticket, whatever you already use, so you don’t have to re-scan the whole backlog every time
you have a few idle agents.
6. Project memory files
All of this repeats across sessions, unless you find a way to make it stick. Models don’t have memory. They behave like they do only because they store some things in files from time to time. If you work in the filesystem in an agentic workflow, a common practice is to create an AGENTS.md or CLAUDE.md file. The agent reads this file at session start, or whenever it’s referenced, and treats it as high-priority context. The expected filename differs depending on which model you use.
For software development, this file can hold conventions, gotchas, and standards your company follows.
Example:
## Gotchas
- SqsConsumer retries: use RetryPolicy typeclass, never Thread.sleep (breaks IO referential transparency, caught in
review 2026-09)
- Terraform alarm modules: always check `terraform/modules/alarms/README.md` before adding new alarm blocks, naming
convention matters for dashboards
- KafkaConsumerSpec flakiness: root cause was test ordering dependency, not the consumer itself, see PR #412
And for a non-dev example:
## Gotchas
- Win-back campaigns: always check campaigns/2026-q1-winback.md for the discount used last cycle before proposing a new
one, legal flagged offers above 20% in Q1, caught in review 2026-03
- Job postings: always check hr/pay-band-language.md before drafting compensation ranges, generic phrasing like
"competitive salary" gets rejected by compliance, use the exact pay-band template instead
- Q2 board deck churn discrepancy: root cause was two teams pulling from different dashboards (Salesforce vs. product
analytics), not a calculation error, see thread in #finance-reporting 2026-06
As you can see, this helps other people on the team too. It speeds up all the previous steps, because you’re teaching the model how to navigate your knowledge graph for a particular type of task.
None of these six practices work in isolation. Fundamentals are what let you judge whether the output is any good in the first place. Everything else, the spec, the context, the delegation, only pays off once you can tell a good result from a confident-sounding bad one.
These habits started with software engineers, but they apply to any work you do with AI.