AI-Assisted Development

Abstract

The most profound shift in software engineering isn’t a new language, framework, or cloud service. It’s the transition from writing code to expressing intent, and trusting intelligent systems to translate that intent into working software. Writing code for the sake of writing code has never been the point of software engineering, it is about creating a solution to human problems. Software engineering is more than just writing code.

A New Paradigm

A new paradigm has arrived in which developers express what they want to build rather than how to build it. The machine handles implementation while humans provides intent, architecture, and judgment.

The first generation was accelerated autocomplete. Tools that predicted the next line, filled in boilerplate, and saved keystrokes on repetitive patterns. Useful. Genuinely time-saving. But the workflow stayed identical to what it had always been: you drove, the tool assisted. The feedback loop was: write code, run it, debug, repeat. The AI just reduced friction inside that loop.

The second generation introduced synchronous agents. You described a task in natural language. The model generated code. You reviewed it, corrected it, iterated toward a working result. This moved further up the stack. Less typing, more describing intent. But you were still present for every step. The agent was a collaborator, not an autonomous worker. You held the context, directed the next move, and caught mistakes in real time.

The third generation introduced autonomous agents. These agents can take a specification and run with it for thirty minutes, an hour, several hours and increasingly days. They set up environments, install dependencies, write tests, hit failures, research solutions online, fix the failures, write the implementation, test it again, set up services, and produce artifacts you can review. You hand them a task, move on to something else, and come back to logs, previews, and pull requests. You are no longer interacting line by line. You are defining outcomes and reviewing results. This is where swarms of agents and even self-improving agents come into play.

Now, fully autonomous agents can clone repositories, plan multi-file changes, execute them in sandboxed environments, run tests, and submit pull requests: all without a human typing a single line of code.

flowchart TB
    A["🔤 Autocomplete 2021 \n\n Simple token prediction. \n The editor guesses your next few characters."]
    --> B["📝 Inline Code Suggestions 2022 \n\n Complete entire functions. \n The model understands patterns, not just tokens."]
    --> C["💬 Chat-based Generations 2023 \n\n Describe features in natural language. \n The conversation became the interface."]
    --> D["🔄 Coding Agents 2024-25 \n\n Multi-file edits, tool callings, test executions, iterative self-correction. \n  The agents runs its own loop."]
    --> E["🤖 Autonomous Agents 2025-26 \n\n Clone repos, plan architecture, execute in sandboxes, run full test, submit pull requests \n No human keystrokes required."]

    style A fill:#003333,stroke:#4a4a8a,color:#fff
    style B fill:#003399,stroke:#4a4a8a,color:#fff
    style C fill:#000066,stroke:#4a4a8a,color:#fff
    style D fill:#330066,stroke:#7a5ab5,color:#fff
    style E fill:#660066,stroke:#7a5ab5,color:#fff
Figure 1: From Autocomplete to Autonomy

A New Software Development Life Cycle (SDLC)

The software development life cycle has already been through one major transformation. Over the past two decades, most enterprises moved from sequential waterfall processes to iterative models: Agile sprints, continuous integration, DevOps pipelines, and rapid release cycles.

AI compresses this cycle dramatically, but unevenly: implementation that once took weeks can now be done in hours, while requirements, architecture, and verification remain stubbornly human-paced.

The Factory Model

https://addyosmani.com/blog/factory-model/ The most useful mental model for this new paradigm is that you are no longer just writing code. You are building the factory that builds your software.

That factory consists of fleets of agents. Each agent has a task, a toolbelt (repositories, test runners, deployment scripts, documentation), context (specs, architecture decisions, prior constraints), and a feedback loop. Instead of hand-holding a single agent through a single task, you spin up many agents in parallel. One handles backend refactors. Another implements a feature. Another writes integration tests. Another updates documentation. You review outputs, give feedback, refine specs, and redeploy.

The analogy runs deeper than it might first appear. A factory has quality control. A factory has process documentation. A factory has inputs that need to be precisely specified or the outputs come out wrong. A factory stalls when the environment is unreliable. All of these properties map directly onto agentic software development, and taking the analogy seriously points you toward the investments that actually matter.

Inside teams that have adopted this model aggressively, a substantial portion of merged pull requests now originate from agents running autonomously in cloud environments. That is not theoretical anymore. It is production reality for a growing number of engineering organizations.

The sentiments from Cursor around “The developer’s job is becoming building the system that builds the software, the factory, not just the product” and “reviewing ideas is a lot more fun than reviewing code” (video) resonate with these points.

The mental model that ties these transformations together is the factory model. In this model, the developer’s primary output is not code: it’s the system that produces code. This system includes:

  • Specifications and context that define what needs to be built
  • Agents that translate specifications into implementation
  • Tests and quality gates that verify correctness
  • Feedback loops that route failures back to agents for correction
  • Guardrails that constrain agents to safe, predictable behavior

A factory manager does not assemble every widget by hand. They design the assembly line and ensure quality control. Success comes from giving agents success criteria rather than step-by-step instructions, then letting them iterate.

flowchart TD
    Dev["👨‍💻 Developer\n(Factory Manager)"]

    subgraph Factory["🏭 The Factory"]
        direction TB
        Spec["📋 Specifications\n& Context"] --> Agents["🤖 AI Agents\n(Implementation)"]
        Agents --> Tests["✅ Tests\n& Quality Gates"]
        Tests --> FL["🔄 Feedback\nLoops"]
        FL --> Agents
        GR["🛡️ Guardrails\n& Constraints"] --> Agents
    end

    Dev --> Factory
    Factory --> Code["📦 Production\nCode"]

    style Factory fill:#1a1a2e,stroke:#4a4a8a,color:#fff
    style Dev fill:#533483,stroke:#7a5ab5,color:#fff
    style Code fill:#1a3d1a,stroke:#4a8a4a,color:#fff
Figure 2: The Factory Model — Developer designs the system, agents produce the code, tests verify the output

Harness Engineering: What Surrounds the Model

There is a temptation to treat the model as the system. A new model comes out, the agent gets smarter. That intuition is wrong, and it leads to the wrong investments.

A raw model is not an agent. It becomes one once a harness gives it state, tool execution, feedback loops, and enforceable constraints. The behaviour developers experience when working with Claude Code, Cursor, Codex, Aider, or Cline is dominated by what the harness does, not just by which model is underneath.

\[\text{Agent} = \text{Model} + \text{Harness}\]

flowchart TB
    subgraph Harness["🔧 The Harness"]
        direction TB
        IR["📜 Instructions &\nRule Files\n(AGENTS.md, CLAUDE.md)"]
        Tools["🛠️ Tools\n(APIs, MCP Servers)"]
        Sandbox["📦 Sandboxes &\nExecution Environments"]
        Orch["🔀 Orchestration Logic\n(Sub-agents, routing)"]
        GR["🛡️ Guardrails / Hooks\n(Lifecycle checkpoints)"]
        Obs["📊 Observability\n(Logs, traces, evals)"]
    end

    Model["🧠 Model\n(Reasoning Engine)"] --> Harness
    Harness --> Agent["🤖 Agent\n(Working System)"]

    style Harness fill:#1a1a2e,stroke:#4a4a8a,color:#fff
    style Model fill:#533483,stroke:#7a5ab5,color:#fff
    style Agent fill:#1a3d1a,stroke:#4a8a4a,color:#fff
Figure 3: Harness Anatomy — Agent = Model + Harness

What’s in the Harness

  • Instructions and Rule Files — the text that defines who the agent is, what it cares about, and what it is forbidden from doing. Includes AGENTS.md, CLAUDE.md, GEMINI.md, skill files, and sub-agent prompts.
  • Tools — the functions, MCP servers, and APIs the agent can call, plus the prose that tells the model when and how to call them.
  • Sandboxes and execution environments — where the agent’s code actually runs, what it has access to, what it cannot reach.
  • Orchestration logic — sub-agent spawning, model routing, hand-offs between specialists, and the rules that govern when each fires.
  • Guardrails / Hooks — deterministic code that runs at specific lifecycle points: before a tool call, after a file edit, before a commit. Hooks are the place for things the agent should never forget but often does.
  • Observability — logs, traces, evaluations, cost and latency metering. Without observability, there is no way to tell whether the agent is doing well or quietly drifting.

Harness in SDLC

flowchart LR
    subgraph P1["Phase 1\nRequirements & Architecture"]
        H1["⚙️ Configure\nInstruction files,\ntool access, rules"]
    end
    subgraph P2["Phase 2\nImplementation"]
        H2["▶️ Run\nSandboxes,\nexecution environments,\ntools"]
    end
    subgraph P3["Phase 3\nTesting & QA"]
        H3["🔄 Feedback Loop\nOrchestration logic,\nguardrails → self-correction"]
    end
    subgraph P4["Phase 4\nReview, Deploy & Maintain"]
        H4["👁️ Observe\nHooks, observability,\naudit trails"]
    end
    P1 --> P2 --> P3 --> P4

    style P1 fill:#1a2a3d,stroke:#4a6a8a,color:#fff
    style P2 fill:#1a3d1a,stroke:#4a8a4a,color:#fff
    style P3 fill:#3d2a1a,stroke:#8a6a4a,color:#fff
    style P4 fill:#2d1a3d,stroke:#6a4a8a,color:#fff
Figure 4: The Harness Across SDLC Phases
Most Agent Failures are Configuration Failures

When an agent does something wrong, the first instinct is to blame the model. More often, the failure traces back to a missing tool, a vague rule, an absent guardrail, or a context window stuffed with noise. Public benchmarks confirm this: one team moved a coding agent from outside the Top 30 to the Top 5 on Terminal Bench 2.0 by changing only the harness, with no model change at all.

The Developer’s Evolving Role: Conductors and Orchestrators

As AI takes over more of the implementation work, developers move fluidly between two modes:

flowchart LR
    subgraph Conductor["🎼 Conductor Mode"]
        direction TB
        C1["Real-time collaboration\nwith AI pair-programmer"]
        C2["In the IDE, watching\ncode appear"]
        C3["Fine-grained control\nover every change"]
        C4["Tools: Copilot, Cursor,\nWindsurf, Gemini Code Assist"]
    end
    subgraph Orchestrator["🎭 Orchestrator Mode"]
        direction TB
        O1["High-level abstraction:\ndefine goals, assign to agents"]
        O2["Agents work in background,\nin parallel"]
        O3["Review results,\nprovide course corrections"]
        O4["Tools: Jules, Copilot Agent\nMode, Claude Code"]
    end
    Dev["👨‍💻 Developer"] --> Conductor
    Dev --> Orchestrator

    style Conductor fill:#1a2a3d,stroke:#4a6a8a,color:#fff
    style Orchestrator fill:#1a3d2a,stroke:#4a8a6a,color:#fff
    style Dev fill:#533483,stroke:#7a5ab5,color:#fff
Figure 5: Conductor vs. Orchestrator — Two Modes of Working with AI Agents

The Conductor: Hands-On, Real-Time Direction

In conductor mode, a developer works in real-time with an AI pair-programmer. They’re in the IDE, watching code appear, guiding the AI with prompts and corrections, maintaining fine-grained control over what gets written.

This mode is typical when: - Working on complex logic - Debugging tricky issues - Working in unfamiliar codebases where each change must be understood

The risk is that it can become a bottleneck — if the developer is personally directing every keystroke, the throughput improvement from AI is limited.

The Orchestrator: Async, Multi-Agent Delegation

In orchestrator mode, the developer operates at a higher level of abstraction. They define goals, assign them to agents, and review results — not watching code appear line by line. Agents may be working in the background, in parallel, on different parts of a codebase.

This mode is typical for: - Well-defined bug fixes - Feature implementations against established patterns - Codebase migrations - Test generation

The orchestrator mode requires different skills:

  • Specification — defining tasks precisely enough for autonomous execution
  • Decomposition — breaking large tasks into appropriately sized units
  • Evaluation — quickly assessing whether agent output meets quality standards
  • System design — designing the constraints, tests, and feedback loops that keep agents productive

The Pareto Law

…WIP…

The 80% Problem

A persistent challenge: AI agents can rapidly generate approximately 80% of the code for a feature, but the remaining 20% — edge cases, error handling, integration points, and subtle correctness requirements — demands deep contextual knowledge that current models often lack.

The nature of AI errors has evolved from simple syntax mistakes to more insidious conceptual failures: wrong assumptions about business logic, missing edge cases, and architectural decisions that create subtle long-term maintenance burdens. These errors are harder to detect because the code “looks right” and may even pass basic tests.

Tip

The developers who navigate this challenge most effectively use AI for what it’s good at (rapid implementation of well-specified tasks) while reserving their own attention for what AI struggles with (ambiguous requirements, architectural trade-offs, and correctness verification).

Where to Start

  1. Set up an AGENTS.md for the project. Start with ten lines: stack, conventions, hard rules, workflow. Add a rule every time the agent does something it should not do again.

  2. Install a set of skills for your coding agents (like Agents CLI) to build, evaluate, deploy and optimize agents.

  3. Pick one repetitive workflow and make it the first agent. A research workflow, a code review process, a recurring report. Use a coding agent for the prototype, graduate it to a production agent when it earns its keep. Building one agent end to end teaches more than reading about a hundred.

  4. Write the tests and evals before generating the code. Together they are the contract with the AI. A well-written test and eval suite communicates intent more precisely than any natural-language prompt, and turns AI-assisted development from vibe coding into agentic engineering.

  5. Review every line the agent produces that is going to ship. Be skeptical of anything that looks clever. Check imports for real packages. Verify that error handling covers realistic failure modes.

  6. Maintain your developer skills. AI handles the routine so the developer can focus on the challenging. That arrangement only works if foundational skills — debugging, system design, intuition for performance and correctness — stay sharp.

  1. Make context engineering a first-class engineering practice. Treat AGENTS.md, system prompts, eval suites, and skill libraries as code: reviewed in pull requests, versioned with the project, owned by named engineers.

  2. Set the bar at the eval, not the demo. A working demo proves an agent can succeed once. A passing eval suite proves it succeeds reliably. Define what you are scoring: task success, tool use quality, trajectory compliance, hallucination, and response quality.

  3. Re-shape code review for AI-generated code. Extra attention to hallucinated dependencies, inadequate error handling, and subtle correctness gaps that look right at a glance.

  4. Distinguish prototyping work from production work in team norms. Vibe coding is the right speed for exploration. Agentic engineering is the right discipline for production. Make the boundary explicit.

  5. Invest in harness components as a shared team asset. Reusable system prompts, skill libraries, MCP server connections, and evaluation harnesses compound across projects. Treat them as infrastructure.

  1. Treat AI-assisted development as an engineering investment, not a productivity feature. Rolling out a coding agent without eval coverage, observability, and clear architectural standards produces speed without quality.

  2. Invest in the production substrate before scale. What graduates a vibe-coded prototype to production is operations discipline: trajectory and final-response evals in CI, traces of every agent run, scoped permissions, and security review tuned to generated code’s failure modes.

  3. Adopt open standards. Model Context Protocol (MCP) for tool access and Agent2Agent (A2A) for cross-agent delegation are converging into the connective tissue of multi-agent systems.

  4. Plan for hybrid teams of humans and agents. The strongest production results come from architectures where humans set direction, agents do the implementation, and clear handoff protocols govern the boundary.

  5. Reframe hiring and skill development around judgment, not just implementation. The most valuable engineers in the next several years will be the ones who can direct agents well, not the ones who can write the most code.