Don't Imitate Understand - #7
Hello!
In this seventh issue of the "Don't Imitate Understand" newsletter you'll get:
- Course news and a discussion of avoiding code review burnout in the age of AI.
- A bunch of interesting links!
Course News
- The special founding member lifetime pricing opportunity for All-Access Mentorship ends in two days and never returns. Access all existing and future courses, a community, and a monthly dev round table on lead and architect skills.
- All courses and coaching are on sale through the Dec 31st. If your team has an education budget left to spend, you can now grab discounted team licenses for Understanding React and the new Modern JavaScript Frameworks course and AI-assisted development course.
Avoiding Code Review Burnout in the age of AI
Social media is full of posts talking about having multiple AI agents generate large amounts of code in a fraction of the time it would take a human coder.
These breathless posts, however, ignore an important fact: often a human needs to review that code. And reviewing that code can be exhausting.
I've spoken with students who are beginning to hate their jobs as coders, not because AI generates code for them, but because they have to review it. For most of us, reviewing code isn't nearly as fun as writing it.
Eventually you reach one of two states: apathy, in which you no longer review as carefully, or burnout, in which reviewing thousands of lines of code becomes unsustainable.
How can you avoid apathy and burnout in the age of AI, and still ensure AI-generated code doesn't break your software or your business?
Last month Gergely Orosz (of The Pragmatic Engineer) interviewed Martin Fowler and Mr. Fowler compared software development with non-deterministic LLMs to structural engineering where you deal with degrees of tolerance. Mr. Fowler said: "we need probably some of that kind of thinking ourselves what are the tolerances of the non-determinism that we have to deal with and realizing that we can't skate too close to the edge".
I've written about and been giving conference talks on my approach to this I call "Entropy Tolerance", which you may have read or watched.
One of the simplest, most impactful things teams working with LLMs can do right now, today, is to mark the entropy tolerance (ET) of the tickets the team is working on.
As a reminder, the definition of entropy tolerance is: how much uncertainty (or AI-generated 'guesswork') a software-supported process can handle.
The idea is not the tolerance of the code itself, but of the processes the code is supporting. For example, the entropy tolerance of creating a prototype for testing is high, but the tolerance of a function to calculate payroll is low.
The entropy tolerance (ET) of a ticket tells you how detailed your human code review needs to be.
This has direct benefits when it comes to code review apathy and burnout. By marking certain work as having a high tolerance, you can focus your team's code review energy on the areas that are the highest risk, and permit AI-generated bugs in areas where it is low risk or can be identified and fixed over time.
If you mark your tickets in Jira, Linear, or however you manage work as high, medium, or low tolerance, you can carry that forward into code reviews and pull requests.
High tolerance: code review can by cursory or just review the running software.
Medium tolerance: code should be reviewed, but the review can be high-level and coders don't need to burn out reading every line.
Low tolerance: every line of code must be reviewed by a human coder.
Another benefit of this is setting accurate expectations for yourself and your team. If you end up with most tickets having a low ET, then you know that you simply aren't going to have the 10x speed up with LLMs that social media tells you that you should have.
You've surface that the processes your software supports can't risk unreviewed AI-generated code. And that's ok! It means you need to adjust your processes, and have your coders prompt and review in slower, smaller, iterative steps to avoid burnout.
So consider the Entropy Tolerance of the process being supported by the code you are writing today. Surface that tolerance in the related tickets or requirements.
Avoid burnout. Avoid unreasonable expectations of AI-enhanced productivity. Your team will thank you.
Are you or your team suffering from AI-generated code review burnout? I'd love to hear your stories, feel free to reply to this email and let me know!
Links
- A UX analysis of Apple's Liquid Glass (hint: it's not good)
- An interesting breakdown of how React serializes Promises
- I completely agree with Jared Spool's quick take on LinkedIn on the usability of AI prompts
- I wrote a short blog post that hit the top of Hacker News: We're Losing Our Voice to LLMs
That's it for this seventh issue!
You received this because you either a) signed up for the newsletter directly on tonyalicea.dev or b) get emails from dontimitate.dev. If you enjoy my content, please let other people know about the newsletter! They can sign up here: https://dontimitate.dev/newsletter/.
Happy coding!
Tony Alicea