AI and Software Development

Let's do some engineering! In this post we analyze how Generative AI is changing the way we write code.

Hello, Hypers!

This is yet another article on Generative AI and LLMs. Specifically, I want to analyze how these technologies are shaping how we write code today and how we’ll write code tomorrow. I’ll give you some examples of how my own coding habits have changed in the last year and what I think the future for developers will look like.

This is not a post to explain some AI technology. I just want to give my two cents about a very specific activity that I think is being heavily impacted by AI (for good). That said, let’s get started!

The Copilot I needed

If you have been programming periodically for several months, you probably have thought about how wonderful would be to have an IDE that could “analyze“ your code better and save those valuable minutes you would spend creating things instead of copying and pasting, debugging, or reproducing the same logic. No matter that you apply the best engineering standards, coding seems to be 80% boring and 20% extremely fun (or so).

That sweet 20% is the creative part of coding. Coming up with clever solutions, optimizing some critical parts of our applications, etc. But no matter how sophisticated the IDE is, it seems that it is impossible to avoid dealing with the boring 80%.

Then Copilot arrived. I was lucky to be able to use it almost from the release date. It is amazing! It is able to predict and suggest pieces of code in a way we haven’t seen before. I write the name of a function and its parameters and Copilot implements the entire thing. I write a comment on what I want to do with some data, and Copilot does the transformations for me. All of a sudden, the boring part is reduced dramatically.

Yes, sometimes there are errors in the suggestions. I need to review the important and not trivial completions but still, it is a huge difference. But the most interesting part is that my way of coding has completely changed.

For example, I care more about the names of variables and functions than about the implementation itself. Whenever I feel lost, I write a comment about what I want to do, and most of the time Copilot’s suggestions tell me how to continue. I try to take the maximum advantage of Copilot. But, is this good for software engineering?

The infamous TDD

Once upon a time, Tech Twitter was flooded with these three letters: TDD. Test Driven Development is a methodology to build software. It divides the development methodology into a few steps:

Suppose we want to implement a feature F, then we would do the following:

1. Write a set of tests in a way that passing all the tests means we successfully implemented F

2. Run the tests and see how they all fail (this is the most sadistic part of the methodology)

3. Implement/Fix F

4. Run the tests again, if any of them fail, then go to step 3. Otherwise, we have successfully implemented F.

This methodology has several advantages. Writing tests first is equivalent to defining the requirements of what we need to do. It forces us to have a clear definition of F before diving into the implementation details. Also, it puts us in the place of the user or consumer of F. We need to define how is F used even before thinking about creating F. Also, these tests are like executable documentation for your code. When a codebase is well-tested, I always go to the tests to learn how to use the specific parts I care about.

Disclaimer: I’m a big fan of TDD

Test definitions guide us through software implementation (that’s not a surprise from a methodology that calls itself test-driven). I can’t avoid thinking that this is somehow similar to the way I’ve been programming since Copilot's release. I define some requirements by naming a function or writing a comment, and that definition guides Copilot through the implementation.

Programmers now define requirements not with an entire test set but with naming conventions and comments. From those requirements, Copilot-like technology creates simple test cases. And from the revised test cases, we, along with our AI buddy, build the entire software.

Another important thing to notice is that we now spend more time not just creating but thinking about descriptive enough names and comments. “Code is not written for machines, it is written for other humans“, they say. This is a lesson that takes years to learn. One of the causes is that the only direct counterpart we had from the very beginning was the compiler. The compiler was always available to tell us whether our code was syntactically and semantically correct. Compilers don’t care about naming conventions or good comments. But now we have another counterpart, and this is an amazing breakthrough for software engineering.

Conclusions

There are a lot of existential and ethical questions about Generative AI. It is a hot topic now! We can question how good it is for education, or whether it is fair people lose their jobs because of it. But I think nobody should have doubts about the benefits of this technology for software development.

Of course, there are other ethical concerns about this. Not everybody is happy about the training methods for technologies like Copilot. This could be the topic of a future article. Today, I just wanted to highlight how AI is contributing to Software Engineering. Thanks to Generative AI, the code of the future will be much better than today’s code. And not just the code of a few amazing guys that know their stuff. The methodology itself will enable the vast majority of us to write good code for humans (and bots).

I hope you have enjoyed this article. Feel free to reply with your take and experience on this topic. Thank you very much for another week of reading Under the Hype.

See you next Tuesday!