For fifteen years the answer to “I want to build this” was always the same: learn to code, or pay someone who can. That sentence is no longer true.
I’m saying this from the other side of the fence. I’m a computer science student and systems administrator, I work in infrastructure and security, and I’ve spent years writing the code and the YAML that a model now generates in thirty seconds. It doesn’t bother me. I think it’s the best news of the decade for anyone who has a business problem and no way to solve it.
But there’s a version of this narrative that drives me up the wall: the one claiming you don’t need to know anything anymore. That’s false, and it’s an expensive kind of false. The barrier hasn’t disappeared. It moved, and it moved somewhere almost nobody is looking.
What actually collapsed: the cost of version one
It’s worth being precise about what changed, because the hype blurs everything together.
What collapsed is the cost of getting from zero to a first working version. That stretch used to take weeks: environment, dependencies, boilerplate, auth, a CRUD, a deploy. Today it’s hours, and in many cases you don’t write code at all.
This isn’t just my read. Microsoft embedded Copilot into Power Apps, Power Automate and Power Virtual Agents with the explicit goal of letting people build solutions by describing them in natural language (Microsoft News). ServiceNow has used the term “citizen developer” for years to describe the business person who builds their own applications without going through IT (ServiceNow). And the aggregate effect is the one MyNextDeveloper describes: an explosion in the number and variety of applications being created, because writing code stopped being the bottleneck.
The word people use for this is “democratization” and, brochure-flavored as it sounds, it describes what’s happening. Access opened up.
My own evidence
I’m not talking about this in the abstract. A good chunk of what I use daily was built exactly this way:
- My personal finance system classifies thousands of bank transactions with a cheap model and writes them into Notion. The “program” is a few hundred lines of Python that I mostly didn’t type by hand. I wrote the whole thing up in how I automated my finances with Notion and AI.
- At WhiteLabs I build B2B automations in n8n. Flows that five years ago would have been a microservice with its own repo, pipeline and on-call rotation are now a canvas of nodes with a model call in the middle.
- This blog runs on Astro over Cloudflare Pages. I write the content; a large part of the scaffolding was generated by an agent running locally against the repository.
None of this is a demo. It’s in production, I use it, and when it breaks it’s my problem.
So yes: if you run a business and you have a concrete idea of what the software should do, you can build it today. That part of the pitch is real.
Where the story breaks down
Now the part that never makes it into the LinkedIn thread.
Everything I described above shares one trait: these are small systems, single-user or single-team, over data that isn’t critical to third parties. The moment you step outside that perimeter, the invoices start arriving.
Nobody generates day 2
AI gives you day 1. Day 2 — the day it’s been running for eight months, filled up with data, and it fails on a Tuesday at three in the morning — is still yours.
A real and not particularly glorious example: I had an n8n flow syncing data between two systems every hour. It worked perfectly for weeks. Then the source endpoint started returning 200 OK with an empty body instead of an error. The flow didn’t fail: it processed zero records and carried on happily. There was no “zero is suspicious” alert, because nobody writes that alert when the goal is to make it work. I caught it eleven days later, while looking at something else.
No code generator warns you about that. Happy-path logic is what a model does brilliantly. The question “what happens if this degrades silently?” isn’t in anyone’s prompt.
Same story with backups. I run a NAS with encrypted backups to Hetzner using Restic, and I learned the only lesson that matters here the hard way: a backup you’ve never restored isn’t a backup, it’s a folder. The first time I ran a serious test restic restore, I found out one of the repositories hadn’t received a new snapshot in weeks because the cron job ran in a context without the credentials loaded. Silent, again.
Vendor lock-in: the bill that arrives late
The most honest analysis I’ve read on this comes from Unico Connect, which acknowledges three limits without hedging: scalability, lock-in, and how hard migration is. The second one is the one most people underestimate.
When you build on a no-code platform, your business logic doesn’t live in a file you can read. It lives in that platform’s internal representation. There’s no git diff. There’s no code review. There’s no “I’ll take this elsewhere” that isn’t a full rewrite.
This isn’t a theoretical architecture problem, it’s a power problem. The day they raise the price, change the licensing model or sunset the product, your negotiating position is zero, because the cost of leaving is rebuilding. It’s the same dynamic that pushed me to buy a NAS and pull my data out of other people’s clouds: not paranoia, just not wanting someone else’s decision to take my operation down.
The mitigation isn’t “don’t use no-code”. It’s: keep the logic that gives you a competitive edge somewhere you can leave from, and use the platform for the glue.
Security: the surface you can’t see
This is the part that worries me most, occupational deformation included.
When you build an application with a visual tool and an assistant, the attack surface doesn’t disappear, it becomes invisible. There’s still a public webhook. There’s still a third-party token stored somewhere. There are still OAuth permissions granted to integrations you installed one afternoon and never looked at again.
The difference is that now there’s nobody in the loop who knows how to look at that. The Aalborg University paper on low/no-code and generative AI flags exactly this in its limitations section: these platforms accelerate delivery, but they inherit governance and control problems.
And it isn’t hypothetical. I already wrote about the Vercel hack and the OAuth supply chain: the vector wasn’t a code bug, it was an integration token holding more permissions than it needed. A no-code stack has more integrations, not fewer. You multiply that vector and remove the only person who knew how to audit it.
The minimum I’d apply, and none of it requires being an engineer:
- No secrets in the body of a node, a prompt or a chat message. Ever.
- A written inventory of which integrations have access to what. A spreadsheet is fine.
- Quarterly review of OAuth tokens, revoking anything you don’t recognize.
- Personal or customer data: ask where it physically ends up before you connect anything, not after.
The control ceiling
There’s a fourth limit, subtler. AppBuilder puts it well: AI-assisted features tend to box you into the suggestions the system generates and strip away fine-grained control over the outcome. You describe the intent, the tool decides the implementation, and when you need it to do something specifically different, there’s no lever to pull.
Ashish Rangnekar frames it as a rewrite of the no-code vs low-code vs custom development debate: no-code isn’t obsolete, what changes is where the decision boundary sits. I agree. The mistake isn’t choosing no-code, the mistake is not knowing you’re choosing.
The new barrier is judgment
Here’s my thesis, and it’s the only thing I care about you taking away.
The barrier was never syntax. Syntax was the teachable part, the part that gets automated. The real barrier was always knowing what to build, how it should behave when things go wrong, and what happens the day it grows. Nobody has automated that, and nobody is close.
A model will write any function you ask for. What it won’t do is tell you the function you’re asking for is the wrong one.
That’s why the work moved up a level: from writing code to specifying behavior. It’s exactly the flow I described in Spec Driven Development: before asking for an implementation, you define rules, happy paths and — above all — sad paths. The AI implements; the judgment is yours.
And this is good news for the non-programmer, not bad. Because you already have the business judgment. You know what counts as a valid return, which customer is profitable, which process is bleeding money. That input, the hardest thing to transmit to an outside developer, is now the primary input.
What you’re missing isn’t coding. It’s knowing how to ask a system the uncomfortable questions.
How I decide: three questions before picking a tool
I don’t have an ideological rule. I have three questions, and the answers decide.
1. What happens if this disappears tomorrow?
If the answer is “I lose an afternoon”, build it with whatever is fastest. If the answer is “billing stops”, don’t build it on something you can’t export.
2. Who operates this in six months?
Not who builds it: who fixes it. If the answer is “me, and I don’t code”, then you need a tool that fails loudly and visibly, even if it’s less powerful. Observability matters more than elegance.
3. Is this piece my competitive advantage, or is it plumbing?
Plumbing — notifications, syncs, forms, reports — goes to no-code with zero guilt. What differentiates you goes into code you can version.
In practice this lands on a hybrid architecture. That’s precisely the conclusion uCertify reaches comparing no-code AI with traditional development: the debate isn’t which one is better, it’s which one fits your situation, and the blended approach is what balances speed, cost and control.
In my case the split looks like this:
Plumbing (n8n, managed platforms)
- syncs between SaaS tools
- notifications and alerts
- recurring reports
Core (code in Git, Docker, my own infrastructure)
- proprietary business logic
- handling of personal data
- anything that has to survive a vendor changePlus one cross-cutting requirement, whoever is building: if a process runs unattended, it has to tell me when it does nothing. Silence is the default failure mode of every automated system.
# The alert almost nobody writes, and the one that saves weeks of corrupted data
# Rule: if the flow processed 0 records on a run that should have had data, that's an incident.
if [ "$PROCESSED" -eq 0 ]; then
notify "sync: 0 records processed — check source"
exit 1
fiWhat this means for custom software businesses
The interesting consequence isn’t that more people will code. It’s that building software becomes economically viable for problems that never added up before.
Think about the repair shop, the clinic, the accounting firm, the small distributor. Every one of them has a weird, specific process no SaaS covers well, and every one of them has lived with the same dilemma: either bend to the generic tool, or pay for custom development that never pays for itself. That gap — real problems too small to justify a project — is where AI genuinely changes the economics.
That’s where I see the opportunity, and it isn’t in “making apps”. It’s in being the person who understands a sector well enough to specify the problem correctly, and who also knows how to operate what they build. That combination used to be extremely expensive. Now it’s within reach of one person.
What hasn’t changed is that software has to be maintained. Anyone selling you otherwise is selling day 1 and charging for day 2.
Conclusion
Coding is no longer the barrier. I’ll sign that.
But the honest conclusion isn’t “anyone can build software”. It’s: anyone can build version one, and almost nobody is ready for version two. Between the two there are backups to restore, tokens to revoke, silent failures to detect, and decisions about where your logic lives that will constrain you for years.
If you’re a non-programmer and you’re getting started: go for it, genuinely. Build the thing. But don’t confuse the absence of code with the absence of a system. Start by defining how it should behave when it fails, not when it works.
And if you’re a developer and this reads like a threat, my take is the opposite. What got devalued is typing. What got revalued is exactly what we do when nobody’s watching: thinking about the failure before it happens.
See you on the net.