The sweet taste of AI-assisted indulgence
Working with LLMs in our internal software development is redefining routines and styles in many ways. In my case, what started as a lack of discipline seemed to open interesting possibilities for flow and business impact.
A lot of it is context-dependent (working as a solo developer on my company’s internal software, primarily for internal users), so don’t take it as anything close to general-purpose advice. But there’s more to the context than this; I’ll explore it in detail before closing.
Focusing and staying on track
In a typical scenario for business software development, we might pick a story from the backlog and run a quick collaborative modeling session to clarify scope and concerns. We extract the acceptance criteria to drive our development journey towards the desired business goal. A clear, deterministic set of completion criteria is a great way to make sure we don’t fall into the trap of gold-plating (adding extra costs after we’ve already delivered the desired business value) or lose focus along the way. Staying on track allows us to build value incrementally: our implementation journey might be designed so that the system incurs no regressions and progressively delivers business value.
When working on a task, it’s almost inevitable to see opportunities for improvements: bad abstractions in the code, unclear labels in the frontend, small bits of accidental complexity and ugliness. If you are a perfectionist, you’ll probably see a lot more. These side quests are probably just distractions, but sometimes they deliver good value. If we want to stay on track, we should ignore these distractions or quickly write them down as reminders for future work, usually as small notes that will require further refinement. Not now is the leading imperative; adding too much detail right now will be perceived as a detour. When pair or ensemble programming, the resulting peer pressure is a great way to stay on track. Theoretically, the most efficient path is the one that ignores the side quests, delivers the expected value, and stops right before gold plating.
That’s the reference model I have in mind; two small clarifications are needed before moving on.
The illusion of linearity
In practice, perfectly linear software development doesn’t exist, especially when working with legacy code. There will inevitably be deviations, surprises, and possible dead ends. So don’t take the previous picture too seriously.
Weaponized focus
This stay-on-track approach may also have a dark side, depending on your backlog policies. If most of your backlog is business-driven with little space for cleanup and refactoring, the side quests are the only places where technical work may happen. In a healthier environment where refactoring activities may happen regularly, then stay-on-track is just a neutral policy that preserves clarity of intent.
Indulging, instead
When working on my codebase, I’ve found myself, over and over, widening the scope of my tasks and adding many small changes on top of the original goal. Like sitting at a restaurant, intending to order something light, only to find myself enjoying the house specialty - which is never a salad - and a side dish, and the dessert.
Maybe I just lack discipline
The first response was to blame my lack of discipline in solo mode. I should define a goal, sketch a plan, set a timer, and follow the plan. It just didn’t happen that way. Instead, the many fire-and-wait moments that were punctuating my interaction with my coding assistant were giving me a continuous stream of leverage points - “I know exactly what I want, now.” - and of opportunity to multitask. I couldn’t resist and found myself forming the habit of starting more agents for the possible side quests.
I wasn’t getting into rabbit holes, well …most of the time. Initially, they were competing for my attention, with requests for approval, but after a few iterations, tweaking the permissions and providing more background context, the side quests were stealing less and less focus from the main task.
When closing the session, I’ve found myself with multiple PRs to merge into the main branch.
Observing overall impact
Session after session, I started to enjoy the situation. I was delivering the main objective, and some side quests. Side quests were small, sometimes just a visual glitch, or getting rid of something that had annoyed me for a long time. But things were moving, and opening new user habits.
What used to be a hard choice - taking a side quest will steal time and focus from the original goal - now becomes a lot softer, like a dessert with almost zero calories. While the core business feature usually requires close inspection, side quests can be executed in parallel and contribute to greater combined impact/business value.
Moreover, I was leveraging the sweet spot of having the perfect example of the small thing I wanted to fix right under my fingers: writing a task description for an agent now instead of writing it for a future self seemed like a no-brainer. Same typing effort, just on a different medium, less issue-tracker ceremony, and earlier value delivery.
The combined effect of the side quests was broadening the impact of the features. I honestly don’t know whether the main task or the side quest made the difference. I suspect it’s a combination of both.
A different type of multitasking
We know that multitasking is bad because of the extra overhead of context-switching in our brains. Here, the situation is slightly different: I am not multitasking; the agents are. So the resulting economy is different:
- When firing an agent, I am not really context-switching; I am capturing some of the current context and turning it into a prompt for another agent so I can quickly refocus on the original goal. I am reducing the ceremony of writing it to the issue tracker.
- Context switching may occur at closing/approval time, or if the side quest opens a bigger can of worms. But that may be a moment we designate to minimize the impact on our flow.
Now I don’t feel guilty for firing side quests anymore. I should just make sure I am not broadening the scope too much.
Low-hanging fruits
Sometimes the parallel task has nothing to do with the original one. It’s just sitting there, waiting to be solved, and I am too bored by the original task. In this case, we may still deliver some value, but we need to ensure the low-hanging fruit is safe to explore. I’ll rephrase: sometimes the trigger is not the opportunity of the sweet spot, but the boredom of being temporarily inactive.
It still works, but it’s not rationally justified by the sweet spot. In fact, this just signals that boredom is an ingredient in this choice and that our brains work differently when using AI-assisted coding. This is a topic for another post.
The upside
Overall, I’ve found myself increasing the perceived quality of the coding activities. The side quests often delivered small, noticeable changes that made users a little happier. The overhead for the small fixes also began to decline: the moment you notice something off or an opportunity for improvement, you may fire an agent with little worry.
Less overhead
Firing an agent over a side quest feels a little more efficient and sensible than writing a short specification for a future day that may never happen. We are solving small problems instead of seasoning them. No extra cost in prioritizing, and planning, not to mention negotiation and the mental effort to understand or worse, to explain to another person what we had in mind at issue creation time.
A broader idea of value
While key features continue to have a well-defined business rationale, focusing on smaller details improved the perceived quality of new features, especially in backend areas where UX wasn’t a high-priority concern.
A feeling of motion
Things are changing. Our release process is a relatively robust continuous delivery. But nobody notices progress unless you deliver something that improves their user experience. Many small positive increments can also be a Kaizen boost. While we are still tackling the big issues, which will require considerable time and a longer wait, things are moving in the right direction, and coding sessions deliver a small reward.
The downside
Now, this is clearly different from what I was used to. Is it good? There are a few issues worth noticing.
Messier Pull Requests
If you’re serious about committing discipline and workflow, the indulgent approach might result in a messier commit history or in some extra work to resolve the changes. Your agents are going to have a higher probability of working exactly on the same portion of the code you’re touching with your main task, increasing the probability of merge conflicts.
Session intensity
This indulgence has a price: I keep my brain busy, switching to the side quests when the main one forces me to wait. Sessions often take longer than the dedicated slot - Just one more thing - and drain a lot of energy, making your brain switch to reactive mode, without noticing.
Closing when you’re depleted
The moment you’re supposed to finalize the changes and promote them to the next environment in the chain, you’re going to be tired and prone to approve, no matter what. This is all happening on top of green test results, but I heard my brain thinking: “It’s good enough, let’s go home.”
What is the token cost?
Firing an agent doesn’t come for free. I am leveraging my subscription plan, which is a reasonable flat fee. My token consumption is more or less in line with my subscription plan. A sensible strategy with my current plan might be to keep my agents busy, accepting the possibility of occasionally hitting some limits. A different plan may challenge your priorities: if your token bill skyrockets because of your indulgence in gold plating, you may want to reconsider.
Uncomparable metrics
If you’re measuring fine-grained throughput on an issue tracker, your data is going to look a lot different. Small glitches, the ones that we could file with a screen capture and two sentences, stopped appearing in our issue tracker; they became agent tasks directly. Many small issues were fixed before being tracked. The flow improved, but not in the usual numbers. If you have a tighter integration between your AI assistants and your issue tracker, you may observe the opposite scenario: a sharp increase in the number of small chores.
Context
Every post about AI is meaningless without clarifying the context
- Single-person team This makes me more vulnerable to side quests due to the lack of peer pressure, but also allows me to pick up details I would have been reluctant to ask about.
- I approve my own PRs → I am not putting a colleague under a DoS attack with my side quests. Many small chores that accumulate as PRs can have a terrible impact on your overall throughput.
- I run the business. → My business needs are not presumed. In a corporate scenario, I would probably forbid most “regular developers” from guessing what the business may need, but in my case, I know what the business needs.
- Mostly features for internal users → Working on customer facing product features will require a different workflow, taking care of the feedback loops.
- I am autonomous. → Maybe this is the same previous point under a different lens, but it’s worth highlighting anyway. I don’t need a layer of business approval. That workflow may slow down operations way more than the technical review of the pull requests.
- Well-defined architecture → The foundation has been Domain-Driven from scratch. A CQRS/ES modular monolith with a strong separation into Bounded Contexts helps keep the exploration scope and the resulting token count under control. Low coupling makes side quests cheaper and safer.
- Stable & robust codebase. → The codebase is not collapsing under variations. Test coverage is good and protects from regressions. Don’t try the same on a fragile codebase.
- Continuous Delivery → Changes are released to users quickly, so the business impact is immediate and the feedback loop closes quickly. A high-ceremony release process would probably kill the vibe.
- Domain-aware harness. → Bounded Contexts are documented individually, providing a clear description of the expected behavior and a local glossary. AI rarely guesses wildly. Side quests’ descriptions are usually very short, because the context is already clear. This makes the agents themselves a little more autonomous, too.
Final thoughts
This is not a general-purpose approach. It works because some feedback loops can close faster than in a traditional corporate setting. However, taking a closer look behind the many hats I am wearing in this scenario (business owner, architect, user, domain expert, developer), you might not need all of them. Business competence and autonomy are the key enablers of a more effective development flow. Software professionals with a deep understanding of the business need can have the competence and the autonomy needed to unlock this possibility.
The economics of side quests have changed. Agents can enable parallel execution without stealing much focus. But the hidden accelerator is not waiting: writing for later carries significant process overhead. Small things stop accumulating in the backlog.
A domain-aware harness provides meaningful guidance on top of a robust foundation. Describing bounded contexts is pointless if the codebase has no real boundaries. A coherent codebase (see my previous post: Code is still a side effect) allows smaller prompts and less improvisation. This way, side quests can happen in parallel with a manageable impact on our attention.
Want to leverage the potential of Domain-Driven Design in your customer-facing products and services? Avanscoperta provides consulting services, and trainings on Domain-Driven Design and other fundamental topics for modern IT organisations.