How AI agents are changing coding, startups, and the meaning of work
At the beginning of this year, OpenClaw became one of those names that seemed to appear everywhere at once. In China, the atmosphere around it was almost absurd. People joked that the whole country was “raising crayfish” together. Middle school students were installing it. University students were sharing setup guides. Experienced engineers were queuing up to test it. Retired programmers were back at the terminal again.
I have seen many waves of tech excitement before, but this one felt different. It did not feel like people were only chasing one more tool. It felt like they were testing a new relationship with software itself. OpenClaw was interesting because it made many people ask a much bigger question: if an AI agent can think in steps, use tools, call subagents, and iterate by itself, what exactly is left of the old software workflow?
I felt that question while building with OpenClaw and again while working on OnlyBaby with an AI-heavy workflow. The more I watched how people around me reacted to agent tools, the more I realized that we are not just seeing an improvement in programming productivity. We are seeing the early shape of a different production model.
1. OpenClaw fever was a social signal, not just a product trend
When a tool becomes popular among people with very different technical backgrounds, something deeper is usually happening. The OpenClaw moment was interesting because it collapsed several old boundaries at once.
For a long time, serious software creation belonged to a relatively narrow group. You needed strong programming skills, patience for complex tooling, and enough persistence to survive long periods of confusion. That filter was part of the identity of software engineering itself. OpenClaw weakened that filter. Not completely, of course, but enough that many more people could finally touch the process.
That is why the hype looked so strange and so energetic. It was not just that people wanted better autocomplete. They wanted agency. They wanted to see whether software could now be produced through intent, iteration, and orchestration rather than through line-by-line craftsmanship alone.
In that sense, the so-called OpenClaw craze told us something important. AI agents are not being perceived only as assistants. More and more people are beginning to see them as production units. That shift in imagination matters more than any single feature.
2. Three development modes are now competing in public
From what I have observed, developers today are gradually splitting into three groups.
The first group still follows what I would call traditional coding. They write most code by hand, review code manually, and may use AI only as an ask feature. For them, AI is a search box with better language. This mode is still strong where reliability matters, where regulation matters, or where teams need every change to be highly legible. Its advantage is control. Its weakness is speed. Its learning curve is familiar for experienced engineers, but it does not unlock much new leverage for newcomers. The biggest failure mode is obvious: people mistake caution for durability and slowly become uncompetitive.
The second group uses AI as an assistant but keeps the original workflow mostly intact. AI helps generate boilerplate, drafts tests, explains logs, suggests refactors, and supports review. This is probably the most common mode today. It fits existing teams well because it does not force them to redesign everything. Its advantage is balance. Its weakness is that it can trap teams in a halfway state: faster output, but the same organization, the same handoffs, and the same bottlenecks. The failure mode here is local optimization without structural change.
The third group is the most controversial and, in my opinion, the most disruptive. This is the all-in agent workflow: prompt-driven, skill-driven, subagent-driven, and deeply iterative. In this model, code is often produced by orchestrating an agent system rather than by manually writing every important line. Review does not disappear entirely, but it changes shape. Instead of reviewing every patch in a classic sequence, people review outcomes, trajectories, prompts, architecture choices, and release quality. The code may be rewritten so quickly by the next iteration that the old review rhythm no longer fits.
I understand why this third group makes many engineers uncomfortable. Its reliability is uneven. Its learning curve is strange because it rewards judgment more than syntax memory. It can be a bad fit for teams with safety-critical systems or heavy compliance constraints. Its main failure mode is serious: people confuse speed with understanding and ship chaos with confidence.
But even with all those limits, this third mode is different in kind, not only in degree. It does not merely make the developer faster. It changes the unit of production from “person writes code” to “person directs a system that produces code.” That is why I think it matters so much.
The biggest change is not that AI writes code. The biggest change is that software can now be produced through orchestration.
3. From vibe coding to the one-person company
This is where the conversation becomes much more interesting to me. Once people accept the third development mode, many of them begin to ask a business question: if agents can cover more and more specialized work, why does the minimum viable company still need so many people?
That is where the idea of the one-person company, or OPC, starts to feel less like fantasy and more like a real operating model. I do not mean that one person can literally do everything with perfect quality. I mean that the minimum org chart required to launch, ship, document, support, and market a digital product is shrinking fast.
In practice, each subagent starts to resemble one role from the old company structure. One agent drafts implementation plans. One writes code. One reviews architecture. One converts notes into documentation. One summarizes customer feedback. One produces landing page copy. One handles repetitive support workflows. One monitors logs or prepares release notes. The human in the middle is still essential, but the shape of the work changes. Increasingly, the human is not manually executing every function. The human is defining direction, choosing tradeoffs, checking quality, and deciding what matters.
I felt this very clearly in my own work. Projects that would once have required a broader team or a much longer timeline started to feel possible within a much smaller operating surface. When I built OnlyBaby with a vibe-coding workflow, the surprising part was not just that code could be generated quickly. It was that the whole cycle of thinking, building, revising, and shipping became shorter. Skills gave the agent reusable capabilities. Subagents let work fan out. Prompts became operational tools. Suddenly, a person with strong product intuition but incomplete technical coverage could still move very far.
This is why I think the barrier to software entrepreneurship is dropping for a much wider population than many engineers expect. Some of the people now experimenting with OPCs were never elite programmers in the first place. Some were barely programmers at all. In the old world, that would have disqualified them. In the agent world, it does not. They can describe a workflow, validate an outcome, iterate on a business idea, and let the agent system handle much of the implementation detail.
Of course, this does not mean the only cost is tokens. That line is catchy because it captures a real shift, but it is not the full truth. The true costs are still judgment, domain knowledge, taste, distribution, and the emotional stamina to keep iterating. Bad prompts can waste tokens, but bad strategy can waste a year.
Still, the economic compression is real. When more business functions can be simulated or partially automated by agents, a single person can get much closer to the productive surface area of a small company. At the same time, many larger companies are already under pressure to reduce headcount, and AI is clearly part of the picture.
I do not think OPC will simply solve unemployment. That would be naive. Competition between one-person companies will become intense very quickly. If building becomes easier, building alone is no longer enough. We may soon enter a world where thousands of solo builders can ship competent products every week. In that world, distribution matters more, positioning matters more, and what I would call vibe marketing becomes just as important as vibe coding.
The new bottleneck will not be whether you can make the product. It will be whether anyone cares, whether they trust it, and whether your taste is clear enough to stand out.
To become a boss, you may only need a Mac mini. To win, you still need judgment, distribution, and taste.
4. Small startups may survive by reorganizing around domain ownership
Even so, I do not believe that the future belongs only to solo builders. One person cannot absorb every kind of uncertainty forever. That is why I think the more durable pattern may be the rise of very small startups rather than the total disappearance of teams.
But these teams will not look like many current engineering org charts. The traditional division of labor by platform or language already feels less natural in an agent-driven workflow. The clean split between frontend engineer, iOS engineer, backend engineer, and data engineer starts to weaken when agents can bridge implementation gaps across stacks.
I expect more teams to organize around business domains and customer surfaces instead. Instead of asking, “Who owns React? Who owns iOS? Who owns Go?” companies may ask, “Who owns the platform business? Who owns the customer-facing workflow? Who owns growth? Who owns operations automation?”
In that world, every engineer becomes more full-stack by necessity, but not in the old heroic sense of manually mastering every framework. Rather, each engineer becomes the owner of a business domain who can use agents to implement across many layers. Language choice and tooling preference matter less. What matters more is whether the engineer understands the domain deeply enough to design good systems, spot bad tradeoffs, and guide the agent toward a usable architecture.
This is one reason I think architecture decision records, or ADRs, become more important, not less. If code is cheap to generate and cheap to regenerate, the scarce thing is not keystrokes. The scarce thing is clear decision-making. Teams will need short, durable records explaining why they chose a workflow, a boundary, a storage model, a deployment strategy, or a product constraint. Agents can write drafts, but humans still need to own the reasoning.
So the future role may look something like this: a platform business engineer, a customer-facing business engineer, and a few domain owners coordinating a growing fleet of agents. They are full-stack because the business requires it, not because the company wants everyone to suffer. Their leverage comes from understanding the problem deeply and using AI to span the implementation surface.
5. The old software ecosystem is about to face a speed challenge
The deepest challenge of all may be speed. Agent-native workflows respond faster, reframe faster, and iterate faster. Today they are still constrained by model quality, tool reliability, context limits, and token budgets. Anyone building seriously with agents already knows these limits are real. Agents misunderstand intent, hallucinate APIs, make architectural mistakes, and can burn money if used carelessly.
But I see these as temporary bottlenecks, not permanent arguments for the old order. As models improve and orchestration becomes more reliable, the advantage of the new workflow becomes obvious: business ideas can be tested, revised, and rebuilt much more quickly than before.
That changes the status of legacy complexity. In the past, a large codebase often protected incumbents because rebuilding was too slow and too expensive. In the future, parts of that moat may erode. Not because legacy software becomes easy in an absolute sense, but because rebuilding selected workflows from scratch may become much more feasible. Complex business logic can be decomposed, reassembled, and re-shipped at a speed that conservative organizations are not used to competing against.
I think this will be especially painful for companies that confuse process weight with quality. If a team needs weeks to react to a change that an agent-native competitor can ship in days, the market will notice. Service capability is judged by adaptation speed as much as stability.
As an individual developer, I do not feel there is much room for denial here. I do not say that with triumph. I still value careful engineering, deep technical understanding, and the products that demand rigorous review and patient craftsmanship.
But I also think there is no real way back. The social imagination has already changed. Too many people have now seen what is possible when ideas can turn into software through agent-driven iteration. The pressure this creates on teams, companies, and individuals will only increase.
For years, programmers repeated the phrase: talk is cheap, show me the code. That idea came from a world where code was the main bottleneck. We are entering a different world. Code still matters, but when it can be produced, replaced, and regenerated much more easily, the bottleneck shifts upward.
In the age of AI agents, TALK and IDEAS may become more valuable than code itself.
That does not mean empty talk wins. It means clear thinking, strong taste, domain insight, and the ability to direct execution are becoming more valuable. The code is still there. It is just no longer the only scarce thing.
I am not celebrating the end of traditional engineering, and I am not claiming every company will become an OPC. I am simply saying that after OpenClaw, after vibe coding, and after watching how quickly AI-native workflows are spreading, I no longer think this is a niche experiment. I think it is the beginning of a structural shift.
We may not all become one-person companies. But more of us will probably work like one, think like one, or compete against one. That alone is enough to change the future of software.
Comments