AI Agents in the Delivery Pipeline: A Hands-On Ownership Playbook for Code You Never Hand-Wrote

If your team already runs AI coding agents inside a real delivery pipeline, the interesting question is rarely model quality. It is who answers when the artefact those agents produced lands in main and starts misbehaving. The practical question — what an application owner needs to know, where to check agent output, and how deep to go — is answered below as an operating routine rather than a philosophical debate.

What one red CI flag looked like end to end

The setup was an agentic workflow tuned tightly enough that a committed branch with failing tests seemed unlikely, so the first suspicion fell on a CI flake or an environment issue. The real signal came from SonarQube, which appeared to complain about App.tsx. That prompted the obvious follow-up: had npm brought in a new suspicious dependency? It had not. What was flagged was cyclomatic complexity, an issue that had not been encountered recently.

App.tsx contained about 30 lines of code, except 15 of those lines were complete components that Codex had written each on a single line. Formatting with prettier would have solved that surface problem, but it would not explain the complexity: each component carried a substantial amount of display and business logic. An earlier generation of engineer would have refactored carefully for readability; Codex did not mind single-line components, and it also did not mind complexity, having kept iterating on the file across several features.

The CI tool was raising a problem that might be correct or incorrect, but the system was real, so investigation was mandatory. After formatting, the components and their logic were inspected. Codex had covered edge cases more than a typical developer might and had slightly over-engineered parts, yet the result was correct and no complaint remained — the complexity matched the business requirements. Asking Codex to make SonarQube happy produced a refactor that split the work into 10 files. CI passed, and the change shipped. The incident resolved quickly, but it could have gone badly, because this was code the operator had never seen.

The boat, the divebots, and the two camps arguing about them

This points to where software is heading. Imagine a boat and a job of collecting small gold nuggets from the ocean floor. Until recently, filling a bag required jumping in, swimming down, looking around, and stuffing the bag. In clear shallow water that was easy, and it became much harder as conditions changed. As shallow mines dried up, engineers built machinery and tooling for deeper and more dangerous water, which worked for a time: teams assembled, maintained, and rotated the machinery while still diving to keep the seabed operation running. Sometimes operations collapsed from pressure, accidents, or operator incompetence, and the seabed kept changing, with mines drying up and new ones appearing elsewhere.

The last few years brought more sophisticated divebots that can descend and build a mining operation on their own. You tell them where to build, and they dive, surfacing only with updates and gold nuggets. That is the Optimists camp: you can relax on the boat while the divebots work, worrying mainly about how much gold fits in the boat.

Then the skeptics arrive, with warnings such as “Wait till your divebots go too deep and get lost” and “Haha your divebots brought you stuff that looks like gold but is actually shiny octopus poop”. As divebots spread, horror stories multiply. Some get lost and forget what they were supposed to build. Others produce something so complex and grotesque that they struggle to maintain it, only for the next generation of divebots to discard it. Underwater mining shifts from carefully engineered cathedrals to haphazard mansions with hidden passages and lurking horrors, and the more detached you are from the operation, the more spectacular the failures become. That is the Skeptics camp.

Where the agent sits in the workflow — and what ownership no longer guarantees

Software engineering, and probably many other industries soon, is living a version of this scenario. Most readers already know whether Skeptic or Optimist describes them better, even if they have not chosen a camp.

The traditional wisdom is that maintaining a non-trivial system requires a proper working model of it, and few dispute that. In software engineering that model was acquired by working directly with the code: years and decades of writing and reading code supplied the knowledge and tools needed to understand responsible systems, and every production incident, every late-night debugging session, and every successful release contributed perspective. In that context, ownership means you are the one who gets called when something breaks.

Agents, or divebots, turn it on its head. They produce output faster than anyone can absorb, and the old assumption that code in a complex system had at some point passed through human hands is no longer guaranteed. Experienced practitioners can now manage fleets of divebots and create software at a scale that would have been unprecedented before, using considerable craft and experience to manage and architect large systems that once required teams. That exposes a major challenge: how do we train the next generation of engineers?

At their extremes, the camps give very different answers. Reputable voices say control requires reading every line the divebots produce, being able to code it by hand, and explaining what each piece does and how it fits the application. Equally reputable voices say not to look at the code at all: put energy into deciding what to build and forget how it is built, because the models will handle it. Neither answer seems right. The route by which today's senior engineers learned — coding by hand, endless debugging, production incidents, and similar work — is not a viable route for juniors today, and it is not economically viable either: companies are unlikely to sponsor juniors for years while they “learn to do it by hand”. That is wishful thinking. The alternative advice is equally unrealistic in most settings: “make sure you understand every line your agent wrote”, “pair with a senior”, or “perform careful code reviews”. If you think the industry at large will adopt these practices, there is a bridge to sell you.

What it takes to own a non-trivial system you did not write

To find a viable route to some measure of mastery, start from what ownership means for a typical architect, lead, or CTO: success depends on having a model of the system in their head — a chart of the waters. The real question is the level of granularity that model needs.

Imagine a legacy 1-million line codebase written and expanded over years by many people, parts of which the CTO may even have written. Now imagine a production issue, with you as the unlucky SRE trying to resolve it at 2AM while getting angry texts from people in different timezones. The chart you need is a high-level, far-away map of the entire system: you need to know just enough to know where you need to dive in and where the monsters live, and you need to be able to jump into any unknown codebase, figure out what is happening, push a hotfix, and describe what happened clearly in your incident report.

That is not detailed knowledge of the whole system. Complex systems are managed by building abstractions; each layer lets us build a bit more, but whatever map you have, abstractions go all the way down, and no one really understands all the layers.

Kind of knowledge	What it supports	Where it stops
“I wrote module X and know it inside out”	Deep familiarity with one part you built by hand	It is what coding by hand gives you — and it is not what the owner who gets called needs
“I have an appropriate model of the system abstractions and can dive into any module and fix it when it breaks”	Choosing the dive, shipping a hotfix, writing a clear incident report	It still does not amount to understanding every layer of the system

Quiet failures, fundamentals, and the depth you need on demand

In complex systems, some of the most insidious failures are quiet ones. Things mostly work, but there is something off about the system: it may suddenly be slower, error rates may rise, or it may work perfectly most of the time but fail every 19th attempt. That is not enough to be paged at 2AM, but it is enough to create a feeling that something is off. As a system owner you need to understand those failure modes, and the industry already has tools for teaching people to detect and reason about them: fundamentals. These have been taught to unwitting CS majors for decades — data structures and algorithms, networking, concurrency, distributed systems, and similar areas. Formal education is not required; they are topics people can read about and learn on their own.

To paint a simple picture, imagine sending your divebot on a mission. You are in shallow water and send it 2m underwater to collect some gold nuggets; it comes back in 4s and all is good. Next, you send it down 4m, and this time it takes 16s. That is odd. The next mission is 16m down, and it takes 256s. You get the picture: something is obviously off. In computer science, this would be called quadratic complexity, and the best way to recognize it is probably to understand the theory and know that such a thing exists.

Breadth: the high-level map that tells you where to dive

Breadth is the next pillar of ownership. Many successful engineers and engineering leaders could hold a discussion on almost any topic, technical or not; they may have been specialists in certain things, but the most impressive ability was drawing on and weaving together seemingly disparate concepts from different disciplines to solve problems. This is the high-level map of the waters, the thing that tells you certain seas are more dangerous than others, and it enables you to say “let's dive here”. It is not expert-level knowledge in every domain, just enough to know what to look up when something is off. The buoys guide your ocean exploration.

Someone asked, “how do we teach breadth? a survey class on everything?”, and the honest answer is that this is not something you can teach: there is no “Everything 101” you can take. The most anyone can do is encourage people to read, explore, and be curious, absorb as much information as possible, remember the weird incidents and the “oh crap” moments, and think about how they connect to the work. As experience accumulates, make a conscious effort to connect everyday experiences with your work; there are countless cases of one bit of knowledge learned while working on a random project years earlier swooping in to save the day. That experience and breadth compounds, but it has to be maintained.

Just-in-time depth, or learning under pressure for real

The final pillar is just-in-time depth: the ability and willingness to dive into any problem and figure it out, even in uncharted waters, even if you have to get in the cage and swim with the sharks for a bit, or gather your team, load up the big proper submarine, and dive down past the giant squids to figure out what is wrong with the system. It is also the humility to know when a dive is beyond your capabilities and you need to look for help. A dive cannot always be done alone, and a dive is not always worth taking.

Some months ago, while an agent orchestrator was being built, stability issues and lifecycle bugs surfaced across its agents and subagents. What they were supposed to do was clear, but the divebots that had built the thing had done so rather haphazardly, and all of the bugs were coming home at once. After watching the agents crash for the nth time in an hour, and after several failed attempts at having the divebots fix their own mess, a Kubernetes book read years earlier brought the words “level-triggered state machine” suddenly into view. The dive that followed went deeper than originally intended, as far as the electrical engineering origins of “level-triggered”. The divebots were brought along for the ride and the core architecture was re-designed from the ground up; it has been rock solid since. That successful rewrite was mainly possible because someone happened to remember something read years earlier and was willing to dive in and learn whatever was needed to get the job done.

You start, then, with a high-level map of the ocean, which is the system, and the understanding that it is layers of abstraction all the way to the bottom. Because all of those abstractions leak, the job as system owner is to know where to dive and how deep. It is no longer generalist versus specialist, or even the mythical T-shaped folks. The new way of building things requires a generalist who can dive deep into the unknown, a “quick learner under pressure”, and not in the resume-padded way: you will actually need to be able to learn quickly while fighting with sea monsters. Interviewers who hear “quick learner” on a resume tend to ask for a time you had to learn a complex system quickly — how did you do it, and what would your answer be?

Checklist: the six checks before an agent-written change ships

• Treat the tool's complaint as an investigation trigger. A CI or static-analysis flag on code nobody hand-wrote might be correct or incorrect, but the system is real, so it has to be checked.
• Format first, then read. Formatting removes surface noise, yet it will not explain why a metric is high — inspect the components and the logic afterwards.
• Compare complexity against requirements. Agent output can be correct and still over-engineered; what matters is whether the complexity matches the business requirements.
• Expect wider edge-case coverage than a typical developer's — and confirm that extra coverage is not hiding logic that no one will want to maintain.
• Ask the agent to refactor and split the work into smaller files, then re-run CI before shipping.
• Log the part you could not explain. Fast resolution is not the same as ownership; note the code you had never seen and what you had to learn to clear it.

Step-by-step: the ownership routine for agent-built systems

1. Keep a chart of the waters. Maintain a high-level, far-away map of the whole system and remember that its abstractions go all the way down.
2. Watch for quiet failures. Sudden slowness, rising error rates, or a run that fails every 19th attempt are signals even when nothing is on fire.
3. Interpret the signal with fundamentals. Data structures and algorithms, networking, concurrency, and distributed systems are the reading tools for failure modes.
4. Sanity-check the shape of the curve. A divebot sent 2m down returning in 4s, then 4m in 16s, then 16m in 256s is quadratic complexity, not bad luck.
5. Use breadth to choose the location. The map is what lets you say “let's dive here” and know which seas are more dangerous.
6. Dive just-in-time. Learn whatever the job requires, alone or with the team and the big proper submarine — and recognise when the dive is beyond your capabilities.
7. Bring the divebots along on the dive. Once you understand the real mechanism, have the agents re-design rather than patch the same mess.
8. Close the loop with a clear incident report so the shared map improves for everyone.

Common misconceptions about AI-assisted ownership

• “Either read every line or read none.” Both extremes fail in practice; the usable position is knowing enough to notice what is wrong and diving when needed.
• “Sponsor a junior to learn to do it by hand for a few years.” Not economically viable; companies are unlikely to fund it.
• “Careful code reviews and pairing will save us.” Sensible advice that most settings will not adopt at scale.
• “Owning a module is owning the system.” The inside-out knowledge of one hand-written part is not the working model the person who gets called needs.
• “Breadth can be scheduled.” There is no Everything 101; it is gathered through reading, curiosity, and deliberate connection of experience to work.
• “Every dive is a solo mission.” Some dives need the team, and some are not worth taking at all.

Action suggestions for teams using agents this quarter

• Put static-analysis and CI thresholds in front of the same dashboard your operators watch, so quiet failures get noticed rather than averaged away.
• Assign a named owner to every agent-written area of the codebase — the person who will get called at 2AM.
• Turn each resolved incident into map updates: what the abstraction layer was, where the dive went, and what had to be learned.
• Give juniors the fundamentals path explicitly (algorithms, networking, concurrency, distributed systems) instead of years of hand-coding they will never be funded for.
• Practise dives on unknown codebases in low-risk settings, so the just-in-time muscle exists before it is needed in anger.

Who ends up owning the fleet

None of this arrives through a certificate. Fundamentals can be learned, breadth is gathered, and just-in-time depth can be practised: those three pillars are what enable someone to grow their ownership share in a system. Start in shallow waters and send your divebots down, but keep the suit within reach for the day you have to put it on and swim with the monsters when something breaks. As for who will be responsible for the sprawling underwater mining operations in the future, no one knows — but the safer bet is the individual able to wield the three pillars: the kid who took an old radio apart and fixed it without knowing the first thing about radios, driven by nothing more than a desire to listen to music, even if a couple of extra screws were left over after putting everything back together.