AI-First Software Development Isn't About Copy-Pasting From ChatGPT
We built our latest web app, zedl.app, without writing a single line of code ourselves.
We had an idea, a real pain point, the know-how, and the drive to build it.
The app has been running in production for a while now, and it has paying customers. We built it while both holding full-time jobs, without outside help, no offshore developers either. We had been riding the front edge of the AI moment since 2023. Things accelerated right around the time we decided to actually build this. It helped that we genuinely wanted to know: how much do you still have to code yourself, and how much can an LLM take over?
What and how we work today has less to do with programming than with architecture and orchestration. We built a lean setup that fits exactly how we work. Now we have a workflow where, by describing features well, an LLM can develop most of it on its own, test the software, and push it to production. We designed the architecture so the coding agent has guardrails in place and can get to work without us hovering over every step.
We used to call this automation, but the definition doesn't quite fit anymore. It still runs automatically, and in most cases the outcome is deterministic, but the path there is different every time.
The Real Difference Isn't Technical
In conversations with business partners, clients, and friends, I've noticed something shifting in professional circles right now. Decision-makers no longer treat AI as just "slop" or a fun gimmick. They're actively hunting for the "right" tool they can plug in and use. I think that's the wrong approach.
The better the models and agents like Claude Code, OpenAI Codex, or Cursor get, the easier it becomes for non-programmers to produce decent solutions. Whether the end result is top-tier or not depends less on the model or the tool alone, and more on the expert who built a process that can consistently deliver top-tier output. That's been roughly true across all the major providers for about six months now, if you know how.
Most decision-makers have no idea that people already inside their own company are deeply engaged with this technology, have very good ideas, and are already building them. The problem is these people aren't visible with the right title, they mostly stay well under the radar. I don't know why that is.
What gets lost in the tool-versus-platform-versus-model debate is the actual question: how does the thinking behind the work change?
While building zedl.app, we didn't use ChatGPT to copy-paste code. We identified and established the processes needed to give an agent the ability to implement our requirements. Simplified, it looks like this: we give the coding agent a curated description of what we want, and sometimes minutes later, sometimes hours later, it messages us on Telegram once it's done, depending on how big the feature is.
Most people we show this to think it's some kind of trick. For us, it's become as normal as programming without AI used to be. The biggest changes for us:
- Processes are AI-first, not code-first.
- We no longer need the code to match our style or our exact idea of elegance.
- If the tests are well designed, that's enough. The app is stable and works.
For us, the new version of automation isn't building rigid rules anymore. It's having a system where the agent "automatically" completes tasks inside a defined lane.
What We See
From our own work and from what we observe elsewhere, a pretty clear picture emerges.
There are broadly two relevant currents: small expert teams of two to five people with the right mindset and skillset moving mountains, and on the other side, experts who are still thinking it through and testing in small steps how to bring these tools into their everyday processes.
The fundamental difference, in my view, is whether you're willing to let go of the idea that a large chunk of your existing knowledge is still relevant, and instead commit to moving forward in a new, different way.
One group is in the F1 car, racing on the track. The other group is on the same track, but behind a safety car.
That creates a strange state, a situation I call "asynchronicity." Two systems emerge in parallel and drift apart from each other. The process is neither even nor slow. It's fast and jumpy.
What This Means for IT and Digitalization Experts
There's a narrative floating around that supports a controlled transition, gradual transformation, milestones, the works.
What we've seen and learned is that the models keep getting better, but on codebases that weren't built AI-first, you burn through tokens endlessly.
We made a clean cut and started building new projects radically AI-first. The older projects get adapted step by step, as needed, for example when we develop them further.
Where we focus effort on existing projects is where we turn our implicit knowledge explicit, through thorough documentation and the guardrails for agents that build on it.
That's how we manage to keep growing a company on the side. We're lucky enough to be able to shape our own structures and processes and rethink them radically.
We're building knowledge and experience much faster than a lot of people around us. We're on a good path, and more importantly, the right one for us.
The Most Common Mistake: AI Decoration
Here's what I see most often: wherever the AI sticker gets slapped on today, it's usually a simple use case with a chatbot bolted onto it, or somewhere an AI summary gets generated. Then it gets labeled "AI-powered," while nothing actually changes about the process or the "how." It's just repainting the same old thing.
That's exactly where the distortion comes from, the one that leads a lot of people to conclude AI is just hype and nonsense. When in reality it's just a new surface on the old logic, with a fresh coat of paint. The result is usually a PoC, some nice slides, and the shared narrative of "well, technically it counts."
In my view, this AI decoration comes from a lack of commitment, which in turn comes from a lack of trust, paired with risk aversion.
The difference is still subtle right now. My guess is in two years you'll be able to tell very clearly which side of that split someone landed on.
Who Benefits
This way of working isn't an instant fit for every team or every organization. But there are groups where the leverage is already very concrete:
- Small expert teams who want to build products without standing up a large development organization.
- IT and digitalization experts who already see that AI is more than just another tool in the toolbox.
- Companies with existing codebases who want to understand why AI agents so often create friction there.
- Founders and product teams who need to find out fast whether an idea holds up.
- Decision-makers currently stuck choosing between buying a tool, picking a platform, or making a real process change.
Frequently Asked Questions
What does AI-first software development actually mean? AI-first software development means processes, architecture, documentation, and tests are built so a coding agent can work effectively. It's not about throwing individual prompts at ChatGPT. It's about putting the agent inside a system that provides clear guardrails, context, and verifiable results.
Did you really build zedl.app without classic programming? Yes, in the sense that we didn't hand-code feature after feature ourselves. We described requirements, designed architecture and processes, used tests and reviews, and let the coding agent handle implementation. Responsibility for the outcome still sits with us.
What role do tests play in this? Tests are one of the most important parts of the setup. If an agent writes code, the result needs to be verifiable. Well-designed tests give confidence that the app works, even if the code doesn't match a developer's personal style.
Is this only possible with Claude Code, OpenAI Codex, or Cursor? No. Tool choice matters, but it isn't the core of it. The better the models get, the more similar the results become across providers, as long as the process behind it is solid.
Why do so many AI projects at companies fail to deliver? A lot of projects stall at AI decoration. An existing process gets a chatbot, a summary feature, or an "AI-powered" label, but the underlying work logic stays the same. What usually results is a PoC that looks great on slides but changes little in real operations.
What about existing codebases? Existing codebases are often not built for AI agents. They lack explicit knowledge, clear documentation, good tests, and understandable guardrails. Then you burn through a lot of tokens without the agent ever really working autonomously and productively.
Who benefits the most from this approach? Small expert teams, product teams, and organizations with people who are strong in their domain and willing to rethink their processes benefit the most. The leverage doesn't come from a single tool. It comes from combining domain expertise, architecture, tests, and AI-first process design.