Type a prompt, and anyone—even a child—can now write a program.
Until now, the people who wrote code fast, and wrote a lot of it, were called "productive." But if everyone can build at the same speed, speed no longer sets anyone apart. So in this era, what do we mean by "productivity"? And what happens to team development?
No one has the answer yet. So we're looking for it by actually running our company (EarthLink Network) on AI—every part of the business. This article is where we stand right now.
Here's the conclusion first (about a 5-minute read):
- The yardstick for productivity changes — not "how fast you build" or "how few bugs," but "how correct your decisions are" and "how many decisions you make"
- The work goes to AI; the judgment stays with humans — AI writes the first draft; humans keep the final call on what to send, what design, what price
- We automate the entire company — not one person doing everything. It's a corporation trying to hand its ordinary business operations over to AI, as a company
- We rethink what team development means — one person can run it all. But large projects still need division of labor. What the "team know-how" of this era even is, we're working out in real operation
Why "productivity" is being questioned again
Not long ago, writing a program took study and experience. So people who wrote fast and correctly had value.
But now, type a prompt and something that runs comes out. The design, the code, the tests—AI produces the first draft of all of it. The raw speed of building is no longer where individual skill sets people apart.
So what's left? Whether you can adopt the draft AI gave you, or not. That judgment. The center of value is shifting from building fast to deciding correctly.
Do we stop needing teams?
Put bluntly: you could spin up many Claude Code terminals (Claude Code is a tool that has AI write your code), never step in mid-way, and let it process every task. Push Human-Out-Of-The-Loop (running with the human outside the loop) far enough, and one person can do a great deal.
But it doesn't end there. Have several AIs touch one product at the same time, and their changes collide (conflicts). Avoid that by having them touch separate products, and all you get is more "solo development"—which feels like something other than team development.
So large projects still need division of labor. The real question is what comes next:
- What team structure makes AI development run well?
- What does "team know-how" even refer to in this era?
- How should we present the output of productivity?
These are open questions. Team development in the age of AI—this is the large question that runs through this whole blog. We're thinking it through while testing it in our company's real operation. But within it, one thing has come into focus: the center of value is moving from build-speed to judgment.
What we're actually doing: automating the entire company
It is not a sole proprietor doing everything alone. It's a corporation trying to replace the ordinary operations that a normal company runs—all of them—with AI. A corporate effort.
The method is simple. First, automate one operation. Next, integrate those and make them more efficient. Then build a tool to monitor that automation, and a tool to manage the monitoring tool. This nests, and keeps growing.
For example, we moved the very execution of development onto our own local LLM (large language model). Run it 24 hours a day and the metered charges for cloud AI pile up every month. We didn't want the center of judgment to depend on an outside service's billing. Buy the hardware once, and run the work locally. The human keeps only the final approval—the judgment.
One more. AI will happily report "done." But even when the tests pass, it may not actually work on the real device. So we stopped accepting "done" on a claim alone, and put in a quality gate that won't treat anything as done until the evidence is in. We bind "done" to evidence, not the AI's own say-so. The one who looks at that evidence and approves, at the end, is a human.
The tools born this way are not the goal themselves. They're the evidence left behind while searching for a new way of working. One need has given rise to the next product.
The conclusion: humans become "machines that make decisions"
Pull it all together and it comes to this.
The chores—the routine work with fixed steps—we want fully automated. The human concentrates on judgment. This does not mean "you get to do nothing." It means staying only on the judgment, and letting AI do all of the actual work.
- In customer support, deciding "is this email OK to send" is the human's call
- Deciding "is this architecture right" is the human's call
- Deciding "is this pricing right," "is this legal wording right"—also the human's call
So who thinks up the draft? AI does. Writing what AI produced into an admin screen, and other cleanup, is also a chore. We keep moving all of that to AI. Beyond that, the human becomes, more and more, a "machine that makes decisions." That's how we see it.
Next-generation productivity is measured by "the quality and count of decisions"
Once that happens, the yardstick for productivity changes too.
Not "development is efficient" or "few bugs." How correctly did you decide? How many decisions did you handle? Next-generation productivity, we think, moves toward being measured by this—the quality and count of decisions.
We're pushing this forward not as armchair theory, but as something we actually do in our own company. Automate all operations, keep humans on judgment, measure productivity by the quality and count of decisions, and team development in the age of AI. This blog is the record of that search.
Summary
This article raised several questions. What is productivity when anyone can build with a prompt? Do we still need teams? Can a company move all of its operations to AI? What do we measure next-generation productivity by?
Right now, one answer is clear. The center of value has moved from build-speed to judgment. The work goes to AI; humans keep only the final call on what to send, what design, what price. Productivity, too, is heading toward being measured not by build-speed or bug-count, but by how correctly you decide and how many decisions you handle.
What is still open is how to spread that judgment across large, many-person development—the know-how of team development in the age of AI. We keep looking for that answer while running our whole company on AI.
This article was originally published by DEV Community and written by uehara.
Read original article on DEV Community