The agent writes the code. Who designs the work?

Codex, Claude Code, GitHub, and Linear: building an environment where an agent can carry a task through to a verifiable result

Sergey Avdeichik · DOBROVOLA · September 15, 2026

Imagine this: you go out for lunch while the agent keeps programming. You come back to dozens of changed files, new tests, and a neat report. Beautiful. Only one small question remains: can the user now do the thing the whole effort was meant to enable?

Sometimes the answer is yes. And sometimes the agent has simply spent the last hour being extremely busy.

This is no longer a conversation limited to enthusiasts of new tools. Martin Fowler writes about agentic programming — development in which a person directs an agent and checks its work. Addy Osmani proposes thinking not about a single prompt, but about a loop of execution and evaluation. Robert Martin and Justin Martin show a multi-agent process where coding is surrounded by specialized checks. These are different approaches, not one manifesto. But they share the same question: how do we organize engineering work when code is no longer produced only by humans? [1] [2] [3]

That is where things become genuinely interesting for a student. You can learn to obtain impressive answers. Or you can learn to build a small engineering system that turns an idea into a result you can verify.

In the previous materials we discussed Software 3.0 and the route from conversation to blueprint, research, technical specification, and acceptance. Now we move one step further: the intent is already understood — how do we organize the development itself? A related article about verifiable work is listed in the sources. [23]

What follows is my working method, not a mandatory OpenAI or Anthropic procedure. I separate platform capabilities from my own recommendations. The project, task, and numerical examples are educational: they are not presented as results of a controlled experiment.

1. The working environment is not the Codex window

When someone asks where my agent works, “in Codex” is too short an answer. It is a bit like saying that an engineer works in a text editor. Technically true — but the project, requirements, colleagues, tests, and the actual product have all disappeared from the picture.

In my setup, a project has two repositories and a task space in Linear.

The documentation repository stores the intent: blueprint, research into options, technical specification, milestone briefs, architecture decisions, and notes. This is the place where thinking can be broad. But every document should have a status: idea, draft, approved, superseded. Yesterday’s “what if we also added…” does not become a requirement merely because it was written down in Markdown.

The application repository stores what has actually been implemented: code, tests, build configuration, and run instructions. Its history shows what truly entered the product, not what an agent merely promised in a chat.

Linear stores the state of work: which milestone is active, what has been assigned, what is blocked, where the evidence is, and what decision was made. Linear itself lets teams group issues into project milestones; turning that structure into rails for agents is our own way of organizing work. [4]

Codex or Claude Code is an execution tool inside this environment. Today one, tomorrow another. If all project logic lived only inside a session that later disappeared, we have not merely lost a tool — we have lost control of the project.

I use the following separation. Documentation answers “what are we building, and why?” The application repository answers “what has been built?” Linear answers “what is happening now?” Tasks and milestones set the large-scale direction. AGENTS.md, CLAUDE.md, roles, and skills are finer adjustment knobs: how the agent should behave and what it should check in the current area of work. No layer replaces the others. Two repositories are not the only possible storage architecture. For a small exercise, two sections of a single repository are fine. But I would preserve the boundary between intent and implementation from day one.

Figure 1. The environment is bigger than the tool.

>

Blueprint and specification in project-docs → milestone and issues in Linear → agent work → changes and checks in project-app → human decision.

>

Linear comments connect the assignment, the result, and the next step. Codex and Claude Code sit inside this process; they do not replace it.

How to avoid three competing versions of the truth

Do not copy the same requirement into five places. In the issue, point to a specific section and version of the specification. In the pull request — PR from here on — point to the issue. In the result comment, point to the PR and the exact commit that was checked.

It is especially important to connect the two repositories technically. A link to documentation does not mean the agent has read it. In the starter context, specify the repository address, the required version, and the available access path — for example, a sibling directory or an approved reading tool. Ask the agent to name the files it actually opened. An inaccessible specification is a blocker, not an invitation to reconstruct it “from context.”

2. What the model actually receives

The word harness is useful here: it means the software wrapped around the model. The harness passes context, coordinates tool calls and tool results, and maintains the work loop. OpenAI’s engineering description makes the distinction clear: the model and the agent loop are not the same thing. [5]

Now for an important distinction. There is the semantic organization of the project, and there is the technical assembly of the model’s input. They are easy to confuse.

In the semantic organization, an approved blueprint matters more than a random note, and an assigned task matters more than the agent’s sudden desire to refactor something. But that is our project discipline. Linear does not become a system-role message merely because we call it “the rails.”

In OpenAI’s published explanation of Codex, the initial input contains base instructions, developer messages about the environment and settings, user context from project files and information about skills, and then the current task. This describes a specific implementation published on January 23, 2026 — it is not a promise that every future client will always assemble context in exactly the same order. [5]

We are not going to reverse-engineer the complete hidden startup prompt of every closed platform. What we need is a practical map: what the platform defines, what we add, which materials the agent actually read, and which actions are technically permitted.

Codex and Claude Code have similar goals, but not identical mechanisms

In Codex, project instructions are assembled from AGENTS.md and, when present, AGENTS.override.md. User settings and the path from the project root to the current working directory are taken into account; more local instructions are added later. Do not assume that every file in every subdirectory is preloaded into context. The documentation separately describes the size limit and how the instruction chain is built at startup. [6]

Claude Code uses CLAUDE.md, project rules, and memory. Its documentation explicitly distinguishes those from enforceable configuration. Files in parent directories can be loaded at startup; instructions from nested directories can be pulled in when related files are read. Imports such as @path are supported. The existence of a file alone is not proof that it was connected correctly. [7]

Figure 2. Two different control loops.

>

Model context: platform instructions → connected project rules → current task → materials actually read and tool results.

>

Technical action boundaries: allowed tools, filesystem isolation, network access, service-account permissions, merge rules.

>

This is a conceptual diagram, not a universal priority table. Each client has its own loading mechanism. Technical boundaries are not just another paragraph in a prompt.

Instruction, permission, and restriction are three different things

“Do not modify the main branch” is an instruction. The ability to write to the repository is a permission. A branch-protection rule that blocks direct writes is a technical restriction.

That is why a rule in AGENTS.md is not a substitute for access control. Anthropic describes containment as a combination of model behavior, environmental restrictions, and controls over accessible resources. A document read by the agent can itself contain malicious instructions: an accessible source is not automatically a trusted instruction source. [8]

For a student project, I recommend separate test data, minimum necessary permissions, and no automatic release without an agreed review step. GitHub can require PRs, checks, and reviews before merging; the exact rules available depend on the plan and repository type. You should also verify whether administrators or service accounts can bypass those rules. [9]

One more subtlety: a local sandbox should not automatically be treated as protection for an external MCP tool. The remote service has to enforce its own permissions and allowed operations. This boundary is also called out in OpenAI’s Codex engineering write-up. [5]

3. Start with a starter package, not a two-hundred-page constitution

My usual workflow does not begin with “create the application.” First I give a text model the approved blueprint, the specification, and my design preferences. In my own practice this is often GPT in Pro mode. I ask it to review the current documentation of the agent platform I plan to use and prepare an initial set of project files.

The important word is initial.

We do not yet know every future problem. Trying to write perfect instructions for the entire project before the first task is like writing a rulebook for every mistake a student might possibly make before the first class. The result is a lot of text and very little usable orientation.

The starter package should explain where requirements come from, how to run checks, which boundaries must not be changed, and what evidence must be presented at acceptance. The detail for the next milestone appears when we actually reach that milestone.

The approach is not tied to Python

The intent, task boundaries, work sequence, evidence, and stopping conditions are universal. The language, application structure, and verification commands change.

For Python, the stack profile might include pytest, ruff, type conventions, and module layout. For TypeScript it might include the package manager, type-checking, test, and build commands. Writing pnpm test in a document is useful only if that script really exists in the project. Copying somebody else’s file does not create missing infrastructure.

So I separate the process core, the stack profile, and the platform adapter. This is a recommendation for our starter package, not built-in Codex terminology.

Figure 3. What transfers between projects.

>

Core: sources of requirements, roles, handoff, acceptance.

>

Stack profile: language, dependencies, structure, run and test commands.

>

Platform adapter: discoverable instruction files, skill format, agent and tool configuration.

>

When moving from Python to TypeScript, you do not need to reinvent work management. But you do need to re-check the commands and project structure.

A minimal layout might look like this:

workspace/
  project-docs/                 # separate Git repository
    blueprint.md
    specifications/project.md
    milestones/M1.md
    decisions/
    agent-design/roles/
    agent-design/skills/
  project-app/                  # separate Git repository
    AGENTS.md
    CLAUDE.md
    PROJECT_CONTEXT.md
    STACK.md
    src/
    tests/
    .gitignore

PROJECT_CONTEXT.md is our entry map: repository addresses, document versions, active milestone, and access method. STACK.md contains real commands and conventions. The agent-design/roles and agent-design/skills directories are our source material — they are not magic names automatically read by every agent.

Assignment for the model that builds the package

Review the approved blueprint and specification. Separate decisions from open questions. Using the current documentation for the selected platform, prepare a minimal starter package: project instructions, two roles, one delivery-verification skill, a stack profile, and a source map. State which files are discovered automatically by the platform and which must be connected explicitly. Do not invent permissions or commands. Do not describe future milestones in detail. Include a file manifest and a safe deployment instruction.

You still need to read the resulting ZIP. Pay particular attention to permissions, external actions, script execution, and the definition of “done.” Human review applies to instructions as well as to code.

Assignment for the agent that deploys the package

Prepare the environment only; do not implement product logic. First inspect the archive and any existing directories. Do not silently overwrite files and do not run unknown scripts. Create the agreed structure, .gitignore, configuration examples without secrets, and a minimal startup check. Initialize Git only where it does not already exist. Connect repositories only to explicitly supplied and approved remotes. Publishing, changing access, and deployment require separate authorization. Present the created files, verification results, and blockers.

At acceptance, I want to see more than “environment ready.” I want a reproducible startup, working checks, correct repository remotes, no secrets in tracked files, and accessible documentation. A prepared environment is a deliverable of its own. The application has not been written yet — and that is fine.

4. How to write AGENTS.md, roles, and skills without magic

A common trap is turning every file into a repetition of every other file. The agent ends up with three similar but slightly different rulebooks. There is no reason to make it take an exam in resolving our contradictions.

General instructions answer: “Which rules are always in force?” A role answers: “Which result are you responsible for right now?” A skill answers: “How should a recurring procedure be performed?”

Keep AGENTS.md thin

Here is a teaching template. Links and commands in a real project must point to resources that actually exist.

# Working in this project

Before starting, read PROJECT_CONTEXT.md and STACK.md.
Work only on the assigned task of the current milestone.
Check the specification version and acceptance criteria in Linear.

Do not change requirements or acceptance criteria merely to make tests pass.
If documents conflict, stop the disputed part of the work
and ask a specific question in the issue comments.

Do not add unrequested features or refactoring.
Do not publish secrets. Do not release without authorization.

In the report include the issue, commit, PR, commands run,
actual check results, limitations, and the next step.
A check that was not run must be explicitly marked as not run.

Do not list every application endpoint here. The file should help the agent find the right rules, not compete with the specification.

For Claude Code, you can create a small CLAUDE.md that imports the shared base and adds only client-specific differences:

@AGENTS.md

# Claude Code specifics
Before starting, verify that the required tools are available.
Obtain the role and task from the initial assignment.

Claude Code supports this import mechanism. After configuration, verify the loaded context using the client’s own mechanisms; do not treat the mere presence of the file as proof that it was applied. [7]

A role is not a list of every virtue of the ideal programmer

For an implementer, a clear mission is enough: implement the agreed task, keep changes inside its boundaries, reproduce the required checks, and present the result.

The supervisor has a different job: compare real progress with the milestone goal, notice missing evidence, and issue concrete corrections. Not “be a world-class senior principal staff architect,” but verify specific things.

Both roles may call specialized helpers when useful. One might inspect code, another test user scenarios, a third check the risk of breaking an API contract. But roles are justified by actual work, not by how impressive the diagram looks.

As of the verification date, Codex supports project definitions for custom agents in .codex/agents/*.toml; Claude Code uses .claude/agents/*.md with a configuration header. These are different formats. Our role text must either be explicitly passed into the session or adapted to the corresponding platform format. [12] [13]

A skill: when, with what input, and to what result

On both platforms, a skill revolves around SKILL.md. Its description helps select the procedure, while details are loaded as needed. For project-level placement, Codex documentation points to .agents/skills/, while Claude Code uses .claude/skills/. The shared idea does not mean every auxiliary field and loading mechanism is identical. [10] [11]

An example of a custom procedure:

---
name: verify-delivery
description: Verify a task result before handing it to a human reviewer.
---

Input: issue, acceptance criteria, commit under review,
list of changed files, and CI results.

1. Map every criterion to verifiable evidence.
2. Check the main, empty, and error scenarios.
3. Compare the changes with the task boundaries.
4. Use only approved commands from STACK.md.
5. Separate actual defects from unverified assumptions.

Output: satisfied criteria, defects, unverified items,
links to evidence, and a recommendation for the next step.

Do not modify code as part of this skill.
Do not change criteria, merge, or release.

This is a verification instruction, not a guarantee of independence. If one agent invents a wrong expectation and the second accepts it as truth, two participants can reproduce the same mistake. Expected results therefore need to come from requirements and prepared examples, and important checks should be reproducible.

Test the skills themselves. Give the procedure a PR with a deliberately missing scenario, then a correct PR. In the first case it should detect the gap; in the second it should not invent a defect just to make the report look convincing. We can test not only the application, but also the way we work on it.

5. One milestone — one understandable result

Consider a teaching application called ReadingLab. A student logs study sessions: date, topic, and duration. We want to add a report for a selected period. In this example, session logging already exists; the first milestone under discussion covers the report only.

A bad milestone: “Build a learning-activity analytics system.”

A better one: “The user opens a report for a selected period and sees correct data, including an honest representation of missing values.”

The task is no longer a bag of possibilities. We can define its boundaries. For example, in this milestone we build the screen and the calculation. Model recommendations, PDF export, and comparison with other students stay outside the milestone.

A few sequential tasks are enough: agree on the contract and examples; implement the calculation and data output; connect the screen; perform final end-to-end verification. The number of tasks is a tool for manageability, not a cult of tiny issue cards. If a task is still too large to explain and verify, shrink the milestone.

What a workable issue card looks like

A sample issue READ-12:

Result: the report for a selected period shows sessions and the sum of known durations.

>

Basis: the approved specification section and the versioned example set.

>

Boundaries: no recommendations, no export, and no changes to storage of the source records.

>

Criteria: the period is treated as a half-open interval [start, end) in the agreed time zone; only the current user’s records are included. For the example “20 minutes, 35 minutes, duration missing,” the result is 55 known minutes and one record with unknown duration. A missing value does not become zero. An empty period produces a normal empty report, not an error.

>

Evidence: tests for calculation and period boundaries, user-data isolation check, reproduction of the screen flow, and links to the PR and exact commit.

Some of these choices could have been made differently. But they need to be made before the agent silently makes them for us. Now both the functionality and the method of checking it are clear.

Do not confuse “tests are green” with “the task is solved”

We need different levels of observation. A unit-level check confirms the calculation. An integration check confirms that data moves correctly through components. A user scenario confirms that a person can actually open the intended report. An authorization check confirms that another user’s records do not leak into the result.

Each check answers a different question. One hundred tests for helper functions do not compensate for a missing check of the main user scenario. And a screenshot of a beautiful screen does not prove that the total is correct.

Figure 4. From task to delivery.

>

Criterion → example with an expected result → code change → verification of a specific commit → PR → human decision → merge into main → check in the agreed environment.

>

Plan the next milestone in detail from the accepted result of the previous one. Merging and deployment are separate events.

For a beginner, I recommend one active milestone. That does not forbid research into future ideas. It is simply a way to learn how to finish work before trying to manage several unfinished stories at once.

6. Non-productive coding: when files move but the product does not

A familiar scene: the agent adds a helper class, improves a handler, renames a module, writes more tests — and then improves the improvements. Everything looks reasonable. The user still cannot get the report.

I call this non-productive coding: activity around the code starts replacing progress toward an accepted result.

That does not mean refactoring or research are useless. Sometimes the correct result of research is to avoid writing the proposed function. Sometimes an architectural defect has to be fixed before delivery is possible. But the connection must be visible: which obstacle was removed, which decision was tested, which acceptance criterion moved closer to completion?

So I do not look at the number of commits. I ask: what can the user do now that they could not do before? Which risk has been reduced? What still blocks completion? How much time and how many retries were required for an accepted result?

If the agent is already in its second cycle of discussing the architecture of a report factory while we have not even defined what an empty period means, the problem may not be model capability. Perhaps we did not provide a sufficiently clear task.

Instructions evolve inside the milestone too

You do not need to wait for the milestone to end before fixing a rule that does not work. But adding another “never do X” after every incident is also a poor strategy.

I use a small loop: find a concrete episode → identify the cause → change the relevant part of the environment → repeat the check.

Does the agent turn a missing duration into zero? First inspect the data contract and expected-result example. Perhaps the specification and test need to be corrected, not the global role. Does the agent run an expensive full verification after every tiny change? Perhaps you need an agreed order of fast checks and full checks. Does the agent read an old specification? Fix the source map and version-selection mechanism.

Instruction changes should also have a reason and a version. When moving between milestones, reconsider which competencies matter. For data import, validation and error handling may dominate; for a UI milestone, user scenarios and accessibility may matter more. Do not carry the entire accumulated configuration forward automatically.

And verify that the changes were actually applied. Codex documents how the AGENTS.md chain is built at startup; for a running session, you cannot simply assume that a new file has replaced the old context. Restarting the session or using the client’s supported context-refresh mechanism should be part of the procedure. [6]

7. Supervisor and implementer: separating attention, not drawing job titles

Now for a useful pattern when work lasts longer. One agent implements the task. Another is deliberately removed from day-to-day product coding and watches whether we are drifting away from the goal.

I call them the supervisor and the implementer. These are composite roles. The implementer may call a helper for code review; the supervisor may call a testing specialist. The pattern does not require exactly two models and does not forbid subagents.

But it does require one clear boundary: the implementer advances the implementation; the supervisor checks progress and the quality of the evidence.

A convenient starting setup is two separate sessions. The supervisor receives the current milestone and issue, reads the sources, and formulates an assignment. The implementer executes it and presents the result. The supervisor checks it, returns concrete corrections, or recommends handing the work to the human reviewer.

Native subagent capabilities, context inheritance, and allowed nesting vary by client. Our organizational pattern does not depend on a subagent being able to spawn an infinite hierarchy of further subagents. Platform documentation exposes separate mechanisms for specialization and tool restrictions; configure those explicitly. [12] [13]

Shared process memory lives in Linear comments

Chat is convenient for launching work. But the assignment, result, and correction should remain in the issue card. Otherwise the next participant has to guess what was decided in a private conversation.

I use a short comment protocol. This is our convention, not a built-in Linear standard:

ASSIGNMENT / version 2
Issue: READ-12. Specification: version and section.
Goal and boundaries: ...
Criteria: ...
Checkpoint and stopping conditions: ...

RESULT / response to assignment version 2
Branch, PR, commit under review: ...
What changed: ...
Commands and actual check results: ...
What was not checked and why: ...
Blockers and next step: ...

REVIEW / of the same commit
Confirmed: ...
Reproducible defects: ...
Correction or recommendation to the human reviewer: ...

Do not paste the entire terminal log into the issue. Keep a compact summary and links to accessible evidence. If the commit changes after the review, the old recommendation does not automatically apply to the new code.

Assign one owner to each instruction. The implementer confirms the version it accepted; the supervisor does not issue several contradictory corrections at the same time. Comments should show which instruction superseded the previous one. This becomes especially valuable after a session restart.

Figure 5. Oversight without a second implementer.

>

The human defines the goal and accepts the result.

>

Supervisor → assignment in Linear → implementer → PR and evidence in Linear → supervisor review → human decision.

>

Both agents may use specialized helpers. The supervisor does not secretly modify the product behind the implementer’s back and does not accept the work instead of the human.

What exactly should the supervisor check?

Not “how convincing is the report?” but whether the acceptance criteria are met, the real user flow is complete, unrequested changes are absent, and the claimed checks actually happened.

For example: “The total-duration test passes, but unknown duration is not covered. Reproduce the specification example. Do not redesign the API: fix missing-value handling and add the necessary check.” That is more useful than “improve quality and act professionally.”

Delegation also has a limit. A second model opinion is not independent truth. The supervisor should open the changes and supporting evidence, not merely read the implementer’s self-report. At acceptance, the human should be able to explain how the feature works and what proves that it works.

8. Long-running work: start manually, then automate

An agent may work on a large task for a long time, but duration is not a quality metric. Useful checkpoints include: before expanding scope, after a significant change, after a repeated failure, and before handing over a result.

Later, you can add a time rhythm — for example, a review every 15, 30, or 60 minutes. This is an example of a supervision policy, not a promise that every interface supports every schedule.

Writing “check the implementer every half hour” is not enough. You need an actual scheduler, a live execution environment, access to the implementer’s outputs, and a channel for delivering corrections. A supervisor does not gain access to another private session simply because we gave it a supervisory role name.

OpenAI documentation distinguishes scheduled tasks in the web and desktop interfaces; local workflows depend on the computer and files being available. Do not automatically assume that CLI and IDE clients have the same scheduling interface. Check the capabilities of your client and account. [14]

Claude Code documents /loop, including interval-based execution. It is a session-level mechanism: execution depends on the session being alive, the agent not being occupied, and scheduler rules; delays are possible, and recurring jobs have a lifetime. It is not a hard real-time timer. [15]

A teaching example for a separate supervisor session with access already configured:

/loop 30m Review new evidence for READ-12 in Linear
and the linked PR. Do not change code. Compare progress
with the acceptance criteria. Leave a correction only when
there is a new defect, blocker, or deviation from the goal.

In a real assignment, also define a cost limit, a limit on repeated failed cycles, and a condition for disabling supervision. After the task is finished, cancel the schedule with the supported tool and verify that it was cancelled. If nothing has changed, do not spend money repeatedly reviewing the same commit.

Check the delivery path for corrections separately. A Linear comment will not necessarily interrupt an implementer that is already busy. You can agree that new instructions are read at checkpoints, or use a supported event mechanism. Emergency stopping needs a real control channel, not hope that the agent notices a comment in time.

An automated supervisor is useful when it reduces your workload. If you are now watching the implementer, the supervisor, and the dispute between them, the additional complexity has not paid for itself yet.

9. For the curious: OpenAI Symphony

At this point it is worth looking beyond manual switching between chat sessions. OpenAI has Symphony — not Symfony, the PHP framework, but a different project with a similar name.

The Symphony repository contains a specification and an experimental orchestrator implementation. Its authors position it as an engineering preview for trusted environments. Treat it as material for study and adaptation, not as a promise of a universal production system. [16]

The idea is straightforward: the orchestrator takes an eligible task from a tracker, prepares an isolated workspace, launches an agent, and tracks the lifecycle of the work. The specification separates execution configuration from the task text; those rules can live in a version-controlled WORKFLOW.md. It also covers concurrency, retries, and state reconciliation. [17]

In the sample workflow, an important part of the exchange with Linear is performed by the agent itself through available tools. That does not mean a single WORKFLOW.md file will automatically connect your account and permissions. The example still requires deliberate integration setup. [18]

Figure 6. An orchestrator and a supervisor are not the same thing.

>

Orchestrator: select an eligible task → allocate a workspace → launch → observe state → retry or finish.

>

Supervisor agent: evaluate the meaning of the result → detect deviation → propose a correction.

>

These functions can be combined. Having a scheduler by itself does not provide substantive product review.

I would not advise a beginner to start with an “agent factory.” First complete one milestone manually. Then automate a process you already understand. Only after that decide whether this level of orchestration is actually useful.

Before reusing somebody else’s workflow, inspect its states, transitions, permissions, and handoff conditions. In particular, successful completion of an agent run may mean ready for human review, not automatic merge and release. For this method, that distinction is fundamental. [17] [18]

10. What is actually changing: publications and field observations

I work continuously with Codex and Claude Code, so I see changes not only in the models but in the environments around them. In my experience, harness updates increasingly make it possible to delegate longer stretches of work to an agent. This is an author’s observation, not measured statistics on release frequency.

There are also verifiable signals of the direction of travel. On September 10, 2026, OpenAI announced the public beta of the Agents API: managed execution built around the Codex harness and infrastructure for long-running agents. This is a separate product announcement, not a new command added to the existing CLI. Claims about runtime length come from the vendor’s description, not from our own student-project benchmark. [19]

On May 25, 2026, Anthropic published an engineering article about containment — limiting what an agent can access at all. The engineering emphasis matters: long-running work requires more than good instructions; it also requires boundaries that are designed into the environment. [8]

Earlier articles — OpenAI’s harness-engineering piece from February 11 and Anthropic’s article on long-running application development from March 24, 2026 — show the foundations of this approach. Environment design, feedback, and organization of extended work are becoming engineering problems in their own right. These are useful background sources, but they should not be presented as publications from the last four months. [20] [21]

None of these sources proves that every vendor now enables maximum autonomy by default, or that human review is obsolete. A more careful conclusion is this: platforms are expanding the portion of work that can be delegated and are developing mechanisms for managing that delegated work.

Three recent voices — and one useful earlier warning

Martin Fowler, May 21, 2026. In Agentic Programming, Fowler distinguishes working with an agent under deliberate developer control from an approach in which the human is no longer interested in the resulting code. For our course, this is an important boundary: delegating implementation does not mean ceasing to understand the system. Verification, understanding, and direction still matter. [1]

Why it is worth reading: it helps establish useful terminology and prevents us from treating every code-generating chat as a new engineering methodology.

Addy Osmani, June 7, 2026. In Loop Engineering, the focus shifts to organizing a repeatable loop: execution, evaluation, preserved state, and the next step. This is close to our idea of extended work within a milestone. But the article does not imply that any number of autonomous cycles is automatically useful. A loop should produce verifiable progress, and the complexity of managing it should pay for itself. [2]

Why it is worth reading: it broadens the view from a single prompt to an operating loop while also revealing the cost of a badly designed loop.

Robert Martin and Justin Martin, June 2026. The public description of episode six of Agentic Discipline shows Swarm Forge: different stages for task definition, implementation, cleanup, architectural review, and quality control. The public description provides a meaningful example of distributing engineering competencies across agents; the complete video is available separately. [3]

Why it is worth reading: it shows how engineering discipline can move into the design of an agentic process. It would be inaccurate to attribute to this material the claim that “clean-code principles are no longer needed.” While preparing this article, I did not find a reliable primary source for the popular paraphrase that “the book is obsolete.”

Kent Beck, April 23, 2026 — an earlier warning. In Nobody Wants Agents, Beck describes an unpleasant effect: he wanted to change a program and instead found himself coordinating several agents. This is a personal account of a specific experience, not a universal argument against multi-agent systems. But it gives us a useful criterion: the tool should help us obtain the result, not create a new maintenance burden around itself. [22]

Why it is worth reading: it is a sanity check for our supervisor-and-implementer pattern. If cognitive load increases, simplify the system.

The community has not converged on a single recipe. Good. That means there is still something worth investigating. But these positions suggest a productive question: not how many agents can we launch, but which engineering work they help us perform better.

11. Autonomy increases the cost of an unclear intent

When an agent performs a small action, a human can notice deviation quickly. When the agent is given a long stretch of work, ambiguity in the original task has time to grow into a large implementation.

No clear blueprint? It is unclear which outcome matters more. Vague specification? The agent fills in gaps by itself. Unclear task boundaries? Neighboring improvements begin to enter the task. No examples and no acceptance criteria? We lose a stable way to distinguish a good result from a merely plausible one.

Many interpretations become admissible. That does not mean every path is actually optimal. It means we have not provided enough grounds to prefer the path we want over the alternatives.

Figure 7. Preserve freedom of implementation; remove ambiguity from the result.

>

Vague goal → many incomparable interpretations → difficult acceptance.

>

Clear goal + boundaries + examples + checks → several acceptable implementations → verifiable choice.

>

We do not constrain every step the agent takes. We constrain the required properties of the result and the consequences of actions.

That is why the center of gravity in software development is shifting. The ability to describe an application, research options, write a specification, decompose work, prepare context, and design verification is becoming increasingly important.

This does not free us from learning programming languages, algorithms, databases, or security. Without those skills it is difficult to notice when an agent has implemented a bad idea beautifully. The change is that engineering competence is now expressed not only in what you wrote by hand, but also in what work you were able to define, constrain, and verify.

Do not turn the environment into a prison made of a thousand instructions. A good task definition leaves the implementer freedom to choose an implementation — while leaving no ambiguity about the required outcome.

12. A small experiment instead of a large belief

Here is what I would suggest in practice. Choose one useful feature in your project. Define a milestone, a few tasks, and acceptance examples. Prepare the minimum necessary instructions. Then complete the entire loop — all the way to a verified result, not merely a polished agent message.

After that, choose a comparable next task and change one element of the environment: for example, add a skill for checking missing values or introduce a separate supervisor. Record the model, client version, source materials, run cost, and the time you personally spent. Compare defects, rework, and accepted output.

Two runs will not give you a scientifically rigorous conclusion: the tasks differ and model behavior is variable. But they will give you a sensible starting point. Then you can repeat the experiment on several similar tasks and see whether the effect persists.

For a student report, I would require three things: a working feature, an evidence chain from requirement to verification, and a short analysis of what had to be changed in the environment. The most interesting observations are usually not victory slogans but surprises: where the agent understood the task differently, which test proved nothing, which rule turned out to be unnecessary.

Before submitting the project, try explaining it to someone who has never seen your chat: what was required, where it is implemented, why you believe the result is correct, and what has not yet been verified.

If you can do that, you are no longer merely generating code. You are designing work. The agent can help you do that work faster, across a broader surface, and — when verification is well designed — more reliably.

Learning to obtain code quickly is a good start. Learning to carry someone else’s work — including machine-generated work — through to an understandable, accepted result is far more interesting.

Sources and routes for further reading

Links were checked on September 15, 2026. Client capabilities change; verify the documentation for the version you are using before configuring a project. The “recent publications” window used in this article is May 15 through September 15, 2026. Earlier materials are marked separately. For reference pages without a publication date, the date is the date on which the page was checked.

How the developer’s work is changing

[1] Martin Fowler — Agentic Programming. 21.05.2026. https:/​/​martinfowler.com/​bliki/​AgenticProgramming.html

Why it is worth reading: clarifies the difference between deliberate delegation and a style of work in which the developer no longer cares about the resulting code.

[2] Addy Osmani — Loop Engineering. 07.06.2026. https:/​/​addyosmani.com/​blog/​loop-engineering/​

Why it is worth reading: proposes thinking in terms of a managed loop rather than a single successful prompt.

[3] Robert Martin, Justin Martin — Agentic Discipline 6: Swarm Forge Demonstration. June 2026. https:/​/​cleancoders.com/​episode/​agentic-discipline-6

Why it is worth reading: the public description shows engineering competencies distributed across agents. The full episode is paid; this article limits its conclusions to the public description.

Building the working environment

[4] Linear — Project milestones. Documentation. https:/​/​linear.app/​docs/​project-milestones

Why it is worth reading: turns the word “milestone” into a concrete structure of tasks and helps avoid confusing a progress percentage in a UI with actual product acceptance.

[5] OpenAI — Unrolling the Codex agent loop. 23.01.2026; foundational reading. https:/​/​openai.com/​index/​unrolling-the-codex-agent-loop/​

Why it is worth reading: explains how context is assembled and where the boundaries lie between the model, the harness, and tools in one concrete implementation.

[6] OpenAI — Custom instructions with AGENTS.md. Documentation. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​agents-md

Why it is worth reading: lets you verify file discovery order, scope, and load timing instead of guessing from filenames.

[7] Anthropic — How Claude remembers your project. Documentation. https:/​/​code.claude.com/​docs/​en/​memory

Why it is worth reading: explains CLAUDE.md, imports, local rules, and the difference between contextual guidance and enforced restrictions.

[8] Anthropic — How we contain Claude across products. 25.05.2026. https:/​/​www.anthropic.com/​engineering/​how-we-contain-claude

Why it is worth reading: moves safety from the wish “let the agent behave well” to the engineering of access and isolation.

[9] GitHub — About protected branches. Documentation. https:/​/​docs.github.com/​en/​repositories/​configuring-branches-and-merges-in-your-repository/​managing-protected-branches/​about-protected-branches

Why it is worth reading: helps enforce review and checks technically before changes enter the main branch.

[10] OpenAI — Build skills. Documentation. https:/​/​learn.chatgpt.com/​docs/​build-skills

Why it is worth reading: shows the SKILL.md format, skill discovery, and how details can be loaded only when needed.

[11] Anthropic — Extend Claude with skills. Documentation. https:/​/​code.claude.com/​docs/​en/​skills

Why it is worth reading: helps adapt a procedure to Claude Code without assuming that platform configurations are fully interchangeable.

[12] OpenAI — Subagents. Documentation. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​subagents

Why it is worth reading: explains how to turn a logical role into an actually configured specialized agent.

[13] Anthropic — Create custom subagents. Documentation. https:/​/​code.claude.com/​docs/​en/​sub-agents

Why it is worth reading: helps define a helper’s separate context, purpose, and tools; the exact format should be checked against the client version you use.

Automate only a process you understand

[14] OpenAI — Scheduled tasks. Documentation. https:/​/​learn.chatgpt.com/​docs/​automations?surface=app

Why it is worth reading: shows differences between interfaces and the conditions under which scheduled work will actually execute.

[15] Anthropic — Run prompts on a schedule. Documentation. https:/​/​code.claude.com/​docs/​en/​scheduled-tasks

Why it is worth reading: explains /loop, session-level scheduling constraints, delays, and termination of recurring runs.

[16] OpenAI — Symphony, official repository. Engineering preview. https:/​/​github.com/​openai/​symphony

Why it is worth reading: provides an architectural starting point for executing work from an issue tracker, not a promise of a ready-made software factory.

[17] OpenAI — Symphony Specification. https:/​/​github.com/​openai/​symphony/​blob/​main/​SPEC.md

Why it is worth reading: lets you study states, workspaces, retries, and the WORKFLOW.md contract independently of the implementation language.

[18] OpenAI — Symphony: WORKFLOW.md example. https:/​/​github.com/​openai/​symphony/​blob/​main/​elixir/​WORKFLOW.md

Why it is worth reading: shows a concrete workflow to adapt; pay particular attention to transitions, permissions, and handoff to a human.

Understanding the direction — without promising magic

[19] OpenAI — Introducing the Agents API. 10.09.2026. https:/​/​openai.com/​index/​introducing-the-agents-api/​

Why it is worth reading: a recent example of how much long-running execution a vendor is moving into a managed platform.

[20] OpenAI — Harness engineering: leveraging Codex in an agent-first world. 11.02.2026; foundational reading. https:/​/​openai.com/​index/​harness-engineering/​

Why it is worth reading: shows why repository structure and feedback mechanisms become part of engineering work with agents.

[21] Anthropic — Harness design for long-running application development. 24.03.2026; foundational reading. https:/​/​www.anthropic.com/​engineering/​harness-design-long-running-apps

Why it is worth reading: gives an example of organizing extended work instead of endlessly extending one prompt.

[22] Kent Beck — Genie Lessons: Nobody Wants Agents. 23.04.2026; earlier first-person account. https:/​/​newsletter.kentbeck.com/​p/​genie-lessons-nobody-wants-agents

Why it is worth reading: helps spot the moment when managing agents becomes a new problem instead of solving the old one. Beck discloses that the session discussed in the post was sponsored by Augment Code.

[23] Sergey Avdeichik — You got an answer. Who organized the work? 12.09.2026. https:/​/​dobrovola.dev/​en/​writing/​from-ai-answers-to-verifiable-work

Why it is worth reading: covers the previous stage of the method — conversation, research, blueprint, specification, and a verifiable result.