Reflections on AI Coding

A few years ago, OpenAI released ChatGPT, bringing mainstream attention to the otherwise still niche area of LLM research and development. The world was captivated. Investors flocked to funding LLMs and we've since seen an explosion in the presence of LLMs that's rippled through the world: creating new markets, driving research, and sparking discussion on the ethics of how LLMs acquire their knowledge, on the consequences of LLMs on the economy and even its consequences on human dignity. Whatever your opinions on LLMs are, there's no dispute it's permanently left its mark in the cultural zeitgeist.

What I want to focus on in this post is the use of LLMs as it relates to software engineering and my personal experiences with using it. For the rest of the post, I'll be reluctantly referring to LLMs as AI, since that's the more common name that society's given it, despite LLMs being only a small subset of what AI traditionally meant in computer science.

I'm just vibing, bro 😎

Since its launch a few years ago, providers have been trying to push ChatGPT and other AI models to help with programming. In theory, AI models should do well with programming. After all, LLM stands for large language model, programming languages are a kind of language, even if it's artificially constructed and highly structured compared to natural language. People began "vibe coding", a term coined by Andrej Karpathy referring to a practice where code is created by prompting AI in natural language and guiding it to accomplish your needs.

When the term was coined and it initially gained its popularity, I treated it as a joke. "Seriously? We're throwing out rigorous computer science and software design in favor of slop generated from natural language?" was my sentiment. I thought it was utterly insane. Smart people have created a way to interface with computers in a precise way via something called programming languages and compilers. By adding another compiler from natural language to programming languages, we're adding another layer of indirection and losing precision.

That said, I wasn't dogmatically against AI. In fact, I found myself using it when exploring new topics. For example, when I was setting up a streaming infrastructure, I consulted AI to figure out what technologies were out there, some of their high level summaries, and interfacing capabilities. Similarly, I'd ask AI about starting points when researching new topics, like asking for references about programming language design.

For a while, AI was a useful tool to me that aided in software engineering and made it more enjoyable. Purists may loathe this, but I prefer asking AI about some weird syntax error in a programming language I'm trying to learn rather than digging up some StackOverflow post from 12 years ago with answers that are outdated. During this time, my use of AI left the fun part of programming intact for me.

The dawn of agents

Fast forward to some time in 2025. Throughout the software industry, there had been wide scale adoption of AI in professional development, particularly in agentic coding. I treat agentic coding as a branch of vibe coding: rather than needing to relay information between your system and the AI (e.g. by copying around snippets of code), you install a program that interfaces with an AI and is able to read and write files and run commands on your system directly autonomously (with safeguards of course).

I was skeptical. I didn't trust that AI could write high quality code. I refused to use AI in any capacity for coding (apart from what was mentioned before, as a fancy search engine with a chat interface). In fact, I had worked with people that did vibe code and had seen first-hand how terrible the code was.

That was until around the start of 2026. I had coworkers who were trying to push the limits of AI in their daily workflow. Moreover, there had been a cultural shift at my company to be more AI-driven.

Again, I wasn't dogmatically anti-AI. My chief concern was the quality of code that AI produces. Beyond that, I didn't have a principled reason against using it. So when coworkers started asking me to review AI generated code and seeing a general trend in improvement in the code quality since I last remembered, I decided to give it a try. My company gave me access to Claude so I installed Claude Code and started playing around with it.

At first, I started using it for only small, focused work like refactoring or writing tests or asking questions to the agent like tracing a variable up a long and confusing call stack or searching how something was done idiomatically in a codebase. I found this to be remarkably successful and as of writing, I still feel positively about this use of agentic coding. It removed some of the frustrating parts of programming, especially on a large and unfamiliar codebase (I was still relatively new to my company at the time).

I kept experimenting with using AI in my daily programming and pushing the limits of tasks I deferred to it, even outside of work. At first, I was impressed. When I glanced through the code it generated, it believably looked like decent quality and to be fair, it really did generate passable code when working with popular tooling.

At some point, I was writing maybe 80% of my code at work with AI agents. I was measurably writing a larger quantity of code and in an industry with endlessly increasing demands, it felt difficult to refuse a magic tool that boosted productivity. It was steroids for the software industry: even if it's not explicitly forced upon anyone, people will feel like they're falling behind if they don't use it. Damned if you do, damned if you don't.

Is this truly a fair analogy to draw though? After all, steroids have known adverse health effects long-term and is generally frowned upon. We should investigate whether this comparison is justified.

My anecdote

I was asked recently to patch a fork of a 10+ year old C++ library we maintain. Even getting the library to run is a rite of passage, needing to deal with an antiquated CMake build that only works on very specific configurations, and I was one of the few that had passed the ritual, had sufficient C++ knowledge, and had done work on it recently so I was first in line for duty.

I had a great time when I last worked on the library. Well, it was a struggle while working through the problem, but it was satisfying to solve it, like any good problem.

A blue story

The program was segfaulting when sending it certain data. I was working on macOS laptop and I had very limited familiarity with the LLVM toolchain so I couldn't even get a debugger attached to the process at first, which made debugging painful, especially since this was dealing with a segfault. I got desperate enough to start placing print statements at every line along the critical path of failure. Eventually, I wisened up and just built the project on my Linux desktop with the GNU toolchain I was familiar with and got a debugger attached.

The segfault was occurring within some STL function that accessed invalid memory. That was odd. I should surely be able to trust the STL to competently handle its own memory, right?

Weirdly, I also noticed the program was segfaulting at a different line on my desktop. I triple checked on my laptop (still without a debugger) to make sure this was the case.

std::cout << "OK GOT HERE 2 REAL (ACTUAL) FR" << std::endl;
// crash
std::cout << "DO NOT SEE!!!" << std::endl;

This was informative. The fact that there was a discrepancy between the two platforms hinted that the underlying issue was likely due to some memory corruption introduced earlier in the program rather than the offending lines themselves initiating the invalid memory access.

Indeed, I found in that in a function earlier in the call stack, there was some odd-looking memory allocation patterns they did with their inhouse dynamic array implementation (why even use an inhouse implementation if we end up using the STL anyways...?). In any case, it looked like an object wasn't properly being initialized with their inhouse implementation and sure enough, adding a single line to initialize it properly fixed the segfaults on both platforms.

What a joy! Each step in the process was soaked with blood and tears, but I felt so alive when working on the problem. I was proud of myself for being able to use these subtle hints to deduce the underlying problem and it culminated in a sweet, sweet victory.

At this point, you might be wondering whether you're reading the right post. This is a post about AI, not about some esoteric C++ library and its internal mechanisms. So why am I talking about this? I promise I'll answer this soon. First, let's talk about the more recent patch I did for this library.

A bitter victory

I was told that this was an important patch and that a deal with a customer was sitting on the line for this. I was reluctant to give estimates because the nature of this work is inherently unpredictable and I was in the middle of other work at the time. The importance of the patch was emphasized when I was invited to a channel "urgent-XYZ" and prompted to fix it though.

The thing is, this was an issue in the application code in a domain I had absolutely no knowledge of. Realistically, I'd need to take at least a few dedicated days to understand the relevant parts of the domain well enough to give a well-informed assessment of the situation. So I turned to AI.

I turned on the most advanced and expensive model and asked it to help work through the problem. Understanding the domain could take too much time and it wasn't clear what the benefits would be if this problem could be solved with a blackbox approach. I fed the agent more data, suggesting it to look through potentially relevant files, relaying information from domain experts to it, praying that it'd magically fix the problem.

It did.

The executives were happy. I was praised for being able to get the fix in. Yet I felt nothing. What was my role in this process? What even was the underlying problem? What did I even do?

At this point, I was a glorified CI runner. All I really did was feed a magic text box some funny-sounding words and run builds to see if the magic text box made the code work and reported back with a green checkmark when it did.

This particular instance made me realize the effects AI was having on me as a programmer. I had a conversation with a coworker a while back about the use of AI in programming and I had agreed with his sentiment that AI takes the joy out of programming, but now I felt it at a visceral level. Programming with AI is just... not fun.

Unmistakably, I am more productive with it. There's no way I could have made the patch in the time I did without the use of AI. There's no way I can push out the volume of changes I do without the use of AI. But I've realized using to the extent that I feel like I have to to be competitive as a programmer has taken the joy out of programming.

Closing thoughts

In my mind, there's little doubt that AI is revolutionizing the software industry and it will continue to do so, provided the economics of running LLMs can stabilize.

Junior engineers equipped with AI tooling are transformed to a human-machine hybrid capable of pumping out medium quality changes at a faster rate than more experienced programmers without AI.

Even if this isn't completely accurate right now, I believe advancements in LLMs will make this generally true, and the quality of LLM-generated code will increase. It likely won't replace the artistry and craftsmanship of hand-crafted code, but as far as corporations see, I believe it will produce code at a quality indistinguishable from human code.

So where does that leave us?

...I don't know. I'm trying to answer this question myself. I enjoy puzzles. I enjoy problem-solving. I enjoy meticulously crafting line-by-line a cohesive answer to a problem in the same way I enjoy crafting an elegant mathematical proof. I enjoy programming.

The way that the software industry seems to be heading is increasing demands on productivity in a way that I can't keep up without the use of AI, yet using AI in the ways to keep up in the ways I need to is fundamentally at odds with what made working in the software industry appealing to begin with though.

This is a rather bleak outlook.

I suppose I should just embrace this. This predicament is surely not unique to the software industry, and it may not be the first time a predicament of this nature has happened even within the software industry. Maybe in the late twentieth century, I would have been lamenting about compilers taking the joy out of those who enjoyed writing machine code.

Only time will tell if we're able to preserve our dignity.