I Stopped Writing Code at My Own Company

I stopped writing code at my own company.

Not because I forgot how. Not because I got promoted into some meeting-filled version of myself I don't recognize. I stopped on purpose, and it's the best decision I've made for AIFlowiz all year.

I know how that sounds. I run an AI agency. Code is the product. Saying "I don't write it anymore" sounds like the kind of thing a founder says right before the wheels come off. But I want to tell you how I actually got here, because the path matters more than the conclusion, and because I think most people trying to get real leverage out of AI agents are optimizing the wrong thing.

For a long time, my bottleneck wasn't the agent. It was me.

I'd fire off a task, the agent would come back twenty minutes later with a diff, and I'd sit there reading it line by line like I was still the only engineer at a two-person startup. Some days that was fine. Other days I had four of these queued up, and I was the thing standing between "done" and "shipped," reading code faster and faster and still falling behind. I remember thinking: this is supposed to feel like leverage. It felt like a second job stapled onto my first one.

The advice everywhere told me the fix was a better prompt. Tighter instructions, more context, a longer system message. And sure, that helps a little. But I kept noticing something that advice never mentioned: the founders and teams who were actually getting compounding output out of agents weren't the ones with the cleverest prompts. They were the ones who'd quietly redesigned how they worked, the same way you'd redesign a company, not a conversation.

That's the part nobody puts in the thread. Prompting is a skill. Running a crew is a different skill entirely, and it's the one that actually scales.

So I started paying attention to my own habits instead of my prompts. Where was I actually spending time? Not writing code, barely. Reading code, constantly. Repeating myself to agents that had no memory of yesterday, constantly. Sitting in one terminal window babysitting one agent while three other ideas rotted in my notes app, constantly.

Each of those turned out to be a fixable design problem, not a model problem.

The first thing I fixed was where I live while I work. I moved almost everything into the terminal, on purpose, and kept my hands on the keyboard as close to always as I could manage. This sounds like a small, nerdy preference, and it is, but the reasoning behind it isn't. Every time you reach for a mouse, your brain context-switches. It's a small tax, but you pay it constantly, and constant small taxes are how a day disappears. Living in one fast, keyboard-driven environment meant I could start a task, jump to another, check a third, without ever breaking the thread of what I was doing. It's also the only setup I've found that stays identical whether I'm at my desk or ducking into something from my phone. Same muscle memory, everywhere.

The second fix was memory. Every agent I spin up starts as a stranger. It doesn't know how we like to work, what we've already tried, what mistakes we've already paid for. So instead of re-explaining myself every single session, I started keeping a running file of exactly that, the honest, boring preferences that used to live only in my head. Don't default to the cheap solution just because it looks faster to build. Reproduce a bug the way a real user would hit it before touching anything. Small, specific, hard-won rules, the kind you only get by watching an agent get something wrong and correcting it. Over time that file becomes the actual institutional memory of how AIFlowiz builds software, and it gets smarter every time something goes wrong once and never again.

The trick is keeping that memory lean. Cram too much in and every agent burns tokens loading context it doesn't need for the task in front of it. So the stuff that's only relevant sometimes, how we do end-to-end testing, how we structure a certain kind of feature, gets pulled out into its own separate reference that only loads when it's actually relevant. The always-true rules stay in the core memory. The sometimes-true rules become something an agent reaches for on demand. Small distinction, big difference in how sharp the agent stays over a long session.

There's a third fix that took me longer to notice, because it's not about the agent at all. It's about what you hand the agent to work with.

I used to assume the model was the whole game. Better model, better output, end of story. Then I started paying attention to how much time an agent burned just talking to its own tools, not thinking, just moving data back and forth through some heavy, chatty interface built for a human to click around in. Swap that for something lean, something built to be read and written by a machine instead of stared at by a person, and the same agent finishes the same task faster and cheaper, with no change to the model at all. It sounds like a small technical detail. It isn't. The tools you give an agent shape its behavior as much as the instructions you give it, and almost nobody audits that side of the setup. I do now, every time we wire an agent into something new, and it's usually where the easiest wins are sitting.

Once an agent actually knows how we work, the way I talk to it changes too. I stopped asking for a plan and accepting a wall of text back. A thousand words of "option A does this, option B does this" is exhausting to read and almost impossible to give precise feedback on. Now, before anything gets built, I ask the agent to show me, not tell me, a rough working version of the idea I can actually click through and react to. Point at the part that's wrong. Approve the part that's right. Building nothing until we agree on what "right" looks like turned out to save more time than any prompt trick I ever tried, because the expensive mistakes in software aren't typos, they're building the wrong thing beautifully.

Here's the part that actually changed how I spend my day, though.

When an agent says a task is done, the old instinct is to open the diff and start reading, the same instinct that was burning me out in the first place. I had to consciously kill that instinct. Not because reviewing doesn't matter, but because reviewing every single line personally doesn't scale past one person working alone, and it never did, agents or not. Nobody becomes an engineer because they dreamed of reading diffs all day.

I noticed something else too, once I actually sat with the discomfort instead of just pushing through it. The instinct to review everything wasn't really about quality. It was about control. Reading every line made me feel like I still had my hands on the machine, even when my hands weren't the thing making it run anymore. That's a comfortable lie to tell yourself, and I told it for longer than I'd like to admit. Letting go of it felt less like delegating and more like admitting the old version of my job was already gone, whether I kept reading diffs or not.

So I stopped thinking of myself as the last engineer checking the work, and started thinking of myself the way a director thinks about a team. A good engineering director doesn't review every pull request either. They build a process that catches problems before it ever reaches them, and they trust the process because they built it to be trustworthy. That's exactly what I did, except the team is agents. Before anything reaches me, it goes through its own gauntlet: a fresh, skeptical pass that tries to find what's wrong with the change, a real end-to-end check against what we actually meant to build, not just a unit test that technically passes, a documentation pass, a lint pass. Only after all of that does it land in front of me, tagged with how risky the change actually is. Low-risk changes I barely glance at anymore, because I've watched that gauntlet catch the same class of mistakes over and over. High-risk changes, the ones touching money or user data or something structural, I still read closely. That's judgment, not habit, and it's the only place my personal attention is actually the scarce resource.

That single shift, from reviewer to director, freed up more of my week than any other change I made.

And once I had time back, I noticed the obvious next question: what do I do with agents when I'm not even watching? Some tasks are boring in a very specific way, the kind of thing that just needs iteration and judgment over a long stretch, improving something measurable, hunting down a usability problem by actually using the product the way a real person would. Those don't need me hovering. They need a clear goal and a condition for stopping. So some nights I just describe the objective, set a limit on how long it can run, and go to sleep. I wake up to a branch full of small, tested commits and I get to decide, with coffee in hand, which ones are worth keeping. The agent didn't get smarter overnight. I just stopped being the reason it had to wait for me.

From there it was a short step to running more than one agent at once, each in its own isolated workspace so they're never stepping on each other's changes. That part sounds simple and it is, mechanically. What's not simple is what it does to your day. Juggling four or five parallel sessions, each wanting your attention at a different moment, is its own kind of exhausting, a different flavor of the exact bottleneck I was trying to escape. You've just traded "reading every diff" for "context-switching between every session," which is not actually a win.

I want to be honest about that stretch, because it's the part most people skip when they talk about scaling up with agents. For a while, running four parallel sessions felt worse than running one, not better. I'd flip to a tab and have no memory of what I'd asked it to do twenty minutes earlier. I'd answer a question in the wrong window. More agents working didn't feel like more leverage. It felt like managing four impatient interns at once while also trying to think. If I'd stopped there, I would have told you parallel agents were a bad idea. The problem wasn't the parallelism. It was that I was still trying to be the coordinator myself, on top of everything else.

The real unlock was putting one more layer between me and all of that: a single point of contact that manages the crew for me. I don't talk to five agents anymore. I talk to one, and it decides which task needs its own workspace, which agent gets it, when to check in, when something needs to come back to me for an actual decision instead of a status update. I only see the moments that require judgment. Everything else gets handled without ever touching my attention.

That's when I noticed the pattern had a name, and it wasn't a technical one. It was a management one. Every improvement I made had the exact same shape: less of me doing the work, more of me deciding what the work should be.

This is also, quietly, the whole reason AIFlowiz exists as an agency and not just my own side project. The workflow I just described isn't something I only run for myself. It's what we set up for every client engagement, because the mistake I see most teams make when they "add AI" to their process is bolting a chatbot onto the same workflow they already had, and wondering why nothing actually got faster. Handing someone a smarter model without redesigning how work moves through their team is like handing a company a faster typist and calling it a transformation. It isn't. The gain isn't in the model. It's in the memory, the review gates, the parallel workspaces, the one point of contact managing the rest, all of it working together as a system. That's the part clients are actually paying for, whether they know to ask for it by name or not.

I think that's the actual unlock, and I don't think enough people are saying it plainly. The upgrade AI agents give you isn't faster typing. It's a forced promotion. You stop being the fastest engineer in the room and start being the person who decides what the room should be building, which is a genuinely different job, with genuinely different hours, and for me, a genuinely better one.

If you're building something similar and you only take one thing from this, take this: go find the place in your own workflow where you are personally the bottleneck right now, today. Not where the model is weak. Where you, specifically, are the thing everything else has to wait on. For most people that's reviewing every single change by hand. Build one piece of process that catches problems before they reach you, even something small, and give it a real test on a week's worth of actual work before you trust it. You'll feel exactly how much time comes back the moment you do.

I still don't write code at my own company. Some weeks I barely open an editor at all. For a long time I would have told you that meant I'd stopped being an engineer.

I don't think that anymore. I think it means I finally started doing the job I actually signed up for when I started AIFlowiz in the first place, which was never to be the fastest typist in the room. It was to decide what gets built, and why, and to build the kind of team, human or otherwise, that I trust to carry it out without me standing over their shoulder.

That's the whole workflow, honestly. Everything else is just details.