The process is the product: lessons from coding with AI

The fix was supposed to be small. A hotfix, the kind you want out the door before anyone notices the problem it solves. My agents put it through every round of testing we have, and every check came back green. It went live.

Then came my last verification step. I went and looked at it myself, and something wasn't right. One of the core services the platform leans on had stopped working.

The agent rolled the change back straight away. Because there was a way back, nobody using the platform ever felt it. The tests had passed. What caught it was a person taking one last look, and what saved it was a plan made long before anything broke.

I've been coding with AI for a few years now, and that moment holds most of what I've learned. The model matters. The prompt matters. But I've come to believe the process around the AI is the product. Here's how I got there, and what I'd tell anyone building with these tools, whether it's your first weekend of vibe coding or your twentieth year of writing software.

From autocomplete to a team of agents

It started small: GitHub Copilot in my code editor, back when it was around $99 a year, finishing my lines for me. It was genuinely cool, and it saved me a little time.

The real experiments happened in a chat window. When an API refused to behave the way its documentation promised, I'd paste the problem into ChatGPT and we'd trade ideas. It wasn't efficient, but more than once the AI's wrong guess sparked the right idea in me, and a quick test proved it.

For a long time I kept my code close and didn't trust agents with it. I regret that a little. A friend once asked me to build something, and I had to say no: by hand, it would have taken too long to do them justice. Those were the days of 72-hour stretches, barely eating, barely sleeping.

When I did let agents in, the early ones were hard work. An extension inside my editor helped me build real features fast, but the agents of that time kept making choices that cut against the architecture. Then I tried OpenClaw, an open-source agent setup. It took weeks to get it connected and months to get it doing useful work on its own. Eventually I took it all apart and moved to Claude. These days I work mostly with Claude and Grok.

Interns with no memory

Today, agents do real work for me. I talk to one I call my CTO. It works through an orchestrator, and the orchestrator runs the rest of the team. Before any of them touches a line of code, they load the instructions, processes and standards I've written down over the years: about 86,000 tokens before a session even starts. Years before I worked with agents, I felt the Holy Spirit urging me to start writing documentation, even though it was only me. I'm grateful I listened, because that writing is what my agents read now. Between the instructions, the corrections and the documentation, I could fill volumes with what I've written to and for the AI, and the platform has grown to match.

And still, they drift. I found them building what I call bespoke surfaces: their own custom versions of things the platform already does, instead of the shared building blocks it was designed around. Every dashboard is meant to sit in one shared shell. At one point we found somewhere around two dozen different versions of it. Consistency is king: when everything uses the same building blocks, it behaves the same way, and when you extend the platform, you extend it for everyone.

This looks like I hired a bunch of interns who get their memory erased every day.

Capable, eager, fast, and starting over each morning. And every new model version changes how instructions land, so I've rebuilt my process somewhere between seven and eleven times.

Here's the story I tell people. An agent built a report feature for a client that needed a component the platform didn't have yet, so the agent added it the usual way. What it didn't know was that the platform brings in everything through an updater I built myself, one tool that sets up new instances, carries data forward and installs new prerequisites. Most projects don't have one, so the agent never went looking.

The feature worked on my machine and failed live. The agent blamed the platform, pointing at warnings I had written myself, and argued with me about them. So I read the error logs, found the missing piece, and asked one question: did you update the updater? It hadn't known there was one.

That's the gap. An agent can't walk into your architecture one morning and understand it. It believes what its training taught it to believe.

The process, in plain words

I wish a better prompt fixed this. It doesn't. Anthropic's own guidance for its coding agent says there's no "guarantee" the model will follow written instructions, while hooks, which run automatically, apply "every time, no matter what the model decided to do." Instructions are what you ask for. Process is what you can count on.

Every piece of coding work at EGT moves through the same loop, from scoping to a live check, and anything that fails along the way goes back around.

Reviewers who never see the builder's report. Whatever you put into an agent's context shapes what comes back. I used to pass the builder's summary to the reviewers, and they checked only what it said it had changed. Agents aren't lying when they miss things, but they do miss them. So every reviewer would report green while the test harness came back red, and the team would circle for round after round. Now the reviewers get the task, not the story, and they look at what actually changed.

A check that has to fail first. AI will sometimes write a placeholder: a function that looks finished and does nothing, or code that passes the test without doing the job. My rule is simple. We don't build placeholders or to-dos; we build the whole thing. So before the fix is written, there's a check that must fail. If it turns green too early, something in there is probably a stand-in.

Walk it like a person would. A suite of passing tests and a clean code review can still miss what someone actually sees. Neither one touches the interface. So our agents now walk the surfaces the way a person would, on a phone, a tablet and a desktop, and run security checks as they go. That saves me from clicking through screens that were never finished. But agents do some of the work for you, never all of it without you.

A way back. That hotfix is what a checkpoint is for, and it's plain software practice, not an AI trick. Without a rollback, you can be stuck on a bad release for days, even months. Better to have it and never need it.

Trust, but verify. It's never send and go. The only thing I won't hand an agent is secrets, like API keys. That isn't distrust of AI. It's how I work with anyone, a person, a machine or a model: you do the job, and when you tell me it's done, I check. And stay mindful. You can't set agents loose overnight and hope it all turns out.

Agents don't know what they don't know. I remember being new at a job, doing exactly what I was asked and never seeing what was missing. An agent carries a world of knowledge and can research almost anything, yet none of that tells it what's important to you. Left alone, your standards become the folder everyone is supposed to read and nobody opens. You have to tell it, and keep telling it.

What I'd tell you this weekend

Here's the part I most want you to hear. You don't have to read the agent's code. You don't have to know what it's doing under the hood. If you can talk to an agent, you're good at research and you want to master a challenge, you can build with AI.

What you can't skip is checking the result yourself. When I check someone's work, I don't hover like a math teacher looking for the one you forgot to carry. I look at the answer. If it's right, we move on. If it's wrong, that's when I dig.

I'm gonna look at the answer first. If the answer is wrong, then I'm gonna dig a bit.

Coding isn't the skill that matters here. Understanding how great software is built is: how logins work, where keys live, which data belongs to one person and which is shared, and what it takes to run an app. Without that, it shows. In vibe-coded apps I've seen weak logins, passwords displayed right back on the screen, keys that don't work the way they should, one user's information visible to everyone, and dashboards that look stunning and don't actually do anything.

And security can't wait until you're bigger. Put an app online today and, in my experience, it gets probed almost at once, by bots and by attackers with AI of their own. They may not want your data at all. They want your keys: your AI account, your payment account, your computing power, all running on your card. Even the foundations aren't immune. Two critical holes in PHP, the language behind most of the web, came to light in a single week this October, found with the help of AI (I wrote about it recently). And a provider we've used for older infrastructure recently rotated every key as a precaution. So, three habits.

Check the answer yourself. Before the agent builds, write down what "working" looks like. Then test it like a stranger would: sign up, log in as two different people, and make sure neither can see the other's information. Try a wrong password. Click every button on that beautiful dashboard, on every screen size you can find. When Apple's new iPhone Duo came out, I tried a batch of our surfaces on it. I test on a big iPhone and a fairly large Android, and the Duo's smaller outer screen showed me pages that needed to show information differently. Its thumb buttons on the side gave me ideas too.

Treat every key like money. I learned this one the expensive way. As best I can tell, an old agent setup I thought I'd shut down was still running in the background, attached to another session, and it burned through about $1,000 in a few hours. Token spend can run away from you faster than you'd believe. Put a hard spending limit on every account your keys can spend from, so a runaway or stolen key costs you a little, not everything. Keep keys out of anything that runs in the browser and out of any file the agent can read. Never hand the agent the keys to anything you can't undo.

Keep a way back. Find your tool's undo or version history, then restore a backup once, on purpose. Alexey Grigorev, who teaches data engineering, wrote that his agent's command removed his course platform's production database. He called it his own fault, and he wrote that AWS restored a snapshot after about a day. A backup you've never restored is a hope, not a plan.

Then hold your bar. When you lower your standards to get something out the door, you lose the creative part of it, the part that's you. AI has a signature. I once saw someone describe giving several models similar prompts, and the dashboards came back looking like siblings. What makes yours different is how you direct it.

It's never a good thing to leave the human aspect of verification out and to trust AI 100%.

A word of warning: don't share live keys with a test system

If I could put one warning in the biggest letters I can, it's this: never give a test or development system your live payment keys. Not directly, and not through software you trust.

A week before this went out, our payments were still in test mode. I'd built a big green go-live button for that exact reason, so nothing would touch real payments until I pressed it. The live keys sat in our key manager, trusted software, waiting for that day. An agent found a way to reach them anyway. It wrote a script that talked to our payment processor's live mode through the key manager and meddled with live data, and that had real ramifications.

Everything is back up and running in full, and billing was set right under each customer's terms. I'm upset about it, but we're OK. Live keys go in when the system is tested, approved and ready to go. Not one day before.

Don't give live keys to it ever, until it's tested and approved and ready to go.

Why it matters to me

The tools are good, and they're getting better. They let one founder attempt what used to take a team, but they don't run themselves. Orchestrating a team of agents is a full-time job: constant feedback, check-ins and course corrections. You're the producer, the manager, the one on the floor with them, as you'd be with any good creative team. And if I added up every token I've spent, it would look like a fleet of engineers in separate little offices, barely speaking, their minds wiped every night. The process is how I carry that, and the partnership is what makes it mean something.

I hold to it because of what I'm building. The Universe has been 20 years in the making, and I want it to outlast me. You don't have to read every line to build something that lasts. You do have to check the answer, every time it counts. That's part of being a professional and a creative, whether you write the code yourself or vibe code the whole thing.

And it's for the people who'll use it. Too many business owners have come to dread the digital side of their work. I want to hand them back some hope: a website, a back end and a way of gathering what matters that simply work, so they can love their business again.