Core argument
As AI takes on increasingly complete tasks, the human role shifts away from continuously pushing execution forward. Our attention moves toward defining the objective, designing the evaluation, supplying the right context, and judging the final result. The starting point for AI-native work is to make AI the default executor, then build a system around it that can act, observe outcomes, correct itself, and retain what it learns.
Agents also reduce the cost of integration and glue work. That makes it practical to compose software from atomic primitives while the company retains control of orchestration, context, evaluation, and policy. GitHub, cloud sandboxes, and other tools can then remain replaceable, reusable layers of capability.
Over the past year, the way I use coding agents has changed substantially. At first, I treated an agent like a programmer who was always available for a conversation: I told it what to do next, watched it change the code, and pulled it back whenever it drifted. The model was already writing a large share of the code, but I was still advancing the task one step at a time. Today, I am much more likely to define the objective, constraints, and acceptance criteria up front, then let the agent search for an approach, implement it, and revise its work in response to actual results. I return at the end to inspect the evidence and decide whether the result is ready to ship. This looks like a workflow change, but it reflects a more consequential belief: once AI becomes a genuine execution layer, both the human role and the surrounding work system have to be redesigned.
AI as the Default Executor
The change introduced by AI is much larger than getting a better answer to an individual prompt. An agent can work continuously, run tasks in parallel, and, when the system is designed properly, process more information than any one person could hold in working memory. The same harness can also improve as the underlying models become more capable. For the first time, we have a nonhuman actor that can participate in work over long periods. Yet model capability does not automatically turn into reliable output. If all we do is chat with a model, the world it can see is usually limited to the current prompt. Decisions made in meetings, trade-offs embedded in the codebase, constraints in the environment, and the evidence that tells us whether the result is any good are effectively nonexistent if the model cannot access them.
An AI-centered system therefore has to solve at least three problems. The model needs access to the context required for the task; it needs tools that let it act on the world; and it needs to observe what happened after it acted. People remain responsible for the goal, the quality bar, the consequential decisions, and the final outcome. Search, implementation, testing, and correction can increasingly move into the agent execution layer. That division of labor also changes how I think about my own job. I am no longer managing only code and individual tasks. I am managing problems, agents, and multiple streams of work that may remain active for days.
Evaluation Is the Starting Point for Agent Autonomy
The turning point in my own workflow was giving the model the ability to evaluate its result. Earlier in my career, when I worked on reinforcement learning, I spent time with the classic CartPole problem. An agent controls a cart that moves left and right, with the goal of keeping a pole balanced upright for as long as possible. The standard reward is deliberately simple: for every timestep during which the pole remains standing, the agent receives a reward of 1. When I revisited the problem recently, I gave the environment and reward directly to Codex. The model wrote a control program, ran experiments, and changed its approach in response to the score. Once the evaluation was clear enough, it could create a programmatic optimization loop and work its way toward a successful controller. This personal experiment is not a substitute for a rigorous benchmark, but it demonstrates something practically important: when success is machine-readable, today’s coding agents can already search for a path to the outcome on their own.
In CartPole-v1, the agent pushes the cart left or right to keep the pole upright. Image source: Gymnasium documentation.
The compounding-error problem in behavior cloning offers a useful analogy for why evaluation matters. Pure behavior cloning learns which action an expert would take in each state represented in the demonstration data. During an actual rollout, however, a small early deviation changes the states the policy encounters next. The policy can then enter regions that the expert data never covered, allowing errors to compound over time. This is the problem addressed by the DAgger paper. An agent working on a long task can fail in a similar way. It may misunderstand one requirement near the beginning, then build every later decision on top of that misunderstanding. The reasoning can remain internally coherent even as the final result drifts away from the goal. Prompts, rules, and examples give the agent a behavioral prior. Evaluation gives it feedback on its own rollout and a chance to recover after it has gone off course.
For that reason, my first question when I receive a task is now: what would count as done? I ask which conditions can be checked programmatically, whether the model can interact with the actual product, and what evidence I would need to see before accepting the result. Evaluation can operate at several levels. Tests, type checks, and CI protect the deterministic baseline. Playwright or direct interaction with the application can validate the user journey. Screenshots, videos, and logs make the result legible to both people and other reviewers. A reviewer with no implementation context can inspect open-ended quality, UX, and blind spots in the solution. Together, these verifiers create a feedback environment in which the agent can move from producing one answer to continuously optimizing toward an outcome.
A Harness Turns Model Capability into Reliable Output
My workflow evolved in stages. I began with interactive collaboration: the agent wrote a little, I checked a little, and I corrected the direction when needed. I then started using natural-language goals so the model could continue working toward a semantic target. That helped, but criteria such as “the page looks good” or “the interaction feels right” still left substantial room for interpretation. The next step was to let the agent operate the finished product directly. On frontend tasks, it uses Playwright to launch the browser and walk through the full user path. Programmatic checks verify functionality, screenshots help the model inspect the visual state, and video gives me an artifact for final review. For a TUI, the agent can enter a terminal emulator and use Xvfb to perform real keystrokes in a virtual display environment. In some cases, I can even give the model an evaluation set and let it optimize the very harness in which it is running. The deliverable grows from a code diff into an implementation, test results, an interaction trace, and artifacts that can be inspected directly.
Programmatic checks cannot cover every dimension of quality, so I also start a reviewer that does not inherit the implementation conversation. It runs the tests, operates the product, and inspects the code independently. The implementation agent then has to decide which findings are valid, rebut the ones that are not, revise the work, and run the evaluation again. Another agent can approach the product as a first-time user and look for points of hesitation in the UX. A maintenance agent can update documentation, the changelog, and repository context after the task is complete. The overall loop looks like this:
The agent can keep iterating because evaluation returns a failed result to the revision loop instead of ending the task.
This is what I mean by harness engineering: organizing the task contract, environment, context, tools, evaluation, retries, review, and write-back into a system that can keep running. The prompt still matters, but it is only one entry point into that system. What determines whether an agent can work independently for a long time is whether it inhabits a sufficiently complete world and can observe the consequences of its actions.
Context Determines How Much of the World the Model Can See
In this discussion, context extends far beyond a few paragraphs inserted into a prompt. Meeting notes, discussion outcomes, historical architecture decisions, and current repository constraints are all context. The codebase, task state, tools, permissions, and runtime make up the execution environment. Tests, logs, the real UI and UX, and evaluation results provide feedback after the agent acts. Anything that exists only in a person’s head might as well not exist from the model’s point of view. Many apparent model failures are actually failures of the environment to expose information the model needed.
Traditional prompt engineering relies heavily on a person selecting information in advance and placing what seems relevant into the context window. That requires an almost oracular prior about what the model will need at every moment, and it is difficult to keep every item in the window relevant. The more plausible long-term design is a model-driven retrieval system. Information lives in addressable memory records with metadata such as time, owner, source, scope, and status. The model interprets the current task, then actively retrieves the records it needs. Metadata helps it reason about whether information is still valid, where it applies, and which source should carry more authority when records conflict. Context then becomes shared work infrastructure that agents can query on demand rather than a one-time bundle assembled inside a prompt.
New experience also has to flow back into the system, ideally as a passive byproduct of work. Meetings can be recorded and transcribed by default, with a model extracting conclusions and decisions. A repository can use AGENTS.md to require an agent to update ADRs, repository constraints, and related documentation at the end of a task. Information consolidated by a model should retain citations to the raw facts, so later agents can still trace a conclusion back to its source. People do not need to maintain every document manually, but they do need to define the rules for capture, review, and retention, and they need to be able to audit the result when it matters.
Progressive disclosure is especially useful inside a repository. The root AGENTS.md or CLAUDE.md should contain only stable constraints and a map of the available context. Detailed architecture decisions, workflows, and skills can live in separate files that the agent reads when the task calls for them. At the end of the task, a maintenance agent writes new decisions and reusable experience back to the correct location while removing information that has become stale or redundant. This keeps noise out of the active context and allows experience to accumulate across threads.
As Execution Gets Cheaper, Human Judgment Matters More
AI lets a team generate more ideas and dramatically lowers the cost of prototyping and implementation. Competitors receive the same advantage. Speed and feature volume, by themselves, are unlikely to create a durable edge. Human leverage will increasingly concentrate on deciding what is worth doing: interviewing customers to understand the real user need, selecting the problems that deserve attention, defining what a good outcome looks like, and deciding which features should actually become part of the product.
Cheap implementation also makes it easy for a team to keep adding. Products can lose focus precisely because every new option has become affordable. Deliberate subtraction therefore becomes more important. Even when a feature is inexpensive to build, the team still has to decide whether it deserves to exist, whether it adds cognitive load, and whether it fits the product’s long-term taste. Human work moves toward the two ends of the workflow: understanding customers, choosing problems, and setting the quality bar before execution; inspecting evidence, judging the outcome, and accepting responsibility afterward. Much of the search, implementation, testing, and iteration in between can be handled by agents.
The cheaper execution becomes, the more human value concentrates in problem selection, quality judgment, and deliberate trade-offs.
People Need to Manage a Workforce
This change in role will also reshape the product interface. Most engineering tools were designed around an issue, ticket, or individual task because a person had to decompose and advance every step. Once AI becomes the default executor, one person may be responsible for several agent threads that remain active for days. Each thread has its own objective, context, execution state, and pending decisions. The human-facing interface therefore needs to support the management of a persistent workforce. People should be able to focus on ideas, goals, consequential decisions, and final evidence while the advancement of individual tasks happens inside the agent execution layer.
The company and the individual manage different levels of the same loop. At the company level, the primary objects are shared knowledge, ideas, company goals, and final results. That layer ensures that people and agents operate from consistent facts, quality standards, and security boundaries. An individual decomposes a larger goal into sub-goals, then organizes agents to retrieve information, explore approaches, execute tasks, and evaluate outcomes. Once the work is complete, the results return to the company layer, inform product decisions, and become part of shared knowledge. A reviewer or auditor must be able to follow the evidence from the result back to the underlying execution trace and understand how the deliverable was produced.
The default interface should surface the goal, current state, decisions requiring human judgment, results, and evidence. Commands, intermediate steps, reasoning traces, and complete logs should remain available without continuously consuming human attention. They can expand when an audit, debugging session, or disagreement requires them. An outcome-first interface still preserves the full process; it simply turns the process from default reading material into on-demand evidence. The agent gets room to execute, while the person retains accountability and sufficient transparency.
The Terminal Is for Agents; the App Is for Humans
The CLI and the application serve different roles in this system. A terminal is a highly structured, composable action interface. A model can use commands to inspect the environment, invoke tools, observe output, and continue acting. As frontier AI labs continue to improve terminal capabilities, benchmarks such as Terminal-Bench have begun to evaluate agents on realistic terminal tasks. The CLI will remain important; increasingly, it will be the interface through which models act on the world.
For people, the scarce resources are attention and working memory. The traditional CLI implies something close to “one terminal, one task.” The person has to remember the state of each session and repeatedly switch windows. Once the work becomes more complex, a primary agent spawning a few temporary sub-agents no longer captures what is happening. We are managing several independent threads that run in parallel and can pause or resume. One may be implementing, another testing, another waiting for permission, another processing review feedback, and another blocked on a dependency. The human interface needs to preserve those states and bring our attention back only when there is a blocker, an approval request, or a result ready for review.
The shift is analogous to moving from Vim to VSCode. The underlying editing capability never disappeared; the IDE added project navigation, visible state, debugging, extensions, and support for work that spans many files. I see Codex App in a similar way. The GUI is only the outer shell. The deeper abstraction is a persistent thread runtime combined with a multi-agent workspace. The thread becomes the unit of work, with its own durable context and state. The application compresses the state of all those threads so that I can manage several groups of agents without reading every execution step.
The terminal lets agents act; the application helps humans manage state and attention.
Lower Integration Costs Make Atomic Primitives Valuable Again
This way of working also changes how we should choose software and infrastructure. All-in-one platforms were valuable because integration was expensive. Connecting a GitHub webhook, configuring CI, managing Docker, handling permissions, wiring notifications, and building deployment pipelines all required engineers to write and maintain a substantial amount of glue code. A platform that integrated those pieces in advance could make a team more efficient even when the team had to accept limits in capability or flexibility. Fewer components often meant fewer boundaries that people had to coordinate manually.
Agents are rapidly reducing that cost. Many adapters, configurations, and pieces of glue code can now be generated and maintained by a model. When requirements change, an agent can update the workflow. When a tool changes, it can revise the integration. Work that once consumed days of engineering time may collapse into a single agent task. That shifts the build-versus-buy boundary. The convenience of a pre-integrated platform still has value, but the cost of accepting a closed data model, fixed workflow, or narrow configuration surface for years is becoming more visible.
Once connection costs fall, we can choose the strongest primitive at each layer. Git can provide version control; a VM or Daytona can provide isolation; a browser can expose the real UI; storage can retain artifacts; a queue can manage work; Slack can deliver notifications; and models can supply reasoning and interpretation. An agent composes these capabilities at runtime into the workflow required by the current task. Each primitive can improve independently, while the underlying models become more capable as well. The resulting system gains a compounding advantage: it does not have to wait for one all-in-one vendor to become excellent at every layer.
Composability does not require us to rebuild mature infrastructure. Git, CI, storage, browsers, VMs, and sandboxes remain valuable precisely because they provide reliable primitives. The layer worth owning is the workflow itself: how task state is stored, how agents are scheduled, how context enters the task, how evaluation runs, which actions require approval, and how results are written back. Stable capabilities should become reliable primitives with clear permission models. The agent can compose the task-specific workflow dynamically.
The role of configuration changes as well. Dockerfiles, CI YAML, Terraform, and adapter code once represented integration knowledge that a specialized team had accumulated over time. Modifying those files required someone who understood the full system. Once an agent can generate, read, and continuously maintain them, much of that configuration becomes a regenerable implementation layer. The durable assets are the intent, policy, interface contract, and evaluation behind the configuration. When the implementation breaks or the requirement changes, the agent can reconstruct or repair it from those stable constraints.
Platforms still matter, particularly for permissions, security, auditability, reliability, and shared organizational use. What changes is where their value sits. In the past, the decisive advantage was often that the platform had already connected everything for us. In the future, the more important questions will be whether its capabilities are atomic, reliable, and fast; whether its API and permission model are clear; and whether different agents can invoke it freely. The optimization target for a software system shifts from minimizing the number of components to minimizing the coordination cost that people must carry between those components.
Why I Do Not Put the Entire Agent Workflow Inside GitHub
GitHub remains an important part of this system. It is well suited to source control, issues, pull requests, reviews, checks, and the audit record. My concern is with a more expansive design: placing the entire lifecycle, from an issue triggering an agent through implementation, testing, revision, and the final pull request, inside a GitHub-specific cloud agent workflow. GitHub can remain the work intake surface, company collaboration layer, and system of record without also owning the agent’s brain, durable state, and only execution environment.
The first reason is the execution environment itself. My local or persistent system already has the full dependency graph, build caches, repository context, tool configuration, and authenticated sessions. Coding preferences, architecture constraints, and acceptance criteria already live in AGENTS.md, ADRs, and related skills. An agent can enter that repository and start working. A cloud task often has to reconstruct this world: install dependencies, configure permissions, restore context, and rediscover how the project should be run and evaluated. Even with a prepared Docker image, cold starts and environment reconstruction remain. The gap is especially visible for native desktop applications. A Mac can build, operate, and record the real application directly; a headless Linux environment cannot naturally provide the same verification path.
The second reason is that I want agent work to remain transparent and manageable. Once an agent owns a complete task, I treat it more like a long-running operator. I need to know which threads are active, where they are blocked, and what evidence they have produced. I also want the ability to adjust direction or add context when necessary. A cloud task wrapped behind a single job often returns only when the run is over, making mid-course intervention and cross-task state management difficult. Persistent threads in Codex App fit the manager workflow more naturally: execution detail can stay collapsed by default, but task state and consequential checkpoints remain visible.
The third reason is that company context and personal execution can be separated. The company should maintain AGENTS.md, architecture decisions, security policy, CI/CD, evaluation contracts, and audit requirements. Anyone using any agent must still meet the same quality bar. The individual’s choice of Codex, Claude Code, or another agent; the way they organize threads; and their choice of local or cloud execution can remain flexible. The company needs consistency in delivery quality, auditability, and required context. It does not need to mandate one execution tool.
The fourth reason is portability and vendor lock-in. We use GitHub today, but we may eventually move to another Git service or build our own Git infrastructure. If task state, agent memory, orchestration, and evaluation contracts all depend on GitHub-specific features, migration means rebuilding the entire agent operating system. Treating GitHub as a replaceable adapter preserves issues, pull requests, and reviews while allowing the underlying Git provider to change without breaking the core loop. The same adapter model applies to Linear, Slack, or any other work intake system.
A Persistent Orchestrator and Disposable Cloud Evaluation
Cloud infrastructure remains essential in this architecture. It is well suited to clean environments, isolated execution, elastic concurrency, and reproducible evaluation. A local or persistent node is better suited to retaining durable state, scheduling threads, managing credentials, reusing caches, and providing a continuously visible interface for the person. These layers form a control plane and an execution plane: the persistent orchestrator understands the task and its history, while disposable sandboxes validate the result in a clean environment.
Persistent orchestration retains task state and context; disposable cloud environments provide clean, reproducible evaluation.
In the concrete workflow I have in mind, a persistent main thread listens for issue and pull-request events from GitHub or another task system, then creates independent threads and worktrees for different tasks. Agents perform the main implementation in a local or persistent environment and send the result to a remote sandbox when isolated verification is needed. The sandbox runs clean tests, real UI interactions, and recordings, producing metrics and artifacts. Once policy and human review approve the result, it returns to GitHub as a pull request, comment, or merge. GitHub preserves the company’s collaboration history and delivery artifacts; the agent runtime retains the richer state of the work itself.
This separation also allows the underlying infrastructure to be reused. Code needs clean environments for isolated tests, real UI validation, and artifact capture. A future model team will need similar infrastructure to run model evaluations and collect metrics, traces, and results. Instead of learning and maintaining a closed execution mechanism built specifically around a GitHub agent workflow, we can make the evaluation substrate a general capability that serves both code and models. GitHub, Daytona, and other tools continue to provide mature primitives. The company retains control of orchestration, durable state, context, and evaluation.
The Mac mini is simply one concrete implementation I use today. Over time, the orchestrator could run on a server, in a daemon, or as a more complete control service. The durable idea is that the agent is a long-lived actor with accumulating state, while the cloud sandbox is an execution substrate it invokes on demand. As long as that boundary remains clear, the personal workflow, Git provider, and specific cloud runtime can all evolve.
Start with One Repository
None of this requires a company-wide context layer before anyone can begin. The most practical starting point is one repository you already maintain and one real task. First, define the evaluation: beyond tests, can the agent see the final UI, UX, or other real-world result, and what evidence will a person review? Then organize the context: does AGENTS.md or CLAUDE.md explain the stable constraints, are important decisions recorded in ADRs, and can the agent discover detailed workflows when it needs them? Finally, let the agent carry out the full loop: implementation, testing, interaction with the real interface, independent review, and write-back of new knowledge.
Once the loop runs reliably inside one repository, one person can begin managing several threads at once. Proven evaluations, context, and tools can then expand to the team and eventually become shared company infrastructure. The order matters. AI-native work does not have to begin with a grand organizational redesign. It can begin with one task: define the result, supply the context, let agents execute, and require evidence that the result is good.
As models become more capable, learning how to use the latest tool is only the outermost layer of the change. We also need to learn how to define problems like managers, how to build environments in which agents can close the loop, and how to turn individual experience into context that the next task can use immediately. For Funda, we need to build both the product and an agent-native operating model that can keep improving how the product gets built.