※ Editorial Note: The following work scenario and characters are hypothetical, designed to help understand the terms. They do not represent actual experiences of the author or events at any specific company.
Let's assume a hypothetical scenario where you trace logs to debug an intermittent inventory processing concurrency bug.
You spot traces of something a colleague installed in a recent commit, explaining why the log format suddenly changed.
When a new tool feature suddenly appears: Plugin
text
1Loaded plugin: log-formatter-pretty
Looking at your colleague's last commit, they installed an extension that formats logs to be more readable. This is a design where the core features of the main tool remain unchanged, and only the required features are built separately to be plugged in later. It is similar to swapping out modular parts while keeping the main chassis intact. Thanks to this, the logs became much easier to read.
A structure that plugs in required features separately while leaving the main body intact
As you organize and inspect the logs further, you notice the agent outputting messages indicating it references a specific file right before executing an action.
When the agent processes tasks in a specific way: Skill File
text
1Using skill: systematic-debugging
You realized it after reading the message on the screen. This is a method where the agent loads and follows a pre-defined procedural document that outlines which steps to take and how to solve problems in specific situations. It is like a chef preparing recipe cards for different scenarios and retrieving them as needed. Right now, it was following a procedure to systematically isolate the concurrency bug.
A structure of pre-defined procedural documents retrieved and followed as needed for specific situations
While following the procedure and opening files one by one, you notice an option that the person in charge in the scenario had configured in the past.
The reason why no confirmation prompts were appearing: Auto-approval Mode
json
1{"autoApprove":["Read","Grep","Bash(git *)"]}
You had completely forgotten configuring this months ago because approving every single read command was tedious. This is a setting that pre-approves specific types of low-risk operations so they execute immediately without asking every time. Thanks to this, your workflow of reading and searching through logs tonight could continue without interruption.
A setting that selects low-risk operations and runs them immediately without prompting every time
Finally, you find a suspicious spot in the middle of the logs. Two processes were halted at the exact same moment. Similar hangs were repeated throughout the logs.
When two operations wait for each other and halt indefinitely: Deadlock
After seeing the same pattern repeat multiple times in the logs, you became certain of the cause. It was a state where one side waits for a resource held by the other, while the other waits for a resource held by the first, halting indefinitely without yielding. It is like two people meeting on a narrow single-log bridge, each waiting for the other to step aside, leaving both stuck in place.
A state where both sides halt, waiting for the resources held by each other
Only then did you search and find out why this bug only reproduced once every few weeks.
When it works sometimes and fails other times: Race Condition
You looked it up, wondering why it occurred only occasionally rather than every time with the same code. The key was that the order in which the two operations accessed the resource was not exactly the same every time.
It was a phenomenon where the issue in the scenario is revealed only when they happen to overlap in a specific sequence, with the timing of which operation reached the resource first changing slightly every time. Like a race where the winner is decided by a hundredth of a second even when starting at the same signal, the one that arrived first changed every time. Because the two operations overlapped with that exact timing only at specific moments of high traffic, it was that much harder to reproduce.
An issue that only manifests when overlapping with a very slight difference in timing
By the time the cause was firmly identified, it was already light outside. A single fix to unify the locking order solved both the deadlock and the race condition.
Frequently Asked Questions
Isn't auto-approval mode risky?
There is little risk if you only allow operations that do not need to be rolled back, such as read-only tasks. However, it is not recommended to include actions that are difficult to revert, like deletions or deployments, in auto-approval.
Why is it difficult to filter out deadlocks in advance?
Since the individual pieces of code themselves are normal, they aren't caught by syntax checks. Because it only manifests when multiple operations run concurrently, it requires separate tests that reproduce the execution flow.
Can race conditions always be caught through testing?
Since it depends on timing, it is often difficult to reproduce with standard tests. It is more effective to use load testing that generates a large volume of concurrent requests, or dedicated tools that intentionally disrupt timing.
This is the 13th episode in the <a href="/glossary/code-generation" class="glossary-link" title="A technology in which AI automatically writes programming code based on natural language descriptions or the context of existing code.">AI Coding</a> Tool Glossary series. Next Episode Preview · Episode 14: Reflecting on the Year While Preparing for the Year-End Security Audit (Audit Log · Plan Mode · Headless Mode · Semaphore · Core Dump)
