Beware of Geeks Bearing Gifts

Everyone seems to agree that AI has lowered the barrier to building software, and in a narrow sense everyone is right. What I think gets missed is that the barrier has forked, and that the people most exposed to the fork are the ones least equipped to see it, namely the non-technical buyers who are now being offered “beautifully” finished software (laced with em-dashes and sentence-case capitalised titles) at a fraction of what it used to cost.

The Wooden Horse

Troy held out for ten years. The Greeks tried everything an army of the period could try against a walled city, and the walls held, which is worth remembering; the Trojans were not careless people with weak defences. The city fell because of a gift. The Greeks built an enormous wooden horse, left it on the beach, sailed out of sight, and the Trojans themselves dragged it through their own gates and celebrated.

There was a warning. In Virgil’s telling, the priest Laocoön ran down to the beach shouting that he feared the Greeks even when they came bearing gifts, and drove a spear into the horse’s side, where it stuck and the hollow belly rang. It is one of the great unheeded warnings in literature, partly because it was so obviously correct, and partly because shortly afterwards two sea serpents came out of the water and ate him, which the Trojans understandably took as a sign that he had been wrong.

I first learned about this horse when I was twelve, and it has been popping into my head a lot recently, because a version of it is being wheeled into a great many organisations, and the walls those organisations have spent years building, procurement processes, security reviews and IT policies, were designed for threats that arrive looking like threats.

What Actually Fell

The cost of a convincing demo has collapsed for everyone. A competent person with a modern coding model can produce something in a weekend that looks, to an untrained eye, indistinguishable from a product that took a team six months, complete with a login page, a dashboard, a chat box and a pricing page with Stripe connected.

The cost of software that actually holds weight can fall just as far, and I want to be careful here, because the cynical version of this argument (AI only makes toys) is as wrong as the breathless one. Software that handles real data, real permissions and real users for years can now be built far faster and more cheaply than it could two years ago, but only with the right execution, which means someone steering the model with taste, deciding what should not be built, and checking what comes out the other end. In the wrong hands, the same tools push the true cost in the opposite direction. The savings are visible on day one, and the bill arrives later, as rework, as data exposure, and as a system that nobody can maintain once the person who prompted it into existence has moved on.

So there are now two cost curves where there used to be one, and from the outside, at the moment of purchase, they look identical. That is the horse.

Right execution Wrong execution

The Specialist at the Gates

I meet more and more people who describe themselves as AI specialists, and an increasing number of them are selling the same thing. The architecture is almost always the same: a Next.js front end deployed on Vercel, Supabase handling the database and the logins, a component library that makes everything look expensive, and an API call to a language model somewhere in the middle. Supabase and Vercel are both good products, but I would suggest that a large share of the people using them chose them because they were their LLM’s first pick, and that choice tends to leave much to be desired by way of critical thought and reasoning of their own.

The difficulty for buyers, therefore, is that the signals they used to rely on have become free. Polish used to correlate with care, because polish was expensive, and speed used to correlate with competence, because only experienced people could move quickly. Both are now available to anyone with a subscription, so the client sits through a slick demo, sees something that works, and quite reasonably concludes that they are looking at a finished product.

What climbs out of the horse tends to arrive a few months later, and it usually looks something like this:

• Open Doors: database access rules that should stop one user reading another user’s records were never written, or were switched off during development to make an error go away.
• Keys Under the Mat: secret credentials sit in code that ships to the browser, where anyone who knows where to look can find them.
• Nobody Home: the system lives on whichever account happened to be to hand when it was first deployed, and nobody is actually accountable for running it, patching it or answering the phone when it goes down.
• No Foundations: there are no tests, no proper migrations and no monitoring, so nobody finds out something is broken until a customer does.
• No Way Out: nobody has agreed how the client gets their data back if the relationship ends, or what a handover would look like.

None of this is hypothetical. In 2025 a security researcher scanned more than sixteen hundred apps built with Lovable, one of the popular AI app builders, and found that around a hundred and seventy of them were leaking user data, because the Supabase access rules that should have protected it had never been set. Every one of those apps presumably demoed beautifully.

There is a second-order effect here that I think is underappreciated. When a client eventually realises how little sat behind the demo, the lesson they tend to draw is that software is easy, that they were overcharged, and that they could do it themselves, and having watched a weekend build sold to them as a quarter’s work, it is hard to blame them. The horse lets soldiers into the city, and then convinces the Trojans that they never needed walls.

Mētis and the Spear

So what should a buyer look for, beyond someone who can write code? I think it is a balance of qualities that the Greeks would have recognised, and which happen to be split across the two characters at the centre of the story.

The horse was Odysseus’s idea, and the Greeks had a word for his particular kind of intelligence, mētis, which translates loosely as cunning and means something closer to adaptive practical intelligence, the ability to change approach to fit the situation, and to see possibilities where others see only walls. Laocoön had the opposite gift, the scepticism to walk up to something beautiful and hit it with a spear to hear what was inside. The Trojans had neither, which is why they lost. What you want in anyone building software for you now is both, held in balance, and I think it shows up in three ways.

Appetite and Scepticism. There are two ways to fail with AI. The first is the refuser, who will not use the new tools at all and is therefore slower and more expensive than they need to be. The second is the convert, who accepts every default the model suggests, because it compiles and the demo works. The useful position between them is a narrow one, combining an aggressive openness to new tools with a deep distrust of their defaults.

Taste. A model will happily produce ten versions of anything, so the scarce skill has become knowing which one is right, a judgement that depends on the domain far more than on the technology. Good taste in property software is not the same as good taste in a consumer app, and someone who has never worked in your industry has to borrow that taste from somewhere, usually from a model trained in part on X (Twitter) and Reddit, which has its own statistical idea of what “taste” looks like.

Restraint. The cheapest software is the feature you talk a client out of building. AI makes it trivially easy to say yes to everything, and every yes is something that has to be secured, tested and maintained for as long as the system exists, so the people worth hiring are increasingly the ones who say no most often and can explain why.

If You Are Hiring an AI Specialist

If I were a non-technical director about to sign off on an AI build, I would ask three questions in the first meeting, and I would pay as much attention to how they were answered as to what was said.

I would ask to see the access rules on the database, in plain terms, and expect someone to be able to walk me through them. I would ask what tests exist and how I would know if something broke. And I would ask whether my own IT team (even if that is just Claude) could review the architecture before anything went live, because a confident builder will welcome that and a nervous one will find reasons to avoid it.

Then I would apply one blunt rule. If the whole architecture turns out to be a backend-as-a-service template, Supabase behind Vercel or something like it, and the person cannot explain why they chose it over the alternatives, what it costs at scale and how I would get my data out, I would run. The core problem in that situation is the absence of reasoning, as it so often is.

Laocoön was right, and the Trojans ignored him because the gift was too impressive to doubt. The modern version of his warning is a little less elegant, but it is worth keeping in mind every time someone offers to build you something remarkable in a weekend. Beware of geeks bearing gifts (unless that geek is me).