The Era of Great Flattening
Shen Translation is a translation team under 36Kr, focusing on technology, business, workplace, life and other fields, focusing on introducing new foreign technologies, new perspectives and new trends.
Editor's Note: Say goodbye to the traditional development model that relies on stacking manpower. When the cost of intelligence halves every four months, the future belongs to the "great flattening" era where bottlenecks are overwhelmed by Tokens. This article is translated from foreign sources.
The Awakening of Large Models
Over the past year, something has happened that most people have not yet fully digested and absorbed. Large language models have surpassed human capabilities in the field of programming — not just showing a trend, not nearly approaching, but truly outperforming humans at this very moment. I used to rank top among Indian participants in major competitions such as Google Code Jam, Topcoder and ACM ICPC, but cutting-edge models have left me far behind. I am in awe of this every single day.
Such powerful models are no longer suitable to be confined to your personal computer. With every new version release, models can run autonomously for longer, plan their own work, and derive dedicated auxiliary programs. A machine that must be placed next to you and kept powered on is by no means the right carrier for all of this. The future of software development lies in the cloud. The rest of this article will clarify the logic behind it and the required conditions.
You Are Still Part of the Loop (Humans in the loop)
With every iteration, the independence and efficiency of model operation keep increasing. However, walk into any engineering organization, and you will still see humans tied to the process: inputting prompts, reviewing code, correcting deviations, and being firmly bound to the machine. I have experienced all of this firsthand. I used Claude Code extensively and monitored every session like a babysitter, but excessive interference erased the speed advantage; while leaving it unattended would easily deviate from the established direction. The latest models have put an end to most of these dilemmas. They can run unattended for hours, plan their own work, streamline context, and independently verify outputs before delivering results. So, is the babysitting-style supervision over? Not really. Just like all bottlenecks, it has only been elevated to a higher dimension. In the past, you supervised individual sessions; now you supervise the entire system: do you dare to trust a merge request that you have not reviewed line by line? Can twenty autonomous sessions work on the same codebase at the same time without conflicts and collisions? Has the result been verified in a real software stack before it is presented to you?
You crave extreme parallelism. You want to close your laptop and come back to find the work already done. The more you are removed from this loop, the more the work must run in the cloud.
If that's the case, why haven't everyone fully embraced the cloud yet? Because the cloud currently provided to them is blind. An Agent can write code on a virtual machine somewhere, but it cannot run your application, nor can it spin up all your services for end-to-end testing. As a result, every branch eventually has to be pulled back to the local laptop for verification, and you are pulled back into that loop again. The cloud must effectively solve the end-to-end operation and testing problem to truly save you time.
The Entire Company Is Being Flattened
Writing code is no longer the bottleneck. In the past, engineers received instructions from managers, listened to requirements from product managers, and then executed them; information decayed as it passed through layers, and iteration cycles were endlessly stretched. Those days are gone. When you can turn an idea into production-ready code in minutes, the scarce resources shift to novel ideas, the ability to extract requirements directly from customers, and the courage to launch the next experiment. I was the co-founder and CTO of Rippling. Recently, the number of lines of code I deliver every week even exceeds that of the engineers under me — not because I am more skilled, but because customers throw out ideas during calls, and these ideas go directly to development sessions, and the code is even merged before the call hangs up. Backlogs should never exist in the first place, an idea should be turned into productive output within hours.
Extending along this transformation, past your desk, it will completely reshape the entire company's structure. Every company has a fixed "human cell boundary": the interface facing the outside world. Sales, customer relationships, and those moments where a human must represent the company to face another human. These areas remain human-dominated for now... at least for the time being. Inside the boundary, planning, design, architecture, review, execution, everything is collapsing into Harness, the control framework that drives work. The organizational chart is not so much shrinking as it is morphing. There may only be one person left inside, or no one at all. This is the Great Flattening.
As a result, the work itself moves to the "Meta" level. You no longer stick to solving the specific task at hand, but instead start exploring why this organism cannot solve the task on its own. The core job of everyone becomes self-analysis and dissection: what decision frameworks exist in your mind that have not been written into the codebase? How do you prioritize? What data do you need to access? And what unique choices do you make? This "judgment" becomes the only scarce asset. So where exactly should it reside?
Harness (Control Framework)
If today's work has evolved into codifying judgment rather than mechanically performing operations, then this judgment needs a carrier. It resides in Harness. Harness is the only place where your engineering principles no longer stay only in your mind, but actually operate in every session: how you triage problems, your unique architectural decisions, and uncompromising delivery thresholds. If you just write them into documents, they will become obsolete and ignored the next day; if you write them into Harness, even when you are not present, it will execute your judgment thousands of times in work you do not notice. This is the embodiment of "meta-work". There will inevitably be loss when your principles are communicated to new employees, half of the content is never even verbally expressed; but when communicated to Harness, it remains intact and generates compound interest — because every decision you code means you never have to make it a second time. This is a core barrier that competitors can never copy, because it is the written, tangible form of your company.
The second reason why Harness must be exclusive to you is that every release of the model is swallowing the technical layer beneath it. Handwritten context management, custom Sub-agent configurations, clever workarounds that people rack their brains to come up with... AI labs are closely tracking which solutions work and integrating them directly into the system by default. As a result, the tricks you rely on this quarter will become default system features next quarter. Betting on mechanisms is essentially competing with AI labs, and you are doomed to lose with every new model release. However, there are two things they structurally can never provide: one is your judgment, the decisions that only you would make (this is the core of the above); the other is neutrality. Current lab Harness can schedule their own Sub-agents and run their own review processes — this is real engineering design, and it is indeed excellent — but they are always limited to a single family, tuned for the median codebase, because no lab will route your work to a competitor's model. Since we do not train any models, this layer remains absolutely neutral: your judgment can flexibly move between the top models of major labs, and work flows to whichever model ranks first in specific tasks this week. We do not train models, labs deliver their preferences, and only you can deliver your own preferences.
Dissect Bottlenecks and Overwhelm Them with Tokens
So how do you build such a Harness? It is not built by smarter models, nor by faster auto-completion. People who have long been in this pattern converge on the same method: fine-tune configurations for their own codebase, and pour Tokens frantically on the parts of the development lifecycle that are most likely to trip you up. There is a popular term for this in the industry: Tokenmaxxing.
Those who have mastered this have entered a brand new paradigm. The team size remains lean, with high information symmetry and high idea execution efficiency. Features that were turned down by your team for months because the queue was full can now be completed by the time you wake up. The following are real portrayals of some of my current clients:
A product manager acts as an entire R&D team on his own. He spends $1000 on Tokens every day, and merges code faster than any team he has ever managed.
A venture-backed solo founder decided to give up hiring people entirely.
"Seats" are the wrong unit of measurement for computing power, "Tokens" are the correct one. The principle is extremely clear: with every model iteration, dissect where human time is spent, where the bottleneck is, then smash it with Tokens until the bottleneck is eliminated. The finish line is: start with a prompt, minimize human intervention in the middle, and end with a one-shot successful merge. Human time is the bottleneck, Tokens are never the bottleneck.
Implementing this principle to the fullest is a full-time job in itself. Building infrastructure, configuring Sub-agents, assigning appropriate models to various tasks, integrating adversarial review mechanisms, and then re-tuning everything every few weeks when a new model is released and the top-performing model changes — most teams do not have such a position on their payroll, and what they build manually tends to become outdated within a quarter. Opus 4.8 reshaped the industry landscape at the end of May; two weeks later Fable 5 rewrote the rules again, only to fade away quietly within days of its release. No matter what you tuned for last week, a better alternative could emerge this week.
From a prompt to the final merged Pull Request, there are six bottlenecks in between: machines, planning, orchestrating many micro-plans into a single change, testing, review, and the merge itself. Every bottleneck is resolved in the exact same way: analyze it, then overwhelm it with Tokens.
While You Sleep
Before dissecting the parts, let's outline the ultimate blueprint first, because the ultimate blueprint is what matters. The only reason tasks are piling up in queues today is that every task requires you to sit in front of your computer and handle it one by one. But the work itself does not require that. Queues exist because scheduling is manual and execution is serial. Remove these two points, and the queue is no longer a queue: defined tasks are immediately distributed in parallel the moment they are defined, hundreds of sessions run in parallel on hundreds of isolated machines, and all are completed overnight while the person who made the request is still sound asleep. Backlogs never exist because the workload is too large to complete, but because a huge number of tasks are queued up behind a single person waiting for their turn. The following six bottlenecks are all that stand between the present and that wonderful night, and how each of them can be dismantled.
Bottleneck 1: Machines
Let's start with the runtime carrier of work, because everything else depends on it, and this is the real root cause why everyone is still stuck on local localhost. Production-grade applications are complexes connected by a whole set of services and microservices that need to run concurrently: your frontend, backend, mobile application, and database. Cloud sandboxes may be able to run a script, but they cannot spin up the entire system. CI/CD is not connected, environment variables have no references, and the secrets that point all of this to the real environment have never been requested. Any team that tries to use cloud Agents in production will eventually retreat back to their local machines, because the Agents keep delivering them code that has never been run and verified in the real system.
Therefore, we set up the environment on a native EC2 instance the way developers configure their personal computers: groups of Agents clone the codebase, install dependencies, and spin up every process. Multiple codebases, single session, enabling simultaneous editing and joint operation of frontend, backend and mobile. It actively requests the required secrets and environment variables. Those tedious and hidden details are also properly handled: identity authentication, seed data, cookie passing for cross-browser sessions; when it needs permissions that are not obtained, it will make a request, and hundreds of native integrations are ready to be accessed at any time. Then, the system creates a snapshot of this active machine, so that every new session can wake up on an already ready computer: dependencies are installed, processes are spun up. At this point, a high-level prompt is all you need.