ChatGPT, and later, all the other LLMs that came out, have changed the game for coding. This isn’t a secret nor is it something new or earth-shattering. In fact, this first sentence should be so obviously a “duh” that right now you’re wondering if this will be another AI slop article that’s worth reading.

Well you won’t know unless you read more… but you should keep going.

I’ve been building software since I was 14, professionally since I was 21, and I’ve probably written millions, if not tens of millions of lines of code in my career.

But in the past 18 months, I don’t think I’ve written more than 5 lines, and yet, I’ve rolled out three products, am launching two more, and have consulted for 5+ companies.

I built:

I’ve had a few contractors helping along the way, but by and large, I oversaw and built a large majority of the functionality solo.

I was able to do this all because, as a solo developer on most projects and a small bootstrapped-founder on others, I had to move fast, which means I had to figure out a new way of doing things.

Here’s what that means for me, and hopefully how it might help some of you going forward.

The first thing I had to do to make it all work was to be okay with the idea of “losing my job.”

I have been coding for a LONG time. But I’m okay with never doing it again. I do like it, it’s a great feeling to be able to knock out a piece of functionality after having thought through it, struggling with the different nuances and challenges, only to come out the other side and see it in use by someone else.

But I can take it or leave it, if I’m being honest. Which means that, when AI came out and started getting better at coding than pretty much any human coder out there, I was very happy to embrace it.

Not everyone feels the same way. And I think that’s the first blocker to get over.

I’ve talked to a lot of devs who have said they don’t want to hand over their entire process to AI, that they don’t trust it, or that they don’t want it to handle everything for them.

For better or worse, I think that mindset will have to go away, quickly.

While they’re right, in that AI cannot be trusted, it absolutely can write code faster and more efficiently than humans, and it is fantastic at taking well-defined problems and finding good solutions to them.

In the end, coding isn’t really about coding, is it? It’s about creating a product that others can benefit from, and that companies can make money off of. I think most coders either forgot that or never cared about that to begin with.

That’s not to say that I’m hands-off when it comes to the projects I work on. In fact the truth is quite the opposite. I have been spending more and more time on the technical side of building things than I ever did before, it’s just that where I spend my time is different, and a lot of it is spent on building systems and managing the AI so it doesn’t totally screw up everything.

The most important part of never writing a line of code again is to build a very tight, guardrailed process that minimizes the chances of AI creating bad code. It’s a simple process, one that any tech team can implement.

Sadly for all the CEOs and non-technical managers out there, though, it still requires having some minimum number of (highly capable) engineers to oversee it all.

Here’s what it looks like, at least from my point of view:

If you’re coding full-time, or if you’re using AI on an hourly basis, you’re the token-based APIs are going to bleed you dry. But, right now, at least, Claude and Codex are offering highly-subsidized subscription plans. At $200/month for their highest plans, I’ve only hit limits once. You can even use your subscription plans for automated code reviews and locally-based agents.

It’s a given that AI is going to do dumb things, the key to moving fast is to create systems that minimizes the impact of those dumb things. The main thing that goes into this is to ensure you’ve got Git set up to run automated code reviews.

AI is quite good at catching errors and regressions, and if you implement automated code reviews with multiple AIs, you’ll catch a lot of would-be bugs before they get merged to main. I use both Codex and Claude. On any PR push, these systems will produce code reviews, and I can even tell my locally running agents to monitor the PR for reviews, automatically handle any comments that come up, and continuously fix and update the PR until it’s ready for my own review.

The great thing about using AI for coding is that we don’t really have to write our own tests anymore. This means we can have extensive test harnesses set up for our code. But be careful, the tendency will be to use simpler, dumber unit tests. Those are necessary but not sufficient. AI tends to mess up at the seams and edges, which means that having sufficient integration tests and E2E tests, the kinds that actually open up a browser and actually try to click buttons and fill in forms and save things to your database and data warehouse, is crucial.

This means that your test setup will need to be extra robust to failures and highly idempotent. One bad test run should not leave your test infrastructure in a state that prevents future tests from running.

But once you’ve got it all set up, when all your tests are passing you can rest a bit easier. Passing E2E tests, especially, are a great sign that a new update didn’t break your app.

Back when LLMs were first being used for coding, I was thinking I could give AI a high-level overview of what I wanted and it could go off and create everything I needed.

This worked for smaller projects but blew up in my face for any project that was even a bit more complex. I quickly learned that while I might not be writing a single line of code anymore, I couldn’t get over the more strategic and thoughtful parts of software engineering - the architecture.

Planning out how a set of systems will work together, or how code should operate at the highest level is still something that LLMs don’t do well, at least not when you’re working strategically at the start of a project.

I quickly found that if I provided a detailed breakdown of how everything should be implemented, the AI would do a pretty good job of implementing everything in a way that followed best practices.

To make my life easier, I actually found that the AI was pretty good at generating its own plans after I gave it an example of the type of structure I wanted it to follow and a high-level overview of what the system that I was building needed to do.

Having a detailed plan in place is arguably the most important piece of the puzzle when it comes to actually getting good, production-quality software. But if you let an AI go to town on a large plan, it will inevitably screw up somewhere, causing you to have to backtrack and waste time.

That’s why, whenever I have a plan in place, I try to have the AI work on only one piece of it at a time. I ask it to implement the functionality needed for each top-level item in a plan, creating the code, the tests, the database migration files, etc. and then pushing a PR for when it’s done.

Once a PR is pushed, I spend a lot of time and energy code reviewing it. This is probably the big tradeoff when it comes to using AI for coding. Before LLMs, when I was creating all the code myself, I spent a lot of time implementing the code, which meant I was highly familiar with how it worked, and my code reviews could be a bit more cursory.

But now, I have to examine almost every new line of main code to ensure it not only follows best practices but also actually implements the functionality that it’s supposed to without introducing any new bugs or errors (the automated tests that I mentioned above help a lot with this piece, though).

Steps 1-4 have helped me move dramatically faster when it comes to rolling out software. But maintaining it and ensuring that it doesn’t cause any negative side effects in production is also extremely important. Outside of the standard monitoring and alerting that you should have anyway (more below), I may set up a scheduled task on Claude Cowork to actually go through and test previous regressions or new functionality on my live product in a way that a user would test them. This is helpful for catching any pesky errors that make it through your development process and into production.

So that’s pretty much it, at least from a process perspective. There are a few things here that I haven’t mentioned, primarily because most of them go without saying (and yet, so often, they need to go unsaid anyway).

For example, the process above only covers the new way of doing things in a world of AI. It doesn’t mean that you don’t also need to incorporate all of the traditional best practices that are still important (implementing monitoring and instrumentation of all your systems, implementing an event system to track analytics around what your customers are doing, using threshold-based and dynamic alerts to watch for failing infrastructure, etc).

All of the traditional software and devops practices that you used to implement are still needed. AI can certainly help you put them into play, but what I’ve found with AI is that its rarely proactive. You’ll need to know to tell it to do these things, which is where it could still be helpful to have a seasoned engineer managing all these things, at least for the near-term.

Outside of all this, the only other thing I’d suggest you do is to not be afraid of working on multiple things at once. Now, there is a point where you might have too many projects in play at any given time. As you’ve seen, human oversight is still needed for most large projects, and there comes a point where you’ll be burned out and losing your mind if you’re trying to do too many things at once.

But unlike before, you can now work on more than one thing and make reasonable progress on those things, and working on multiple things at once allows you to move incredibly fast when it comes to building things.

Everyone will have their own breaking points - for me, I found myself getting burned out when I was managing 5 projects all at once. I now try to focus on 2, maybe 3 simultaneous projects. In fact, these days I’ve gone back to trying to focus on 1 project at a time, but knocking it out as quickly as possible so that I can move on to the next project.

And yes, I realize the conflict in saying that you can focus on multiple things at once but also saying now I try to only focus on one thing at a time. In reality I generally have 1-2 long-term coding agents running in the background and 1 primary task that I spend most of my time on, only switching away from it to monitor and guide the other agents every so often. Everyone’s different and your mileage may vary.

Ok so that’s all I’ve got for today. I’m not sure if this helpful but I’ve been asked enough times that I thought it could make sense to give some high-level guidelines on how to move faster.

Separately, maybe related, maybe not, I’m thinking of writing a book. I feel like I’ve accumulated enough experience across a few different areas that a book on something that matters could be both helpful to others and act as a good way for me to build trust with potential customers.

The only thing is - I’m not sure what to write about (or, really, if it even makes sense to write about anything at all). If you know me and there’s a particular topic that you think you’d want to hear more about from me, I’d love your thoughts.

If you were sent this post by someone you know and you liked it, feel free to subscribe to my non-periodic, unspecific, random newsletter at https://in-motion.beehiiv.com/.

-Shanif