Every week, someone asks me whether they should learn to code.

Wrong question.

I build AI agents for a living, and here is what I actually see: the people getting the most value from these tools are not the ones who learned Python. They are the ones who already knew how to delegate work to another human, and figured out that the same skill works on a chat box.

If you have ever onboarded a new hire, briefed a freelancer, or written a contractor SOW, you already have the skill that matters in 2026. You just have not realised the new junior on your team does not have a name, does not take coffee breaks, and is sitting in your browser tab right now.

The ‘should I learn to code?’ question is a 2018 question

It was a reasonable question seven years ago. If you wanted software to do a thing, somebody had to write code, and a lot of office workers were quietly nervous that the somebody would need to be them.

That world ended quietly between 2023 and 2025. The AI systems that exist now write code on demand. They write better SQL than most analysts. They draft contracts, summarise meetings, build websites, and clean spreadsheets — not perfectly, but well enough that the bottleneck has moved.

The bottleneck used to be: can someone write this code?

The bottleneck now is: can someone clearly describe what they want the code to do?

That is a completely different skill. And it is a skill most knowledge workers already have, because they have been doing it with other humans for their entire careers.

When people ask me “should I learn to code?” what they usually mean is “I am scared of being left behind and I want a plan.” The plan they are looking for is not the one they are asking about.

What I actually see, building AI for a living

I build autonomous AI systems. I get a front-row seat to who extracts value from this technology and who does not.

The people who extract the most value are almost never the technical ones. They are lawyers who know how to write a clear engagement letter. Managers who know how to give a new hire a useful first task. Accountants who know how to brief a junior on a reconciliation. Founders who have written a hundred SOWs and know exactly what makes one work.

These people pick up an AI tool, write three sentences, and get a useful first draft back. They do not need to learn Python because they already learned the harder skill: how to describe a job so somebody else can do it.

The people who struggle, in my experience, are not non-technical. They are people — technical or not — who never developed the muscle of clear delegation. They write vague prompts, get vague answers, and conclude the tool is useless. Their colleagues who delegate well are getting work done in minutes.

This is the thing nobody says out loud: AI did not create a new skill. It made an old, slightly out-of-fashion management skill suddenly worth a lot more.

The actual skill: three sentences

Clear delegation, when you strip the management-book language off it, is three sentences:

  1. Here’s the job. What needs to get done, in plain language. Not the strategic context. The concrete output.
  2. Here’s what you have to work with. The inputs. The constraints. The information the other party needs to do the job.
  3. Here’s what ‘done’ looks like. The shape of the output. The format. The audience. The things that make this useful versus useless.

That is it. If you can hand a task to a junior consultant and they come back with something usable, you can do this. If you have ever written a job description that produced a hire who actually did the job, you can do this.

The interesting part is that the order matters. Most people skip step three, because with another human there is usually a feedback loop — the junior comes back, asks a question, you clarify, they redo. With an AI, there is also a feedback loop, but the round-trip is so fast that most people do not bother. They give a vague brief, get a vague output, and walk away annoyed. If they had spent one extra sentence describing what ‘done’ looked like, the first draft would have been 80% of the way there.

A decent rule of thumb: if you cannot describe what ‘done’ looks like, you do not yet understand the task well enough to delegate it — to a human or to an AI. The task needs more thinking, not more tooling.

You already do this every day

Look at how much of your existing work is already a delegation in disguise.

  • The lawyer. You hand a paralegal a 300-page contract and say find every clause that touches data residency, summarise each in one sentence, flag anything unusual, and give it back to me as a table by Friday. That is exactly the prompt that gets you a useful AI output. The same prompt.
  • The manager. You onboard a new hire by giving them a small, well-bounded first project: take last quarter’s customer feedback, group it into themes, pick the three biggest, and write a one-paragraph summary of each. You would not throw them at the entire feedback archive and say “figure it out.” You also should not do that to an AI.
  • The founder. You write a contractor SOW. Build me a landing page with these three sections, this brand colour, this CTA. Here are two examples of pages I like. Done means it loads in under two seconds and works on mobile. That SOW is already in the right shape for any modern AI tool.
  • The accountant. You hand a junior a reconciliation: match these 400 line items to invoices, flag the unmatched ones, and tell me which categories drove the variance. Same job description works on an AI assistant. The numbers are the same. The framing is the same.

You have been writing these briefs your entire career. The thing that has changed is who is on the receiving end.

A worked example

Let me make this concrete.

Suppose you are a marketing director and you want to draft an internal memo summarising three competitor announcements from last week. You could open ChatGPT and write:

“summarise these three competitor announcements”

You will get something. It will be generic, it will be slightly off-brand, and it will be missing the part that actually matters to your boss.

Now try the three-sentence version:

Here’s the job: Write a one-page internal memo summarising three competitor product announcements from last week and what they mean for our roadmap.

Here’s what you have to work with: [paste the three press releases]. Our product line is enterprise database tooling. Our CTO cares about positioning vs. open-source incumbents, not vs. cloud hyperscalers.

Here’s what ‘done’ looks like: A one-page memo addressed to the leadership team. Three sections, one per announcement, each with a two-sentence summary and a two-sentence “so what for us.” Plain prose, no bullet points, no marketing language. Tone matches a thoughtful internal Slack message, not a press release.

The second version takes about 90 seconds longer to write. It will get you a memo that is roughly 80% publishable on the first pass, instead of 30%. That delta — the difference between “useful first draft” and “useless mush” — is the entire skill.

No Python. No JavaScript. No prompt-engineering certifications. Three sentences.

When coding actually does help

I want to be honest about this, because the reframe is not “coding is useless.”

If your job is to build systems — to create the tools other people will use — coding still matters, and learning it is still a great investment. Software engineers, data engineers, analysts who build pipelines, and anyone whose job description includes the word “automation” should keep going.

The argument here is specifically for the much larger group: people whose job is to use systems to do their existing work better. Lawyers, doctors, accountants, teachers, consultants, managers, founders, salespeople, marketers, operators. For that group, the coding answer was always somewhere between “nice hobby” and “distraction.” Now it is more clearly the second one.

Learning to code costs months. Learning to delegate clearly costs an afternoon — and you have been practising it for years without realising.

What to actually do this week

Open whatever AI tool is already in your other browser tab. You probably have one. Most people I talk to are paying for a subscription they barely use.

Pick one task from your week that you would normally hand to a junior, a freelancer, or a contractor. Not the big strategic stuff. Something concrete. A first-draft document. A spreadsheet cleanup. A meeting summary. A research lookup.

Write three sentences:

  1. Here’s the job.
  2. Here’s what you have to work with.
  3. Here’s what done looks like.

Paste them in. See what you get back. Iterate the way you would iterate with a junior — no, more concise; no, keep this section but cut that one; no, the tone is wrong, here is an example of the tone I want.

The first time you do this, it will feel weird. By the third time, it will feel like a normal Tuesday. By the third week, you will look back at colleagues still asking “should I learn to code?” and you will know what they actually need to hear.

You already know how to do this. You have been doing it for years. The only thing that changed is that the new junior is already in your browser tab — and is willing to take another swing at the draft in thirty seconds.

Try the pattern this week. Then come back and tell me how it went — reply, comment, or hit subscribe and I will send the next one.