An engineer, not me. He is part of a small company run with a few close collaborators, with a structure that is simple but flexible. They build their own products there, the ones they genuinely want to exist, and they also develop systems for third parties who need something built.
The same company sometimes functions as an umbrella that allows its members to spend part of their time contributing inside more traditional organizations, simply working as engineers within those teams. Moving between those environments is fairly natural. The arrangement is less exotic than it might sound. It is simply a practical way of organizing work while staying connected to different layers of the industry.
For years this engineer wrote software the traditional way. Nostalgia had nothing to do with it. That was simply the best available method. Automation tools existed, but they did not meaningfully compete with a careful implementation written by an experienced developer.
That changed quickly. Once he understood how to extract real value from LLMs, the shift was immediate. By defining behavior with precision. The specification describes not only the functionality but also the structure of the implementation: hooks enforce architectural decisions, constraints define patterns, even relatively small details like naming conventions, variable formats, authentication mechanisms, linting rules, structural expectations of the codebase.
Under those conditions there is no guessing. The model implements what was specified. Tests are generated alongside the implementation and remain part of the process as verification, simply confirming that the constraints defined in the specification are respected. Fuzz testing expands the surface further, probing edge conditions and unexpected inputs so that the system is exercised beyond the obvious cases.
There is something here that might be called pseudo-determinism. Not in the classical sense. The same prompt does not always produce the exact same output (or does it?). With constraints in place, the results converge. The human eye sits at the end of the cycle, confirming again and again that the output looks no different from what a deterministic process would have produced. This is March 2026, not October 2025. Six months apart, humanly close, technologically not so much. Was the developer writing code in 2019 deterministic? Was his brain? Perhaps yes, perhaps no.
The effect on productivity becomes visible very quickly. Inside his own company, both in their internal products and in the systems they build for clients, things that previously required several months can now be implemented in a few weeks, sometimes less. Not with lower standards, but often with stricter constraints, broader automated tests, and documentation produced as part of the same flow.
Once the mechanism becomes clear, the transition tends to be immediate. Teams whose survival depends directly on delivery do not debate the shift for long. If a tool allows them to implement the same systems faster, with tighter constraints and broader automated verification, they adopt it.
There is a certain picture that appears in corporate narratives about this transition, almost a projection: the engineer as a reluctant artisan, deeply attached to traditional craft, resistant to change, needing to be guided toward the future. In this picture, he sits at his keyboard, grudgingly weighing each decision. This function with AI... this other one by hand... click, click... tapping away at the keys. A little AI here, a little tradition there. Fifty-fifty. Incremental progress. Curves that slope upward across quarters. This picture is useful. It gives adoption programs something to measure, a narrative to unfold, a story of progressive improvement driven by the right initiatives.
But the engineer in this story has a shop to run. He may appreciate traditional craft, but he also needs it to be profitable. Once he verifies that the tools work, he adopts them. The transition is immediate because the results are tangible. There was no internal debate about preserving artisanal methods. There was a business.
And this is where the contrast becomes interesting. Inside the corporate environment where he occasionally contributes, artificial intelligence is also a strategic topic. Workshops appear, initiatives are launched, managers are asked to help incorporate these tools into the development process in order to improve delivery.
But the role they occupy comes with a slightly different responsibility. They are not only introducing tools. They are also expected to demonstrate how those tools improve the organization over time. Adoption must be visible and progress measurable, ideally emerging in smooth curves across quarters.
From the perspective of someone who spends time both inside small teams and inside large organizations, the contrast is sometimes striking. In smaller environments focused directly on delivery, the same tools are already compressing months of work into weeks. Pull requests can be analyzed automatically against the same constraints that generated the code in the first place, verification layers catch structural problems, style violations, architectural drift. Human review remains present, but it is often lighter because much of the mechanical verification already happened.
Meanwhile, inside larger organizations with far greater budgets and explicit AI initiatives, development can still move through familiar patterns. Pull requests circulate between reviewers for days or weeks, discussions grow around minor details. Sometimes entire review cycles revolve around commas in documents that were never strictly necessary for the implementation itself.
For years he repeated the familiar mantra: documentation matters. And it does. But he realized, well before AI entered the picture, that code itself is the best documentation for a programmer. Better still, the test that covers that code. Now add what sounds like laziness but is actually insight: an LLM can extract optimal documentation on the fly from that same code. All that minutiae starts to feel like a relic.
Within those walls, it is not unusual to hear concerns about hallucinations, almost as a form of caution. Let us move forward, yes, but carefully. The word itself feels dated now, a concept so 2023 it almost hurts to hear. Not that the possibility does not exist, but for someone working daily with proper constraints in place, it is a visitor that got lost somewhere along the way. Perhaps the engineer in this story is simply fortunate.
None of this comes from bad intentions. Large systems move carefully, and the responsibility attached to them is real. But paradigm shifts have a pattern. The window opens, and those who move first take the largest slice. It happened before in previous bubbles. Small shops had their moment, some seized it, and eventually the cycle closed on them again. The opportunity was real while it lasted.
Now the window is open again. Small organizations without elephant movements can skip the adoption curve entirely. In fact, they already are. There is no position to justify, only a business to make productive. The opportunity is not only for the small shops. It is also there for the suits. But not for those who slow down the wheel to measure it. There is a certain Heisenberg effect in creating hard bureaucracy to track how much we are progressing instead of using all the steam to actually progress. The measurement apparatus consumes the energy it tries to quantify.
The real credit will go to those who let results speak for themselves. Not to those who focus on the ritual of measurement, the regularity of reporting, the smooth adoption curves carefully decelerated by the very process of tracking them.
Cold turkey beats gradual adoption when the tools already work. The engineer in this story, and many of his colleagues, can attest to this. Not that sharing this changes much. It is not a secret guarded under twelve locks. It is a truth already revealed and verified by anyone willing to look. And yet the inertia seems almost inevitable, part of how the human mind works, how societies move. Perhaps that is simply how these things go.