The Work Moved Up a Level: What Building Three AI Platforms Taught Me
A reflection across 2,597 main-branch commits: AI did not remove the work of building software. It moved the work toward intent, context, verification, coordination, and judgment.
On February 22, 2026, the J5 Agent Fleet repository contained one file: a requirements document.
Five months later, the three repositories I reviewed for this reflection—J5 Agent Fleet, J5 AI Test, and J5 A2A—contained 2,597 commits on their main branches. They had become an agent operations platform, an AI-driven browser testing system, and a coordination protocol for agents and humans.
A commit is not customer value. A large codebase can be a large liability. I am not offering the number as a trophy.
I am offering it as evidence that the unit of software development has changed.
A few years ago, my output was bounded by how quickly I could understand a problem, type a solution, test it, and move to the next thing. Today I can direct several streams of work at once: research, architecture, implementation, review, security analysis, documentation, and testing. The result is more parallel cognitive work than one person could have performed serially in the old model.
But the deeper lesson is not that AI makes code arrive faster.
It is that every time AI removes one bottleneck, the work moves up a level.
Code becomes plentiful, so verification becomes scarce. Verification improves, so coordination becomes scarce. Coordination improves, so judgment, trust, and organizational clarity become scarce.
That is the story hidden in these repositories. It is also, I believe, the story of the next decade of business.
I Did Not Set Out to Build Three Platforms
My AI journey began before these repos. I started using ChatGPT within days of its public launch, then built a sustained study habit around models, prompting, APIs, retrieval, and agent frameworks. I worked through OpenAI Agents SDK, CrewAI, LangGraph, AutoGen, MCP, local models, and production integrations.
That framework work mattered, but it was still mostly about learning what an agent could do.
The inflection point came when I began asking a harder question:
What operating system does useful agent work require?
That question led to three projects. Each one answered a constraint exposed by the previous one.
| Project | First commit | Constraint it exposed | What it became |
|---|---|---|---|
| J5 Agent Fleet | February 22, 2026 | One person cannot manually direct, observe, and govern growing agent capacity | A cross-model operations platform for delegated work |
| J5 AI Test | May 18, 2026 | Faster creation makes reliable verification the limiting resource | Plain-English, agent-driven browser testing and evidence |
| J5 A2A | June 21, 2026 | Parallel agents need identity, shared state, conflict handling, and human control | A coordination layer for agents and people |
This was not a tidy roadmap written in advance. It was a sequence of bottlenecks.
First, Capacity: J5 Agent Fleet
J5 Agent Fleet started as a “BMC”—a control surface around the agents I was already using through OpenClaw. The first day of history is almost comically compressed: gateway authentication, task state transitions, event handling, subagent activity, memory management, retries, bookmarks, and pull requests all appear within hours of the initial document.
The early commits are useful because they strip away the polished product story. They show the real problem:
How do I know what the agents are doing, and how do I keep their work moving?
The answer expanded quickly. A task list became task lifecycle management. One assistant became a fleet of specialists. A single execution path became per-task routing across Claude Code, Codex, Copilot CLI, local models, and APIs. A dashboard became project decomposition, dependency-aware work, consultation, approval gates, Goal Mode loops, durable events, waiting signals, cost controls, research workflows, Slack and Telegram entry points, and native clients.
By May, releases were adding local and cloud runners, a native macOS control surface, browser automation, computer control, and human approvals. By June, the platform was tracking token velocity, model efficiency, cache use, subscription caps, and anomalies. By July, the work had moved again: race-safe leases, atomic finalization, fail-closed dispatch, PKCE for native clients, tenant isolation, and regression-tested security remediation.
That sequence matters. The project did not become less serious as agents wrote more of it. It became more operationally demanding.
The lesson was clear: autonomy is not a model setting. It is a system property made from identity, permissions, context, tools, budgets, telemetry, stopping conditions, and escalation paths.
When Google DeepMind describes a universal assistant that can understand context, plan, act, and run multiple tasks at once, I recognize the destination. Project Mariner demonstrated up to ten concurrent tasks in 2025. But concurrency is the demo. The durable work begins immediately after: Which task has authority? What can it spend? What happens when two workers claim the same resource? How does a human understand why something is waiting? Demis Hassabis's product vision is compelling; building J5 Agent Fleet taught me what has to surround that intelligence before it can become dependable.
Then, Evidence: J5 AI Test
J5 AI Test began almost three months later with a 116-line plan.
The thesis was simple: write a browser test in plain English, let an agent drive Playwright, and return a structured, screenshot-rich result that another agent can use to fix the failure.
The first commit outlined a phased roadmap. The next proved the Claude CLI and Playwright MCP loop end to end. Then came the monorepo, typed test format, subprocess control, event model, REST API, SSE stream, SQLite persistence, project UI, run reports, “Copy for agents” failure briefs, recording mode, an encrypted secrets vault, dependency-aware scheduling, saved browser sessions, and adapters for multiple CLI and API providers.
Sixty-five commits landed across the first two days.
Again, the number is less interesting than the direction. I had increased implementation capacity with J5 Agent Fleet, then ran directly into the next constraint: truth could not be generated as cheaply as code.
This is where a lot of AI adoption goes wrong. Teams measure output—prompts sent, lines added, stories closed—while the cost quietly reappears as review load, regressions, security findings, and production uncertainty.
Faster output without faster truth is just faster entropy.
J5 AI Test is my answer to that problem. It treats the browser, screenshots, traces, step events, and deterministic replay as part of the agent's working environment. It also produces failure evidence in a form another agent can consume. Testing is no longer only a gate at the end of development; it becomes a machine-readable feedback loop inside the work.
OpenAI's own harness engineering reflection reached the same pressure point. As its internal agent-built product accelerated, human QA became the bottleneck. The team responded by making the application, browser, logs, metrics, and traces directly legible to agents.
I do not read that as an opportunity to declare that I “beat” a lab to an idea. I read it as more useful evidence: independent builders operating near the frontier are converging on the same constraint. Once implementation is cheap, environmental legibility and automated verification become core architecture.
There is a useful form of being early that is not a launch-date competition. It is running into tomorrow's bottleneck because you already put today's capability into production. That is where I try to operate: close enough to the work that the next constraint becomes visible before it becomes conventional wisdom.
Then, Coordination: J5 A2A
J5 A2A started on June 21 with a different level of abstraction.
Its initial commit already contained 65 files and nearly 15,000 lines: an implementation source of truth, an operations-console design handoff, database schemas, event contracts, OpenAPI definitions, Redis adapters, storage boundaries, CLI and MCP packages, and CI.
That does not mean the system was finished on day one. It means AI had changed the economics of getting a complete architectural hypothesis into executable form.
From there, the history moves through typed session events, participant identity, presence, inboxes, requests, lease-aware claims, conflict detection, digests, observability, human control actions, wake notifications, encrypted credentials, mobile operation, session knowledge, context-pressure measurement, protocol conformance, durable task lifecycles, remote agent discovery, stable identities, workstreams, portable exports, and cross-session attention projections.
The new problem was no longer “Can an agent do this task?”
It was:
- Does every participant know who owns the work?
- Can two agents detect that they are about to edit the same resource?
- Can an agent ask a question without blocking the entire session?
- Can a human join the same coordination space without pretending to be a bot?
- Can a session survive disconnects, retries, stale claims, and long context?
- Can coordination work across vendors rather than inside one model's ecosystem?
This is why I believe the future is not one omniscient agent living in a chat window. It is a network of specialized humans and agents operating through shared protocols, with explicit ownership and observable state.
The hard part of multi-agent systems is not adding a second model call. It is designing the social and operational primitives that keep multiple capable actors coherent.
From Autocomplete to an Operating Model
The industry often tells this story as a sequence of product features. I think it is more useful to see it as a sequence of delegated units:
| Era | Unit delegated to AI | Human role | New bottleneck |
|---|---|---|---|
| Autocomplete | Token, line, function | Author | Knowing what to type |
| Chat | Question, snippet, explanation | Collaborator | Supplying enough context |
| Multi-file agent | Issue, refactor, feature | Reviewer | Verifying a coherent change |
| Parallel agents | Workstream, subsystem, release | Orchestrator | Coordination and attention |
| AI-native organization | Business outcome | Accountable leader | Judgment, policy, and trust |
Autocomplete reduced keystrokes. Chat reduced the cost of exploration. Repo-aware agents reduced the cost of coherent implementation. Parallel agents reduce elapsed time. Agent platforms begin to reduce the cost of whole workflows.
The work does not disappear at each stage. It changes altitude.
That is why the best engineers are not becoming less important. They are becoming responsible for a larger causal surface. A weak assumption can now propagate through many files, several agents, and a production workflow before a human notices. Conversely, a strong architecture, test harness, or piece of repository guidance can improve thousands of future decisions.
The leverage runs in both directions.
Productivity Is No Longer a Keystroke Metric
Across these three projects, 2,597 main-branch commits landed between February and July. J5 Agent Fleet alone recorded work on 126 different days.
I could not have produced that surface area a few years ago. More precisely, I could not have directed and integrated that much serial knowledge work. The accomplishment is not that my fingers became superhuman. It is that my operating model changed.
The most advanced AI users are beginning to show the same pattern. OpenAI reports that by June 2026, users at the 99th percentile were generating more than 60 hours of Codex agent work per day by running agents in parallel. More than 70% of sampled users had delegated at least one task estimated to require over an hour of human work. That is not a faster typing story. It is a parallelism story.
GitHub has seen enough of this shift in aggregate that it says its infrastructure must prepare for 30 times today's scale, driven by rapid growth in repositories, pull requests, API usage, automation, and large-repository workloads from agentic development. The platform itself is being reshaped by the new volume.
The metric I care about is therefore not “How much code did AI write?”
It is:
How much verified, valuable change can one accountable person move safely from intent to production?
My rough model is:
useful throughput = clear intent × usable context × parallel capacity × verification coverage ÷ coordination cost
Models improve the capacity term. Most organizations will lose the gains elsewhere unless they redesign the system around it.
The SDLC Is Becoming a Set of Continuous Control Loops
The classic software development lifecycle assumes that implementation is expensive. Requirements move into design, then development, testing, deployment, and maintenance. Even agile teams often preserve those handoffs in smaller batches.
When implementation cost falls sharply, queues form somewhere else.
I see six bottlenecks moving:
- From coding to specification. “Build a settings page” is easy to generate and hard to judge. Intent, constraints, and definitions of done become high-value engineering artifacts.
- From documentation to context architecture. Agents need current maps, not a thousand-page instruction dump. Repository structure, decision records, examples, and source-of-truth ownership become runtime infrastructure.
- From individual execution to coordination. Parallel workers create collisions, duplicate effort, stale assumptions, and integration pressure unless ownership and state are explicit.
- From manual testing to evidence design. Tests, evals, traces, screenshots, security checks, and production signals must be legible to both people and agents.
- From project tracking to exception handling. Humans should not push every task forward. They should see the few decisions, approvals, anomalies, and ambiguities that genuinely require judgment.
- From delivery speed to consequence management. Permissions, budgets, auditability, rollback, and accountability matter more as the radius of action expands.
The resulting loop looks less like a relay race and more like this:
sense → specify → delegate → verify → integrate → observe → learn
Several loops can run at once. Production evidence can open the next task. A security review can revise repository policy. A failed browser run can generate an agent-ready repair brief. Human review can focus on decisions with meaningful consequence.
This is still an SDLC, but the scarce resource holding it together is no longer code production. It is high-quality attention.
What This Means for Companies
The AI-native company will not be a company without humans. It will be a company in which every person has far more reach.
Perplexity's 2026 study of its Computer agent found that people attempted broader, more complex work, crossed occupational boundaries more often, and shifted their effort from manual operation toward specifying and supervising outcomes. In its matched analysis, the system reduced estimated time by 79–92% across domains. The most important result is not that existing tasks got cheaper. It is that people attempted work that had previously been outside their practical scope.
That leads me to several predictions.
1. The org chart will gain a runtime layer
Companies will still have people, teams, and leaders. Alongside that human organization will sit an elastic layer of agent capability: research, operations, analysis, software, support, compliance, and coordination.
The competitive question will not be “Do we have an AI chatbot?” It will be “Can our people safely assemble and direct capability around a business outcome?”
2. Every serious company will need an agent control plane
Identity, permissions, memory, tools, policy, cost, observability, evaluation, and human escalation cannot remain scattered across vendor dashboards. They will become a coherent operating layer.
The labs will offer important pieces. Businesses will still need to encode their own authority and judgment.
3. Organizational clarity will compound like software
A decision trapped in a meeting is invisible to an agent and eventually forgotten by people. A decision captured in a maintained, machine-legible system can improve every future task.
Clear policies, examples, ownership, interface contracts, and definitions of done will stop being “documentation work.” They will become executable organizational memory.
4. Management will become more technical, and engineering more managerial
Leaders will design systems of delegation, evidence, and escalation. Engineers will spend more time framing outcomes, allocating parallel work, judging tradeoffs, and maintaining the environment in which agents operate.
The best individual contributors will resemble excellent tech leads. The best leaders will understand enough about agent systems to shape their constraints rather than merely purchase licenses.
5. Software demand will expand as its price falls
Cheaper software will not mean the world is finished building software. It will mean millions of workflows that could never justify a dedicated team become worth improving.
Every spreadsheet held together by tribal knowledge, every manual reconciliation, every internal queue, and every underserved niche becomes a candidate for purpose-built software and agents.
The backlog is not shrinking. The economically addressable backlog is exploding.
Humans Are Not the Legacy Component
The leaders I read disagree on timelines and risks, but their optimistic cases rhyme.
Sam Altman argues that one person's ability to get work done will look strikingly different in 2030 than it did in 2020, while experts who embrace the tools will retain an advantage. Demis Hassabis sees advanced AI as a tool for science, medicine, and productivity. Marc Andreessen's optimistic case centers on intelligence augmentation and the new demand created by productivity. Tesla's Master Plan Part IV gives the optimistic destination a useful name—“sustainable abundance”—and connects autonomy to shared human prosperity. Even Dario Amodei's hopeful vision, written alongside serious warnings, describes the remaining human portion of work becoming extraordinarily leveraged.
My experience makes me optimistic too, but for a grounded reason: more capability has not made my judgment irrelevant. It has made judgment the multiplier.
Agents can generate options. Humans choose which future is worth building.
Agents can execute a plan. Humans remain accountable for its consequences.
Agents can imitate taste. Humans develop taste through experience, empathy, culture, and care.
Agents can expand what one person can attempt. Humans decide who benefits.
“Superhuman” should not mean removing humanity from work. It should mean giving more people the leverage to cross old boundaries: a designer who can ship, an operator who can automate, a domain expert who can build a tool, an engineer who can explore a business, a small team that can serve a market previously accessible only to a large company.
The future I want is not fewer capable people. It is capability becoming less scarce.
How to Start—and How to Move Beyond Chat
If you are new to AI-assisted work, do not begin with a grand autonomous platform.
Begin with one real task you understand well.
- Give the model the outcome, constraints, examples, and definition of done.
- Ask it to explain its plan before it acts.
- Let it produce a complete, reviewable artifact—not just advice.
- Check the work with evidence: tests, source links, screenshots, calculations, or a knowledgeable human.
- Turn every repeated correction into reusable context.
Your goal is not prompt cleverness. It is building a reliable loop.
If you already use coding agents comfortably, your next level is probably not a better autocomplete model. It is better orchestration:
- Delegate complete vertical slices instead of isolated snippets.
- Run independent research, implementation, and review in parallel.
- Use isolated branches or worktrees so parallelism does not become chaos.
- Put architecture, commands, constraints, and examples where agents can discover them.
- Add tests and observability before increasing autonomy.
- Separate low-risk automatic actions from high-consequence approvals.
- Measure cycle time, rework, escaped defects, and business outcomes—not generated lines.
- Study failures as missing system capabilities, not merely bad prompts.
For leaders, choose one workflow with enough repetition to learn from and enough value to matter. Map its decisions, systems, permissions, evidence, and exceptions. Give a cross-functional group permission to redesign the workflow itself, not simply add AI to every existing step.
Then make the learning portable.
The Work Ahead
We are moving from software that waits for clicks to software that pursues outcomes.
That transition will be messy. There will be brittle agents, shallow automation, security failures, impressive demos that collapse in production, and a great deal of content that looks finished but is not true. The answer is not to retreat to the old throughput ceiling. It is to build the missing disciplines.
My repositories show my own version of that progression:
- J5 Agent Fleet made agent capacity operable.
- J5 AI Test made agent work more verifiable.
- J5 A2A made parallel intelligence more coordinatable.
The next bottlenecks will be higher still: organizational memory, cross-system authority, evaluation of ambiguous outcomes, and the quality of the goals themselves.
That is exciting. It means the value of human work is moving toward the parts that were always most human: curiosity, judgment, courage, taste, trust, responsibility, and imagination.
The people and businesses that lead this era will not be the ones that generate the most.
They will be the ones that can turn intent into systems, systems into trusted outcomes, and new capacity into a future worth building.