Ian McNaughtonSoftware Development in the AI Age<br>May 18, 2026<br>LinkedIn has never been my favorite site on the web. I get the impression I am not the intended audience for most of what comes across my feed. The majority of it is focused around AI1, either in a positive or negative light. These articles feel like they could be for me, they touch a subject I work with daily now. Promoting the use of Ralph loops, or tales of deleted databases by rogue agents. Yet I struggle to extract value out of the majority of these posts.Now I will be the first to admit that I have not set up a Ralph loop. The few times I have thrown any sort of caution to the wind and given the model free rein over a project, I have never been happy with the results. So when the CEO of a three person company brags about their Anthropic bill, saying they have never been so proud, I have a hard time relating. Then again, I get the impression I am not the intended audience. However, there is something to discuss here.What Does Software Development Look Like in the AI Age?<br>The entire industry seems to be on the edge of its seat awaiting the answer to this question right now. I know my day to day has forever changed. Yeah, I can burn up my allotment of tokens in a session, but I still keep a tight wrap on what I allow Claude to have access to and modify. My outputs are nowhere near as impressive as the product claims I see flaunted around LinkedIn. Am I falling behind by sticking to the lessons of Clean Code & The Pragmatic Programmer? Did the vibe coded project bring in enough revenue to cover its token bill? Will either of us be able to fix a bug or extend the feature set in a timely manner?There are many ways to skin the cat, but in the end working code wins.<br>An old professor of mine said something like that in an entry level programming class I once took. It's been some time, and I don't remember the exact quote, but he used that for an explanation of not reading our code and only verifying the inputs and outputs of any assignment he gave. Yes, we can debate if this is a good style of teaching or not, but the point I think he was trying to make is something I had a hard time coming to terms with in my younger years. Your users don't care what your code looks like. They care about how they interact with the feature and how the feature interacts with them.If the website takes forever to load, it's a bad website. If the app crashes or the button you're about to press jumps away only to be replaced by an ad, it's a bad app. If the user can easily enter the required info and get a good result back, it's good software. Nobody is worried about how well you followed SOLID principles or if you’re using an O(n2) algorithm where an O(n log n) version exists. Did it do the thing? Was it a nuance to work with? Will I get a letter in the mail saying I have 6 months of free credit monitoring because of a data leak?There is an argument to be made that this is all that matters when it comes to software, I think it's easy to forget that none of these ideas are new.What was I doing before LLM's and AI?<br>Obviously, writing code to solve tasks, yes, but not entirely. Reflecting on things, I can come up with a list of items I would do as a developer, but they all relate to a common theme, maintain the codebase . When working with the code, either directly or by review of others code. The goal here was to reduce unnecessary complexity in the structure and implementation, so it was easier to understand, and by proxy, easier to modify.Dismantling ambiguous tasks was another large aspect of work. Most features originate as high-level ideas. The user should be able to download a report of activity. Or something similar. What data goes into that report, how to access that data, where to store the results and in what format. This sounds unique, but it is rooted in maintaining the code base. The better a feature is understood, the easier I can design the code to achieve said feature, the easier it is to understand and update later if needed.Bugs would need to be identified and squashed. Sometimes the issue is straightforward, the app needs to not crash on invalid input. Sometimes the issues are complex and require more depth, the user is not getting the correct data. Either way, identifying where the issue is taking place and fixing it in code is a common task. If the code is easy to understand, it's generally easier to identify where an issue is taking place, and ensure you don't break other features in the process.Even soft skills like mentoring others or conducting interviews are directly tied to the theme as well. Helping others understand how valuable it is to keep a clean codebase and mentoring others on how to do so necessary in larger projects where you are not the only contributor.So what did I do before AI, I maintained the code to make a working product. To make a system that just worked.AI is a tool it's your responsibility to use it properly, yada yada...