This content originally appeared on Level Up Coding - Medium and was authored by Pete Palles
From Expert Developer to Agentic Orchestrator
There is a moment in agentic software development that feels deeply uncomfortable.
It is not the moment when the agent fails. Failure is familiar. A bad diff, a broken test, a hallucinated API — those are annoying, but they fit inside the traditional engineering model. You find the mistake, correct it, and move on.
The stranger moment is when the agent appears to succeed.
The tests pass. The diff is coherent. The code may even be cleaner than what you would have written under time pressure. And yet, if you are honest, you cannot fully explain every decision that produced it. You understand the goal, the shape of the solution, the verification results. But you do not have the line-by-line authorship relationship with the code that you would have had in a traditional workflow.
That is the event horizon.
It is the point where the old safety mechanism — “I understand everything because I built it” — stops scaling.
A lot of engineers experience this as a loss of control. Some reject the workflow entirely. Others make the opposite mistake and start trusting the agent because it sounds confident, moves quickly, and produces plausible output.
Both reactions are wrong.
The answer is not blind delegation. The answer is not retreat. The answer is governed orchestration.
The Old Expert Model
Traditional software expertise is built around direct comprehension.
You learn the language, the framework, the codebase. You build a mental model of the system. Over time, expertise becomes the ability to hold more of that system in your head than everyone else.
You know where the bodies are buried. You know which abstractions are real and which are decorative. You know which tests matter, which are theater, and which parts of the system are one accidental refactor away from pain.
That kind of expertise is real. It still matters.
But agentic development stresses the old model, because the volume of generated activity can exceed what a human can absorb at the same level of detail. The agent inspects files, drafts plans, writes tests, patches implementation, updates docs, and iterates again before you have emotionally caught up to the first diff.
At small scale, this feels like acceleration. At larger scale, it feels like cognitive displacement.
You are still responsible, but the work no longer flows exclusively through your hands. You are not typing every line. You are shaping the system that produces, constrains, verifies, and accepts those lines.
That is a different job.
Not easier. Different.
The First Phase Feels Like Magic
Most people do not start with full orchestration. They start with assistance.
“Write this test.” “Explain this error.” “Refactor this function.”
At that stage the tool operates inside your existing mental model. You understand the code before it is touched, understand the requested change, and can validate the output at a glance. It feels like autocomplete with better manners.
It is worth being precise about terms here, because one word is carrying too much weight. An assistant works synchronously, inside your immediate context, on a change you are already holding in your head. An agent works asynchronously: it makes multi-step decisions, runs commands, and crosses system boundaries on its own — what Anthropic describes as a system where the model “dynamically directs its own processes and tool usage.” The event horizon is the crossing from the first to the second.
Once the agent is part of the execution path, the old control model no longer applies. It handles multi-file changes. It proposes architecture, finds related call sites, updates tests, runs commands, reviews another agent’s work. You are no longer coding faster. You are supervising a code-producing system. You are designing a control loop around software generation.
There is a wrinkle here we should not rush past. The feeling of acceleration is real. Whether the acceleration is real is a separate question.
In 2025, METR ran a randomized controlled trial with experienced open-source developers working in codebases they knew intimately. Beforehand, they expected AI to speed them up by about 24%. Afterward, they believed it had sped them up by about 20%. In fact, it had slowed them down by 19%.
Read that again. Even the people best positioned to judge misread their own productivity — and they erred on the optimistic side.
That was an early-2025 snapshot in mature repositories — the setting least favorable to AI — and METR has since cautioned that newer tools likely help more, even as the effect has grown harder to measure. But the gap itself, between how fast the work feels and how fast it is, is one of the first signs you are nearing the event horizon. The old instruments stop telling you the truth.
Crossing the Event Horizon
The event horizon is the point where direct personal comprehension is no longer the primary safety mechanism.
This shift has to be understood precisely. (And yes — the metaphor is a deliberate stretch. A real event horizon lets nothing back out; the point here is not that you cannot return, but that past a certain density your old instruments stop giving readings.)
It does not mean you no longer need to understand software. It does not mean code quality stops mattering, or that tests prove correctness, or that “vibe coding” is fine because the demo works.
It means the center of gravity moves. Before the horizon, safety comes mostly from personally knowing what you wrote. After it, safety has to come from process discipline: clear scope, explicit constraints, deterministic tests, reproducible environments, review gates, rollback paths, and observable outcomes.
You still need judgment — more than before, not less. But it moves up a level. The question is no longer only, “Do I understand every line?” It becomes, “Have I constrained this system tightly enough to trust the evidence it produces?”
That is a harder question. It is also the one that separates serious agentic engineering from AI-assisted chaos.
The Psychological Hit Is Real
Engineers are not just rational processors of evidence. We have identities.
A good engineer is used to being the person who understands — who can trace a failure through five layers of abstraction and explain why the fix works. Agentic development threatens that identity. Not because the agent is “smarter” in any simple sense; that framing is mostly noise. The deeper issue is that the workflow breaks the emotional connection between effort and ownership.
The agent produces more code than you can comfortably review the old way. It explores more files than you can keep in working memory. It offers confident reasoning that sounds like expertise but may or may not be grounded. It can make you feel powerful and irrelevant in the same session.
The bad response is to hide the discomfort. The better response is to name it.
Past a certain point you will not feel the control you felt when every line passed through your hands. Trying to recreate that feeling will either slow you back down to traditional development or push you into fake certainty.
Fake certainty is dangerous.
“I skimmed the diff and it looked fine.” “The agent said it fixed the issue.” “The tests passed, so we’re good.”
None of that is enough. The goal is not to feel certain. The goal is to build a system that produces evidence.
The Two Failure Modes
There are two ways to mishandle the event horizon.
The first is blind delegation: treating agent output as trustworthy because it is fast, detailed, and confident. The diff looks professional. The explanation sounds plausible. The tests pass. So the work ships.
That is not engineering. That is outsourcing judgment to a stochastic system and hoping the blast radius is small.
It is not hypothetical. In a controlled study from Stanford, participants with an AI assistant wrote less secure code than those without one — and were more likely to believe their code was secure. The tool did not just introduce flaws. It introduced confidence about the flaws.
Senior engineers are not exempt, and the reason is worth naming. Expertise runs on pattern matching, and agents are trained on oceans of human code — so their output looks exactly like the patterns an expert expects to see. The code is syntactically beautiful and structurally suspect, and it sails straight past the visual heuristics that normally catch junk. Automation bias — our documented tendency to trust automated output even when it is wrong — does not politely route around seniority. In unfamiliar territory it gets worse, because the expert is accustomed to being right.
The second failure mode is total reversion: deciding that because you cannot personally understand every generated detail, the workflow is illegitimate, and restricting the agent to trivial tasks.
That reaction is understandable. It is also not sustainable. The leverage is too high and the economic pressure too strong — when METR tried to run a follow-up study, a third to half of its developers refused to do the work without AI at all. Some domains will and should move slower; safety-critical and heavily regulated systems will keep humans deeper in the loop. But that is a posture, not a reversion.
So the practical question is not whether engineers cross the event horizon. They will. The question is whether they cross it with rails.
What Replaces Total Comprehension
The replacement for total comprehension is not trust. It is deterministic operating discipline.
Your job is to build a workflow where the agent is never the source of truth. It can propose, implement, explain, and review. It does not get to define correctness by sounding confident. Correctness has to live somewhere else.
It lives in contracts. It lives in tests. It lives in invariants. It lives in small diffs, reviewable scopes, and rollback paths. It lives in logs, metrics, and traces — the boring machinery that makes software engineering software engineering.
This matters more, not less, as the tools improve. Addy Osmani calls it the “70% problem”: AI gets you most of the way to a working solution astonishingly fast, but the last stretch — edge cases, integration, security, failure modes — is exactly as hard as it ever was, and now you did not write the first 70% yourself. By early 2026 he had revised the framing to the “80% problem,” and the residue had a name: comprehension debt— the liability you take on every time you accept code you did not fully understand.
This is why determinism becomes emotional infrastructure. It is not just a technical preference; it is what gives you something solid to stand on when the workflow moves faster than intuition. A deterministic test suite, a stable contract, a reproducible build, a clear rollback path, a small reviewable task, a hard stop hook — these are not bureaucratic artifacts. They are the rails that make agentic development psychologically survivable.
The New Expert
The old expert tried to keep the whole system in their head. The new expert knows which parts must be in their head and which must be locked down by process.
Agentic orchestration does not reward ignorance; it punishes shallow understanding. If you do not understand architecture, failure modes, testing strategy, deployment risk, and system boundaries, agents will not make you a better engineer. They will make you a faster source of production incidents.
The agent can generate code. It cannot own the consequences. That remains your job. The new expert defines the operating frame: What is the goal? What is out of scope? What must not change? What assumptions need to be stated before work begins? What tests must fail before they pass? What invariants must hold? What commands prove the work? What review gates are required? What is the rollback path, and where could this break in production?
This is not a downgrade from engineering. It is engineering at a higher level of abstraction. But it only works if you accept the new responsibility instead of pretending the agent is a faster junior developer.
That metaphor breaks fast. A junior learns, carries context, develops judgment, and can be mentored into ownership. An agent owns nothing. It does not care about the business, does not remember consequences the way a person does, does not feel the pain of a bad deploy.
So the orchestrator must be stricter than they would be with a person.
Not meaner. Stricter.
Practical Rules for Success
The safest agentic workflows are not the ones with the most powerful models. They are the ones with the clearest boundaries.
Start with smaller tasks than the model can handle. Counterintuitive, since the point is leverage — but large tasks create large review surfaces, and large review surfaces create fog. The agent can modify twenty files. That does not mean you let it without a staged plan, checkpoints, and gates.
Separate research, planning, implementation, and review. Do not let the agent discover, decide, patch, and declare victory in one motion; that is how assumptions get laundered into code. Make it state what it found, propose the plan, and name the risk before implementation happens inside the approved boundary. Start new sessions in between each of these steps to expose hidden context.
Freeze contracts before implementation. If the API shape, data model, or acceptance criteria are still moving while the agent codes, you are inviting churn. Agents are very good at producing coherent local changes against unstable global intent. That is exactly how a codebase gets weird — and it is measurable. GitClear’s analysis of 211 million changed lines found that by 2024, changed lines associated with refactoring had fallen from roughly a quarter of all changes to under 10%, while copy-pasted code surpassed reused, “moved” code for the first time on record. The machine will happily write the same thing twice. Left ungoverned, it will.
Require tests that prove the bug or behavior. A passing test you never saw fail is barely evidence. The agent should demonstrate the failure, patch it, and demonstrate the fix — otherwise you are only proving the suite still does what it already did.
Treat “I don’t understand this” as a stop signal. Not a personal failure. A signal. If the diff is too large to review, shrink the scope. If the explanation is too abstract, demand specifics. If the agent changed something outside the request, investigate before continuing.
Do not let speed erase provenance. You need to know why a change exists, which requirement it maps to, and what evidence supports it. Generate artifacts fast, but tie them back to intent — or you are building a pile of plausible changes instead of a system.
Keep rollback boring — and verify it is real. Feature flags, reversible migrations, small PRs, clean commits. But beware the reversibility illusion: agentic changes can look reversible without being so. A `git revert` undoes code; it does not un-mutate data, undo a destructive migration, or repair schema drift. If the agent touched state, you need genuine backward compatibility — expand-then-contract, not faith.
Make the pull request the boundary. Most of these rules converge on one place. The PR is where the event horizon is managed day to day — the last point where a human decides what crosses into the system of record. When an agent emits a twelve-file diff in a minute, the PR is where that displacement lands, so instrument it. Watch the signals that reveal whether the agent is accelerating delivery or merely inflating it: diff size, review latency, how often a change is reworked or reverted within days, and change-failure rate. These are the delivery metrics DORA has tracked for a decade, and they are your observable outcomes — the line between “the agent shipped a lot” and “the agent shipped well.” A burst of throughput that quietly raises your change-failure rate is not speed. It is debt with good marketing.
Determinism Is Not Optional
There is a temptation to treat determinism as a luxury you add later, once the prototype is real. That is backwards. The less directly you control the implementation, the more deterministic the surrounding system has to be.
It helps to be precise about what can and cannot be made deterministic. Martin Fowler argues that LLMs are a genuinely new kind of abstraction, and the novelty is not only that they sit higher up the stack: “We’re not just moving up the abstraction levels,” he writes, “we’re moving sideways into non-determinism at the same time.” You cannot store a prompt in version control and know it will behave identically tomorrow.
That is the uncomfortable core of the shift. The generative layer is non-deterministic by nature; you will not fix that by wishing. So you do the next best thing: wrap a non-deterministic core in a deterministic shell. Fowler suggests borrowing a habit from older engineering disciplines and thinking in terms of tolerances — not “will this produce the exact same output,” but “is the output inside a boundary I can specify, verify, and accept.”
That is what the boring machinery is for. If file ordering matters, sort it. If generated output matters, snapshot it. If a schema matters, validate it. If a migration matters, test it forward and backward. If a command matters, run it in CI. If a review matters, make the criteria explicit. If an agent may touch code, define what it may not touch.
This is the discipline that keeps agentic work from becoming mystical. The moment a team starts saying “the agent usually handles that,” the process is already degrading.
The answer is not to trust the agent. The answer is to trust the process that constrains the agent.
The Sanity Problem Is a Systems Problem
A lot of the anxiety around agentic development gets framed as individual discomfort. “Engineers are afraid of change.” “AI is just another tool.” There is some truth there, but it is incomplete. The sanity problem is not only emotional. It is structural.
If the workflow produces diffs too large to review, people feel overwhelmed. If agents make unstated assumptions, people feel suspicious. If tests are weak, people overcompensate with manual review. If CI is flaky, people lose trust. If scope is vague, people argue with the output instead of evaluating it. If leadership rewards speed without evidence, people either burn out or ship unsafe work. You cannot motivational-speech your way out of a broken control loop.
DORA’s research points the same direction, and the year-over-year story is instructive. Its 2024 analysis estimated that a 25% increase in AI adoption was associated with a 1.5% drop in delivery throughput and a 7.2% drop in delivery stability — largely because batch sizes grew faster than the discipline to manage them. By 2025 the throughput picture had reversed: AI adoption now correlates with faster delivery. But the instability did not go away — AI still correlates with more change failures and rework. The teams got quicker; their systems did not get safer at the same pace. DORA’s own conclusion was blunt: AI is an amplifier. It magnifies the strengths of disciplined organizations and the dysfunctions of struggling ones. It does not supply the discipline. It assumes it.
If you want engineers to stay calm while using agents, give them a workflow that deserves calm: clear boundaries, repeatable checks, small review units, explicit approvals, known rollback paths. No mystery-meat automation. No “just trust the model” culture. The psychological safety comes from the technical safety.
What Remains Human
The human role does not disappear past the event horizon. It sharpens.
Humans decide what matters. Humans hold business context, define acceptable risk, and notice when a solution is technically correct but strategically wrong. Humans decide when not to build, and understand the cost of maintenance and the difference between a clever patch and a durable system.
Agents are powerful inside a frame. Humans are responsible for the frame. That is the operating model.
The engineer of the future is not valuable for out-typing a model; that contest is over. They are valuable because they can impose judgment on a system that generates options faster than any person can evaluate casually. That takes taste, skepticism, systems thinking, and the discipline to say no to impressive output that does not satisfy the contract. It takes the maturity to say, “I do not fully understand this yet, so it does not move forward.”
That sentence may become one of the most important engineering skills of the agentic era. Writing in Fowler’s Exploring Gen AI series, Birgitta Böckeler titled one field note simply: “I still care about the code.” The instinct to look, to actually read the thing, to refuse to let provenance evaporate — that is not nostalgia. Past the event horizon, it is a discipline.
Beyond Omniscience
The old model of expertise had a comforting illusion at its center: if I am good enough, I can understand everything that matters. In small systems, that was sometimes true. In modern systems it was already questionable. With agentic development, it is impossible to pretend.
The code will not always fit in your head. The workflow will not always feel natural. The agent will sometimes move faster than your ability to process the change. That does not mean you have failed. It means the job has changed.
The goal is not to recover omniscience. The goal is to build reliable systems of delegation, verification, and recovery.
Past the event horizon, discipline matters more than confidence, evidence matters more than vibes, and engineering judgment matters more — not less — because the tools are now powerful enough to do serious damage at serious speed.
The future expert is not the person who controls every keystroke. The future expert is the person who can safely orchestrate systems they do not fully author by hand.
That is not the end of engineering. That is where engineering judgment becomes unavoidable.
References
- METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. July 2025. metr.org: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ · arXiv:2507.09089: https://arxiv.org/abs/2507.09089
- METR. We Are Changing Our Developer Productivity Experiment Design. Feb 2026. metr.org: https://metr.org/blog/2026-02-24-uplift-update/
- Perry, N., Srivastava, M., Kumar, D., & Boneh, D. Do Users Write More Insecure Code with AI Assistants? ACM CCS, 2023. doi:10.1145/3576915.3623157: https://dl.acm.org/doi/10.1145/3576915.3623157 · arXiv:2211.03622: https://arxiv.org/abs/2211.03622
- Goddard, K., Roudsari, A., & Wyatt, J. C. Automation Bias: A Systematic Review of Frequency, Effect Mediators, and Mitigators. JAMIA, 2012;19(1):121–127. PubMed: 21685142: https://pubmed.ncbi.nlm.nih.gov/21685142/
- GitClear. AI Copilot Code Quality (211M changed lines, 2020–2024). 2025. gitclear.com: https://www.gitclear.com/ai_assistant_code_quality_2025_research
- Osmani, A. The 70% Problem: Hard Truths About AI-Assisted Coding. 2024. addyo.substack.com: https://addyo.substack.com/p/the-70-problem-hard-truths-about
- Osmani, A. The 80% Problem in Agentic Coding. 2026. addyo.substack.com: https://addyo.substack.com/p/the-80-problem-in-agentic-coding
- Fowler, M. LLMs Bring a New Nature of Abstraction. 2025. martinfowler.com: https://martinfowler.com/articles/2025-nature-abstraction.html
- The New Stack. Martin Fowler on Preparing for AI’s Nondeterministic Computing. 2025. thenewstack.io: https://thenewstack.io/martin-fowler-on-preparing-for-ais-nondeterministic-computing/
- Böckeler, B. I Still Care About the Code (Exploring Gen AI). martinfowler.com: https://martinfowler.com/articles/exploring-gen-ai/i-still-care-about-the-code.html
- Anthropic. Building Effective Agents. 2024. anthropic.com: https://www.anthropic.com/research/building-effective-agents
- DORA / Google Cloud. The Impact of Generative AI in Software Development. 2024. dora.dev: https://dora.dev/ai/gen-ai-report/
- DORA / Google Cloud. State of AI-assisted Software Development. 2025. dora.dev: https://dora.dev/research/2025/dora-report/
Further Reading & Background
This essay is part of an ongoing series on agentic software engineering:
The Future of Software Engineering: Supercolonies
https://medium.com/@pete.palles/the-future-of-software-engineering-51de53d2e45a
The Renaissance Engineers
https://levelup.gitconnected.com/the-renaissance-engineers-e3c1efa15572
The Rise & Concentration of the Humans-In-The-Loop (HITL) Class
https://levelup.gitconnected.com/the-rise-concentration-of-the-humans-in-the-loop-hitl-class-bce21ae37b0f
From Puppeteer to Conductor
https://medium.com/@pete.palles/from-puppeteer-to-conductor-520c8f18e37f
Navigating the Event Horizon was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Pete Palles
Pete Palles | Sciencx (2026-06-08T04:15:48+00:00) Navigating the Event Horizon. Retrieved from https://www.scien.cx/2026/06/08/navigating-the-event-horizon/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.