By Friday, the senior engineer in the comic is holding one sheet of paper. The junior is standing beside a stack of code taller than he is. They received the same complaint and used the same AI. They ended up completing different work.
The junior improved the database because the application was slow. The senior opened the reported page and found a 40 MB photo. Their approaches had already diverged before either of them started changing the code.
That is the part I want to examine. AI can help us get work done, including investigating what causes a problem. The result also depends on the information we provide, the questions we ask, and how we check the answers. The comic uses a senior and a junior engineer to illustrate that difference. It does not establish that senior engineers always choose the right approach.
The application is slow. Why start with the database?
In panels 1 to 3, the reader has already seen the photo slowing down the page. The two engineers have not. All they have is a ticket saying that the application is slow.
From the junior's position, the database is a reasonable possibility. The home page might retrieve too much data, run an expensive query, or wait too long for a server response. These are possibilities worth investigating.
A query is an instruction to retrieve or process data in a database. One example is retrieving the list of products shown on a home page.*
The junior chooses a fix before checking that explanation. The request to AI already points toward database optimization, even though the team has no measurement showing that the database causes the customer's problem.
The senior opens the same page as the customer and watches it load. She does not know the answer yet either. This step gives her information that can help determine what to inspect next.
The junior could also ask AI to help plan that investigation. Which page should they open? What should they record? How can they separate time waiting for the server from time spent downloading a photo? They can then run those checks and compare the results with their initial explanation.
Why three degrees?
In panel 4, two lines leave the same point with a small difference in direction. In panel 8, the angle has not changed, but their endpoints are far apart because both lines have continued to grow.
Suppose we travel 100 metres in a direction three degrees off the intended path. We end up roughly five metres to the side. If we continue for 1,000 metres in that direction, the sideways distance is about 52 metres. The angle can stay the same while the distance grows.
Engineering decisions do not come with an angle we can measure. The drawing illustrates how more work can follow an initial explanation that has not been checked. We change a query, write tests, add configuration, and adjust other code to accommodate the change.
If AI helps us produce those changes faster, more work can accumulate before someone checks the original explanation. AI can also help us check it earlier. Its effect depends partly on where we use it in the work and when we review the results.
The comic's claim about producing ten times as much code is also part of the illustration. I am not treating it as a productivity increase that applies to every team. The growing stack of paper shows how much work has followed that first choice.
If the tests pass, what else needs checking?
In panel 6, the junior asks a useful question: is the database actually the slow part? If the team follows that question with measurements from the customer's page, they have a chance to change course before adding more code.
The robot's response is deliberately exaggerated. It praises the question and supplies a faster version of the code. Work resumes before the question about the cause has been answered.
This does not mean AI always agrees or cannot help investigate a problem. We can stop at a response like that and ask what evidence supports the database explanation. If the evidence is missing, what should we measure? A plausible explanation still needs to be checked against the application we are working on.
In panel 7, the tests pass and the benchmarks improve. Those results may show that the database changes work in the ways the tests cover. If the benchmark only measures queries, we still do not know whether the customer's waiting time has improved.
During review, we therefore need to distinguish several questions. Does the changed code work? Does the part being changed cause the problem? When we apply the change, does the customer's problem improve? Answering the first question does not automatically answer the next two.
How can the smaller change be more useful?
In panel 9, the senior explains that the home page photo was 40 MB. She made it smaller, and the page now loads in under a second within the story. The junior realizes that he has rewritten the database for a complaint caused by another part of the application.
That loading time is an outcome given in the story, not a prediction for every 40 MB photo. In a real application, we need to measure it. The result depends on the delivered file size, the connection, other files on the page, and the work the browser performs.
The photo change also needs checking. Is the image clear enough for the customer's needs? Is the original file still available? Does the browser request the new version or reuse a previously stored file? The before and after tests need comparable conditions.
The senior's single sheet of paper does not mean a smaller change is always better. The database may need work. We need to examine how a change relates to the problem we want to solve, including its risks and the additional work required to maintain it.
In panel 10, the junior's code goes into a recycling bin. The comic uses that image to show work that ends up unused. In practice, we do not have to delete every change immediately. We can review it separately and check whether it has another clear use. But spending time on code is not, by itself, a reason to include it in the application.
What should the senior have done earlier?
In panel 11, the senior finally discusses the purpose of the work with the junior. I think this conversation should have happened before the stack of code grew so large.
If the senior knows the application and its possible failure points better, she can use that experience to help the junior plan the investigation. They can start with a short explanation: what problem does the customer experience, what might cause it, and what information supports that explanation?
Suppose the junior proposes improving the database because the home page is slow. The senior can open the page with him, record which part takes the longest, and compare that with the query time. The junior still does the analysis and explains the results. AI can help read the code, prepare checks, or compare the measurements.
Review can then begin before the entire change is complete. After the initial investigation, the team can already discuss whether the next step addresses the customer's complaint. If their explanation changes, they can adjust the plan while the amount of changed code is still small.
For the next task, the junior can keep the original complaint, test conditions, measurements, and reasons for choosing the fix alongside the code changes. During review, the senior can follow his reasoning and the team can check the same page again. The junior then gets practice choosing what work to do and demonstrating its result, as well as using AI to complete the code.