I have been facing a significant amount of decision fatigue when using AI for development. I’ll spend close to eight hours a day, five days of the week, prompting, planning, and reviewing code. This leads to decision fatigue, where I become less able to make sound decisions as the day goes on. Growing fatigue impacts the quality of the features I can produce. The goal then is to change how I work during the day to have a more sustainable level of quality. To drive the direction of these changes, I turned to something I read in a book about game development.
Decisions in Game Design and Software Development
In Designing Games by Tynan Sylvester, he argues that players need a balance of different decision types and scales. This is to maintain interest, novelty, and help manage energy levels. Different decisions require different amounts of thought to make and require different amounts of input. For the rest of this post, I will be using the relative sizes of big and small decisions to talk about how much effort they take to make.
In software development, big decisions require a significant amount of focus, have a high degree of impact on a system, or require significant amounts of information. You can make smaller decisions quickly, and they’ll have some impact but won’t be as significant.
For example, code review is a big decision or task. It requires a significant amount of focus and the risk of missing something is high. Does this new feature line up with the business domain? Is it duplicating logic that has already been defined elsewhere? Is the new code respecting our API boundaries?
By contrast, naming a variable is a smaller task. The context the variable lives in is all that needs to be taken into account. Does the name accurately reflect what the variable holds? Is it easy for someone with less context to infer what it is doing? This decision is important, but the scope of its impact is often reduced, and the amount of information required to come up with an adequate name is less than that of a comprehensive code review.
AI’s Impacts on the Decisions We Need to Make
It is worth noting that AI is generally good at automating small decisions and needs more supervision around bigger decisions. This pushes a developer’s time and energy into heavy tasks leading to a couple of different types of overload.
Information Glut: Where the agents are producing so much information that it becomes impossible to keep track of.
Expanded Decision Scope: Every agent is looking for answers to questions that have system- or module-wide impacts, and there isn’t enough time to process what the actual impacts of these decisions are.
Both of these constantly throughout the day contribute to decision fatigue because a developer can’t adequately research each decision and its impacts before making it. This leads to a snowball. Each time a system is worked on, the developer understands it less and less, since the information that was already overwhelming continues to expand and become more complicated.
Using This Theory to Reduce Fatigue During the Day
My goal then is to maintain focus throughout the day by creating more space to consider the big decisions and giving myself smaller decisions to work on while AI is working on something larger.
Manual Stub Implementations
First, I have been manually implementing the feature or spec in either pseudo code or in the stubbed functions before handing it over to the agent. This little bit of manual work gives me a chance to experience some of the small tasks of development, naming functions and variables, navigating the codebase, finding helpers that could be useful, and baking it into the code so that an agent will see it as it goes through the implementation process. Instead of me trying to tell the robot what to do entirely through the spec.
This has been helpful as I know the structure of the feature better than if I just described it in a spec, and I know where to expect changes when it is time to review the AI’s real implementation.
Bring Back Physical Notes.
Taking physical notes is a recommendation directly from Engaged AI Agentic Development, and I have fully adopted it. I have a beautiful notebook that I have started drawing diagrams in, or noting todos, or demo feedback. The same things that I may have done digitally have become a chance to refine my thoughts and test decisions and designs without committing them to a spec or allowing the AI to drive the process too early.
This impacts the size of decisions because now I am not trying to commit every answer immediately to a canon spec. I can play with it, make sure it is what I want, and then have an easier time describing it to an agent. It also gives me a chance to use a beautiful notebook that I have had for years and neglected due to digital notes.
My current notebook:
Spend more time as a user of your application.
The last thing is spending more time not only making sure each feature does what it is supposed to do, but also that it feels right when trying to use it. This is an opportunity to turn off the information flow from the agents and use what you know about the product to evaluate what has been built.
Open it in a browser and click around. How many clicks does it take to perform each task? Is all the text easy to read? The agent may have copied the design exactly, but does that design still serve the needs of the feature?
These are all questions that we used to ask throughout the process of writing code that now need to be explicitly called out and evaluated. They are decisions that have significant impact on the product but are not automatically present in a typical agentic workflow of defining a spec, generating code, reviewing the code, and then deploying to production.
AI encourages developers to make more decisions, based on more information, and do it faster. But, in doing so, it prevents us from paying attention to decisions we need to make outside of initial product design and outside the context of working with an agent.
Managing Decision Fatigue
All of these are concrete ways of manipulating the decisions that need to be made when building software. They all provide more space and time to research and make the big decisions, as well as small decisions that impact understanding and personal engagement with the software. Or they provide an opportunity to make subjective decisions about how the software feels to use. All of these were always key to building software, and they remain key in managing decision fatigue when working with AI. At the end of the day, when I mock out what I want, track ideas in a physical medium, and spend more time using the product, I have confidence that I am continuing to deliver the best possible software to the client.