What happens to engineering when code generation stops being the scarce resource and trusting an agent becomes an architectural problem. An analytical reading of one panel discussion with infrastructure and SRE leaders.
The panel's central thesis is not that agents write code. It is that code has ceased to be the bottleneck — and the bottleneck has become the decisions that surround the code: architecture, access policy, service ownership, the quality bar, and the organisation's capacity to absorb volume.
Within a year, the sign of trust in machine-generated infrastructure has flipped. A year ago, generated IaC had to be rewritten by hand, and this was considered a waste of time; after the Opus 4/5 generation, the output became reliable enough to accept, and hand-writing infrastructure code has effectively disappeared from practice. This is not a gradual improvement but a change of regime: the engineer stopped being the executor of changes and became their arbiter.
The second thesis: the one area where agents remain predictably weak is architecture. They generate plausibly sounding designs, but not good architecture, because architecture requires accumulated context about how a system degrades, not about how it looks on a diagram. What follows is a redistribution of value: the ability to hold a system in one's head is worth more than the ability to write code.
The third thesis is economic. The threshold for what even counts as a project has collapsed: an idea is tested during the meeting, not after it. But at the same time the bar for what counts as a product has risen: if an artefact can be built in a day, it has no durable value for the customer. The company gets cheap production and expensive discernment — and discernment is precisely what becomes scarce.
The fourth thesis is about control. All three internal products discussed on the panel solve one problem: making a mistake structurally impossible rather than forbidden by instruction. Atlas removes the possibility of accidentally exposing an internal application to the internet. Airlock moves permission checking out of the agent's non-deterministic runtime into an external governor. Review Hub automates exactly those classes of change where the cost of error is low, and leaves a human where the change is irreversible.
The fifth thesis is organisational. "Everyone writes code" stopped being a slogan and became an expectation: AI field engineers embed in non-technical teams, once a month the whole company builds something on Claude Days, recruiting builds on top of a purchased ATS, and finance turns QuickBooks statements and a board deck into an application. This is not about teaching programming but about removing the "non-builder" role.
Production gets cheaper → volume grows → average quality falls → discernment gets more expensive → control shifts from process into architecture and policy → architecture and policy remain human. The whole discussion fits into this chain, and almost every individual storyline is an illustration of it.
The starting point of the discussion is not today's state but the contrast with the state a year ago. Back then, an attempt to hand an agent the generation of infrastructure code ended with the result being rewritten by hand anyway; there was no gain, and the practice was seen as a waste of time.
The break came with the Opus 4/5 generation — the transcript gives the version approximately, so the exact model number cannot be pinned down. What matters is not the version but that a threshold of trust was crossed: the output began to be accepted without full manual rework.
The consequence was stated plainly on the panel: today nobody writes infrastructure code by hand. This does not mean nobody reads it — it means authorship has shifted while the human remains in the position of acceptance.
The second half of the effect is a change in the object of concern. Previously the engineer's attention was concentrated on details: the correctness of each resource, each parameter, each link. Now the details are largely closed off by the generator, and the anxiety moves up a level — to architecture, to how the system will behave under load and under failure.
The panel does not claim that the quality of infrastructure code has risen to perfection. The claim is weaker and more important: the output is good enough to stop rewriting it wholesale, and the residual risk moves into review and into consequences rather than into the text itself.
While code was scarce, engineering culture was built around its production: typing speed, knowledge of syntax, the ability to hold a large volume in one's head. When production stops being scarce, that entire culture loses its load-bearing function — and organisations have to redefine what exactly they value in an engineer.
The panel returns twice to the same limitation: agents can propose a design, but they cannot be accountable for architecture. The phrasing from the stage is "they can come up with a beautifully sounding design", and that is an exact description of the problem. Plausibility and correctness diverge more sharply in architecture than in code.
The reason lies in the nature of architectural knowledge. Code is verifiable: it either builds and runs or it does not. Architecture is verified over years of operation — through degradation, through the cost of change, through which failures become possible. The model is trained on descriptions of systems at the moment of their presentation, not on the history of their slow decay.
That is why the architectural decision stays with people who have experience — not because an agent cannot handle a blueprint, but because the cost of error is distributed over time and invisible at the moment of generation. This is the only domain where the feedback loop is measured in quarters.
The organisational consequence: if architecture is the bottleneck, it has to be explicitly produced. The panel mentions architectural review and spec-driven development as mechanisms that keep the understanding of the system with people rather than with models. Without such a mechanism, architectural knowledge gradually becomes unrecoverable.
An agent outperforms a human at generating options and lags at assessing consequences. It does not follow that the agent should be constrained — it follows that the human should be placed precisely at the assessment of consequences, not at the production of options.
The most mature use of agents in the discussion is not writing code but investigation. When a report comes in, the agent pulls logs, traces, feature flags, source code and architectural descriptions, then produces a coherent explanation of what is happening that you can talk to.
The key difference from earlier tools is not the automation of search but the change in the format of the result. Instead of a dashboard that must be interpreted, and instead of a set of charts between which one must mentally draw a connection, a conversation appears: you can ask "why this particular service", "what changed before it started", "which other dependencies are affected".
Conversationality matters more than it seems. An incident is a process of narrowing hypotheses, and an agent that holds the entire context lets the engineer test guesses faster than by manually switching between systems. The speed-up here is not in the speed of reading logs but in the cost of one verified hypothesis.
The second effect is levelling by experience. The panel specifically notes that the tool helps junior engineers especially: a person who has not seen a hundred incidents gets a structure of reasoning that previously only familiarity could provide.
Investigation is the task where the agent's non-determinism creates almost no risk: the cost of error is a wrong hypothesis, not a broken system. That is precisely why automation has gone furthest here.
Previously a "project" meant a level of importance at which work was worth discussing and had to be defended in prioritisation. A one-hour task was not a project — it was simply done. The boundary ran along cost: if the work required noticeable effort, it deserved a conversation.
Now the boundary has shifted almost to zero. An idea can be tested during the meeting: someone proposes — someone goes off "to hack on it for ten minutes" — by the end of the discussion there is a working prototype. The panel calls this a time-compression device, and the metaphor is accurate: what compresses is not the work but the delay between intent and feedback.
The consequence is not confined to product. The set of disciplines where this loop applies is widening: data analysis, security analysis, performance work, go-to-market. Wherever an answer used to require a separate person and a separate request, the answer can now be obtained at the same tempo at which the question arises.
This changes not the amount of work done but the amount of verified work. The organisation begins to allow itself wrong hypotheses because testing a hypothesis has stopped being expensive. That, not faster development, is the main economic shift.
Cheap production immediately creates a volume problem. In a company where the habit of shipping many products had been cultivated, the quantity of what was built quickly stopped being a signal of value and became an obstacle.
The answer was not to limit the tools but to raise the definition. The phrasing from the panel: if you can build this in a day, then it does not have the durable value that customers pay for. The bar moves from the fact of an artefact's existence to its longevity.
This is an organisationally hard decision because it contradicts immediate feedback. Every individual launch looks like progress; the sum of launches looks like dispersion of attention. The panel records exactly this transition: from rewarding quantity to filtering by lifespan.
| Criterion | The era of production scarcity | The era of discernment scarcity |
|---|---|---|
| What is scarce | The ability to build | The ability to understand what is worth building |
| Signal of value | The fact of a launch | Lifespan and retention |
| Risk | Not getting it done | Building a lot of unneeded things |
| The team's success metric | Volume shipped | Share of what was shipped that survived a year |
| Leadership's role | Removing blockers | Raising the bar and cutting |
When building costs almost nothing, the only scarce resource is the customer's attention and the team's attention. A company that does not raise the bar pays not in money but in dispersion: support, documentation, compatibility and commitments for dozens of artefacts that nobody asked for.
To the question of what remains a defensible advantage, the answer on the panel is unambiguous: infrastructure — the thing agents cannot yet reason about well enough. The reason is not the complexity of the code but the absence of data on how these systems are actually operated.
Product code is abundantly represented in training corpora: thousands of examples of applications, templates, tutorials. The operation of S3 or of a distributed database is almost absent from corpora — that knowledge lives in engineers' heads and in post-incident reviews that are never published.
Hence the practical rule: the closer a task is to scale and to system behaviour under failure, the less useful the model and the higher the value of the human. Infrastructure turns out to be both the last human domain and the last moat around the product.
This conclusion has two sides. Defensive: competitors will not be able to copy your operational maturity by generating it. Offensive: if you build a product that is itself infrastructure, your position is more durable than that of a product that is a presentation layer.
The SRE candidate profile has changed, and not cosmetically. Previously they looked for a T-shaped engineer: broad base plus depth in one area — networking, storage, compute. Coding remained a substantial requirement.
Now the requirement set has been rebuilt. Expertise in individual areas is still useful, but the skill of writing code has become noticeably less important. Two qualities move to the front: architectural judgement and the ability to absorb and filter information very quickly.
The second quality is underrated. The volume of text produced by models — descriptions, diffs, explanations, reports — exceeds a person's capacity to read it. Value shifts to the ability to discard the inessential quickly and retain the signal, not to the ability to process everything.
The panel frames this as a property that the agent amplifies: a person who learns fast gains a superpower with an agent; a person whose value lay in an accumulated stock of specific knowledge loses relative advantage. This is not about age and not about experience as such — it is about the type of accumulated knowledge.
A widespread claim holds that agents are destroying the entry level, because the routine work that juniors learned on is now done by models. The panel records the opposite experience: for junior engineers the moment turned out to be exceptionally favourable.
The mechanism is simple. Previously a junior lacked context and could not be useful in an incident; now the tool supplies a structure of reasoning and access to context that used to take years to accumulate. A smart person who learns quickly becomes relevant far earlier.
Hence the removal of the on-call barrier. The industry had a practice of allowing people onto on-call only after a certain tenure; now observation shows that relatively junior responders work with the tools very well, because they can simply ask what to do.
If an engineer's value was defined by a stock of knowledge, juniors lost. If value is defined by speed of learning and quality of judgement, then the absence of habits is an advantage: there is nothing to unlearn. That is why the narrative "there is no place for juniors here" is not borne out in practice.
Caution is appropriate here: this is an observation from one organisation, not industry statistics. But it points to an important asymmetry — barriers that looked like quality protection may have been compensation for a deficit of context rather than a requirement for maturity.
The starting point of the organisational changes was not a diffusion process but direct intervention. After getting to know the new models during the holidays it became obvious that the engineering part of the company was already using agents and the other departments were not.
The answer was to create a small team of AI field engineers, which was "injected" into go-to-market departments — where there was no technical expertise. The format is not a centralised platform but embedded people who build with the team rather than for it.
Then came the transition from exception to rule. The models made it possible to generate full applications in one pass, and it became clear that everyone should build, not a special group. The centralised function turned into infrastructure for distributed building.
This is an important distinction: the company did not try to teach everyone to program. It removed the "non-builder" role — the state in which a person knows what they need but has no path from that knowledge to a working artefact.
First — people embedded in teams (removing ignorance). Then — regular practice for everyone (removing fear). Then — a platform with security guarantees (removing risk). Only in that order does scaling not lead to chaos.
The mechanism that made the practice regular is one day a month when the whole company builds something. An engineer and a non-engineer work in a pair, and the non-engineer drives. That is the single detail that makes the format work.
When the engineer drives, it becomes a demonstration: the engineer quickly does everything themselves, the non-engineer watches and concludes that this is not for them. When the non-engineer drives, they are forced to master the interface, hit errors and gain their own experience of overcoming them. Experience, not observation, removes the barrier.
The format is durable: the practice continued after the platform appeared, and it is not tied to one model or environment — Claude Code, Cursor and other tools of the participant's choosing are mentioned. The institution sets the rhythm; the tools remain replaceable.
The internal phrasing is "everyone writes code" as an expectation rather than an initiative. The difference is fundamental: an initiative implies voluntary participation and quickly runs out of steam; an expectation implies that the absence of a built artefact is an anomaly requiring explanation.
A side effect, but a telling one, is recruiting. The team has a purchased ATS and keeps paying for it, but builds its own tools on top of it. This is not replacing the system but removing friction where the purchased solution does not fit the process.
The same pattern in finance: quarterly reports from QuickBooks together with the board deck were turned into an application that can be opened at any moment. The task is not analytics but removing the delay between question and answer — the same compression of the loop as in engineering.
The panel calls this the era of personal software. More precisely: software stops being a common good that must be fought for and becomes a personal tool that everyone assembles for their own task.
When employees started building, it turned out that deployment was a separate problem. Applications sprawled across a dozen services: some on a host, others on serverless platforms, others on random accounts. Every placement is a separate surface of risk.
Atlas appeared as the answer to this chaos: "a safe target for vibe coding", to which you point your application and it receives organisational security and access rights by default. The phrasing from the panel is that the application cannot accidentally be exposed to the internet.
The key difference from policy is modality. Policy says "you may not" and requires someone to watch for compliance. The platform makes it so that you cannot, because the corresponding operation does not exist in the interface.
This is the same principle as in Airlock, and the panel names it directly: remove the very possibility of doing something destructive rather than forbidding it by instruction. The design error here is not "too strict" but "too strict for one case and too lax for the rest".
Airlock is described as a layer between the agent and all of the company's systems — a coding agent, a GTM agent, any other. It intercepts tool calls and checks permissions, that is, it works as a governor, not as an MCP multiplexer.
The difference from a proxy is fundamental: policy can be written on top of routing. The framing of the task is "I want my agents to be able to do this only under such-and-such a condition or scenario", with the condition expressed in natural language and evaluated by a model.
The architectural meaning is externalisation. Security stops being a property of the agent's runtime, which is non-deterministic, and becomes a property of an external layer that is deterministic by construction. This allows the same policy to be applied to different agents and different environments.
The practical conclusion, stated directly: there is no need to trust either the harness or the model. The agent may be Claude Code, Cursor, another coding agent or something homegrown — the policy stays the same, because it lives outside the agent.
Not the "AI firewall". What is new is the idea of a single point of access definition for a fleet of heterogeneous agents. While there were two agents and they were manual, policy could be kept in one's head. When there are dozens of agents launched by different teams, the only workable model is an external governor with a shared graph of permissions.
The least trivial part of the architecture is splitting checks into two classes by the nature of the uncertainty. There are decisions that must always compute the same way: they are moved into a deterministic engine with a graph of permissions.
There are decisions that cannot be computed in advance, because before launch it is unknown which systems the agent will touch. The agent works this out as it goes, and this is exactly where a natural-language policy evaluated by a model applies.
The mechanics are described as negotiation. The agent states an intent ("I need access to this data to answer the question"), the governor evaluates it against policy and either lets it through or demands clarification. This is what is called intent-based access control.
The practical value is that policy becomes expressible. A rule like "allow reading customer data if the query is aggregated and contains no PII" is almost impossible to write as an ACL, but it is naturally stated as a condition and checked by a model.
| Class of check | Nature | Implementation | Example |
|---|---|---|---|
| Deterministic | The answer does not depend on the call context | Graph of permissions, fixed rules | The role has no access to the production DB |
| Probabilistic | The answer depends on intent and context | Natural-language policy + LLM | An aggregated query without PII is permissible |
| Mixed | The frame is deterministic, the edges are not | Both layers in sequence | Access to the table yes, to the email column no |
The weak point of the approach is admitted indirectly: the quality of the probabilistic layer depends on the quality of the model. On the panel this is reframed as an advantage — "it gets better as the models get better" — but a dependency remains a dependency.
The practical consequence of the architecture is indifference to the tool. The policy applies equally to Claude Code, Cursor, internal agents and anything else, because the check does not live inside them.
This answers a question that usually goes unanswered: how to ensure security when employees choose their own agents and teams assemble their own wrappers. The answer is not to standardise the agents but to standardise the point they pass through.
The second consequence is that trust is replaced by verification. The phrasing from the panel is direct: you do not need to trust the harness and you do not necessarily need to trust the model. This is not paranoia but an architectural position: any non-deterministic component can be replaced without revisiting the threat model.
"We couldn't break it" is the developers' claim about their own product, made on a public panel. It is informative as a signal of the team's confidence, but it is not the result of an independent audit. It should be treated as a hypothesis, not as proof.
Airlock began as an internal experiment, and the team was divided on whether the approach would work. This is a typical trajectory for infrastructure products: first internal pain, then a tool, then a public product — keeping the original scenario as the primary one.
A separate line of the discussion is work with frontier model labs on security tasks. The observation is stated strongly: the result surpasses the human one, and if the model points to a defect and the engineer objects, the truth is usually on the model's side.
The phrasing from the stage is harsher: [if you think this is a bug, you are wrong — the model is right, you just haven't understood it yet]. This is not worship of the model but a statement of fact: in the narrow task of finding a vulnerability it has more context than a human does in the allotted time.
But between this capability and reliable action in production there is a gap. The defects the model finds are application-level and local. Infrastructure changes are built differently: it broke here, the effect showed up there, and the fix is needed in a third place.
That is exactly why what is missing is not intelligence but infrastructure context. The agent sees the code and finds the error in it; it does not see how that error will propagate through dependencies and after how many days it will surface.
An application defect is local: it breaks a function and is rolled back with a release. An infrastructure defect is cascading: it changes the state of several systems and is not undone by rolling back one configuration. The same quality of detection yields different value depending on the topology of consequences.
The third control layer works at the entrance to the codebase. Review Hub is triggered by a mention in a pull request, conducts a review and can automatically approve changes of certain classes.
The boundary is drawn not by the size of the change or the type of file but by irreversibility. Migrations are an explicit example of what is not auto-approved; for them the system determines who should look and routes the reviewer.
Within the permitted class, routing by ownership applies. Some teams own certain parts of the system and must see changes in them; the system automatically assigns the right person rather than the first available one.
The second criterion, besides the formal rule, is understanding. Even if a change violates no written rule but touches, for example, the data ingestion pipeline, people must genuinely get to grips with it. Such changes are flagged as requiring human attention regardless of compliance with policy.
The rollout order is described as gradual: first a very limited set of change classes, then expansion. This is the opposite of the "switch on auto-approve for everything and see" approach — and that is precisely why the system did not lose trust in the first weeks.
The most precise answer to the question "won't automatic review make things worse" is arithmetic. Previously a pull request had one or several reviewers, and the author was not among them, because the author had already "forgotten" the code.
Now there are three reviewers. The first is the agent, which checks for catastrophic defects. The second is the author, who rereads the generated code because they did not write it by hand and have no illusion of remembering every line. The third is the human reviewer following the normal process.
The paradox is that the author has become the best reviewer precisely because they stopped being an author in the old sense. When a person wrote the code themselves, they skimmed past their own mistakes because they remembered the intent; reading someone else's (generated) text, they read the text, not their memory.
Coverage grew not because the agent replaced the human but because the blind spot of authorship disappeared. Formally there are more reviewers; informally, for the first time there is an independent view of every line.
It follows that the question "will the agent replace review" is posed incorrectly. What is being replaced is not the human but the function of "first pass over the diff", which the human already performed badly — because of fatigue, volume and a deficit of attention.
The division of competences is described precisely: the agent is strong at detecting catastrophic defects — things that obviously break the code on reading — and weak at judgements about the product.
Product judgement is framed as the question "did I build this feature so that it makes sense for users". That is a question about intent and context that is not in the diff. The agent sees the change but does not see who needs it and why it was chosen this way.
Therefore human review shifts from finding errors to assessing the intent. The engineer no longer spends time proofreading syntax and boundaries but answers questions that require knowledge of the product and the customer.
The second weakness named is the absence of a long-term perspective: the agent may take a decision that is optimal in the short horizon but destructive for the codebase a year out. This is not a bug of the model but a property of local optimisation.
| Review task | Agent | Human | Comment |
|---|---|---|---|
| Catastrophic defects | strong | weak on attention | The main area of automation |
| Product judgement | weak | strong | Requires knowledge of the customer and strategy |
| Long-term consequences | weak | strong | Local optimisation versus compounding |
| Style and consistency | strong | medium | Cheaply automated |
| Safety of changes | medium | strong | Depends on infrastructure context |
Separately named is the cultural component, which matters more than the technical one: whether you trust engineers not to ship meaningless features. The problem of the codebase in such organisations is not the quality of individual features but the quantity of the unnecessary.
The first and most frequent anti-pattern is recursive review. The AI reviewer comments on code generated by an AI author, the author replies, the reviewer comments again. The cycle does not converge, because both sides optimise not for the result but for the cessation of the argument.
The marker of this state is named directly: about ten rounds and a diff of ten thousand lines. This is not a sign of thoroughness but a sign that the change was not decomposed and nobody understands its boundaries.
The second anti-pattern is size. The practical rule mentioned on the panel is not to make a pull request larger than one or two thousand lines. The threshold is not absolute, but it separates a change that can be meaningfully reviewed from a change that can only be skimmed.
The third anti-pattern is review overload. People receive more code to check than they can meaningfully process, and review degenerates into a formality. AI helps here not by replacing the human but by taking the mechanical part of the load off the human.
In the "agent versus agent" cycle both sides confidently confirm each other. Formally the process has been followed; in fact, not one participant has taken responsibility for the meaning. This is the worst kind of review: expensive, looking thorough and checking nothing.
The answer to the previous problem is to move review one step earlier. Instead of checking the implementation, the specification is checked: the product document, the backend spec, the description of the desired behaviour.
After that the agent implements and verifies compliance with the specification itself. The human accepts not the code but the intent — and this is exactly the work they do better than a machine.
The logic is economic: the cost of review is proportional to the volume of the diff, while the cost of checking a specification is proportional to the volume of the intent. The first grows linearly with generation, the second does not. That is why moving review upstream is the only way to retain control as volume grows.
On the panel this is described as an area of active experimentation rather than established practice. The honest formulation: the direction is clear, the implementation is still being sought.
When non-technical employees gained the ability to build, a new class of contribution appeared: large pull requests dumped straight into the main codebase. The panel has an exact term for it — slop cannon.
The problem is not the quality of the code as such. The problem is the absence of ownership: the author will not be on call for this code, will not maintain it and will bear no consequences. Such a contribution shifts risk onto the team that accepts it.
The answer is to change the artefact at the entrance. Instead of a pull request they ask for an issue or a PRD: a description of the task and the desired behaviour. After that, engineering agents and engineers turn it into a change that someone understands and someone is accountable for.
This is not a ban on participation but a redefinition of the role. The non-technical employee remains the author of the intent and the customer, but does not become the author of a commit into the shared product — which protects both them and the team.
A personal tool and a shared product are different systems with different consequences. The "give me a PRD" policy draws exactly this boundary: in your own application do whatever you like; in the shared product — through a specification and an owner.
The panel's remark that engineering teams already have their own systems for turning a PRD into quality pull requests matters: the problem was not the non-technical people but the fact that they were bypassing the existing pipeline.
A question from the audience that turned out to be central: who owns the service in production. The answer is not technical but organisational — an agent cannot own, because ownership means responsibility, and responsibility requires a subject who can be called.
The practical test of ownership is stated bluntly: can the owner be paged, will they come to the war room. If the answer is "no", then there is no ownership, regardless of who wrote the code.
Hence a principle worth adopting before rather than after introducing agents: people must use agents but remain accountable. Automating execution does not abolish authorship of decisions.
The panel adds that the problem of a deficit of architectural understanding is real in engineering teams too. When code is generated, nobody walks the path of its creation, and therefore does not know where the boundaries run. This is a separate risk that review does not solve.
An observation that explains the distribution of automation: application incidents are handled easily because they roll back. You shipped code, something broke — you rolled back the release, and the system returned to a known state.
Infrastructure incidents are built differently. It broke in one place, the effect showed up in another, and the fix is needed in a third. The causal chain crosses system boundaries, and rolling back one change does not restore the state, because the changes have accumulated.
The phrasing from the panel: in security and operations almost all the problems a team encounters are infrastructure problems. Application ones are rare and trivial by comparison.
This is why infrastructure remains human: not because of the complexity of the code but because of the topology of consequences. This is precisely the class of task the agent performs worst — not because it cannot write a configuration but because it cannot hold the cascade.
An agent works well in systems with local consequences and badly in systems with cascading ones. Infrastructure is a system where any change may surface through two dependencies and after a day. This is exactly where autonomy is more dangerous than slowness.
A separate argument against trusting pre-production checks: staging is not a faithful copy of production and cannot be one. The order of magnitude is roughly a thousandth of the traffic, at best.
At such a scale neither concurrency, nor the distribution of requests, nor cache behaviour, nor rare states are reproduced. Staging checks that the system starts and that the basic scenarios work; it does not check that the system will hold.
The practical conclusion the panel draws is to build production so that it is robust by construction, and to test changes on a small share of real traffic rather than on a simulation. A canary release and feature flags turn out to be more honest than staging.
This changes the role of testing in an incident. If staging does not predict, then the only reliable source of knowledge about behaviour is production itself, observed gradually and with the possibility of instant rollback.
The historical model of operations is reactive: a metric turns red, a human looks, an incident is declared, work begins. The panel records the transition to a proactive model, where observation is led by the agent, not the human.
Deterministic practices are already available today: continuous deployment verification, canary rollouts, automatic rollback on metric deviation. This does not require intelligence — it requires policy and a willingness to trust automation with a reversible action.
The next level is observing user scenarios. After a release the agent walks the customer's key paths and checks that the change has not broken behaviour that is not reflected in technical metrics.
The top level is prediction. The panel treats it cautiously: today it is more a direction than a practice. But the intermediate step — automatic rollback on an observed deviation — is already real and does not require prediction.
There is a short exchange in the discussion worth highlighting: can the agent create an index in the database itself. The position "no, let it propose one" meets the objection — if the agent thinks it will be faster, why not let it do it and wake a human in the morning so they can drop it if they wish.
The argument for autonomy rests on an asymmetry: creating an index is a reversible operation with a limited radius. A mistake costs a few hours of degraded write performance, not data loss.
The argument against is that the schema of a knowledge base does not reduce to performance. An index changes the query plan, affects other queries, takes up space and interacts with migrations. This is exactly the class where consequences are distributed and not locally visible.
The panel does not reach consensus, and rightly so: the question is empirical. The answer depends on the maturity of observability and on how quickly degradation can be detected. Where rollback is automated, autonomy is reasonable; where it is not, it is not.
The argument "may an agent" is fruitless until a criterion is defined. There is one criterion: can the system detect degradation faster than it becomes expensive, and roll it back without a human. Everything else is a consequence.
The remark that databases always go down at night, and the joke about a company operating across time zones, point to a real motivation: agent autonomy is valuable primarily as a way of not waking people up. This is the economics of attention, not of technology.
The most theoretical part of the discussion concerns the nature of infrastructure abstractions. S3 is described as a product that in the developer's mind behaves like unlimited storage, although technically that is not the case.
A limit exists: at a sufficiently large volume the provider will call and say that more machines need to be provisioned. But the threshold is so high, and the probability of reaching it so low, that the abstraction works: in practice people treat S3 as infinity and never encounter its physics.
That is the goal of good infrastructure — to disappear. Not "to be understandable" but to cease to be an object of thought. A TypeScript developer does not think about memory management, although it is precisely what runs underneath.
The panel tests this with a question to the room: how many people know how memory management works. A handful of hands go up. Yet everything being built stands on that layer — and works, because the abstraction holds.
From this follows a non-obvious conclusion about the value of infrastructure work: it is measured not by how many people understand it but by how many people do not have to. Good infrastructure is invisible, and that is what makes it undervalued inside an organisation.
The definition of failure given on the panel is worth quoting in substance: infrastructure breaks when the abstraction leaks and the underlying primitives and their limits become visible.
This is more precise than the usual definition via availability. A system can be available and at the same time be in a state of leakage — when the developer has to think about things they should not have to think about: connection limits, batch size, retry timeouts.
The practical consequence for design: the quality of infrastructure is measured by how rarely it demands attention. Not by the number of nines but by the number of occasions when a developer is forced to descend a layer.
For AI agents this is critical. An agent works in terms of tools and has no model of the lower layer's physics. When the abstraction leaks, the agent does not notice — it keeps acting in high-level terms, and the consequences accumulate.
This is exactly why infrastructure remains human: the agent does not see the leak, because its interface with the system is the abstraction. A human with experience notices that the behaviour is "strange" before they understand why.
The next step is systems that notice degradation themselves and eliminate it themselves. The example from the panel is concrete: Postgres that sees queries are slow and adds the needed index.
The argument for inevitability is simple: previously this was impossible because products contained no intelligence. Now they do, and the need for a human as an intermediary between observed degradation and action disappears.
A more radical version is self-designing. The system notices that the load has changed and proposes not an index but a change of component: a different database, a different worker type, an additional service. That is already an architectural decision, not an operational one.
Here the panel diverges. One voice says the direction is inevitable if models keep improving. Another — that the most complex systems will remain human for a long time, because there is no training data about their operation.
| Level of autonomy | What the system does | Who decides | Maturity |
|---|---|---|---|
| Observation | Detects a deviation and explains it | The system | exists |
| Reversible action | Rollback, turning off a flag, redeploying | The system | exists |
| Optimisation | Creating an index, tuning parameters | Disputed | boundary |
| Redesign | Replacing a component, changing the topology | The human | does not exist |
The key argument against the upper levels is the absence of data. An enormous amount of text has been written about how to build a small product; almost nothing about how to operate S3 at scale. A model cannot learn what is not in the corpus.
One of the strongest theses of the discussion concerns not technology but beliefs. For a long time it was held that an early architectural decision is almost impossible to correct: rewriting is expensive, sometimes fatal, and the product compounds the accumulated compromises.
That calculation has changed. Rewriting has become possible — including in a different language. The cost of changing a fundamental decision has fallen so far that the habitual caution has turned into a brake.
Hence the formulation: the danger of a wrong early decision is greatly overrated, and the real currency is speed of learning. Not "getting it right the first time" but "gaining experience faster than the competitor".
This also changes the object of review. If code can be rewritten, then reviewing the code loses part of its meaning, while reviewing the design gains it. At a design review the question asked is not "is the architecture correct" but "why are we shipping this" and "who have we talked to about it".
When rewriting gets cheaper, what gets more expensive is not the error but the delay. An organisation that keeps acting on the logic of "measure seven times" pays not for risk but for missed learning.
Caution is needed in one place: where the decision is irreversible. This is exactly the same criterion as in the delegation matrix — and it also explains why migrations remain human.
Go-to-market turned out to be one of the first places where agents produced a measurable effect. The question "has anybody talked to this company" used to require going to the sales reps and collecting answers by hand. Now it is put to an internal agent.
The answer is built on primary data — recordings of calls, not reports. And this changes the quality of the answer: an agent that has read the transcript can say that a deal is possible, but that no budget was mentioned in the conversation.
The phrasing from the panel is deliberately provocative — agents lie less than sales does. The point is not to insult the profession but to point at a difference of motivations: sales is optimised for optimism, the agent for correspondence with the text.
The practical value lies in detecting the gap between promise and fact. The classic case: in the CRM the deal "closes this quarter", while in the call recording there is not a word about budget. The agent records this discrepancy without trying to smooth it over.
The agent reproduces what was said but does not assess what was understood. Conversations in which the customer politely dodges the answer read worse than direct refusals. The tool reduces the optimism of reports but does not replace judgement about the customer.
A more important observation concerns the distribution of attention. If agents write the code, then agents also choose the tools. When an agent decides which library or service to use, it does not read advertising and does not go to a conference.
The consequence is harsh: if you are not in the set the agent considers, you do not exist. This is not a metaphor but a description of a funnel in which the first stage is not passed by a human.
The panel compares this to SEO: being present where models form the answer becomes as mandatory as being present in search results. The difference is that optimisation for agents is a new discipline without established practices.
Hence requirements that did not exist before: machine-readable documentation, predictable APIs, examples that the model can reproduce. A product must not only be convenient for a human but unambiguously interpretable by a model.
The practical answer to the previous problem is described concretely: a specification by which an agent can not merely find the service but register and start using it. In the transcript it is named in garbled form ("you must go off dot MD"), so the exact file name cannot be reconstructed; the meaning is a contract document for agents.
The distinction between "find" and "start using" is fundamental. Discoverability solves the first task; the second requires the agent to have a path: obtain access, authenticate, make the first successful call without a human.
This changes the requirements on the product. If onboarding used to be designed for a human with patience, now it is designed for an agent without patience and without the ability to guess. Any ambiguity in the documentation turns into a refusal to use.
The strategic conclusion from the panel: the door for agents cannot be kept closed. Even if the core business remains human, the absence of a machine path means losing the entire upper segment of the funnel.
Documentation stops being marketing material and becomes an interface. Its reader is not a human assessing quality but an agent choosing what to call. Ambiguity here costs more than incompleteness.
The metaphor proposed on the panel deserves separate analysis: sales is an API for exchanging value between organisations. The product says what it does; the salesperson translates that into how the buyer's business will change.
The translation is necessary because value is contextual. The same product means different things in different companies: savings, speed, reduced risk, compliance. Without translation what remains is a list of features that decides nothing.
This work standardises poorly. The panel says directly: you cannot take a successful salesperson from one company and move them to another with the same result, because every buyer's interface is their own.
At the same time part of the work automates well — training and coaching salespeople. If the mentoring process can be moved into a system, it is cheaper than maintaining an army of people and more reproducible.
The panel agrees that people will persist longest in enterprise sales. The argument is not about the complexity of the product but about the nature of the deal: it is structured as a relationship between people.
A practical detail that illustrates this is the threshold above which the buyer wants to talk to a person. The figure given is roughly 30–40 thousand dollars a year: below it self-serve is normal, above it there is an expectation of personal contact.
The second argument is purchase as experience. Even with no cold outreach at all, people want someone to answer their questions and help with setup. This is not about selling but about reducing uncertainty in decision-making.
The third is the symmetry of roles. If agents choose the tools, the next step could be an exchange between agents in which no human participates at all. But the money is still moved by owners, and they prefer a conversation.
The agent chooses the tool, the human signs the contract. These two processes do not compete but are separated in time: the first determines whether you get on the shortlist, the second whether the deal closes. A loss at the first stage cannot be compensated at the second.
The final block of the discussion concerns the monetisation of open source now that agents have learned to reproduce enterprise functionality quickly. The question from the audience is framed precisely: if an enterprise can assemble the paid capabilities itself, what is it paying for.
The first answer is open-core with a narrow gate. What becomes paid is not convenience and not the volume of features, but what an enterprise cannot use the product without: access rights, multi-node deployments, certain advanced capabilities.
The key property of the gate is that it is small in volume and critical in function. It is not "half the product for money" but a small part whose absence makes use impossible. The panel emphasises precisely the compactness: usually it is a relatively small share of the codebase.
The second answer is an honest admission that the gate does not always work. If the capabilities are easily reproduced, then the product has perhaps not yet reached the value that people pay for. This is self-criticism, not a defence of the model.
An observation from their own practice: clients pay a licence fee formally for features, but in fact for round-the-clock support from the team that keeps the product working in their infrastructure.
This changes the nature of the business. What is sold is not the right to use the code but an obligation to operate it. The licence becomes insurance, not access.
A telling example from practice: debugging someone else's installation from a photograph of the screen, because security policy forbids screenshots. This describes exactly what an enterprise buys — not a feature but a person who will work out an awkward situation.
The modern form is BYOC: the client provides a cloud account, access is strictly limited, and the product is deployed in their infrastructure under the vendor's management. A compromise between "ours" and "yours" that removes the main risk for both sides.
If what is sold is support, then margin depends on the number of clients per engineer, not on the number of licences sold. That is exactly why open-core without strong support turns into charity, and with it into a services business with low leverage.
The further evolution is described directly: a significant part of revenue comes from the cloud model. At the same time self-hosting remains, but rather as a gesture of goodwill than as a monetisation channel.
The reason is simple: those who self-host often would not have paid in the first place. They are either companies with strict requirements, or organisations in jurisdictions where using foreign hosting is difficult, or extremely cost-conscious teams.
Hence a formulation that sounds harsh but is accurate: self-hosters are people who would not have paid anything. Their presence is not lost revenue but the cost of supporting the community.
| Model | Who pays | What they buy | Economics |
|---|---|---|---|
| Open source | Nobody | Adoption, trust, hiring | Marketing spend |
| Open-core licence | Enterprise | Features + 24/7 support | Services, low leverage |
| BYOC | Enterprises with requirements | The product in their own cloud under the vendor's management | Medium margin, high barrier |
| Cloud (SaaS) | Startups and mid-market | A ready service | The main revenue |
The strategic conclusion the panel draws: cloud turns out to be practically all the revenue, while open source performs the function of a funnel and a reputation. This inverts the familiar model in which open source was a way of monetising enterprise through licences.
One of the most useful facts in the discussion concerns the real cost of operations at large clients. An example is given: a company with a team of about fifteen people maintained a system that five engineers had built.
The 3:1 ratio in favour of operations is not an anomaly but a typical structure of large organisations. The reasons are organisational: separation of duties, compliance requirements, multiple approvals, absence of any incentive to optimise.
Hence an unexpected conclusion: enterprise does not try to do everything itself, contrary to a widespread belief. It tries to shift operations onto someone who will do it more cheaply and more reliably.
This also explains why managed services beat self-host even when the technical capability exists: it is not about technology but about operations being an organisationally expensive function.
The closing thesis of the block is framed as a supposition, and it should be preserved in that modality. If agents can quickly reproduce functionality, open source may cease to be a growth model.
The argument: the value of open code lay in the fact that it solved a problem you would otherwise have had to solve yourself. When the solution costs a few hours of an agent's work, ready-made code loses part of its advantage.
The counterweight is companies that moved from an open model to a closed one and grew. The panel mentions such a case without naming it unambiguously (the name is garbled in the transcript), and admits that the thesis is debatable.
The practical conclusion for a founder: open source cannot be taken as the obvious choice. The question "what exactly will people get from openness that they cannot do themselves" has become mandatory, and the answer to it much narrower.
Openness as a default marketing strategy. If the code is easily reproduced, openness does not create defensibility — it creates an obligation to support someone else's use without matching revenue.
The forecasts on the panel are cautious and concrete. The first is self-healing infrastructure: not full autonomy but the ability of a system to notice degradation and eliminate it without a human in the loop.
The second is migrations. The formulation: press a button and move to another cloud or change the language entirely. Migrations already happen every few months, and the cost keeps falling.
The third is self-improving products: the system observes how it is used, finds points of friction, makes changes and rolls them back on degradation. The panel notes that the first steps in this direction are already being taken, although the process remains heavy.
The fourth, and the most radical, is the size of companies. Mature companies of dozens of people, growing fast because the market adapts faster. This is not a forecast about unemployment but a forecast about structure.
The forecast about the structure of companies is built on an analogy with careers. Previously the path was sequential: school teaches you to write code, you arrive as an executor, you get tasks, then you become a manager who passes tasks on, then a director who sets direction.
The point of that ladder was the accumulation of context: to influence strategy you had to understand the business, and understanding came through execution. Each level added information the previous one did not have.
Now execution is delegated. A person receives an army of agents immediately, and the question shifts: not "how do I get to the level where decisions are made" but "what do I do with the ability to execute almost anything".
Hence the forecast: companies of dozens of people at the mature stage, where every employee has an executive function and not only their own speciality. The bottleneck is not production but judgement about what to produce.
What is freed up is not time but the throughput of intent. People who today are constrained by a lack of hands, capital or permission gain the ability to act. That, not headcount reduction, is named as the main effect.
A caveat worth preserving: this is the participants' forecast, not an observation. Nobody on the panel claims the transition has already happened; this is about the direction in which practice is moving.
The recommendations below are derived from the logic of the discussion and are not direct quotations. They are ordered by what must be done earlier so that later steps do not cost more.
The first action is not choosing a tool but inventorying operations by the criterion of reversibility. Infrastructure, schema migrations, rollouts, monitoring, everything that changes the state of data — a separate list with a human owner.
Everything else that rolls back in minutes can be given to an agent without dramatic consequences. Mixing these classes is the main source of incidents in the transition period.
If there are more than two agents and they are launched by different teams, policy must live in one place. Otherwise every team invents its own rules and audit becomes impossible.
The minimum architecture is an external layer through which all tool calls pass, with a single graph of permissions and a single log. Deterministic checks in code, probabilistic ones in policy.
Do not switch on auto-approve for everything. Choose categories with a low cost of error, limit the size of the change, set a ceiling, and expand as trust accumulates.
Separately, protect yourself against the loop: if the reviewer agent and the author agent have exchanged more than two or three times, the change must go back to a human. Ten rounds is not a sign of quality but a sign that the task has not been decomposed.
Review of code does not scale with generation. Review of intent does scale, because the volume of intent does not grow linearly with the volume of the diff.
A practical format: a short spec describing the behaviour, success criteria and boundaries; the agent implements and verifies; the human accepts the spec and the result of the check, not a line-by-line diff.
The prohibition "do not deploy to the outside" does not work with a hundred builders. What works is an environment where such an operation does not exist. The same with permissions: not "do not give the agent access to prod" but "the agent cannot have such access".
This is more expensive at the start and cheaper in operation: a policy requires supervision, a platform does not.
Cheap prototyping is useful only with a hard filter at the output. Define a criterion of enduring value — lifespan, retention, willingness to pay — and apply it to every launch.
Without this, the organisation trades speed of learning for a support debt: dozens of artefacts that must be maintained, documented and kept working.
If code has stopped being scarce, then what must be tested at interview is not the ability to write but the ability to understand a system and quickly discard the inessential. Architectural judgement becomes the primary skill, not a bonus.
Separately: do not close the door to juniors. The panel's observation is that tools narrow the context gap, not widen it.
Practice shows that the format "an engineer embeds in the team" works better than a centralised function. Regularity matters more than intensity: one day a month for the whole company gives more than a one-off intensive.
And essentially: in the pair, the non-engineer drives. Otherwise the format turns into a demonstration and does not remove the barrier.
Documentation by which an agent can register and make the first successful call without a human is as mandatory an artefact as a landing page. If an agent cannot start using it, you are not in consideration.
Check what exactly you gate: it must be small in volume, critical in function and hard to reproduce. And answer honestly what people pay for: the code, or the fact that someone is accountable for it working in someone else's infrastructure.
Autonomy by reversibility. Policy in one place. Review by specification. A platform instead of a prohibition. The product bar higher, the prototype threshold lower. People on judgement, not on typing text.
The source is an automatic transcript of a panel discussion, produced without proofreading. Company, product and people's names are garbled, some technical terms have been reconstructed from context, and some remain illegible in the transcript. Everything that could not be reconstructed unambiguously is marked in the text.
The passages discussing the names of internal tools, specifications for agents and the names of external services are especially unreliable. Where a term cannot be reconstructed, the wording "illegible in the transcript" is used instead of a guess.
The second limitation is the source of the claims about the products. Airlock, Atlas and Review Hub are described by their developers on a public panel. Statements of the kind "we couldn't break it", "the application cannot be published to the outside" and "this works very well" are self-reports, not the result of independent verification.
The third is the selectivity of the experience. All the observations relate to companies of a certain profile: infrastructure product development, relatively small teams, a culture of high autonomy. The conclusions cannot be transferred to regulated industries or large hierarchies without adjustment.
The fourth is the numbers. The quantitative estimates in the transcript are approximate by the participants' own wording ("roughly", "about", "or something like that"). The order of magnitude can be considered reliable; the exact values cannot.
The fifth is the genre. This is a panel discussion, not a study: there is no data here, no methodology and no verifiable metrics. The analytical value of the text lies in the coherence of the arguments and in the questions it allows one to ask, not in demonstrativeness.
Everything that describes the companies' practice is a reconstruction from spoken speech. Everything that describes principles (reversibility, externalisation of policy, the leakiness of abstractions) is durable engineering ideas that the panel merely illustrates. Verify the first; the second can be applied.