Thriving in the Age of Artificial Intelligence

Almost all advice about surviving AI reduces to "keep learning", which is both true and impossible to act on. Learn what? Prompt engineering courses are mostly obsolete within a year, and the people selling them know it.

Here is a more specific claim, and one I can support from having got it wrong: producing things got dramatically cheaper, and checking whether they are correct did not get cheaper at all. Everything useful about working alongside these tools follows from that asymmetry.

The asymmetry

A language model can draft an article, a function, a contract summary or a migration plan in seconds. What it cannot do is tell you whether the result is right — and neither can reading it, because these models are optimised to produce text that reads as correct.

I found this concretely. Auditing eight articles a generator had written for this site, the prose was the part that held up. What had failed was a factual claim repeated four times, a code sample that raised an exception on line two, and structural damage that never appeared on the rendered page. I wrote that up separately in what breaks in AI-written blog posts.

The lesson was not "the tool is bad". The drafting was fast and mostly fine. The lesson was that I had no verification step, and the output was confident enough that I did not notice the absence.

When generation is free and verification is not, verification is where the value moves.

What verification actually is

It is not proofreading. Proofreading checks whether text reads well, which is precisely the property these models already have.

Verification means checking claims against something outside the text:

• Run the code. Not read it. Run it, with the current library version, in a clean environment.
• Check the proper nouns. Companies, products, people, versions, dates. In my audit the single largest error was one wrong company attribution, repeated consistently enough that it read as confidence.
• Find the source. If a claim matters, ask for the quotation it rests on and then go and look at it. Fabricated citations are usually obvious the moment you check one.
• Test the edges. Generated logic tends to handle the ordinary case and skip the empty list, the negative number, the duplicate entry.

None of that is glamorous and none of it can be delegated back to the thing that produced the work. That is exactly why it holds its value.

What this looks like day to day

The practical shift is in where you spend attention, not in how much you use the tools.

Supply the facts; ask for the shape. Asking a model what your refund policy says invites invention. Pasting the policy and asking it to apply the policy does not. Move every load-bearing fact from the model's memory into your prompt.

Ask for something you can check. "Summarise this" produces a summary you must read the original to evaluate. "Summarise this, quoting the sentence each point came from" produces one you can check in seconds.

Keep the last mile. Whatever step decides whether the work is correct — running the tests, checking the numbers, reading the contract clause — is the part to keep. Automating the drafting and keeping the judgement is a much better trade than the reverse.

Notice when you have stopped checking. This is the real risk, and it is gradual. The first ten outputs are fine, so the eleventh gets a glance, and by the fiftieth you are not reviewing at all. Everyone I know who has been bitten by this was bitten well after they had decided the tool was reliable.

On jobs, honestly

The two loudest positions are both unserious. "AI will take all the jobs" and "AI changes nothing, it is just autocomplete" are equally easy to hold and equally unhelpful.

What seems defensible: work that is mostly producing a plausible artefact to a known pattern is under real pressure — boilerplate copy, routine translation, first-draft anything. Work that involves deciding what should be built, being accountable when it is wrong, or operating where mistakes are expensive is under much less.

The uncomfortable part is that the pressure lands on the junior end of almost every field, because that is where the pattern-following work sat, and that work is also how people used to learn the judgement that makes them senior. Nobody has a good answer to that yet, and you should be sceptical of anyone who claims to.

What I would not do is try to out-produce the tools. Volume is the one axis on which they cannot be beaten.

What to actually learn

Concretely, in rough order of durability:

1. Your own domain, deeply. You cannot verify what you do not understand. This is the whole foundation, and it is the part nobody sells a course in.
2. How to test things. Writing a test, checking a source, designing a spot-check. Directly convertible into verification speed.
3. Enough about how these models work to predict their failure modes — that they interpolate, that they cannot distinguish true from fluent, that they average across library versions in training data.
4. Writing clearly. A prompt is a specification. People who struggle to brief a colleague struggle to brief a model, for the same reason.
5. Prompt technique, last and least. Useful, learnable in an afternoon, and the fastest-decaying item on this list.

The first four are things that were valuable before any of this and will be valuable after.

The part that is genuinely good

It is worth saying plainly that the upside is real. The distance between "I wonder if this would work" and a running prototype has collapsed, and that changes what an individual can attempt. Ideas that were not worth a weekend are now worth an evening.

That is the opportunity, and it is a large one. It just arrives attached to an obligation: if you are going to ship ten times as much, you need a way of knowing that what you shipped is right. The people who will do well are not the ones producing the most. They are the ones who can still tell.