The Edges, Not the Middle: Where AI Belongs in a Task

Somewhere in the second day of a course we ran for a client's technical team, a support engineer said the thing that reorganised the rest of the week. She had been trying to get an assistant to diagnose a recurring fault, without much success, and she put down her laptop and said: it is fine at the beginning and the end. It is useless in the middle.

She was right, and it turns out to be the most portable rule we have found. Every task has a middle. The middle is where you earn your salary. Everything either side of it is fair game.

The anatomy of an ordinary task

Take any piece of work you did this week and it will have roughly three parts.

There is a front edge: gathering what you need. Finding the previous version, reading the log, pulling the figures, remembering the syntax, setting up the scaffolding, writing the parts you have written forty times before.

There is a middle: the decision. Which approach, given what you know about this business, this customer, this deadline and the thing that broke last March. This part is usually short. It is almost always the reason you were the one doing the work.

And there is a back edge: making the decision usable by other people. Writing the tests, formatting the output, documenting what changed, drafting the note to the client, preparing the version of the explanation that a manager will read without their eyes sliding off it.

When we did the twenty-minute audit with that team, the middle came out at a fraction of the day. Not because they were unskilled — the opposite. Experienced people reach the decision quickly. What takes them time is everything wrapped around it.

Why the edges are safe and the middle is not

The edges share a property that makes them ideal to delegate: you can tell instantly whether the result is right.

If you ask for the boilerplate and it comes back wrong, you know within seconds, because you knew what you wanted before you asked. If you ask it to reformat a table, or convert a query, or draft the covering note, you are evaluating against a standard you already hold. The failure mode is visible and cheap.

The middle has the opposite property. If you ask for the decision, you are asking precisely because you have not made it — and so you have nothing to check the answer against. What comes back is fluent, structured and confident, and if it is subtly wrong about your business you will not notice until it costs something. The output looks the same either way. That is the trap.

Delegate the parts where you would spot a bad answer immediately. Keep the parts where you would not.

What this looks like by role

The rule survives contact with very different jobs, which is why we keep using it.

For a developer, the front edge is scaffolding, test fixtures, regex nobody enjoys writing, and translating a stack trace into a hypothesis. The middle is choosing how the change should be structured given what else is coming this quarter. The back edge is tests, the commit message that explains why rather than what, and the note in the release. There is real gain at both ends, which is roughly the picture we drew when we looked at what AI-assisted development actually changes.

For an analyst, the front edge is getting the data into shape and remembering the window function. The middle is deciding what the number means and whether it can be trusted. The back edge is the chart, the caveats and the paragraph the executive will read instead of the chart.

For a systems administrator, the front edge is reading the vendor documentation and drafting the config. The middle is deciding what the change risks at four on a Friday. The back edge is the runbook, the rollback note and the message to the business explaining the maintenance window in words that do not require a diagram.

For a support engineer, the front edge is finding the three previous tickets that look like this one. The middle is working out what is actually wrong. The back edge is the reply, in a tone the customer will not read as dismissive, and the article that stops the next person asking.

The most undervalued edge is translation

If we had to name the single highest-return use we saw all week, it would not be code generation. It would be moving something between forms without changing its meaning.

A dense technical finding into an email a non-technical manager acts on. A rambling requirements call into a numbered list you can argue with. A log file into a description of what happened. A specification into a test checklist. A customer's frustrated message into a clear statement of the actual problem.

Technical people tend to undervalue this because it is not the hard part. It is, however, an enormous share of the working day, and it is the part most likely to be skipped when things get busy — which is exactly why documentation goes stale and why the business believes IT never tells it anything. Give that edge to a machine, review it in ninety seconds, and a chronic organisational problem quietly gets smaller.

The failure mode, in one sentence

The way this goes wrong is not dramatic. Nobody makes a reckless decision. Somebody simply asks the assistant the question they were supposed to answer, gets a reasonable-sounding response, and — with no particular moment of choosing — ships it.

The test we gave the team is deliberately social rather than technical: could you defend this in a meeting tomorrow, out loud, without the tool open? Not recite it — defend it, including the part where somebody senior asks why not the other way. If the answer is no, you have handed over the middle, and the fact that the output is probably fine is not the point. You will not know when it is not.

Where the edges are widest

Two practical observations from the week, both of which surprised the people they applied to.

First, the more senior you are, the wider your edges. Seniors reach decisions fast and then spend hours on the packaging: the write-up, the board summary, the handover, the explaining. That is a large edge attached to a very short middle, which makes senior people the biggest beneficiaries in most teams — and usually the last to try.

Second, unfamiliar work has almost no usable edge at all. When you do not yet know what good looks like, everything is middle, because you cannot check anything. That is the case for doing new things the slow way at least once, and it is the argument behind the competence trap — the lesson from that same week that a manager has to plan around rather than hope about.

The honest summary

Aim at the edges. They are wide, they are safe, they are most of your day, and the results are verifiable in seconds. Keep the middle, because it is short, it is the reason you are in the room, and it is the only part that cannot be checked by looking. Do that consistently and the change is not that you produce more work — it is that a larger share of the work you produce is the part that actually required you. That is a better deal than the one most people are currently getting from these tools, and it does not require a single clever prompt.