Reading · Noesis Hiring · RSS Amplifier

Right decision: instead of renting pieces of software to get functions done, each company can create whatever they need with an LLM.

Consultants now ride the wave, their claim is catchy: “I’ll enable your teams to boost productivity by 50%“

Actually much of this is true, an LLM like Claude can not only execute any functions, but it can act on behalf of people: The Agentic-AI.

An active agent who receives input, decides the reaction, then enacts it. And it is faster, cheaper, more consistent and reliable than a human.

So: cancel the software. Use the model. Enable the difference.

It is. Properly executed, agents are the largest leap in productivity anyone alive has seen, and a real competitive weapon. Badly executed, they cripple the organisations that adopt them — quietly, and from the inside, because what breaks is not visible on any dashboard.

The difference between the two outcomes is not the model. Everyone has the same model. The difference is knowing which software an LLM actually replaces, and which it only appears to.

The good news is that nobody has to guess. History has already run this experiment — at full scale, for twenty-five years, with a universal instrument everybody owned.

By the mid-nineties a great IT innovation promised to boost productivity: the spreadsheet. It could hold a customer list, manage a pipeline, flag a renewal, and produce a report a board would accept. During the first quarter of this century Excel enabled so many functions and possibilities that it virtually supported anyone in developing their own CRM, for the price of a tiny licence.

We didn’t see a massive adoption of Excel as a CRM. Some did it, and they may have had good or entirely wrong reasons.

And here is the fact that settles the argument before it starts: in exactly those years, the CRM industry did not shrink. It grew into one of the largest categories of business software on earth. Salesforce was founded in 1999 — into a world where every one of its prospective customers already owned Excel. The market held the universal instrument in one hand, priced at almost nothing, and reached for the application with the other. Twenty-five years of capital answered, decisively, the question we are now treating as new.

Why? Because a CRM turns out to be more than a database. What the business needs from it was more than the functions — Excel had the functions too. It is accountability: who changed what, who promised what to which customer, who answers for the forecast. It is reliability: it has to work every morning, recover from bugs, never lose a record, including after the person who built it has left. And it is cross-function by nature: sales, marketing, service and finance operating on the same customer at the same time. Every one of these is weak in a self-built spreadsheet, and some are outright risks — a formula quietly edited, a file that dies with its author, five departments keeping five copies of the truth. Nobody wanted to bet revenue on that. So they bought.

And where a company did build its own, the failure was almost never Excel’s. Excel was sufficient. What was missing was any idea of what a CRM has to be.

That is the distinction the current enthusiasm has mislaid, and it is about to be mislaid again.

A great deal of it, and the piece would be dishonest not to say so.

Call middleware any software whose value is a function — where the function can now be replicated by a model. The screening chatbot. The outreach sender. The scheduler, the parser, the note-taker, the thing that rewrites a job advert into four tones of voice… Each was a slice, each was rented monthly, and the rent was only ever justified by the difficulty in build it. The difficulty has left.

Which is why the collapse of that market needs no forecasting. Perpetual rent against a build cost of roughly nothing is not a business anyone defends for long. Companies have been paying extortionate sums for trivial tools, thirty or fourthy small line items nobody cancels because each is too small to bother with, and a great many of them can and should now be made in-house.

That is not the interesting part. The interesting part is what the same arithmetic does when you point it at something that was never trivial.

The tools you should build are the ones that cost nothing to build. The ones you should buy — or better, delegate — are the ones that are complex, consequential, and dependent on a mastery your company has no business acquiring. Payroll. Audit. Security. Nobody writes their own. Not one of them is unimportant, and not one of them is your core business.

And the ones you should never let out of the building are the ones that define who are you. Your inner value creation. The thing your company would be delegating itself by outsourcing it.

Hiring, likewise CRM, and ERP sit in the middle box, and this is where most of the confusion lives.

For a staffing agency, hiring is the product: business-critical, then build it, as it is what you are. For a company that needs people in order to build houses or ship a digital solution, hiring is mission-critical, not core. In this area the solution can be consequential, complex, mastery-dependent — and not the thing you are in business to be good at.

The first box needs no imagination. A company that trades in tiles, or freight, or insurance, runs a chatbot on its website to field customer questions. A Middleware. Useful — and trivial. It demands no mastery the company doesn't already hold: the answers are its own catalogue, its own prices, its own policies. The model builds it in a day and runs it for pennies. Paying a monthly licence for it, forever, was the habit of the past. Make it. Own it. Cancel the subscription.

Which means it needs a suite. Not a chat window, and not thirty rented slices.

Here is the part that makes this era more dangerous than the Excel years.

Knowing the work is not knowing how to design the system that carries the work. A salesperson does not become a CRM designer by selling well. A recruiter does not become an ATS designer by recruiting well. Two different masteries, and the second is invisible from inside the first — because from inside the job, the system looks like an inconvenient description of what you already do.

What does a fish know about the water it has lived in all its life?

That is not a failing. Nobody is asked to audit the paradigm they were trained inside, and most jobs never require it. Twenty years of expertise is fluency within a model. It is command of the that. Mastery is command of the why — why this and not that, why this is correct and that is not — and it is precisely the equipment that immersion does not supply.

Until recently, none of this mattered very much, because the barrier was technical. The cost of building was higher than rent it, so you did not. The model removed that barrier and left the design barrier exactly where it is, unmarked and unlit. The person who could never have built the thing can now assemble something that runs, and nothing in the experience tells them which of the two masteries they were missing.

Excel at least felt like work.

The law is general. Its consequences are not evenly distributed — they concentrate wherever the decisions have subjects. So watch it operate in the domain from the middle box, the least forgiving one available.

Nine months from now, a candidate asks why they were not progressed. Depending on where you operate, they may be entitled to an answer, and to know whether a machine made the call.

What do you have?

You developed a fantastic solution on vibe coding, or even an agent inside ChatGPT. It runs a chat thread in an account that may belong to someone who has left, or nobody is accountable for it. The solution runs on ChatGPT to track applications, which has kept a great deal — stages, timestamps, statuses, the date the email went out — and none of the things being asked for. Not an auditable tracer, not a reliable decision-making record. The machine set a threshold and only the few who passed it were read. Then only a few of them were ever met. Everyone else? Silence.

What has to be demonstrated under any serious reading of the high-risk regime is different in kind from what these systems record. The reasoning behind the decision. What the machine contributed to it. And that the human oversight was meaningful rather than nominal.

In theory you can build it, if you know what needs to be done, how and why.

A stage-transition log doesn’t produce any of the three. Neither does a conversation. Both fail the same test for opposite reasons: one kept no record, the other kept the wrong one.

And the position the entire market is now retreating to — the human in the loop — is the one position that cannot be defended. The industry coined the phrase and gave the human inside it no power: a checkpoint inside the machine’s own cycle, approving at the machine’s pace, on the machine’s information. That is not decision-making; it is, at best, the possibility of it. To oversee a decision you must be able to evaluate it. To evaluate it you need the reasoning and something to judge it against. The recruiter in the loop has a ranked list and a deadline. A human on the loop — standing above the system, holding its record, empowered to stop it — would be a different position. It is not the one being sold.

Notice that nothing in this failure is about hiring in particular. It is the general collapse — capability mistaken for application — landing on people instead of on data.

Every domain in the middle box has its own version of the candidate’s question. This one simply arrives with a legal right to an answer attached.

It would be naive to expect any of that to stop the building.

But here is what the enthusiasm misses: the regulation does not distinguish between the system you bought and the system you assembled. Wire a model into your own screening workflow and you have not escaped the vendor’s obligations — you will be, at once, the user and the vendor. Those are two different sets of duties, and they do not swap; they add up. Everything you already owed as the organisation deploying the system — the meaningful oversight, the answer owed to the person on the receiving end — you still owe. On top of it now sits everything the vendor used to owe you: the risk assessment, the documentation, the record that must survive inspection. You have not shed a liability. You have doubled them — and dismissed the one party who used to carry half.

And a self-developed system fails that test in a predictable way. The evidence it needs cannot be reconstructed afterwards, because evidence of reasoning has to be produced at the moment of the decision, by design. A workflow assembled to get the function done keeps no such record — so the paperwork gets manufactured later, badly, and in some cases dishonestly. That is not a hypothesis; it is the standard market response to every evidentiary requirement. Ask for consent and you get a cookie banner. Ask for demonstrable oversight and you will get an oversight tab, a quarterly report nobody reads, and a certificate.

Compliance retrofitted is compliance theatre. Compliance-born is a different object: a system in which the record, the oversight, and the reliability were design inputs — decided before the first line was built, carried by someone who answers for them by contract. That difference cannot be seen in a demo. It becomes visible on the day someone asks, and that is the worst possible day to discover which one you have.

The belief at the top of this piece is half right, and the half that is right is worth a fortune. Cancel the rented functions. Build the trivial tools. Let the middleware disappear; it is time for it.

But a mission-critical application was never just a bundle of functions, and the LLM does not change that. It removes the cost of building the functions and leaves untouched the two things that made the application worth buying in the first place: the design mastery that knows what the system has to be, and the answerability for what it does. Excel proved this once. The proof did not expire because the instrument got smarter.

For the domains in the middle box — the consequential ones you were never in business to master — the real choice was never build versus buy. It is self-certified versus compliance-born. And compliance here is not owed to the regulator alone; the regulator is merely the newest stakeholder, and the loudest. A company answers to more parties than that, however small it is — the board that committed the budget, the auditor, the investor, the people who live with the decisions. Budgets have been committed on the strength of a resources-management application somebody had grown out of a spreadsheet, and some of those companies paid with losses nobody could explain afterwards: no regulator involved, just the money gone and the workbook unable to say why.

Do you want to run the same risk again, only because the LLM is smarter than the spreadsheet was?

Finally, Claude can do anything. True — and it was never the question. The question is what happens after the anything is done: who stands behind it, who holds the record, who answers when the board, the auditor, or the person on the receiving end wants to know why. A model replaces functions. An application is where someone answers for what the functions did.

The ultimate lesson is still: build what you can, Commodities software. Buy what you have to, Mission-Critical software. Create what you are, Business-Critical software.

In hiring — where it matters — the mission-critical solution costs you significant effort to build, to run, and to become accountable for. Or you can have it, outsourced, at a business-like cost. That is what NoesisHiring was born to do.

Finally Claude can do anything.

Comments