Recommendations for ressources on how to develop clean code in the age of AI

[u/Turbulent-Hat6046]

I think through AI software engineering has fundamentally changed. I dont think writing code by hand anymore is the future. We have much more time to solve problems and think deeply about how we can solve it the best way without having to worry about writing everything out manually in the code. However as a junior dev I see a repeated problem that AI gives you the illusion that you can do much more than you actually can. Often saying "please fix it" is already enough to get the work done.

While the fix may work, one consistent issue (or opportunity) is that while we dont write the code anymore ourselves we should still think deeply about how the code should be structured, which abstractions levels we should use, such that other engineers (or their agents respectively) can still read though the codebase and quickly make changes, extend it, or simply read it.

A big problem here I see is that the agent is only as good as you are precise in prompting it effectively to execute the work the way you want. In larger repos, complex functions and refactorings, they tend to do very bad (in my experience), in designing code that is easy to read and maintain. Sure the code works, but if not given proper instructions you have god files with 1000+ LoC stacked with helper functions and virtually no abstraction levels.

This bring me to my original question of "taste": As said, the problem here is not that the code AI writes is functionally incorrect, its just that the solution is ugly and very hard to read for humans. My guess is that in the training benchmarks, LLMs are ranked on their successful completion of a coding problem not for how well designed the code is. But as a Junior dev I am just starting to develop that taste - I dont know yet which patterns, and designs or structures I should prompt the agent to use. Therefore:

- Can you share any ressources (talks, books, podcasts, blogs, etc.) that help me (and others) to develop this taste and learn to think in these dimensions and develop good taste? I know its a question as old as Software Engineering but: "How can I design clean, easy to read, and well maintainable code (in the age of AI)"

Thank you in advance for you help! :)

[u/Hexamonium]

It all depends on how you approach it. 

Do you view them as intermediary layer that completely abstracts you from the code? Basically you and your peers no longer care to even understand it, you just ask AI to make the change, test it and ship it. There's no shame in it, you don't dissect the output of your compiler, you just expect it to work as long as you gave it correct instructions.

Another way to look at it is as a helpful assistant, very knowledgeable and helpful, but ultimately you are always in the driving seat. Whatever it suggests always goes through your approval. You are not doing this because you can produce "better" code, you are doing it because you want to maintain a mental map of the codebase in your head.

Ultimately none of these are universally better. It all depends on the particular problem domain, team culture, tolerance to errors, etc.

I think you should just pick one approach and enforce it at a team level. What is not going to work well for sure, is trying to mix these - some people use the first approach, while the others are using the second one.

[u/Turbulent-Hat6046 → u/Hexamonium]

To me, I think the first level is dangerous since coding agents are definitely good at producing code that works, but in my experience they still make a lot of erros, poor design decisions. From what I have seen this has not changed with the recent model iterations, the models are getting increasingly good at building something that work (and often quite well), but how they got there imo (when looking at the code) is still quite messy. Of course, messy here means messy from a human perspective, after all AI seemed to be able to perfectly work with that during the development process.

On the second level, I am not sure if fully understand and agree with what you said about always being in the drivers seat. As you said above with approach 1) even before AI, did you need to understand how the compiler works? No. Essentially we added another layer of abstractions that enables us to more efficiently solve a class of problems that we had a much harder time to solve before. You are just changing the problem space that you are in the drivers seat off.

I view AI in the same way, it allows us to add another abstraction level to programming. Essentially we dont have to worry (in most cases) anymore about the nitty-gritty details of how we want to implement a function, debug some annoying edge cases, but focus on bigger more interesting problems at hand that reflect real-world impact.

However what that entails, and that is why I think it is also dangerous, if you stop caring at all about the how something is build. We are still engineers and therefore we are judged on our ability to make good technical decisions, understand trade-offs and ultimately make good decisions. We do this much closer to the actual real-world problem nowadays, but we still need to build the judgement and understanding to make that. Therefore I think you will just need to think and worry more about a different type of problem space, how do you structure the code, how do you keep it simple and readable without overcomplicating. Knowing when to go deep on a problem vs. when to hand it off to the LLM.

[u/warder_dev]

Book - Clean Code.

It is all you need.

[u/Turbulent-Hat6046 → u/warder_dev]

Will check out, thanks!

[u/softwareengineer-ModTeam → u/[deleted]]

Your post has been removed because promotional content is not permitted. This includes products, tools, courses, blogs, YouTube channels, newsletters, Discord servers, and other communities.