A Quotation That Points to a Working System
On September 20, 2026, Simon Willison published a quotation from an engineer who had joined a large company roughly half a month earlier. The engineer said that specifications, code, tests, PRDs, tickets, ticket resolutions, reports, and nearly every other engineering artifact were being produced by Claude Code. The team did not like working this way, but was being pushed to ship as much as possible. Engineers from L1 through L7 were reportedly doing the same thing: talking to the model and moving its output further through the workflow.
The material is not an audited organizational investigation. It names no company, provides no incident history, and includes no measurements of code quality. Its value is not that it proves every enterprise now works this way. Its value is that it makes a conflict visible that management language can easily hide. Management reportedly believed that pushing code was not the bottleneck, while engineers were working 12 to 13 hours a day, almost merely pressing Enter. Faster submissions did not reduce working hours. They may instead have prolonged a mode of production in which very little of the output was understood.
The Bottleneck Has Moved, Not Disappeared
Treating Claude Code as merely a faster code editor would understate the change described by the quotation. The material does not describe the generation of an isolated code fragment. It describes a chain that begins with requirements and extends through implementation, testing, tickets, ticket resolutions, and reports. When a model participates at every point, the organization is not just accelerating one job. It is creating a workflow that can continually generate the next engineering artifact.
Existing knowledge-graph records about Claude Code also describe capabilities such as running plugin evaluations, rereading recently modified files after compression, submitting, monitoring, and debugging OSMO pipelines, and exposing an Agent SDK for broader engineering operations. None of this means that the tool is inherently uncontrolled. It does change how mistakes can propagate. An ambiguous judgment that once remained in one person’s draft can now be expanded into a specification, implementation, test suite, ticket, and report. The result may look complete without having been meaningfully checked by anyone.
From L1 to L7, This Is No Longer a Junior-Engineer Story
One detail deserves particular attention from technical leaders: the quotation places engineers from L1 through L7 inside the same working pattern. There is no described division in which models replace junior engineers while senior engineers provide meaningful oversight. Instead, everyone is reportedly talking to Claude Code, and almost nobody is reading the generated material. Differences in seniority therefore no longer automatically translate into more opportunities to understand the system. They may translate only into pressure to handle more tasks and push more submissions.
This is why the management judgment that code is not the bottleneck can become dangerous. Code can certainly be produced quickly, but engineering delivery includes more than producing code. Someone still has to determine what the requirement actually means, whether tests cover critical boundaries, which dependencies a change affects, and who can explain the decision when something goes wrong. If those judgments are postponed until after deployment, they have not disappeared. They have been converted into rework, debugging, and incident response, all of which are more expensive.
Submission Counts Can Manufacture the Illusion of Progress
When management treats code submissions as a progress signal, generative capacity is automatically translated into more submissions. The metric has an obvious advantage: it is easy to count and easy to compare across teams. It cannot answer the more important questions. Did the submission solve the right problem? Did it introduce new complexity? Can anyone explain its boundaries and failure modes? None of these answers appears naturally in a submission count.
In this field account, the metric is already in direct conflict with the working experience. Team members reportedly dislike the method, yet work 12 to 13 hours a day. Greater automation coverage has not freed their time, because their job has been rewritten as maintaining model output, handling the next generated artifact, and satisfying delivery pressure. As long as more code is treated as more progress, the more continuously Claude Code can perform engineering actions, the easier it becomes for the organization to mistake unexamined complexity for productivity.
Technical Leaders Need to Make Delivery Explainable Again
The practical starting point is not to ban Claude Code, nor to require everyone to hand-write every line again. The more important decision is to define which artifacts may be generated, which decisions must be explained by a person, and which changes require validation of intent, boundary conditions, and consequences before entering a critical path. Sampling generated output can expose some problems, but sampling cannot replace explicit responsibility checks on critical changes. “The model already handled it” cannot be the reason review ends.
The quotation provides no incident examples, so it cannot support a claim that a specific company has already suffered specific damage. It does provide a clear management signal. If every level of the organization is working longer while nobody is reading what the system is accumulating, the problem should not continue to be defined as insufficient execution speed. A more actionable response is to stop chasing submission counts alone and create delivery records that explain the requirement, the reason for the change, the scope of validation, and the responsible person. Automation can expand production capacity. It cannot assume the organization’s obligation to understand and take responsibility.