Grief, Growth, and my Future as a Programmer

As AI transforms software development, this is my honest account of moving from fear and resistance to adaptation and the mindset shifts I’m making to stay relevant and fulfilled.

Whether or not I want them to, things are changing. I started writing code when I was around 11 or 12 years old simply because it excited me. I thought the process of writing some text and it performing some useful function or coming to life visually within my browser was fascinating. I had grown up at the right time for this to be accessible too - information was free and it was everywhere (W3Schools, YouTube, Codecademy, etc).

The process of taking an idea, breaking it apart into abstract concepts, figuring out how to translate those concepts into code, and then actually writing that code was something that I took pride in and helped give me purpose. I think everyone can agree that its a fundamental desire of a human to feel like they posses a unique skill that can contribute back to society in a meaningful way. Coding was this for me. More than that - it was fun. I’ve always enjoyed being a student and continuously learning. Software development was, and still is, changing rapidly and it was fun to attempt to keep up in the places you could. Once coding moved from a hobby into my full time job, this is one of the things that kept it exciting for me.

I vaguely remember OpenAI releasing GPT-3 to the general public sometime in late 2021. A few of my co-workers had already been following developments in the LLM space and were excited about the release. One of them showed me a few things GPT-3 was able to do, and I thought it was pretty neat. In my head I was thinking if this improves enough these could make for cool chat bots or a semi-intelligent autocomplete. I don’t know if I was already in denial at that moment, or if I genuinely though that.

Since that release we’ve obviously seen a lot change. We’ve seen LLMs get much more intelligent, LLMs with a more focused scope of expertise, actual products get built, autonomous agents created, new processes developed (and old ones retrofitted) to allow for collaboration between agents, and finally we’ve seen some pretty inspirational work done through all of these new tools both with and without humans directly in the loop. We’ve definitely gone way past the point of chat bots and semi-intelligent auto-complete. I don’t think I’m alone when I say that I’ve experienced a wide range of emotions over the last year or so as this all has unfolded.

Being completely honest, I’ve mostly experienced sadness, anger, denial, and fear about all of this. I love programming. It’s something I’ve loved doing and it has been a major part of my life for nearly 15 years now. I always told people I was so lucky that I happened to find something that I genuinely enjoy that I get to do as my job. I intentionally stuck my head in the sand for probably far too long about using AI. I didn’t think there was any way it could do my job better than I could, apart from helping me with boilerplate tasks or maybe writing some tests that I didn’t want to expend energy on. We’re officially at the point where I can no longer look away though.

Before I get into the actual part of this blog that I was wanting to write, I think it’s necessary for me to talk about that last emotion I wrote in the previous paragraph: fear. I think a lot of us are feeling this right now for various reasons. We have all spent incredible amounts of time and energy pouring into ourselves to make us better at our jobs. Now we’ve been confronted with a black box that can intake requirements and output software that fulfills those requirements. It sucks. I really don’t have any inspirational things to say here other than you’re not alone in feeling this way and we’ll get through it together.

So, what I actually wanted to write about was how I am changing my approach to software engineering both inside and outside of the workplace due to what AI, LLMs, agents, fleets, etc. have enabled in development. Let’s get into that now:

My New Rules

To preface this section, these are some of the mindset shifts I really want to make as we move into this new paradigm. I think they’ll play roles in both helping me come to terms with the change as well as set me apart in the future.

1. Embrace Change

I’ve been hiding behind my own emotions for too long when it comes to all of this. Whether or not I want it to happen, it is happening. I can either fully get onboard with it, or the train is going to leave without me. I’m at peace knowing that I would rather continue to be in this industry in any capacity than exit it (or get pushed out). In addition to that, there is a lot to be genuinely excited about as it pertains to AI. If nothing else, I have the ability to pursue some passion projects that have been brewing for a few years, but have never came to light because of time and energy constraints that no longer apply due to these new tools.

2. Clarity is Key

It’s more important than ever to be as clear and concise as possible. The writing is on the wall with the recent developments of fleets of agents that the human’s role is actually outside of the loop. The most important interaction you’re going to have in the software development lifecycle appears to be the planning phase. In this phase it pays dividends to be as clear and concise as possible.

What this means for me in my day to day currently is really focusing on honing in my communication skills in all mediums. What is interesting about this point is a thought I’ve always had being carried forward into this moment: almost all of the insanely talented engineers I’ve worked with are all exceptional textual communicators. I want and need to be this way more than ever. In addition to this I’m also really focusing on well written design documents (both as an author and reviewer).

3. Breadth over Depth

Full disclosure: I could be really wrong about this one, but it is how I feel right now. It’s no secret that if you worked as engineer long enough the goal was to eventually become a “T-shaped developer”. What that essentially means is that you’ve got some breadth (the horizontal part of the T), but you’ve naturally found an area where you’ve also got depth in (the vertical part of the T). I think we’re inching towards a new paradigm where you can nearly just become an “underscore” developer (all breadth, nearly no depth). Obviously both cases are an over-generalization, but let me try to explain myself.

If we’re right about the next iteration of software development being mostly prompt-driven with very little need to actually understand what is going on with the code that has been written, then this kind of has to be true. There’s no point in understanding the nuances of things like ring buffers or consistent hash rings. You should just know what they are and the interfaces associated with them. Let your agents handle the intricacies of these subjects, you’re just the architect of the broad solution. The more you broadly know and understand at a high level, the better architect you’re going to become in this new paradigm. At least in my opinion as of this moment.

4. Write as Little Code as Possible

No matter what it is, try to implement it using an agent first. The more exposure you get with the technology, the better. If it doesn’t work as well as you thought it would have with this approach, time-box some brainstorming as to why. Is there a way you could have provided more context either as a human or via MCP? Could you craft (notice how I didn’t use the word write) some tooling to aide the agent in the task?

There is one notable exception to this for me personally. I’m going to continue to do things like leetcode and advent of code the old fashioned way without the aide of AI. For the time being things like that are going to be my outlet in absence of not writing much code directly at work.

5. Think Like a Product Manager

I think the line between product manager and engineer is about to get insanely blurry. I really wouldn’t be surprised at all if these roles were more common combined than separate in the future. I’m going to do my best to soak up as much information as possible from all of the great PMs I know. I think technical product managers are really well positioned to do well in this paradigm shift.

6. Be Kind to Yourself

We’re all in our own stages of dealing with this massive paradigm shift. I’m currently in the acceptance phase, but that doesn’t necessarily mean I still can’t be sad about the thing that I’ve loved doing for so long changing massively. It’s okay to stop for a moment and remind yourself that you’re feeling that way for a reason, and the reason is valid. It doesn’t mean you can change the circumstances, but you should always be kind to yourself.