Artificial Intelligence & Machine Learning

Two things about artificial intelligence hold simultaneously, and conflating them is where the budgets go. The substance is old. Fitting a function to examples instead of writing the rules down by hand is machine learning, and its core, gradient descent over a differentiable model, was settled long before anyone sold a chat assistant. The vocabulary is not old. It turns over roughly once a year, because every vendor needs a name for the thing it shipped last quarter, and those names are chosen to sound like new science rather than new packaging. A reader who cannot separate the two buys courses named after products, pays for a credential in a technique that will be a menu item by the time the invoice clears, and still cannot explain why their own project stalled. The sections below separate the parts of the recent past that broke with what came before from the parts that are familiar engineering with better branding, and draw the consequence for where attention is best spent.

What changed

One thing changed, and it matters more than the noise surrounding it. Generality became cheaper than specialisation. Until recently a working system meant a dataset you had labelled yourself, a model trained on it, and a narrow task it could perform. The transformer architecture, published in 2017 and largely unchanged in outline since, turned out to keep getting better as it was given more text and more compute, and the large language models that resulted could do a passable job on tasks nobody had trained them for. That is the break. It is not that machines began to reason. It is that the cost of a first working version of a language task collapsed from months of data collection to an afternoon of writing instructions. The consequence is where this gets practical. If the model shows up already competent, the expensive part of a project moves: it is no longer labelling, it is specifying what good output means and measuring whether you got it. Teams that understood this built evaluation sets before they built features, and those teams ship. Teams that did not have an impressive demo and a long row of inconclusive pilots, because nobody in the room can say whether this week's prompt is better than last week's. Two further shifts follow from the same cause. The same architecture absorbed images, audio and video, so the old separation between vision work and language work stopped being an organisational fact. And inference, rather than training, became the recurring bill for almost every company doing this, which is a different budget line with different engineering attached to it. Set against that, notice what did not move. A confidently wrong answer is still a wrong answer, and nothing in the architecture fixed it. Messy source data still produces useless output, faster than before and in more fluent prose. The scarce skill in an AI team is still the ability to define a problem narrowly enough to know when it has been solved. And for a working practitioner the race between the frontier labs is the least useful thing to follow, because the event that changes what you can build is not a new capability appearing at the top, it is last year's capability becoming cheap enough to put in a loop that runs a million times.

What only changed its name

Now the renaming, which is most of the rest. Retrieval-augmented generation is search followed by templating: find the relevant passages with an index of a kind that long predates any of this, paste them into the instructions, ask for an answer grounded in them. It is a sound pattern and it is also decades of information retrieval wearing a new acronym, which is exactly why the hard parts of a RAG project are chunking, ranking and freshness rather than anything to do with the model. Agentic AI is a control loop: call the model, parse the output, run a tool, feed the result back, stop on a condition. Engineers have been writing that loop for as long as there have been scripts. What is new is that one step in it is now fuzzy, which makes the old questions about retries, timeouts, idempotency and blast radius harder rather than obsolete. Prompt engineering is interface discipline, and the position least likely to be popular is that it is a real skill and a bad thing to buy a course in, because the specific tricks are the most perishable knowledge in the field, while the durable part, writing an unambiguous specification and testing against it, is technical writing and QA under a fashionable label. The renaming carries a price, and the price is the reflex to route everything through a frontier model. Take ticket routing, where every incoming support message has to land in one of twenty categories. A small encoder fine-tuned on your own resolved tickets runs on ordinary CPU, returns an answer before a call to an external API would have finished its handshake, costs nothing extra per additional message, does not change its behaviour because a vendor shipped an update overnight, and keeps customer text inside your own infrastructure. The frontier model wins on the twenty examples someone tried by hand and loses on every property that decides whether the thing survives in production. Picking it anyway is a habit, not a decision.