Let me stop you right there because you start drawing breath to scream about the hypocrisy of an AI developer chastising AI developer for, well, being AI developers.

And I’ll make you buy a bath toy. But more on that later.

There’s nothing wrong in using AI and code assistants or copilots or whatever you want to call them. It’s a great tool, but there is a right way and a wrong way to use it.

Let’s start with the wrong way, because that’s what you are most likely doing right now, if you are reading this article.

The Wrong Way

I suspect you might be reading this article for one of two reasons – one is that you are currently upset about the title, because you are an AI developer and you are here to tell me right.

The second is that you are an AI developer and you are here to learn.

Because let’s face it, you’re an AI developer. Everyone is.

Stop Writing So Much Code!

So let’s start with an puzzling statement. The most productive developers today are those that don’t write code. And yes, you read that correctly – not writing code is more productive than writing code.

This seems to confuse inexperienced developers and especially and to no end, non-developers. How can you be more productive by not doing your job?

First of all, being productive is producing something, but more practically, it is producing something of value.

If I write 1000 lines of code to draw a line on the screen and someone else writes 1 line of code to do the same, who is most productive?

That’s right, the one writing less code to accomplish the same result.

So how do we get more productive, then? Well, by the same logic, we can’t get more productive by having an AI produce more code.

And if you don’t know how to write a line routine in 1 line, then having an AI do it in 1000 lines is not being productive.

Start Writing More Code!

The second factor of this is that by having someone else write the code, you do not learn. You do not craft, nor create, nor think what do write next.

This is an important factor of getting better. It is practice.

You don’t become a better chef by ordering food from a restaurant, even though the goal of having dinner might be the same.

You do not become a better juggler by hiring a clown for your kid’s birthday party.

You do not become a better writer by hiring a ghost writer.

And that brings us to the obvious contradiction of the wrong way of using AI – One the one hand you want to write less code but to get good, you need to write more code. How can we possibly resolve this conflict?

The Right Way

We have used code companions before. Copilots, if you wish. We’ve used them for decades. I built my first company around it in 1995.

It produces better code, teaches better, and you should do it all the time.

“Wait,” I hear you say, because programmers also get superhuman hearing as part of our secret society membership.

“We haven’t had useful AI companions until the last couple of years. How can this have been a thing developers have done for decades?”

Fear not, grasshopper, but let me first introduce you to the secret weapon of really great 10x developers.

A rubber duck.

The secret society of software developers have long known about the awesome power of this bath toy in understanding everything we explain.

In fact, it is so powerful that rubber ducking now is a term on Wikipedia, despite our attempts at keeping this awesome power to ourselves.

The idea is as simple as it is powerful – Explain to the rubber duck what you are doing.

The simple idea of using natural language to explain something is so powerful that developers have known that this can solve complex bugs or problems for a very long time.

And that’s where we come into pair programming

Pair Programming

In pair programming, you have one or more additional developers oversee what one developer is programming. The programming developer, let’s call them the pilot, write the code and explains what they are doing to the rest.

This serves two purposes. First, it forces the pilot to explain themselves in such a way that others understand what is going on. This forces the pilot to think and make solutions that are understandable.

If they don’t produce understandable solutions, the other people let’s call them… copilots… will let the pilot know and keep them on track.

The second purpose, which is less important for our scenario with AI programming, is that of sharing knowledge and training. If more people are involved in the code production, more people have seen it and can help support it.

Additionally, building code together also builds a shared understanding of patterns, logic, style, and approaches to solving problems.

“Hang on,” I hear you say again, because… Well, you know by now.

“This sounds terribly inefficient! Five people around a table watching the same code being written! How can that be efficient?”

Well, think about it like this… The amount of time a developer needs to understand a piece of code is exactly the same whether they see it get written or they read that code afterwards.

As such, there’s no real difference in efficiency if those developers need to understand that code.

Granted, they may not always need to understand the code, but that is another story not related to what we’re covering here today.

Those Ducking AI Developers!

Now, I’m not going to suggest you use an AI as your pair programming partner, or as your rubber duck. Because there are some major differences, both in how we work and what our goals are.

The main difference now is that we don’t need additional team members to join us. We can do a lot of the work ourselves.

Previously, and I’m talking just a few years ago, we always had to organize pair programming sessions around availability.

That’s a problem sometimes because not everyone is going to be available at the same time, nor focused or motivated at the same time. Thus, we might not be efficient if there’s more than two people who know each other well.

Now, however, we can use AI copilots to build better code because we don’t need to rely on others to do our pair programming or rubber ducking.

However, to do so requires that you are already a really great developer, that you actually have the chops to be the pilot to the copilot.

It requires you being experienced enough to explain to an AI exactly what to write.

Another major difference is that we don’t really care about the AI learning. We’re not building a team with them. We’re mostly interested in ourselves.

As such, we are much less, if at all, interested in whether they actually gain something from it. We want to explain exactly what we want because it forces us to think clearly about what we want to do.

Then, the AI can write that code for us. Who actually writes the code isn’t actually terribly important, unless you are still practicing becoming a good developer, as mentioned previously.

Conclusion

So there you have it. Nothing wrong with using AI to build code, if you understand everything well enough to explain it to a rubber duck, and to be a pilot so that others can be your copilot in a group or pair programming session.

And that’s the write way to use AI – As a copilot to a seasoned pilot, not to replace the pilot.

If you use AI to avoid writing code before you are good enough not to write code, then you are going to remain a mediocre developer and you are going to keep failing in your AI projects, just like almost all AI projects.

And when you do, hit me up because I can help you stay out of the 90% club of failed AI projects.