To say I have conflicted emotions about AI coding is an understatement. It’s like I’m going through the stages of grieving.

At first, I was dumbfounded. Incredulous. You can see it in my article AI Coding is Finally Here. I didn’t know what to make of it. I still don’t.

It’s been a few months since I wrote that article, and I’ve still been using AI. I’ve found some things it’s really excellent with, and some things it’s not so great with. I still write some code by hand, but usually when I go in to type something out, I think, “it would be faster to prompt this.” And so I do, and it is.

Today, that made me sad.

It’s a Murder

I am starting to miss the days when there was really only one way to get programming done, and that was doing it all by hand, and becoming an expert in the syntax and the form and what letters to type. I’m missing the days when I had to google for documentation, read it carefully, and filter out the useful information from the stuff that didn’t apply. I’m missing that learning process. I didn’t appreciate that it was necessary learning back then, and now I’m sad that it’s not necessary any more.

It feels like I lost a friend. I liked the explorative, learning, creative work of coding. Even worse, it feels like that friend died of unnatural causes - it feels like they were murdered. Taken from me. And, to add salt to the wound, the murderer got away with it using some of my intellectual property.

It’s fair to say that with AI you still have to learn things. It’s true. With AI coding, you can’t just let it rip and not look at the code, not understand anything, and not worry. You get into hot water really fast going down that road. So, you still need to understand how the system works. But, the exploration, if there is any, isn’t deeply technical any more because any questions you have about how to implement something are already answered.

But, I liked the detailed technical exploration. I liked answering questions myself like: What’s the best method for this? What’s it’s signature? Is that how most people use it? Oh, that doesn’t return what I thought, let’s try a different one.

When you had those types of questions in the past, you had to read and find out for yourself. That learning process got more information into your head and you became more proficient at the tool you were using.

All that kind of exploration? Gone. It was murdered.

Replaced the Wrong Parts

At work today, I needed to migrate a large chunk of code from one repository into another. It needed to get moved along with all of its tests, any dependencies, and some utilities that had it securely nested in the larger codebase which we were breaking up. I didn’t really do any of that work. I pointed OpenCode at the problem, explained where it needed to move the files, told it to move them first and then solve errors after (doing it the other way blew the context window too fast) and then I let it rip. I went to a meeting in the mean time.

When I was done with the meeting, OpenCode was done with the migration. I checked it. I tested the code. It all ran just fine.

This was not a trivial task. There were 80 files moved from the old codebase. A suite of 150 tests to migrate. It all works.

Did I read the whole PR? No, it’s 80 files for crying out loud! I just ran the code, saw that it worked, looked at the folder structure, and trusted it. When the PR got approved, I threw my head back in my chair, face in my hands, and said out loud, “I’m so cooked. What are we doing?”

More sadness came when I realized that I had just replaced the fun part of my job with a meeting.

Test-driven Development is Ancient

It’s usually uncouth to talk about test-driven development at the dinner table, but I’ve been on a tear with it recently, and my family and team members have heard enough – so I need to write it down. What have I been ranting about? How old TDD is.

The software industry has developed an interesting pattern. As an industry, we’re growing fast, and everyone is always happy to talk about how fast we’re growing. But what doesn’t get talked about is where we came from.

Software companies hire huge swathes of new graduates each year and we always come up with new technologies and methodologies–new fashions – if you will. But most of these methodologies and technologies are actually old. Some are even ancient.

New graduates typically have no idea what came before, because they’re too busy learning what’s here now. And all the experienced programmers don’t have time to explain what came before because they’re too busy teaching the current stuff – or they’re in meetings. And so it is that our industry lies in a perpetual state of inexperience. The new not knowing the history, the old being too busy to teach it. In my view, this is the primary reason we continuously regurgitate old methods and tech ideas. One of those ideas is test-driven development. In my small effort to end the cycle, I’d like to write a bit about its history.

I’ve been searching for quite some time on the history of test-driven development and one of the earliest sources I’ve found is from a 2008 interview with Jerry Weinberg, who worked on project Mercury (the U.S.’s project to put a man in Earth orbit before the Soviets), Jerry recounts a co-worker teaching him to write tests first way back in 1957:

Interviewer: Computers don’t break down as they used to, so what’s the motivation for unit testing and test-first programming today?

Jerry: We didn’t call those things by those names back then, but if you look at my first book (Computer Programming
Fundamentals, Leeds & Weinberg, first edition 1961 —MB) and many others since, you’ll see that was always the way we
thought was the only logical way to do things. I learned it from Bernie Dimsdale, who learned it from von Neumann.

When I started in computing, I had nobody to teach me programming, so I read the manuals and taught myself. I thought
I was pretty good, then I ran into Bernie (in 1957), who showed me how the really smart people did things. My ego was a
bit shocked at first, but then I figured out that if von Neumann did things this way, I should.

So programmers have done test-first development since very near the beginning of software. Of course, things in those days were different, and these 1957 tests were manual. If you only had a few minutes with the computing machine, you’d write your program on the punch cards and write your expected output elsewhere. When you got to see your program’s output, you could quickly compare the two and save everybody time. Jerry Weinberg said that this was seen as “the only logical way to do things,” but there are more reasons for this. In my view, the best of these is in an address from Edsger Dijkstra in 1972. Dijkstra lays out the problem beautifully:

Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to
show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the
confidence level of a program significantly is to give a convincing proof of its correctness. But one should not first
make the program and then prove its correctness, because then the requirement of providing the proof would only increase
the poor programmer’s burden. On the contrary: the programmer should let correctness proof and program grow hand in hand.

How often do programmers today allow a “convincing proof of correctness” to grow with their program? I fear it’s not often, but this is the goal of test-driven development. As Dijkstra said, a bug can easily be proven to exist with testing after programming, but can you prove the absence of bugs with that sort of testing? Not easily. When we write tests first, we provide with our program a proof that each piece works as intended. Of course, this also does not guarantee the absence of bugs related to side effects, but it does guarantee (in theory) the absence of bugs related to the intended behaviors. This is the primary argument in defense of test-driven development – tests written before the program provide more convincing evidence of correctness.

There are more references to old-school test-driven development which I won’t bog down this article with. But I think it will suffice to say that this was in practice in many projects in the early days of computing. It was then in the 90’s that Kent Beck “rediscovered”, and perhaps re-popularized, test-driven development. He describes his discovery as follows:

The original description of TDD was in an ancient book about programming. It said you take the input tape, manually
type in the output tape you expect, then program until the actual output tape matches the expected output. After I’d
written the first xUnit framework in Smalltalk I remembered reading this and tried it out. That was the origin of TDD
for me. When describing TDD to older programmers, I often hear, “Of course. How else could you program?” Therefore I
refer to my role as “rediscovering” TDD.

Kent Beck’s TDD revival is why most programmers today are familiar with the practice. Even Robert Martin (one of TDD’s most ardent missionaries) learned it from Kent, saying that to learn it, they pair programmed, and Martin was struck by the granularity of the practice. Kent Beck wrote a line of test code, then a line of production code to make it pass. This, to my understanding, is the beginning of the adage “red, green, refactor”. Eventually these steps were codified into rules and The Three Laws of TDD were born:

1. You must write a failing test before you write any production code.
2. You must not write more of a test than is sufficient to fail, or fail to compile.
3. You must not write more production code than is sufficient to make the currently failing test pass.

The Three Laws of TDD, in my view, are the gold standard of test-driven development. They put a programmer into a minute-by-minute cycle of writing a test, making it pass, and refactoring. In my experience, following these rules and trying to do so as prescribed by Robert Martin and Kent Beck increases productivity, enables the creation of some ingenious algorithms and designs, and improves code stability and developer confidence. I also think it’s more fun! I won’t be going back to testing after, but I know many developers struggle to apply these rules.

Many developers cite concerns with code quality, working at the edges of systems, and working with legacy code that doesn’t have tests. Indeed, this is where TDD gets difficult or even infeasible. How do we get around these barriers? There is a way, but that’s a topic for another article.