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 AI¹, 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?

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.

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(n²) 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?

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 yada...

Ok, but what does this mean for software developers? Yes, anyone can have code written for them now, and there's a good chance it will be slop, maintainable only via excessive token use and many Ralph loop iterations. At least when maintained by those who do not focus more on the code and only on the results. Yes, we are going to see a lot of half-baked ideas in a semi-working state, and probably get more mail for free credit monitoring from poorly designed systems.

I think it's safe to say that as long as companies like Anthropic are still hiring engineers instead of replacing them with product owners, experienced developers will still matter. If the system could be treated as an absolute black box where the internals did not need to be monitored, companies on the forefront would be hiring those who guide the product, not who maintain it.

I think it's also safe to say that we are in a state of refinement for LLM's, and that on the chart of ability over time LLM's are taking more of a sigmoid shape than an exponential curve. Much like how cars today are still four wheels on the ground and get you from point A to point B, just like they were 100 years ago. They have simply been refined, safety features have been added, creature comforts are in place, and bluetooth has taken over the CD player. The roots are the same, the polish is where you find the improvements. I believe LLM's and AI will follow a similar path.

All to say, I don't think the role of the developer is going away, changing yes, but going extinct, I sure hope not.

Oh, Magic 8 Ball, What will my job look like in a year?

Reply hazy, try again

Amazing, well, I don't know what I expected.

If I had to take an educated guess at what the future holds.

Dev teams will be asked to take on and "productionize" AI created Proof of Concepts

Honestly, this does not thrill me. Maybe I am to use to the old ways, but I would rather discuss requirements and expectations than try to extract them from code. Please, I would urge you, if you are in a position where you are creating such a proof of concept, paired program with a dev while you do. I volunteer as a tribute if you need somebody.

Products are going to get a bit sloppy

Much like the internet of the 90's and early 00's. We are going to see some things. What is the code equivalent of dancing Michael Jackson GIFs and marquee text? I don't know, but I think we are all about to find out whether we like it or not. Be ready to set up credit monitoring.

Products that enable people to go to market will explode

When anyone can create something, they will need a way to ship it. Systems that make this easier for non-technical people will eat this up in attempts to get their idea out there.

LinkedIn will still not be much use for me

The number of posts bragging about something I find less than impressive will increase, but getting back to it, I don't think I'm the intended audience. I'll bet this is more about enticing investors than users.