The AI Hype Didn’t Die. It Was Waiting for a Closed Loop

For most of my life, “building software” meant finding someone technical enough to translate an idea into code. I could understand the customer, define the problem, and see what the product needed to do. But between the idea and a working application sat a wall of syntax, infrastructure, debugging, and deployment.

I tried to work around that wall with no-code and low-code tools. Then I tried AI app builders. Eventually I reached the terminal, where Claude Code and Codex could inspect an entire codebase, run commands, make changes, and test their own work. I went from being a non-technical founder trying to assemble an app to orchestrating multiple agents across real products used by real people.

That experience makes the phrase “software engineering is dead” feel both directionally right and dangerously incomplete.

Justin Phu’s Coreflow post captures an important shift: AI has moved from writing isolated functions to handling increasingly large pieces of the software-engineering pipeline. Its sharpest line is also the one I keep coming back to: “Build systems that let agents verify their own work. That’s the multiplier.”

My extension to that argument is this:

Model intelligence creates possibility. Verified closed loops turn possibility into productivity.

The conventional wisdom treats model intelligence as the main bottleneck. My experience points to a more specific constraint: once a model is capable enough to attempt the work, the quality of the surrounding system determines whether that attempt becomes a reliable outcome.

The history of AI is full of impressive capabilities that never became dependable economic systems. We should study why those waves stalled, because the current boom can still repeat their mistakes. A brilliant model inside a broken workflow remains a demo. A less brilliant model with the right context, tools, tests, permissions, and feedback can become useful infrastructure.

AI hype has died before

The current AI boom is not the first time intelligent machines seemed close enough to reorganize society.

The 1956 Dartmouth workshop helped establish artificial intelligence as a field. Early systems solved constrained puzzles, played games, and created the impression that broad machine intelligence might arrive quickly. The Stanford AI100 history records the cycles that followed: optimism, ambitious promises, disappointing results, and reduced funding.

Those collapses became known as AI winters. Funding and attention fell, but the underlying field did not disappear. Researchers kept working, narrow systems kept creating value, and the missing pieces accumulated out of public view. The hype died in budgets and headlines before the technology itself died.

Expert systems produced another wave in the 1980s. They encoded specialist knowledge as rules and could perform well inside narrow domains. Some created real value. But they were brittle. Someone had to extract the rules, enter them, reconcile conflicts, and keep the knowledge current. A system that looked intelligent inside its approved lane could fail as soon as the situation changed.

The deep-learning wave of the 2010s delivered major improvements in image recognition, speech, recommendations, and prediction. Those systems were not failures either. But most lived inside specialist teams and tightly defined products. For the average knowledge worker, AI remained invisible infrastructure rather than a general interface to their own work. Once again, public expectations moved faster than organizational diffusion.

The pattern was not “AI never worked.” The pattern was that a capability worked in a demonstration or a bounded environment, while the surrounding system remained expensive, fragile, and incomplete.

Earlier waves were missing several things at once:

• Cheap, general-purpose computing and distribution
• A natural-language interface usable by almost anyone
• Enough digital data and connected tools to supply current context
• Reliable ways to check an answer against reality
• Organizational processes redesigned around the technology
• A path from output to action without repeated human translation

That last point matters. A system can produce an answer and still create no productivity if a person must copy it, interpret it, rebuild it in another tool, check it from scratch, and carry it across every boundary.

Economists describe a related effect as the productivity J-curve. General-purpose technologies can look disappointing at first because companies must build complementary systems, skills, and processes before the gains appear in measured output. Buying the technology is fast. Redesigning work around it is slow.

We can see the same tension now. A 2026 survey of nearly 6,000 executives found that 69 percent of firms reported using AI, yet roughly nine in ten reported no effect on productivity or employment over the previous three years. That is not proof that AI is useless. It is evidence that access and adoption are not the same as operational transformation.

In narrower, measurable workflows, the picture is different. A study of customer-support agents found that generative AI increased productivity by nearly 14 percent on average, with larger benefits for less experienced workers. In an experiment with consultants, AI made people faster and improved quality on tasks inside its capability boundary, but hurt performance when people trusted it on a task outside that boundary. Researchers called this the jagged technological frontier.

That is a more useful model than either “AI changes everything tomorrow” or “AI is another bubble.” The capability is real. The boundary is uneven. The workflow determines whether capability becomes value.

My path from no-code builder to agent orchestrator

I did not arrive here through a traditional engineering career. I arrived by repeatedly trying to build things I was not technically qualified to build.

My first route was no-code and low-code. That ecosystem includes visual builders such as Bubble and Webflow, database-like tools such as Airtable, automation tools such as Zapier and Make, and internal-tool platforms such as Retool. Those products lowered the first wall for builders like me: we could connect screens, data, and workflows without beginning with a blank code editor.

Those tools taught me a valuable lesson: lowering the cost of the first prototype does not remove the hard parts of software. As soon as the app needed unusual logic, stronger reliability, better performance, a custom integration, or a clean path out of the platform, the abstraction began to leak.

Lovable was another step forward. Natural language could create an interface and connect more of the application. Replit Agent pushed further toward a product that could plan, write, and deploy software; Replit introduced its Agent in September 2024. I spent heavily on Replit because the promise was so close to what I wanted: describe the product and keep moving until it works.

The experience was useful, but it also exposed the gap between generating an app and owning a software system. A convincing first version is not the same as a maintainable product. When something broke across the database, authentication, business logic, and deployment, I still needed the model to understand how the pieces related and to prove that its fix worked.

The terminal changed the relationship.

Claude 3.7 Sonnet and Claude Code arrived in February 2025. Claude Code could search and read a codebase, edit files, run tests, and use the same command-line tools an engineer would use. Codex CLI followed in April 2025, bringing an OpenAI coding agent into the terminal as well.

For a non-technical builder, the important change was not that a chatbot could produce more code. It was that the agent could move through the environment where software work happens.

I transitioned fully into Claude Code, explored OpenClaw as a model-agnostic agent runtime, and then expanded into Codex and multi-agent workflows. I now use agents to research, plan, implement, test, review, and diagnose parts of web applications. Those applications are functional, deployed, and used by real people.

Running several agents changed my role again. I can assign research to one, implementation to another, and independent review to a third, while keeping their code changes isolated until the evidence is ready to combine. The orchestrator’s job is not to produce more prompts. It carries the objective and constraints, prevents agents from colliding, and decides when a result is proven enough to move forward.

Parallelism is not free speed. If two agents have overlapping ownership or an ambiguous goal, they can create more coordination work than they remove. Multiple agents help when each has a bounded job, a distinct source of context, and a clear handoff or verification point.

I still do not pretend to be a senior engineer. My advantage comes from learning how to define the outcome, constrain the work, provide the right context, demand evidence, and escalate the decisions that should not be delegated.

The progression was not “I learned to type code faster.” It was:

I learned to build an environment in which machines can do useful work and show me why I should trust the result.

Three eras of context—and the fourth one now arriving

The Coreflow post describes the shift cleanly:

1. ChatGPT era: copy and paste the relevant code into a conversation.
2. Cursor era: index the repository so the model knows where to look.
3. Claude Code era: give the agent terminal tools so it can traverse the codebase itself.

Each step removed a human handoff. First, the human selected every piece of context. Then software indexed the context. Then the agent could search for what it needed, make a change, run the compiler, read the error, and try again.

The fourth era is system context.

A repository is only one view of a working company. The truth may also live in analytics, support tickets, database constraints, design files, incident reports, deployment history, customer interviews, contracts, and the unwritten rule everyone learned after the last outage.

An agent with code access but no operational context can produce a locally correct and globally dangerous change. An agent with every permission and no boundaries can produce the same mistake faster.

The goal is not unlimited access. The goal is the minimum sufficient context and permission for the job, paired with a clear way to verify the outcome.

The model jumps mattered, but the harness mattered too

Several capability jumps changed what builders could delegate:

The biggest jumps were not benchmark points in isolation. They were combinations:

• Better reasoning plus tool use
• Larger usable context plus better context retrieval
• Faster models plus longer-running agent loops
• Computer and browser use plus visual feedback
• Specialized coding models plus test execution
• Parallel agents plus isolation through branches or worktrees

Anthropic’s Claude 4 generation emphasized longer-running tool use and coding tasks. OpenAI later optimized Codex models for agentic software work and introduced a Codex app built around multiple parallel agents. Google released Gemini CLI, and open-weight models created more options for private or specialized deployments.

By 2026, GPT-5.4 combined mainline reasoning and coding with native computer use, while Claude Sonnet 5 pushed further across browsers and terminals. Those are vendor capability descriptions, not proof of equal reliability in every environment. They still mark the direction of travel: models designed to act inside software environments, not only answer inside a chat window.

But every model remains jagged. A model can produce an elegant architecture and miss a destructive migration. It can solve a hard bug and break a basic mobile layout. It can generate a passing unit test that tests the wrong behavior.

That is why “the model got smarter” is only half the story. The other half is the harness: the tools, permissions, instructions, memory, tests, sandboxes, and escalation rules wrapped around it.

Verification is the multiplier

The most important change in my workflow has been moving from evaluating whether an answer sounds intelligent to checking whether the work survives contact with evidence.

For software, verification can form a ladder:

1. Does the code parse, compile, and type-check?
2. Do focused unit and integration tests pass?
3. Does the application work in a real browser across the critical path?
4. Do security, privacy, and policy checks pass?
5. Can the change be deployed safely through a preview, canary, or staged rollout?
6. Do production logs and user-visible behavior confirm that the intended result landed?
7. Did the change improve the customer or business outcome it was meant to improve?

Each level catches mistakes the previous level cannot. A green build proves that the code can be built. It does not prove that a customer can complete the task. A successful deployment proves that files reached production. It does not prove that the change created value.

This is also where current agents can look deceptively capable. METR found that experienced open-source developers in an early 2025 study were 19 percent slower with AI tools on the studied tasks, even though the developers expected to be faster. METR’s later work suggests the effect has been changing, but also explains why rapidly changing tools and selective usage make clean estimates difficult.

The lesson is not that agents slow everyone down. It is that perceived speed is not reliable evidence. Generated code, agent messages, and benchmark scores are intermediate outputs. Accepted changes, safe releases, resolved user problems, and improved business metrics are closer to the outcome.

Verification also changes what an agent can do unattended. If failure produces a clear signal, the agent can inspect it and repair the work. If success has no observable definition, the agent can only stop when it feels finished.

Give an agent a task and it may produce an answer. Give it a testable definition of success and it can run a loop.

A closed loop does not mean “remove every human”

Closing the loop means removing avoidable human relay work. It does not mean removing human accountability.

A useful agent loop looks like this:

Objective → context → plan → execute → verify → release → observe → repair or escalate

Today, many “AI workflows” stop after execute. The model writes a document, creates code, or recommends a decision. A human then carries the output into the next system, discovers what is missing, and begins another conversation.

A closed loop connects the steps. The agent can run the test, see the result, revise the change, and present evidence. For low-risk, reversible work, it may also release and monitor the result. For high-risk work, the loop ends at a deliberate approval gate.

That distinction matters. The right goal is not maximum autonomy. It is maximum safe autonomy for this task.

Some actions should remain human decisions: spending money, publishing, contacting a customer, changing production data, making a legal commitment, or accepting a risk whose cost the agent cannot bear. A mature system makes those gates explicit instead of pretending the human is absent.

What I am building toward in Jobsolv Research Mode

I am building this approach into Jobsolv one step at a time. Research Mode is not a finished autonomous employee today. It is the direction of travel: a closed-loop system that can investigate a job, distinguish evidence from assumption, produce a truthful result, check its own work, and escalate uncertainty.

One current brick in the codebase is grounded resume rewriting. The system can compare a proposed rewrite with the candidate’s evidence and stop when the output appears to change the facts. That is narrower than a complete Research Mode, but it establishes the right contract: an AI should not earn permission to continue merely because its prose is convincing.

The fuller loop I am working toward looks like this:

1. Define the job. Capture the role, company, constraints, and the candidate’s approved source material.
2. Research. Gather relevant information from permitted sources and retain where each claim came from.
3. Classify evidence. Separate verified facts, candidate-reported facts, reasonable inferences, and unknowns.
4. Draft. Produce a recommendation, resume version, or application material without filling evidence gaps with invention.
5. Review with a different perspective. Ask another model or specialized agent to challenge the reasoning, factual grounding, and fit.
6. Run deterministic checks. Test required fields, unsupported claims, dates, formatting, and policy constraints with code rather than model confidence.
7. Escalate. Put sensitive, unresolved, or consequential choices in front of a human.
8. Observe the result. Track whether the output helped the user reach the next legitimate stage, then improve the rules without rewriting history.

The objective is not to automate applications at any cost. It is to remove repetitive handoffs while preserving truth, consent, and control.

That is what a closed loop looks like in a domain where “technically completed” is not enough.

Different models should check different parts of the work

I increasingly treat models as a team rather than a single oracle.

One model may be strong at exploring a codebase. Another may be better at architecture review. A smaller model may be the economical choice for classification. A model trained or prompted for security can look for threat paths that a general coding agent missed. OpenAI, Anthropic, Google, and open-weight systems each have different tradeoffs, and those tradeoffs change quickly.

The analogy is a senior engineer reviewing a junior developer’s work, but the analogy has limits. A second model is not automatically senior, independent, or correct. Models can share training data, habits, and blind spots. Two agents agreeing is not the same as the world agreeing.

A stronger pattern is:

• Agent A implements against explicit acceptance criteria.
• Agent B challenges the plan, diff, edge cases, and missing evidence.
• Deterministic systems adjudicate what can be checked through tests, browsers, schemas, and data.
• A human owns the stakes where judgment, accountability, or irreversible action remains.

The reviewer should have a different job, not merely the same prompt with a different logo.

This also avoids a costly mistake in multi-agent systems: adding agents without adding information. Five agents repeating the same assumption create coordination overhead, not intelligence. Specialization matters when it introduces a distinct capability, context source, or verification method.

The AI employee era will not arrive evenly

“AI employee” is a useful metaphor, not a precise description. An agent is not a legal employee. It does not hold responsibility, experience consequences, build trust, or care about the company’s survival.

It can still perform a growing bundle of work that once belonged to a job.

I expect three relationships with AI to coexist:

The third category is not entirely science fiction. The OECD defines algorithmic management broadly as software that automates or supports managerial functions, and found it already widespread in a six-country survey of managers. Not all of those systems use generative AI, but they show that parts of management can be encoded before a conversational AI appears to be anyone’s “boss.”

The next step is bounded proactivity. Instead of waiting for a prompt, an agent can watch a defined signal—an error queue, a support backlog, a broken test, or a conversion anomaly—then investigate, act within its permissions, and escalate when the evidence or authority runs out. That starts to resemble a role more than a tool, but it also requires budgets, rate limits, audit logs, and stop conditions. An agent that never sleeps can also waste money or repeat a mistake without sleeping.

This transition will be uneven across nations, states, cities, industries, companies, and people. Capital, infrastructure, language coverage, regulation, data quality, education, and trust all affect adoption. The Stanford AI Index shows both rapid organizational adoption and large differences in how firms and countries use AI.

The result may be several economies living beside one another. One worker uses AI to polish an email. Another supervises ten agents. Another receives tasks from an optimization system they cannot inspect. Another works in a business where the process is still on paper.

The future rarely arrives everywhere at once.

Agents are junior employees with superhuman speed—and no lived judgment

Agents will continue to get things wrong, just as humans do. The dangerous difference is speed and scale.

A junior employee can misunderstand a requirement, choose the wrong source, or declare a task finished too early. A well-managed junior gets a scoped assignment, relevant context, examples, feedback, review, and an escalation path. We should give agents the same operating structure.

But an agent can repeat its mistake across thousands of records before lunch. It can sound certain without feeling doubt. It does not know which strange-looking rule exists because someone learned a painful lesson five years ago unless that context is available.

So the management system matters more as the model becomes more capable:

• Give it a bounded role and budget.
• Limit access to what the task requires.
• Make success observable.
• Make failure recoverable.
• Preserve logs and evidence.
• Separate creation from approval.
• Escalate uncertainty before irreversible action.

The best AI employee is not the one that never asks for help. It is the one that knows when the evidence is insufficient to continue.

Could a company run only on electricity and tokens?

There is an appealing idea of the fully automated company: revenue arrives, agents allocate resources, software builds and markets the product, customers receive support, and the system keeps operating on electricity and tokens.

Parts of that loop are already technically imaginable. Agents can monitor queues, generate software, route support, buy services under a budget, and evaluate metrics. A small human team can supervise a volume of work that previously required a much larger organization.

But “only electricity and tokens” hides the rest of the stack. Data centers contain hardware, cooling, land, supply chains, and human labor. Companies exist inside legal systems. Banks, vendors, customers, regulators, and insurers need accountable counterparties. Models inherit knowledge from human-created data and depend on tools maintained by people.

The plausible near-term version is not an ownerless company. It is a low-headcount, agent-dense company:

• A small group of humans defines the mission, constraints, capital allocation, and acceptable risk.
• Agents execute much of the research, production, coordination, and monitoring.
• A shared evidence layer records what happened and why.
• Permissions, budgets, sandboxes, and rollback rules constrain action.
• Humans remain accountable for trust, taste, law, relationships, and consequences.

That structure could be extraordinarily productive. It could also concentrate power in the hands of whoever controls the objectives, models, data, and compute.

Why progress feels flat, then sudden

Technological progress often looks like a plateau followed by a leap because several dependencies must mature together.

An intelligent model without tool access can advise. Tool access without context creates mistakes. Context without verification creates convincing uncertainty. Verification without organizational permission leaves the result trapped in a demo. A company may feel no benefit until the whole chain crosses a usable threshold.

My working model, informed by the same evidence discipline I use in my experimentation method, is multiplicative:

Reliable value = capability × context × tool access × verification × organizational readiness × accountability

If any factor is near zero, the product is near zero. Improving one factor can appear to do nothing until another bottleneck moves. Then several years of accumulated improvements become visible at once.

Inside each component is an S-curve: slow early progress, rapid improvement after a threshold, then a plateau. Across the company is the productivity J-curve: investment and disruption before measurable gains. Stack those curves together and advancement feels discontinuous.

This explains both the hype cycles and the genuine leaps. The model may improve gradually while the surrounding environment changes enough to unlock a new kind of work. The terminal was one such environment. Reliable browser control, durable memory, better permissions, and stronger evaluation systems may produce others.

What science fiction can tell us—and what it cannot

Science fiction is most useful here as a library of questions, not a set of forecasts.

R.U.R. asks what happens when artificial labor is treated only as a resource. Kurt Vonnegut’s Player Piano asks what becomes of status, dignity, and purpose when machines can perform most economically valued work. E. M. Forster’s The Machine Stops asks what happens when society becomes dependent on an opaque system few people can repair. Iain M. Banks’s Culture novels ask whether powerful machine intelligence could support abundance—and who governs when machines can coordinate more effectively than people.

Those stories point toward the questions benchmarks do not answer:

• If agents do more entry-level work, where will future experts gain experience?
• When software becomes cheap to create, does demand explode faster than labor disappears?
• Who is accountable when an agent delegates to another agent?
• Does verification reduce error, or teach systems to game whatever we chose to measure?
• What happens when millions of businesses depend on the same small set of models?
• Who can inspect the manager when the manager is an algorithm?
• Which forms of human judgment become more valuable because they cannot be reduced to a test?

The unknown unknowns will not come only from smarter models. They will come from interactions among models, markets, institutions, culture, and people. A capability that seems narrow in isolation can have a large second-order effect once millions of actors reorganize around it.

What the ideal company could look like in three years

There is no permanent terminal state. The ideal company changes as model capability, cost, law, and customer expectations change.

But three years from now, I expect the strongest AI-native companies to share several traits:

1. Humans own outcomes, not task queues. People define the problem, customer promise, constraints, and evidence required for a decision.
2. Agents have narrow authority with deep context. Each one can access what its role requires, but not everything the company owns.
3. Work leaves an evidence trail. Claims, changes, tests, costs, and approvals are inspectable.
4. Verification is part of production. Tests and outcome checks are designed before delegation, not added after an incident.
5. Models are routed by job. The company uses the best available combination of general, specialized, fast, private, and inexpensive models.
6. Reversible work moves quickly. Low-risk actions run automatically inside budgets and rollback boundaries.
7. Irreversible work slows down. Publication, spending, sensitive data, legal commitments, and material production changes require explicit authority.
8. The organization learns. Failures update tests, context, and operating rules so the same class of mistake becomes harder to repeat.

The competitive advantage will not be “we use AI.” Nearly everyone will be able to say that. The advantage will be the quality of the system around the models: proprietary context, clear goals, fast feedback, trusted evidence, and disciplined loop closure.

The next era is not about prompting harder

Earlier AI waves produced extraordinary demonstrations and narrower real-world systems, but they repeatedly ran into brittle knowledge, expensive integration, weak interfaces, and organizations that had not changed around them.

This wave has more of the missing pieces. Models can reason in natural language. Agents can use terminals, browsers, and software tools. They can operate across a codebase, work in parallel, and repair some failures. The cost of turning an idea into functioning software has fallen enough for a non-technical founder like me to build real applications with real users.

That still does not make the future automatic.

The work now is to connect capability to reality: better context, explicit permissions, strong verification, closed loops, and human accountability. The companies that do this well will not merely make existing employees type faster. They will reorganize what a company is able to attempt.

This is what I am building toward—one verified step at a time.

The next two parts will go deeper:

• Entering the AI Employee Era: how to turn model capability into useful, supervised work.
• The Three-Year Company: what changes when agents become part of the operating system rather than another app in the stack.

If you want to follow the systems, failures, and lessons behind that work, subscribe to Lean Experiments or see how I build with Claude.

FAQ

Is AI producing real productivity gains today?

Yes, in some bounded workflows. Controlled studies have found meaningful gains in areas such as customer support and consulting tasks inside the model’s capability frontier. Firm-wide gains remain inconsistent because context, integration, verification, training, and process redesign often lag behind model access.

Will AI agents replace software engineers?

Agents are already taking over parts of implementation, testing, research, and review. That changes the shape of engineering work, but it does not remove product judgment, architecture, security, accountability, or the need to define what should be built. The likely transition is from manually executing every step to designing and supervising systems that execute more of them.

Can one AI model reliably review another?

A second model can find omissions and challenge assumptions, especially when it has a distinct role or specialization. It cannot guarantee correctness. Shared blind spots and confident errors remain possible, so deterministic tests, real-world evidence, and human accountability still matter.

What is a closed-loop AI system?

A closed-loop system can move from an objective through execution, verification, observation, and repair without requiring a person to relay every intermediate step. It should still stop at explicit approval gates for high-risk, irreversible, or sensitive actions.

What is the “AI employee era”?

It is the period in which agents can accept bounded objectives, use tools, produce work, check parts of that work, and report or escalate results. “Employee” is a metaphor for a bundle of capabilities, not a claim that a model has legal responsibility or human judgment.