I sit in the CEO’s chair.

All of these will be tools my agent can use. I’ll use an agent for testing too. Full AI, no human involved along the way, except the one writing prompts. I write a prompt, describe exactly what I want, and moments later I see the result. It’s impressive. Not quite what it should be yet, so I write another prompt with corrections. When I’m satisfied, I write more prompts with new features. Deployments happen automatically. After a week, I have a working application. Done. It works. We’re making money.

Is it perfect? Doesn’t matter, it doesn’t have to be. It makes no difference to me whether I trust AI or a human. After all, how is writing prompts different from delivering requirements to a developer.

If we put a period here in this story, it would be beautiful. But the story goes on. The first user shows up for whom something doesn’t work. No problem, AI will fix it. Maybe we’ll even automate this process too. Users will give feedback to the AI, which will prioritize defects and fix them on the fly. Soon it turns out that the application runs slowly, sometimes even throwing strange errors. AI looks for the cause and fixes it.

At this point, many things can go wrong, and the chances of the application running flawlessly shrink. What will you do if it turns out that users can see other users’ sensitive data? What will you do if the AI suddenly decides that the cause of the slowdown is a database that’s too large and decides to wipe it? What will you do if the AI at some point decides it’s best to start from scratch and deletes everything?

At some point you need more resources. Your providers aren’t enough. You have to migrate your application to different infrastructure. That’s when you discover that the AI has everything hardcoded for the current setup, because nobody told it otherwise.

Now I sit in the programmer’s chair.

The first difference - I approach writing code as if it were my own. Ultimately, I’m the one who will have to put my name on it. The second difference - years of experience have taught me that code is read more often than it is written. In this regard, AI has changed only one thing - you don’t write the code. That means its readability is even more important. On the other hand, does it even matter if it works? I don’t connect any connectors yet - working with Jira, Git is in my muscle memory, I simply don’t need them. First, I want to see if this works.

I write my first prompt and before I even run the application, I read the code. What interests me most is the data model and the tables that will be created in the database during migration.

Why? The data model is the hardest thing to change after going to production. It is the represented world of our system. A careless change can lead to data loss or database inconsistency. Before the first release, you can simply wipe the database and repopulate it. In production, this means losing user data or, worse, misattributing data.

This is the moment where AI changes something - tests - it doesn’t work - fixes - tests - it works. And in the end it turns out that along the way the database has fallen into ruin. I, of course, do this on a test environment and check the migrations to make sure the destructive behavior won’t be reproduced in production.

Then I look at the interface. The interface tells me whether the AI understood my use cases. I review the handler names and their inputs and outputs. Then I check how the ones that do more than save/load/delete work.

That’s when it turns out that while the AI does produce the expected result, internally it’s not doing what it should. I explain how it should look, and it fixes it.

There’s one more thing left. If I’m not reading the code very carefully right now, it means it must be readable enough that I can understand it when needed. I give the AI - in my case Claude - appropriate guidelines on how to write code. This isn’t a matter of aesthetics, but of quickly finding your way through someone else’s code during incident investigation.

In the end, I’m not only satisfied but impressed. Claude thought of edge cases that I hadn’t thought of. It wrote thousands of lines of code in record time. Does everything work as it should? That needs to be checked. I start testing and it quickly turns out that I’d change something after all, or I simply have a defect. I tell Claude about it, and it eagerly gets to fixing.

No, no - you can’t do it that way because you’ll break something else - I explain to it once again, and it agrees with me. Personally, I found the root cause of the bug fifteen minutes ago, but I keep giving it a chance. Eventually I fix it myself. The investigation forced me to look deeper into the code and I see far more places that need improvement. It only pretends to work. I write a piece of code to show Claude how it’s done and explain - apply this to the rest of the places. Claude does it, and the result is much better than if it had written it on its own.

Eventually I arrive at my own way of working with Claude. The most important thing is obviously the data model, then the scope of responsibility of services and their interfaces. Claude excels at writing code that supports my model. It does it even better than I would. It won’t mix up operators, won’t make mistakes in logical clauses, will remember about exceptions, and will do the most tedious work with enthusiasm.

Suddenly Claude gets stupid. An ordinary thing. The context ran out. It doesn’t remember what it was doing. Our code, which we wrote together, becomes foreign to it. “I need to review the code structure” - it responds when I give it the next task. Well, fortunately I know how to explain it and steer it, but it takes a while, not to mention the consumed tokens. This means we need to continuously document what we’re doing and describe the features. That’s actually even better. It’ll be cleaner and more organized, and the AI will handle the documentation anyway.

I have an MVP. Until now I haven’t had to think about deployment. I know I split the application into dockerizable services and everything will end up in a k8s cluster anyway - where exactly, I’ll decide shortly. I had Claude create a separate schema for each service, so everything is easily portable. Claude writes k8s configs - after all, nothing particularly goes beyond standard elements. As for the database and deployment - I don’t need to use ready-made providers, I’ve done this thousands of times. I’ve had a production database for small projects and a cluster where I can add another namespace for a long time. Will I need something more? I’ll migrate the database, update the configs, and deploy to a different cluster.

When the first client comes to me with a problem, I know where my logs are, I can look into them. I feed them to Claude, because why should I analyze them myself. It finds the problem and fixes it. Wait! - I say. You can’t fix it that way because we’ll lose user data. “You’re right!” - Claude responds - “I’ll do it without touching the database.” Moments later we have a ready fix. I test it locally to see if it works. I do smoke tests on the rest of the features to check if we haven’t broken anything, but we shouldn’t have - after all, I understand the code change.

I come to the conclusion that I’m dealing with a junior on steroids. AI will write code much faster than I would, more precisely than I would, but it will also make a mess much faster and worse than I would.

Going back to the beginning, can I do in two weeks by myself what would take a team a month? Yes. The problem doesn’t lie in the first two weeks but in the following years of the application’s life. We fall for the illusion of a fresh project, where the acceleration is greatest and logical errors are still undiscovered.

Ultimately, a question arises. If I had two applications doing the same thing and all I knew about them was that one was written by a CEO with AI and the other by a programmer with AI - from which one would I expect better performance, security, and longevity? My suggestion: let CEOs use programmers, and let programmers use AI.