Why You Should Generate More Code
Not production code, but everything around it
Everyone talks about how you should generate more production code, more features, more tickets, but we should focus more on proofing that our result of generation is correct.
We should be more concerned with whether the resulting code generation fits our architecture, meets our code quality standards, and aligns with our overall development practices.
If you do not have any and you just go with vibes, the resulting slopfest will create more issues at some point than it provides benefits.
I like the thinking that Mitchell Hashimoto shared in his post.
I believe it is not really necessary to remember every single line of code or where it comes from, as long as you know how to go through the methods and understand their purpose and how they fit into the overall architecture.
Yes, I think this is nothing new to you: read the code, understand it, and make sure it aligns with your architectural and quality standards.
Other Angle
What if we shifted left more? Let’s produce less code upfront and focus more on generating supporting code, tests, and documentation that ensures the quality and maintainability of the codebase.
You can generate as much verification code as needed to ensure that a minimal change to the main codebase does not introduce regressions or quality issues.
You do not need to commit all testing boilerplate code, but you can take more steps to ensure that your code changes are thoroughly verified before merging.
If your code is that important, feel free to create many times more verification and tooling around it to ensure its correctness.
Write more tests, create an environment where you can test your code, simplify the setup of the project, automate repetitive tasks, and decrease the time spent on development.
If you avoid implementing one feature after another and invest in it, you will have more trust in your generated code and the overall quality of your codebase.
You can picture it as follows:
I have never felt more encouraged to refactor code and write tests for it. Not because it is required, but because with AI it is easier to do so, and it buys you more time to focus on higher-level design and innovation.
Every time I have doubts that something will not work as expected, I write a test for it and verify its behavior before merging. If the structure does not make sense, refactoring it is not such an issue anymore. It becomes a natural part of the development process rather than a daunting task.
Try this
Next time you implement a feature, before you move to the next one, try to build the tests around it and go even further than your traditional workflow.
Try to implement UI tests and create a config that will make your testing environment easy to set up and maintain.
If you find yourself in an endless loop of tasks, find a way to automate them.
You do not have to be stuck in one endless loop, because breaking it is not impossible. AI can help you automate a lot.
Or in other words, move from spending tokens to investing tokens in generating more code and automation that saves time and ensures quality.
Socials
Thanks for reading this article!
For more content like this, follow me here or on X or LinkedIn.
