Building with AI: from Shiny Prototype to Painful Maintenance

Thinking of building your own HR tool or Cornerstone page with AI instead of hiring help? You’ll nail the easy part in a Friday afternoon. But last time we checked, software still ran on the 80/20 rule – the last 20% takes 80% of the work: the security, the edge cases, the reliability, the upkeep AI cannot hand you. Build the prototype. Then let’s talk about Monday.

A client told me recently they might just build it themselves. AI, a bit of time, a clear idea. And honestly? You probably can build the demo – if you have the tokens to spare, that part is genuinely easy now, and I will not pretend otherwise. We use the same tools, and watching a working prototype appear in an afternoon is still a small miracle.

So we will be the last to talk you out of it. Build the prototype. Feel the magic. And try not to spend the whole weekend away from your family, chasing “just one more prompt.” Then let us tell you – as the team that has built this kind of thing hundreds of times over more than a decade, and stayed to run it long after launch, on the most sensitive platforms a company owns – what happens after the applause.

The demo just LOOKS like the 80 percent

Here is the uncomfortable math of software, and AI has not repealed it. The shiny 80% – the boilerplate, the screens, the happy path – is now fast and cheap, and a demo shows you exactly that, so it feels almost done. It is not. That shiny part is barely 20% of the time you will spend. The rest, the part no demo shows, eats the other 80%: edge cases, malformed data, the permission model, the one manager whose org chart breaks every assumption, the report that has to be right rather than roughly right.

Think of AI as a wildly talented apprentice – eager, fast, and wired to make you happy. That last part is the catch. An apprentice who wants to please takes the shortcut, tells you it is done, and quietly skips the boring, dangerous bits unless you ask. So ask: what happens when the inputs turn messy, who is allowed to see what, where it buckles under load. Do not ask, and it will cheerfully hand you the dumbest security hole you have ever seen, with a smile.

“Looks right” and “is right” are very different things, and AI is built for the first.

It also always looks right, which is a very different thing from being right. Ask for a dashboard, and if the real data source died two days ago, it may just fill the charts with plausible numbers so the thing still demos beautifully. No malice – it wants to show you something that works, and you never asked whether the numbers were real, so it never checked. That is the trap: “looks right” is the hardest kind of wrong to catch, because nothing is visibly broken. Build by hand and you lay a foundation, test it, add the next piece, each step earned before you trust it. AI does not work that way. It touches everything at once, in one confident pass. Without real QA, tests, and someone who knows what to check, that is not a shortcut. It is a time bomb, wired into the data you can least afford to get wrong.

Here is the part that baffles people. The same apprentice that leaves a beginner’s mistake in your login page can also surface a long-buried bug in the Linux kernel that every human reviewer walked past for years. Both are true at once, and hard to square unless you write software for a living. The reason is almost too simple, even now that the models “reason”: at heart a language model is a next-word predictor trained on an unimaginable amount of text. The newer ones add a reasoning step on top – they think out loud before answering, and it genuinely helps – but the machinery underneath is the same, working forward one likely token at a time. Point it at a well-worn problem and it looks like genius; point it at your specific edge case, unsupervised, and it will reason its way, confidently and eloquently, to the wrong answer. Which is why the real work was never getting it to build. It was always knowing what to interrogate before you trust it.

The numbers are catching up with the vibe. Independent testing has found security flaws in roughly 45% of AI-generated code. By day 90 of a vibe-coded project, teams report burning a quarter to a third of every sprint on bugs that trace back to the AI. Maintenance costs have been reported to balloon past 300% within two years. Salesforce Ben, an industry publication, called 2026 “the year of technical debt.” None of this argues against the tools. It is an argument about when the bill arrives – and it arrives after the demo.

Should you build it yourself?

For genuinely throwaway things, honestly, yes. Vibe-code the office lunch poll, the meeting-room finder, the one-off nobody depends on. Own it, enjoy it, replace it next month. Low stakes, low regret.

But be careful what you file under “throwaway.” Take the humble holiday tracker everyone reaches for as the safe example: get the leave calculation subtly wrong and, at least here in Germany, that “simple” tool has wandered straight into labor law, statutory entitlements and records you are legally obliged to keep. What looks trivial rarely stays trivial once real people and real rules depend on it.

For anything your people lean on, the question changes. The moment a tool touches real workflows – payroll data, compliance deadlines, who can see whose record – you are no longer building a demo. You are signing up to run it – and that job does not end. Build your own HR pages and tools, and the afternoon a bug locks new hires out of onboarding – or hides half your training records the week of an audit – you are not doing HR. You are the developer and the QA team both, on a problem that was never in your job description.

You are signing up to run a system. And running never ends.

So the honest fork is this: a quick toy, or something your organization will lean on for years? If it is the second, the prototype was never the hard part.

The second S in SaaS is Service

A post went around HR and tech circles recently that nailed it: everyone forgot what the second S in SaaS stands for. Not software. Service. Nobody ever really paid for the software – they paid for the service it quietly delivered while they slept.

AI collapsed the cost of building. It did nothing to the cost of owning.

The author was refreshingly honest. His own team could vibe-code a small internal tool in two hours, and should. But for anything core, you want it built by people who do only that, all day – not by a manager in one spare afternoon. The comments were even better than the post. “The service is the maintenance, the security patches, the edge cases someone already solved.” “Building is cheap; owning never is.” One commenter did the math on an internal tool built to save $80 a month that now runs $150 a month in server bills – before you even count the AI tokens it took to build it and the tokens to keep it patched. That matches what we see. We have watched a company cancel a subscription to save money and then pay ten times as much in tokens to run the replacement; we have watched a vibe-coded agent loop run all weekend and quietly burn through a fortune before anyone thought to look. We have seen every version of the surprise.

That is the real trade. AI collapsed the cost of building. It did nothing to the cost of owning: reliability, security, the fixes when a Cornerstone release moves something underneath you, the quiet improvements that happen while you get on with your actual job. That is what you were always paying for – and exactly what a prototype leaves out.

The AI layoffs are already reversing

You do not have to guess how the do-it-yourself story ends. Plenty of organizations already ran the experiment at scale, on their own people – and they are quietly walking it back.

Ford spent three years hiring 350 veteran engineers to catch quality problems its automated systems missed; the executive in charge admitted they had wrongly assumed that feeding AI the requirements would just produce a good product, no experienced people watching required. IBM automated a chunk of HR work and cleared about 94% of requests – then found the remaining 6%, the part that needs judgment, was the part that mattered, and is now tripling entry-level hiring. Forrester found 55% of leaders regret the layoffs they made in AI’s name, and more than a third of employers who cut roles for AI have already rehired for them, many within six months. MIT’s 2025 study landed the cleanest line: 95% of enterprise AI pilots delivered no measurable impact – not because the models are bad, but because a demo that impresses is not a system that holds.

The pattern rhymes, and not just with software. The internet was supposed to erase jobs too; instead it multiplied them and changed their shape. Here it repeats: cut the experienced people, keep the shiny automation, and discover a few months later that the experienced people were the hard part. First you let them go. Then you quietly ask them back.

Why this hits hardest in HR and learning

Now put that pattern where we live: HR and learning platforms like Cornerstone, holding the most sensitive data a company keeps. Salaries. Performance. Health. Compliance. Who reports to whom.

This is where “looks finished” gets most expensive. The genuinely hard, invisible work is not the interface – it is making the thing hold, and keeping it safe. My honest prediction: the backlash arrives in full the day someone in HR ships a vibe-coded page or tool on a Friday afternoon and, without ever meaning to, exposes an entire organization’s personal data in a single move. Not out of carelessness. Out of not knowing which question to ask.

There is a second cost, quieter and just as real. If your HR team builds and maintains its own software, it has quietly become a software maintenance team – time not spent on hiring, on developing people, on the human work only they can do. The whole promise was to give that time back, not to hand your L&D lead a pager.

Build versus buy, in the age of AI

We will not spill the secret sauce, mostly because it is not much of a secret – it is discipline. But here is the honest shape of it.

We use the same AI you do, and we love the speed. We also do not pretend to have swallowed all the wisdom in the room – nobody has, and anyone who says otherwise is selling something. So we follow the market closely and experiment constantly, with promising and occasionally slightly mad pipelines and projects, learning where AI shines and where it quietly breaks long before any of it goes near a client’s platform. Anyone who knows their field can now prompt what they want; what almost nobody is ready for is the steep, technical climb that comes after – the distance between a demo and something that survives a storm. There is no prompting your way up it. As a team we are closing in on our own 10,000 hours with these tools, and if that number teaches anything, it is that the reps are the point – the demo is only hour one.

Anyone can prompt a demo. Almost nobody is ready for the climb after it.

Ask AI for a screen and you get a screen. Ask someone who has done this for years and they are already running a checklist the prompt never mentions: i18n, a11y, responsive breakpoints, performance budgets, scalability, portability, tokenomics. If that reads like noise, that is the point – it means other languages, screen readers, every phone, staying fast under load, holding up at ten thousand users instead of ten, surviving the next framework, and not waking to a runaway token bill. Each is its own field, and nobody prompts their way to fluency in seven of them. It is like watching John Mayer write a radio-ready song in ten seconds: what you do not see is the twenty years behind the ten. Fluency looks like the finish line; it is only ever the start.

So yes, we get to a working prototype fast, on purpose – I would rather show you a rough thing that runs than a polished slide about one that does not. Then the real work starts, the part AI cannot do for you: architecture that survives the next platform update, the security and permission scopes nobody asked for but everybody needs, the hosting, the integration plumbing too tangled to prompt through, and the unglamorous finishing. And then we run it. When Cornerstone shifts under a release, that is our problem, not yours. When something breaks, fixing it is on us – not on your training manager.

That is the difference between a prototype and a partner. One gets you to the applause. The other is still there eighteen months later.

Cheap today, locked in tomorrow

Zoom out, because the ground under all of this is still moving. The big labs – Anthropic, OpenAI, Google – are running the oldest playbook in software: win the market first, charge later. Cheap plans, generous free tiers, credits by the bucket, all to get the world building on them. It is working, and it is not charity. Prices are already climbing, and they will keep climbing, because the plan was always to become the thing you cannot leave.

That is the quiet risk of pouring your whole operation into one model this year. Once your processes, your data flows and your team’s muscle memory are shaped around a single vendor, switching stops being a decision and becomes a migration. Enterprises have lived this before – with cloud, and with the very HR platforms we work on. The lock-in is not a flaw; it is the business model.

And yet the opposite force is gathering. Open-source models are closing the gap faster than anyone predicted, and capable ones already run on a laptop, soon a phone – pointing somewhere very different: intelligence as a near-commodity, priced at roughly the electricity it takes to run.

So which wins? Do we end up renting our thinking from one or two global giants, or does it democratize down to the cost of power, within reach of everyone? Nobody knows yet, us included. Which is exactly why we never bet a client’s core on a single vendor, or sign anyone into a future they cannot walk out of. We keep what we build portable, stay model-agnostic where it counts, and watch this shift daily – because the only safe bet right now is that today’s obvious choice may not be tomorrow’s.

A better way to use AI

So, genuinely, not as a pitch: how should you use this moment?

Use AI to kill the blank page. Prototype your idea in an afternoon – it is the best brief you will ever write, and it tells you fast whether the idea is worth anything. Keep the throwaway stuff throwaway.

But for anything your people depend on, buy the service, not just the software. Bring in people who have shipped this exact thing before to do the hard part and, above all, to own the running of it. Keep your HR team on the work that is actually theirs. And be skeptical of long lock-ins – the honest reason nobody wants to sign a 24-month license right now is that a new model two weeks later might do three times better for a third of the price. That is not indecision; it is a correct read of the pace. Work with partners who ask you for weeks, not decades.

That is how we think about our own Cornerstone consulting, the way we run implementations, Workforce AI migrations and the ongoing optimization that keeps them alive, and why the products we build – the Octily Content Editor and our Cornerstone MicroApps – are things we host and maintain, not hand over with a cheerful good-luck. Human to the power of AI, as our friends at Cornerstone put it. For us, the emphasis stays firmly on the human.

The honest bit

Everyone in this market looks a little like a deer in the headlights right now, and we do not blame them. The fog is real, and it is both worrying and strangely exciting. The temptation to cut the hard parts – the people, the partners, the last 20% – is enormous, because the demo makes it all look done. For every finished product someone has cared for over years, a hundred half-built prototypes now float around – each one looking finished, not one of them done.

None of this is us claiming to have it figured out. The world has already changed enormously, and in ways that run deeper than they look: the labs taught their models to code partly because code is how an AI improves the next AI – software that can rewrite its own guts, an exponential nobody has a real map for yet. That does not just make building faster; it quietly changes what software is. Even the fixed interface may be dissolving – tools that assemble the screen you need in the moment, rather than shipping one built months ahead. It will keep changing, fast, and hands-on experience is the only real teacher in a fog like this. Which is why we would rather learn the hard lessons on our own experiments than on your production systems.

One more thing, and let me make it personal. I think the little “AI” label everyone hurriedly stuck on their products is going to quietly fall off. Not because the technology fades – the opposite. Soon there will be almost nothing left that AI has not touched somewhere in the making, and a label that describes everything describes nothing. That is why we are sparing with the word. We are not here to sell you “AI.” We are here to build useful things that make a real difference – whether there is a model humming inside them or not.

It is not done. It looks 80% done, which in software has always meant barely started. The winners of the next few years will not be the ones who built the fastest demo. They will be the ones who kept experienced hands close for everything that came after – and who let their people get back to being people.

Go build the prototype. Then let’s talk Monday.