In the past, writing software was entirely a human’s job.

Now, we live in a world where humans collaborate with AI at every stage of the development process – writing, reading, and reviewing code.

Over the last 50 years, developers built up good practices for working with the code. But, now that we are no longer the only species working on the codebase, is it time to tweak our perspective on the principles and norms we use every day?

1. Bye-bye, DRY: Rediscovering repetition

Consider code duplication.

We have grown up believing that duplicate or superfluous code is less efficient and more difficult to maintain. The principle of “Don’t Repeat Yourself” (DRY) encourages duplication avoidance.

For example, scaffolding tools and boilerplate templates that spit out large chunks of starter code are a great way to kick off projects. But, when scaffolding is rolled out several times over, codebases can soon become littered with slightly modified copies and overlapping functions, making upgrades hard.

My approach to DRY has always been to leverage code abstraction - creating dedicated libraries and frameworks to handle discrete things in isolation.

Even this abstraction has a cost. With your logic partly in your code and partly in a library, you still need to understand each dependency in detail. So, a counter-philosophy, Avoid Hasty Abstractions (AHA), warns us of the pain of going too far:

Developers have always tried to find the balance between DRY and AHA. For example, how “wrong”, exactly, should abstraction be to make duplication acceptable?

AI coding may tip that balance. With AI in your code editor, automated changes to the codebase becomes even “cheaper”, because you're often a few easy prompts away from making a significant rewrite.

Nowadays, I am becoming more willing to accept code duplication instead of abstraction, if it improves clarity and comprehension. That is because the maintenance “cost” of understanding and tidying duplicated code can easily be less than the consequences of abstraction.

Thanks to AI, repetition may no longer be the coding crime it used to be.

My recommendation:
With AI, be a bit more willing to accept code duplication, and a bit less willing to accept complex frameworks.

2. Rethinking code review

As a developer, I’m still amazed by the capabilities AI tools give me. Individual programmers now have a “partner” with which to develop something.

But AI coding is not just changing solo development, it’s also reshaping teamwork, and one area in which a new collaborative process is playing-out is code review practices.

Let’s think about two classes of code review:

1. In-development: Human developer reviewing AI-generated augmentations of her own code, often on a developer’s own machine, without pushing any code or leaving any written comments.

2. Formal review: In a formal code review process, a secondary developer provides a material review to code pushed by the human-and-AI pair.

It may seem obvious, but it’s really important for the primary developer to skip reviewing AI-generated code - else, she would simply be pushing this work to the secondary human review. Shovelling along unchecked AI code is rude and shows a poor team ethic.

To be helpful, the primary developer should also be explicitly clear about which code is AI-generated, stating whether it has been reviewed and adjusted carefully before sending it on for human review.

AI is reliably good at making plausible-looking code. It may be well-documented and well-formatted - for humans, a clear signal of craft and competence at work. But such polish can be misleading during code reviews.

That’s something I need to constantly remind myself about while reviewing AI code.

Recommendation:
Be a good team player: review and clean up AI-generated code before sending it to others. Your teammates should be reviewing your work, not cleaning up AI mess for you.

3. Are you gonna need it?: Beware over-coding

Just as an LLM chatbot is prone to over-writing, it often outputs too much code - way more than a human developer would have written.

• The model may try to build for edge cases that are unlikely to ever arise.
• Sometimes, it decides to implement a library function from scratch.
• You, too, may decide to accept additional feature suggestions that a human wouldn’t otherwise have implemented. After all, adding features so effortlessly feels almost free.

In the past, effort prevented over-building. Developers naturally dropped feature ideas that would take too long to write.

With AI, though, the cost of writing such features is low and the urge to say “why not?” is strong.

• In a single-developer environment, accepting these suggestions and code length is mostly harmless. You can get to a more complete product or prototype quickly.

• But, in a team environment, this is an anti-pattern. Every extra feature adds code review, QA, and maintenance “costs” that slow down a team.

For three decades, the software principle “You’re Not Gonna Need It” (YAGNI) has urged developers not to build for hypotheticals.

In the past, heeding YAGNI’s advice was a no-brainer, because the desire to build more was weighed down by the effort of actually doing the building. If you were not truly willing to do the work in the first place, then you definitely were “not gonna need it”.

Recommendation:
In a world where AI makes further and further development effortless, it becomes easier to ignore YAGNI. That would be a mistake - code proliferation today can bring your business to a halt tomorrow. The long-term cost and confusion of adding unnecessary code for tomorrow actually make considering this principle more important than ever.

Recommendations for a rethink

The historic software development principles which we all learned are still very valid, but we should not be dogmatic about them. AI does shift which approaches work best, and we should keep iterating.

As we all adopt AI in our coding, these are the things I keep reminding myself:

1. Duplication is not a disaster: Be willing to accept repetition, because refactoring is so easy.
2. Don’t pass on AI slop: AI’s additions to your code are your responsibility. Be a team player - review and clean AI code before sending it to your teammates.
3. Appearances can be deceiving: Nice-looking AI-generated code can be very wrong; it’s a misleading signal.
4. Remember YAGNI: When AI is used, and you’re working in a team, always ask if “You’re Not Gonna Need It” is true.

For the first time in a long while, I’m rethinking the rules of the craft and relearning old lessons with a fresh twist. What an exciting time to be a developer.

In the past, writing software was entirely a human’s job.

Now, we live in a world where humans collaborate with AI at every stage of the development process – writing, reading, and reviewing code.

Over the last 50 years, developers built up good practices for working with the code. But, now that we are no longer the only species working on the codebase, is it time to tweak our perspective on the principles and norms we use every day?

1. Bye-bye, DRY: Rediscovering repetition

Consider code duplication.

We have grown up believing that duplicate or superfluous code is less efficient and more difficult to maintain. The principle of “Don’t Repeat Yourself” (DRY) encourages duplication avoidance.

For example, scaffolding tools and boilerplate templates that spit out large chunks of starter code are a great way to kick off projects. But, when scaffolding is rolled out several times over, codebases can soon become littered with slightly modified copies and overlapping functions, making upgrades hard.

My approach to DRY has always been to leverage code abstraction - creating dedicated libraries and frameworks to handle discrete things in isolation.

Even this abstraction has a cost. With your logic partly in your code and partly in a library, you still need to understand each dependency in detail. So, a counter-philosophy, Avoid Hasty Abstractions (AHA), warns us of the pain of going too far:

Developers have always tried to find the balance between DRY and AHA. For example, how “wrong”, exactly, should abstraction be to make duplication acceptable?

AI coding may tip that balance. With AI in your code editor, automated changes to the codebase becomes even “cheaper”, because you're often a few easy prompts away from making a significant rewrite.

Nowadays, I am becoming more willing to accept code duplication instead of abstraction, if it improves clarity and comprehension. That is because the maintenance “cost” of understanding and tidying duplicated code can easily be less than the consequences of abstraction.

Thanks to AI, repetition may no longer be the coding crime it used to be.

My recommendation:
With AI, be a bit more willing to accept code duplication, and a bit less willing to accept complex frameworks.

2. Rethinking code review

As a developer, I’m still amazed by the capabilities AI tools give me. Individual programmers now have a “partner” with which to develop something.

But AI coding is not just changing solo development, it’s also reshaping teamwork, and one area in which a new collaborative process is playing-out is code review practices.

Let’s think about two classes of code review:

1. In-development: Human developer reviewing AI-generated augmentations of her own code, often on a developer’s own machine, without pushing any code or leaving any written comments.

2. Formal review: In a formal code review process, a secondary developer provides a material review to code pushed by the human-and-AI pair.

It may seem obvious, but it’s really important for the primary developer to skip reviewing AI-generated code - else, she would simply be pushing this work to the secondary human review. Shovelling along unchecked AI code is rude and shows a poor team ethic.

To be helpful, the primary developer should also be explicitly clear about which code is AI-generated, stating whether it has been reviewed and adjusted carefully before sending it on for human review.

AI is reliably good at making plausible-looking code. It may be well-documented and well-formatted - for humans, a clear signal of craft and competence at work. But such polish can be misleading during code reviews.

That’s something I need to constantly remind myself about while reviewing AI code.

Recommendation:
Be a good team player: review and clean up AI-generated code before sending it to others. Your teammates should be reviewing your work, not cleaning up AI mess for you.

3. Are you gonna need it?: Beware over-coding

Just as an LLM chatbot is prone to over-writing, it often outputs too much code - way more than a human developer would have written.

• The model may try to build for edge cases that are unlikely to ever arise.
• Sometimes, it decides to implement a library function from scratch.
• You, too, may decide to accept additional feature suggestions that a human wouldn’t otherwise have implemented. After all, adding features so effortlessly feels almost free.

In the past, effort prevented over-building. Developers naturally dropped feature ideas that would take too long to write.

With AI, though, the cost of writing such features is low and the urge to say “why not?” is strong.

• In a single-developer environment, accepting these suggestions and code length is mostly harmless. You can get to a more complete product or prototype quickly.

• But, in a team environment, this is an anti-pattern. Every extra feature adds code review, QA, and maintenance “costs” that slow down a team.

For three decades, the software principle “You’re Not Gonna Need It” (YAGNI) has urged developers not to build for hypotheticals.

In the past, heeding YAGNI’s advice was a no-brainer, because the desire to build more was weighed down by the effort of actually doing the building. If you were not truly willing to do the work in the first place, then you definitely were “not gonna need it”.

Recommendation:
In a world where AI makes further and further development effortless, it becomes easier to ignore YAGNI. That would be a mistake - code proliferation today can bring your business to a halt tomorrow. The long-term cost and confusion of adding unnecessary code for tomorrow actually make considering this principle more important than ever.

Recommendations for a rethink

The historic software development principles which we all learned are still very valid, but we should not be dogmatic about them. AI does shift which approaches work best, and we should keep iterating.

As we all adopt AI in our coding, these are the things I keep reminding myself:

1. Duplication is not a disaster: Be willing to accept repetition, because refactoring is so easy.
2. Don’t pass on AI slop: AI’s additions to your code are your responsibility. Be a team player - review and clean AI code before sending it to your teammates.
3. Appearances can be deceiving: Nice-looking AI-generated code can be very wrong; it’s a misleading signal.
4. Remember YAGNI: When AI is used, and you’re working in a team, always ask if “You’re Not Gonna Need It” is true.

For the first time in a long while, I’m rethinking the rules of the craft and relearning old lessons with a fresh twist. What an exciting time to be a developer.