A New Codebase Every Morning

For years, as a software engineer building large SaaS applications, I worked with my teams, developed requirements and we all turned our nuclear keys to begin projects. This approach meant that everyone understood what they were working on and had context for what others were doing. We would often discuss progress, collaborate to solve complicated issues and we were all on the same path moving, mostly in an orderly fashion 😉.

In order to build features that touched multiple systems, collaboration and communication is key. I am not about to protest that this is all gone. What I have noticed, however, is that because one developer, with their own AI and their own set of tools can generate very complex systems in a way that when something breaks, even with testing, you are now faced with looking at “someone else’s” code.

Someone Else’s Code

We have all felt the emotion of (cracks knuckles) walking into a new job or project and trying to get your head around how and why it was built that way. You factor in the following:

1. What was the development world like when the project was started?
2. How much has the landscape changed since it was started?
3. This project has been living for a while with different requirements from product, design, sales, and marketing.
4. Lots of on-the-fly decisions and pivots were made in order to support customers in that moment. You cannot begrudge anyone who was sitting in the chair when those choices were made. There are pressures being applied from other departments as well as themselves. You have to just make sense of what you are looking at, move forward, and start shipping code.

Each of these are important to consider when evaluating a new codebase. Again, think about what it felt like when you sat down to figure out how to wire up new pages, controllers, APIs, services, modules, etc.

The issues that I have faced personally, are that when I have the AI write all or most of the code for a complicated system, I am now looking at “someone else’s” code every time there is an issue. And the other people on my team are also looking at “someone else’s” code each day. Before AI assisted code, you could say the previous sentence verbatim, however, without the quotes. The main difference was that I understood all of my code and could explain or teach it to anyone on my team. I wrote it, I reasoned through it, and I put it up for review. The level of ownership of the actual code that I shipped was much different.

The Cost of Speed

Let’s say that a feature to wire up subscription payments lands on your desk. You should have a grasp on security, webhooks, logging, recurring charges, nightly jobs/workers, etc. This is a lot to work on. You create requirements for each of these and break them down into bite sized chunks of code to be respectable of your co-workers who will have to read the pull requests to ask questions and offer guidance.

You build the feature mostly with AI.

The next day, you wake up and there are some comments/reviews for you on the feature’s pull request. Some of the comments are asking about approach, commenting on bugs they found, all the fun stuff. You open your laptop and feed in the new comments to the AI to start working. Everything is getting you closer to what you and your coworkers discussed. But, you still have to dive in and once you do, you probably find code that doesn’t look familiar or is a different way of doing things that you are used to. Because you didn’t actually write the code, your ability to think about how to solve the new issues becomes more challenging. Any one issue may not be the worst thing ever. When something like a webhook for processing payments does not work as you expect, then the mental load starts to add up. These are not simple concerns. There are a lot of things to think about: did the webhook succeed? did you log the correct message? do you have retries setup correctly? What is the service sending you the data goes down? What if the webhook times out? At scale, this becomes complicated.

You might be thinking, wait with AI, I shouldn’t have to write all of the code, and I couldn’t agree more. There are a lot of awesome reasons to have AI do things for you that you know how to do, but you just want it done fast. Cool, that is awesome. I really love having AI write tests. This is the speed gain that I am into. The ability for the AI to look at your models, views, controllers, helpers, etc and create the scenarios is outstanding. My favorite gain that I have found is for prototyping large features to test their viability either internally or on the market. This is where I am ok with a little bit wriggle room with quality. Other parts of your team need to see something working to get a better idea of how to create deeper requirements, learn how to sell, and understand how to market it to prospects and customers.

I have been on teams where each individual is now cranking out AI assisted features so quickly that it becomes difficult for the team to have context. I am someone who can hold of lot of context, go on tangents, and come back to what I was doing. I do not believe, however, that we were ever meant to try to effectively manage this much context. Even if you break things out into small pull requests, then you and your team members are now switching context from your current tasks to review these small PRs all the time. Reviews become sloppy.

Working on a codebase over the course of a week means that you are thinking critically about each part of the project. Imagine compressing all of that thought into a few prompts and getting it done in an afternoon. Then, do that 5 times a week. You have now crammed 5 weeks of thought, collaboration, iteration, into 1 week and you are expected to keep that up. You will reach burn out so quickly even though the goal of AI assisted coding is to get you to do more in less time. Then when any one of those afternoon projects has an issue, switching your current context into that one afternoon’s thought process is not something any of us want to do. I am not proposing that speed is bad. It is so cool how quickly we can get things to market, see how users are interacting, and iterate. This, however, doesn’t really take into account the well-being of the developers.

Imagine you are a contractor working on a house. You take your time building a bathroom over the course of a week. Now, someone says, I need that bathroom done in a day. The amount of time you have to think about absolutely every decision is now shrunk 5 fold. You get it done, but barely remember it; it was a blur, but…you got it done. Then a month later, there is an issue with the piping under the sink. You can fix it because you know how sinks work, but when you open the cabinet and see the piping, it doesn’t look like your quality work. You find the wrong schedule of pvc pipe, some joins don’t have glue. From the outside the sink basically works, but when you really look at it, it’s just not right. Then you probably just rip it out and build it again knowing that you have time. Now imagine that each house you built has bathrooms like this. You will never get out from under all of the fixes you have to do.

More Than Just a Developer’s Context

This is not just a developer problem. The pressure to ship faster ripples through every part of a company. Product managers are writing requirements for features at breakneck speed. Designers are iterating on flows that keep changing underneath them. QA is chasing a moving target. Everyone feels the same thing: what used to feel like a healthy week of work now feels like something you should have finished by Tuesday, and nobody is talking about what that pressure is quietly doing to the people under it. The irony is that we are moving too fast to stop and ask if we should be moving this fast.

Software development is never done. There is always another feature, bug, or request. There used to be what felt like a natural rhythm to it. In order to understand what should come next, you shipped something, lived with it, saw how users responded, and then iterated. That was not wasted time. It created the team’s shared context to make appropriate decisions for what comes next.

With AI doing more and more of the writing, that feedback loop gets shorter and shorter. You move on before you have really absorbed what was just built. And when it comes time to write requirements for the next feature, you are drawing on a lesser understanding of the system than you used to have. The requirements suffer. The code drifts further from what anyone fully understands. And the cycle continues.

Speed is not the enemy. But moving fast without understanding what you are building is a different kind of technical debt, one that lives not just in the codebase, but in the people maintaining it.

There is a balance. I am not sure exactly where that lives yet, but for me, when working on my own projects, I try not to entirely use AI for foundational elements, as those are the places where the most reliance on stability is involved. Remember, the AI is just making predictions based on existing documentation, and other code. I recently caught it searching for answers using 2024 as the year. You might build something off of an almost outdated API. I want to close by saying that I use my entire allotment of tokens that I pay for each month. What I have done though is use AI to have it build me tools to make me faster. And to be frank, I am getting a lot out of code snippets. It feels faster to me to create a file, type view and get my view scaffolded. Autocomplete feels good enough for most things. Quite frankly, every second you wait for an answer and not actually coding is time not spent living with the code and understanding it. I know that desire to do more actual coding is fading, but asking people for help or context when they didn’t actually write the code adds friction to the conversation, and then you both have to dive in and walk through the code. You end up basically just doing code reviews all day to navigate through the code base.

✌️ Matt