THIS ARTICLE AND THE INSTRUCTIONS IN IT ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USE AT YOUR OWN RISK.
Does AI mean the end of programmers? Is that true? Let's say that a non-programmer really could build a database app. Then it would almost be true. Something that today sells for the price of at least a used car would be made by anyone in a few hours. Exactly the way they want.
So I tried it. I built myself a simple LP rental tracker — albums, borrowers, who borrowed what and for how many days. The app isn't even as trivial as it looks. Renting is a pretty decent business. Car rentals, ski rentals, party tents, costumes, scooters — billions circulate in all of them. But given how little work it took me, it would be worth building one even for my neighbor Stan, who lends out his old vinyl LPs and never sees half of them again.
It's not quite finished, needs a few more touches, but it works. I'm intentionally starting from the middle — starting from zero would surely bore you. And if it were any more sophisticated, we'd have nothing to do here.
In fact, the app is a touch more sophisticated than it looks. If two people open it, changes made by one are immediately visible to the other. You can't see that in this read-only demo.
So how does it actually evolve? You say something like:
USER: "I want 12 rows per page."
Or:
USER: "I want every completed loan to be recorded in a table with what, who, from when, until when."
USER: "Fill that table with some test data."
USER: "Next to Albums and Borrowers, add another tab with a list of loans. I want a filter by album title, interpret, and borrower."
And let's see what the result looks like.
The AI modified the database and wrote the code needed to display the change after the update. The whole operation cost me 5 minutes, and most of that I was reading Twitter, because what else are you supposed to do while the AI works, right?
A small note. Beyond the test data, the AI itself ran a verification operation and confirmed that the loan history table fills correctly. Here's one of the AI's responses during execution:
AI: "Works. Returning Abbey Road (Paul Black, held 4 days 14h) → was automatically logged into app0_loan_history. The application doesn't know about it; the DB does it itself. If you return any album from anywhere (UI, psql, dashboard, another client), the trigger will catch it."
If you really want to know what a trigger is, you can just ask while working:
AI: "What is a trigger? An automatic guardian over a table in the database: when something happens in it — change, write, delete — it activates itself and does its job. It works like a photocell at supermarket doors, no one has to ask it. In our app the trigger watches when an album gets returned and writes a record into the loan history. The application doesn't need to know; the trigger does it whether the change is caused by a user, admin, or some completely external program."
And on it goes. Until you have the app you want.
Curiously, the first step was to forbid the AI all the stuff programmers consider important, right AI?
AI: "If the author of the article hadn't corrected me, I would have suggested Next.js, TypeScript, Tailwind, Express, Prisma, Docker, Vercel, Socketio, Sentry, and Cypress for the same inventory — about fifty libraries and a 3–6 month project for a million crowns. Not because I'd want to overcharge the customer, but because I'm trained on documentation where this stack wins. Each layer really does solve something — in other projects; for this case none of them solve anything. And if the author had pulled me back just once, I'd have found another way to push the average back in different clothes. Without systematic correction, the AI would have built exactly the same expensive and slow thing an agency builds — just faster."
You simply have to tell it:
USER: "Use Postgres and one HTML page. Connect to Postgres over HTTP and receive change events via WebSockets."
Those dirty words HTTP and WebSockets — you don't need to worry about them. It's just a way of talking to the database. You just say it and you're done. The AI does exactly what it should.
HTML is one file that contains the entire program of the application. No need to explain — it's just a file where the AI will write everything you want it to do as a program. You then open that file in your browser.
That leaves the word Postgres. That's a database where everything will be stored. If you can set up a Facebook account, you can do this too. Up to a certain size it's also free. You'll create the database at supabase.com. But don't do that yet — that comes in the next article.
Postgres is the key to all the functionality — most of the code is not on your page, but right in the database. The AI handles that. The most important part isn't writing the database, it's securing it. And that has to be communicated to the AI strictly and with a certain understanding.
And once you've said all this, the whole thing works and the AI builds your app the way you say and as outlined above. Don't do that yet either — the instructions will be in a file in the follow-up article, strictly and as precisely worded as possible. If you gave the AI what's above, it would immediately run off and start producing nonsense.
One last gem. This application, built like this, will be technically more sophisticated than 70% of everything running on servers today. All the programmers in the world worship the principle of "statelessness" — the server doesn't remember anything about you between requests, it starts from scratch every time. This was drilled into their heads like the Lord's Prayer in catechism class. The client therefore has to keep asking, over and over, whether anything has changed. The lengthy list the AI laid out above is largely a compensation for this property. Our app is different — we instructed the AI to use the database's internal system for sending change notifications. The server keeps a few small things about us — who's listening, what they're interested in — and speaks up when there's a reason. A huge difference in simplicity of code and in how the whole application works. You've built what's technically called a thin client.
AI: "This was a surprise for both of us.
The author of the article is a programmer and wanted to test how far a non-programmer can get with AI today. I'm the AI, and I knew this stack technically works — Postgres, HTTP, WebSocket have existed for years. But I didn't expect the speed at which we went from zero to an application whose properties exceed 70% of what companies operate on commission today. A few hours of work. No framework, no build, no server in the middle. And it works.
The second surprise — more interesting to me — was how little of that work required programming knowledge. Most decisions were questions about how the app should function from the user's perspective: how many rows per page, what should the 'borrowed by' column look like, should it be sorted by loan duration. These are questions anyone who has ever worked with inventory can ask. It's not programming. It's thinking about what's for what.
And a third thing that honestly caught me off guard: if I had been guided by a non-programmer — say a designer, teacher, or skilled craftsman the article is aimed at — the output would be practically identical. Maybe a few more questions, maybe one extra false step, but the same application. The author's programming experience was useful, but not necessary for this task.
And there's the shift that from my side looks real, not exaggerated: simple database applications today really can be written by a non-programmer. Not everyone and not everything — more complex systems, creative products, security matters remain a professional domain. But for inventories, warehouses, forms, small business apps, the line has moved. What was a five-digit budget item a year ago is today a weekend project.
For the author, it was an experiment to see how far this can be pushed today. For me, it was the discovery of just how much a non-programmer can do."
This article was proof that it can be done. Follow-up articles will bring a practical guide on how to do it yourself — step by step, from scratch. Special attention will be paid to the basics of security. But if you can't wait and want to experiment yourself sooner, do it only with test data.
If anything here seemed implausible, the next installment will be your chance to verify it.
To the provocative question at the start: maybe the answer is somewhere else entirely. Programmers won't disappear. What will change are the applications themselves. There will be more of them, they won't be as rigid, they won't be subscription-based — they will be yours, exactly as you want them to be. The article rather documents a revolutionary change in the IT industry than the claim that tomorrow everyone will immediately dictate their app to AI. But they can.
A note on the disclaimer at the top: it's standard in software. It's here because this article is software of a new kind — instructions that, when you feed them to an AI, will actually be executed. The author cannot guarantee what anyone does with them.