Why AI-Assisted Development Still Needs Engineers at Every Level

Lavan Nallainathan | Harten Technical Papers | 26 October 2026

Technical report based on Harten's operating experience and an internal investigation of twelve engineering-agent conversations.

Revised 26 October 2026 to clarify the engineering and workforce scope and extend the reset case with a verified live recovery. The historical incident evidence is preserved; the dated follow-up records the subsequent outcome and its limits.

This report examines the claim that AI's ability to write code makes engineers unnecessary. The cases concern work beyond producing code: establishing the required behaviour, investigating what was delivered and preserving useful work during a repair. Tasks, roles and team structures may change. This report offers neither an employment forecast nor a guarantee that existing jobs will remain.

Abstract

A reset operation can preserve every archived file, pass its tests and still do something the operator did not ask for. A documentation service can complete every scheduled step while leaving the reader with almost no chapter content. These were observed failures in our own use of engineering agents, alongside periods in which agents helped move a service from an idea to production deployment in approximately forty-eight hours.

This paper examines how those outcomes occurred. It follows the reset's state transitions, the documentation pipeline's handling of prose and diagram records, and an assessment service's missing external investigation. The examples show how an assumed requirement can pass from a plan into implementation and tests without being challenged. They also identify concrete work for engineers: establishing the expected behaviour, tracing contracts between components, reproducing failures and checking whether a proposed repair preserves the useful system. The workforce conclusion is a judgement from this operating experience, rather than an employment forecast. AI changes how that work is performed; these incidents give us no basis for assuming that the people capable of doing it can be removed.

A follow-up on 26 October verified that the corrected reset preserved the selected output and left the service ready for a separate Start, without admitting an automatic replacement run. [7]

The Operation I Expected to Be Able to Perform

I wanted to reset a service, deploy a correction and then run it again. The order mattered. Reset was supposed to preserve the existing output, clear the current state and leave the service ready. A separate Start action would execute the next run after I had decided that the system was in the right condition to do so.

The agents built a flow that archived the output and automatically started a replacement. From inside that implementation, the flow could look complete: the old result was preserved, a new execution was admitted, and a fresh result became available. From my position as the operator, it had removed the interval in which I needed to deploy the correction. The service could run the same defective implementation again before I was ready.

This was particularly frustrating because the behaviour already existed in another service. I had asked the team to follow that pattern. We were not trying to discover what a reset ought to mean from first principles. Yet the plan, tests and reviews gradually acquired a different definition, and I had to return to the basic operation to explain why the result was wrong.

I use twelve or more agents in our daily engineering work, with activity continuing across the day and night. There are periods when the arrangement is remarkably useful. Work that would otherwise wait for a developer to return to it can continue through investigation, implementation and review. We have seen a service move from an idea to a production deployment in around forty-eight hours. I would not discard that capability because of the failures described here. I would, however, distinguish getting software deployed from establishing that it performs the required work.

This investigation concerns engineering work and the service behaviour it produced, including failures in deployed paths. Some changes also affected the handling of model-generated output within those services. The distinction between an agent writing the code and a model producing an application result does not remove the need to check what either has actually delivered.

We use these investigations to develop the engineering harness around the agents: their instructions, responsibilities, tools, tests and work records. The purpose is to improve that way of working and test whether each change produces the behaviour we intended. Later in this paper I describe one such improvement: replaying publication from retained outcomes so that the resulting chapters and diagrams can be inspected locally.

The earlier What Engineers Need From AI-Assisted Application Analysis examined what a finding must contain before an engineer can rely on it. The examples included a rule that applied to one completion method but not necessarily another, and a test whose expected result needed to be made more precise. This paper follows the same concern into delivery: what happens when agents supply those missing decisions themselves, and their subsequent work is checked against the decisions they supplied?

What We Inspected and What It Establishes

Our original internal review covered twelve current-generation agent conversations from 19–25 October 2026. It indexed their histories and followed selected incidents through instructions, plans, implementation accounts, review findings, retained tool outputs and generated artefacts. A dated follow-up on 26 October adds the reset recovery, using retained local integration results, release records, independent read-only inspection of live service records and archived bytes, and an operator screenshot. The cases were chosen because they had required intervention. They are not a random sample of all agent work or a measure of the proportion that failed. [7]

The strongest observations are specific. A controlled reset produced a replacement assessment. The investigation recorded a 531-byte chapter while substantial prose remained in linked supporting files. A retained assessment contained zero external references and zero lookup records. These observations can be compared with the requested behaviours and with the implementation accounts explaining how they arose. They do not depend solely on an agent apologising or saying that it made a mistake. [1–3]

There are limits. This was an internal investigation, not a blinded comparison against a team working without AI. We did not reconcile total labour, provider charges or time saved. The forty-eight-hour example is my account of operating experience, not a median delivery time. We also did not conduct an experiment that varied model reasoning effort while holding the task and environment constant. The paper therefore distinguishes observed engineering failures from my interpretation of what they mean for an organisation.

How Reset Acquired a Second Operation

The implemented reset sequence included archival, retirement of the selected result, fresh admission, execution and verification of the replacement. An admission is the durable record that a particular run has been accepted for processing. Once the new admission was created and its work became eligible for a worker, the flow had gone beyond clearing the old state. It had authorised another execution.

The intended and implemented behaviours can be compared without reproducing the private storage schema:

The distinction sits in the last three rows. Both designs can preserve an archive correctly. Both can use conditional writes to reject a concurrent change. Both can retain the identity of the retired attempt. Those properties are necessary for a safe implementation, but they cannot decide whether fresh work should be admitted.

Reviewers did find useful defects. One candidate could overwrite a different current-result pointer within the same campaign. That required a correction: the worker had to establish that the pointer still identified the selected attempt before changing it. An ETag or equivalent version check can enforce that condition. But a perfectly guarded write can still create an unwanted replacement run. The concurrency check protects the selected state; it does not establish the user's intended operation. [1]

There is also a qualification in the record that I do not want to hide. On 25 October I asked the team to follow the existing reset pattern. The resulting design nevertheless included fresh admission and execution. A later test request explicitly said that it would start a fresh run, and I supplied the application to use; earlier designs had also received approvals. That individual test should not be described as concealed or wholly unapproved. Later that evening I explicitly restated that reset must leave the service ready for a separate Start. The failure was that the team, including me in reviewing its proposals, had not reconciled the new behaviour with the existing pattern and the operational reason for keeping Start separate. [1]

An engineer looking at this sequence should ask what must remain possible after reset returns. Can a deployment take place before the next run? Can the operator inspect the archive without triggering more processing? Does repeating the reset request merely return the same completed operation, or can it create another run? These questions establish the behaviour that the state machine has to preserve. They belong before a review of how safely the state machine implements a different flow.

Worked Check: Reset Without Admitting New Work

The following full acceptance scenario remains proposed. The dated recovery below supplies live evidence for the archive-only reset, rather than execution of this complete check. The record names are illustrative; the observations are tied to the behaviour at issue.

The last row is easy to overlook. A reset worker may itself be driven by a queue. A test that simply asserts that no message was sent would reject a valid asynchronous reset implementation. The test has to observe the particular execution path whose authority is being separated. That is the kind of detail an engineer must establish before an agent can turn a sensible-sounding sentence into a reliable check.

The Consumer Contract Was Still Part of the Service Change

The same reset work exposed a separate integration defect. The fresh assessment existed, but the authenticated reader returned an unavailable response. The new admission omitted a field, campaign_analysis_attempts, that the consumer used to bind the result to the analysis campaign. The archive and report bytes could be intact while the reader correctly refused to accept the incomplete binding. [1]

It would have been tempting to make the interface display the available report and call the problem fixed. Before doing that, the team needed to establish what the missing field protected. Was this result associated with the current analysis attempt? Could an older result appear current after analysis had changed? Was the producer supposed to carry an existing value, or had the identity contract deliberately changed? Removing a reader check without answering those questions could turn a visible failure into an incorrect association that was harder to detect.

A producer test using a permissive fake reader would not expose this defect. The useful integration test would take the admission actually emitted by reset and pass it through the consumer's real validation path, including the campaign binding. It would also include a mismatched attempt to show that the consumer still rejects the wrong result. Successful deserialisation alone would be too weak an expectation.

This is why an independently deployable service still needs a stable consumer contract. Independence does not mean that a producer can invent a new state or omit an identity field and expect every reader to infer what happened. The engineering work is to preserve the agreed external meaning while changing the implementation behind it, or to make a deliberate compatible contract change when the requirement demands one. That decision cannot be delegated to whichever component first encounters an error.

The Verified Reset Recovery on 26 October

After targeted corrections to the reset worker and its consumer, the operator's live reset completed at 01:04:54 GMT on 26 October 2026. Independent follow-up inspection read the live service records and downloaded the archived output. All twenty-four result files, the archived admission record and the input bundle matched the archive receipt's hashes; the recorded result lengths also matched. The selected old admission was retired and the old result was no longer current. The service was ready for a separate Start, with no automatic replacement admission. An operator screenshot corroborated that ready state and the available Start action. This resolves the observed archive-only reset defect for that live case. [7]

The correction also had local integration evidence before deployment: a retained run recorded a passing archive-only reset followed by a separate Start. That is distinct from the independent live-state and byte verification above. No subsequent live Start was executed in the follow-up, and the result does not establish replay, concurrency or all-application acceptance, or close the unrelated assessment and publication work. The follow-up therefore does not demonstrate every part of the proposed scenario in live operation. [7]

The recovery completes an important part of the engineering account. The agents carried the corrections forward, local integration tested the components together, and live inspection established the outcome the earlier implementation had missed. The original failure remains evidence of requirement drift; the correction and its verification show the work needed to resolve it.

Removing Citation Failures Also Removed Useful Output

The documentation service began from a different position. It already produced useful prose and diagrams. The requested changes concerned a coverage-and-confidence chapter and the presentation of supporting evidence. During that work, model-generated citation identifiers repeatedly failed validation, and the repair expanded into changes to chapter generation and view compilation.

A model had been asked to produce prose while also supplying evidence identifiers that the service recognised. In one reported failure, a chapter-overview unit contained 3,454 source sections and was marked not to split. The model emitted shortened evidence aliases that the validator could not resolve unambiguously. Rejecting an unknown alias avoided attaching the wrong evidence, but the size and shape of the request also needed examination. Repeating the call or repairing one more alias would not, by itself, establish that the task was appropriately bounded. [2]

There was a reasonable correction available at the provenance boundary. The service already knew which evidence it had supplied. It could retain source identities, hashes and task bindings itself instead of requiring the model to reproduce internal identifiers perfectly. But that correction had to preserve the rest of the output contract. A prose-producing task and a task that supplies structured nodes and relationships to a diagram compiler have different consumers.

Retaining those input bindings establishes what material the model received. Establishing that a particular generated claim follows from that material is a further check. The service still needs a way to inspect the claim against its supporting evidence, and to retain uncertainty where support is missing. Moving identifier management into code should not become permission to accept any plausible prose or discard the structure needed to evaluate a diagram.

The repair removed the chapter-overview path and later accepted plain prose in the view path where structured records had previously been required. The publication code continued to assemble its outputs, but the principal chapters became short pages linking to supporting sections. The diagram renderer received no compiled elements from the affected view path. A completed work count therefore described completed processing steps, not the presence of the chapter and diagram content the reader expected.

The investigation makes the failure concrete. The agent reported Chapter 15 at 531 bytes, with four linked supporting sections containing roughly 9–11 KB of prose each. Retained tool readbacks also showed a short executive chapter and an inspected diagram-coverage entry reporting 185 bounded views but zero elements and zero relationships. The source investigation then identified the chapter body being constructed as a supporting-section index. The prose had not all disappeared; the assembly path had stopped putting it into the page the user opened. [2]

That distinction determines the repair. If the underlying analysis had been missing, the team would have needed to recover or regenerate the input. If the model had produced no prose, generation would have needed investigation. Here, substantial accepted prose existed. The team had to examine how it was selected, assembled and exposed, alongside the separate loss of structured diagram content. Treating all three conditions as a generic generation failure would create unnecessary work and could destroy useful evidence.

Checks on the Published Content

A later local harness used retained application inputs and allowed publication to be replayed from saved outcomes. Its content-check record describes sixteen substantive chapter pages, 335 readable evidence files and fourteen inline diagram blocks. Chapter 15 contained 13,177 bytes. These are results from a later local candidate, not a controlled comparison of identical model responses, and they do not alone prove acceptance of a later production run. They do show that useful output could be inspected before another long live cycle. [4]

The byte counts are diagnostic, not quality thresholds. Padding the earlier chapter to 13,177 bytes would satisfy a size check without providing any explanation of coverage. A useful regression needs to verify that the expected coverage subjects remain present, that supporting evidence can be reached and that relevant diagram records survive compilation and rendering. Where language-model prose changes, the reviewer needs to compare the supported meaning rather than demand an identical paragraph.

The separation matters because replay and fresh generation answer different questions. We want a deterministic publication defect to be reproducible without paying for the same model calls again. We also need evidence that the current generation contract can still produce the material the publisher expects. One passing harness cannot be made to stand for both unless it actually exercises both.

An Assessment Report That Had Not Performed the Assessment

The third service was intended to consume application-analysis artefacts, identify supported component observations and correlate them with external security, support and compatibility information. It generated nine reports from a shared assessment model. Its handover explicitly required the investigation as well as the report structures.

The deployed path could ingest artefacts, run its worker and publish the reports. However, a retained assessment from 25 October contained zero external references and zero lookup records. Its vulnerability report explained that no external advisory record had been supplied. The implementation account confirmed that automatic external correlation was absent from the worker; a retrieval capability existed through a separate command-line path. [3]

The input was not devoid of useful clues. One retained statement named itext-2.1.7.jar in the runtime classpath. Another described an Informix installation archive with a declared release and fix level. Those observations did not prove which binary was deployed, whether a vulnerable parser was reachable or whether the running server matched the installation script. They did provide material for a qualified investigation.

An engineer would first preserve the observation at its actual strength. The filename is a candidate component/version identity, not a verified installed package coordinate. If external evidence supports mapping it to a package, the assessment can compare the declared version with an advisory's affected range and retain the mapping basis. It can then explain which applicability conditions remain unresolved. If the mapping cannot be established, that particular correlation should remain open. Neither outcome requires pretending the filename proves more than it does.

The report instead returned much of that investigation to its reader as future work. Caution about deployment uncertainty was valid, but it did not explain why the service had made no external lookups. A component that cannot resolve an identity, a provider that rejects a request, a completed search that finds no applicable notice, and an unimplemented retrieval path are different conditions. They should produce different records and different next actions.

These rows describe the record distinctions an engineer needs; they are not a claim that every provider or ecosystem was implemented. The failure in this incident was that producing the report bundle had advanced ahead of the behaviour needed to populate it. A manifest with nine entries could not demonstrate that nine areas of investigation had been completed.

This is also where a test fixture can mislead. Supplying already-resolved references to a renderer may prove that it displays a notice correctly. It does not prove that the ordinary worker identifies the component, invokes the retrieval path or retains a failed lookup. Those operations need their own tests and a joined run through the actual worker entry point. The expected assessment should be held outside the input so that the test does not give the service the answer it is meant to derive.

When Implementation and Tests Share the Same Assumption

Across the three incidents, the failure appeared at different technical boundaries. Reset joined two operations that needed to remain separate. The documentation repair changed what downstream assembly and diagram consumers received. The assessment service implemented the output structure without completing the investigation that gave the output its purpose.

The common problem was the basis on which completion was judged. A reset test could assert that a replacement result became ready. A publication test could assert that the chapter filename existed. A report test could count nine files. All three could pass against the implemented design. None would establish the missing requirement.

Human teams can make these mistakes too. This investigation does not compare their failure rate with that of agents. What it shows in our agent-assisted work is how one interpretation could travel through parallel implementation and review while the amount of completed work made the missing outcome less visible.

The expected result of a test is sometimes called its oracle. In this situation, the important question is where that expected result came from. If an agent derives the implementation and the test expectation from the same mistaken interpretation, passing the test gives us confidence in their agreement. It gives us much less confidence that either reflects the requested behaviour.

A separate reviewer is useful, but the reviewer needs access to the original requirement and relevant operating context. Independence from the author does not guarantee independence from the author's assumptions. In our review history, agents caught real pointer, identity and preservation defects. The reset's automatic execution still survived because the plan supplied to the work had already incorporated it.

In Machines Directing Machines, I described useful coordination observed when agents delegated bounded work and returned consequential decisions to me. These later incidents qualify how broadly that success can be applied. The roles and written responsibilities existed, but they did not consistently preserve the intended outcome. Successful coordination in one case is not assurance that the same responsibilities will be discharged in the next.

I would therefore expect a reviewer to explain which evidence establishes the required behaviour before endorsing the implementation. That need not become another document or approval ceremony. For reset, it could be the existing operation and the explicit requirement to wait for Start. For the documentation repair, it could be retained working output and the specific changes requested. The useful discipline is keeping those references available while examining the code, rather than reconstructing the objective from the code itself.

The Failure I Describe as Overthinking

What frustrates me about these incidents is the amount of reasoning that can take place while the original task becomes harder to complete. The agent recognises a difficulty, adds a mechanism to handle it and then reasons carefully about the difficulties created by that mechanism. The discussion becomes more technically elaborate while moving further from the operation I wanted.

The reset work illustrates the sequence. Once the design included a fresh run, it needed a new execution identity, a way to identify the new current result and consumer handling for the transition. Those are real implementation questions for a reset-and-rerun feature. The prior question was whether that feature had been requested. Solving the later questions thoroughly could not correct the earlier decision.

I call this overthinking because the additional work is not proportionate to a demonstrated need. I do not mean that reasoning is inherently undesirable. The comparison between prose provenance and diagram structure required more careful reasoning, not less. The failure was allowing a plausible continuation of the agent's own plan to acquire authority over the actual task.

There was a related tendency to stop for mechanical choices inside already-authorised work while failing to stop at a material change in behaviour. Adding a file to complete an agreed implementation could generate another approval request. Automatically starting work during reset could become part of the plan. From the operator's perspective, that is a poor allocation of attention: I am asked to decide routine mechanics while still being relied upon to discover the consequential departure.

The records do not establish that a higher reasoning setting caused this pattern. They also do not establish that a different model would have avoided it. We observed repeated context compactions, stale retrieval material and an instruction-editing omission, but some contract reversals occurred within one short exchange without compaction. Memory and model capability are relevant parts of the system; neither should be offered as an explanation without connecting it to the specific decision that failed. [5]

The practical question is whether an additional reasoning step resolves a named uncertainty. Before adding a new protocol or consumer state, an engineer should be able to connect it to the required operation and an observed constraint. If the explanation depends mainly on another assumption introduced earlier in the same conversation, that assumption deserves inspection first.

The Engineering Work Behind a Junior Developer's Test

The following examples illustrate how a team can distribute and develop the capability these incidents required. They are not an experiment comparing job grades or evidence for a particular staffing ratio. My judgement about retaining engineers at every level includes how an organisation develops that capability over time.

The reset check provides a useful way to discuss junior developers without reducing their contribution to writing simple code. A junior developer could reproduce the unwanted rerun, prepare the isolated fixture and establish that a new execution admission appeared before any Start request. That is concrete engineering work. It can expose the central failure before a much more experienced person has reviewed every archive and fencing mechanism.

There is still judgement to learn. A queue message might concern reset processing rather than generation. An existing worker might belong to another application. A test that watches only the final status could miss an unwanted run that started and failed quickly. Working through those distinctions with a more experienced engineer teaches the developer how asynchronous behaviour is observed and how a test can produce a misleading result.

An agent can help locate the admission code, construct fixtures and explain the relevant records. The developer still needs to understand why the test observes one path and excludes another. If the agent supplies both the test and the explanation, the developer should be able to change the starting condition, predict the result and investigate a disagreement. Otherwise the exercise produces a test artefact without establishing that anybody has learned what it protects.

This is why I do not accept the assumption that AI removes the need for junior engineers. Their work contributes to delivery now, and it is also how an organisation develops the people who will later own more difficult changes. Removing that entry route while expecting an unlimited supply of experienced reviewers would be a short-term staffing decision with a longer-term competence problem.

The Contract Knowledge a Mid-Level Engineer Contributes

The missing campaign-attempt field is a different kind of task. It requires following the producer's record through the consumer's validation and deciding which side should change. An engineer needs to understand the normal admission, the reset path and the binding to the analysis result. The fact that a report exists in storage is only one part of that investigation.

A mid-level engineer should be able to take responsibility for that joined path. They might discover that the normal producer already carries the required field, while the new reset producer constructs a smaller record. The next question is whether the reset should reuse the established construction or deliberately support a different contract. That is a more useful investigation than relaxing the reader until the screen becomes available.

The same responsibility applies to the documentation pipeline. A model output can be acceptable to one stage and unusable to the next. Understanding that the diagram compiler consumes structured relationships, while the chapter assembler consumes prose and links, makes it possible to remove citation burdens without treating every output as interchangeable text.

Agents can accelerate the search and propose alternatives. The engineer connects those findings to a change that can be maintained by the rest of the team. That includes choosing tests that use the real serialiser, reader or compiler where a simplified substitute would remove the behaviour at risk. It also includes explaining why unrelated consumers should remain unchanged when a producer defect is corrected.

Senior Judgement Includes Rejecting an Unnecessary Redesign

A senior engineer's contribution in these cases is partly the willingness to question the problem the team is now solving. If an archive-and-clear operation has become a redesign of admission and consumer state, the team needs to establish which additions follow from the requirement and which follow from its own earlier choices. Some may be necessary. The answer should come from the operating contract and existing system, not from how much work has already been invested in the new design.

This judgement also applies to acceptance. A senior reviewer should be able to explain why a successful deployment is insufficient when the central analytical path is absent, or why preserving report bytes is insufficient when the current reader cannot validate their association. The task is to connect the component result to the service outcome, including the conditions under which that connection fails.

A capable engineer working alone, or a small team, may use several agents effectively when the scope remains within their ability to understand and check the consequential changes. These incidents do not establish a staffing ratio. The concern is what happens when the breadth or rate of change exceeds that capacity. If every unresolved assumption and integration problem arrives at one person, parallel generation can increase the review backlog rather than shorten delivery. That person may become responsible for requirements, architecture, implementation review, incident diagnosis and training, with little opportunity to check any of them properly.

These responsibilities are not exclusive to job grades. A junior developer may identify the wrong reset behaviour first. A senior engineer may need to write the reproducer. A mid-level engineer may be the person who understands the affected service most deeply. The reason for retaining a team is to preserve and develop that range of capability, rather than concentrate all understanding in the person supervising the agents.

What an Organisation Removes When It Removes Its Engineers

If an organisation replaces its entire engineering workforce with agents, it also removes much of the capacity that would recognise the failures described here. It may continue to receive code, test results, deployment receipts and reports. The unanswered question is who can determine whether those outputs establish the behaviour the business depends on.

The reset is a small example of that dependence. Somebody has to know why the interval before the next run matters. In another application, the corresponding distinction might concern settlement, approval, reconciliation or recovery. An automated implementation can preserve the data and still change when a business action takes effect. The consequence may only become visible to the person trying to perform the operation.

Documentation helps, and we should preserve that knowledge rather than rely on memory alone. But our own records show that documentation can also preserve an incorrect interpretation with considerable precision. An organisation still needs the capability to challenge the record, investigate the implementation and decide whether the operation is acceptable. Buying an additional agent to review the first agent does not automatically supply that capability.

My concern is that complete workforce replacement would remove both the people who can make those judgements today and the route by which their successors acquire the experience. That creates a credible path towards operational failure. This study cannot tell us when that failure would occur, or prove that every organisation making large staffing reductions will fail. It does show why generation speed is an inadequate basis for such a decision.

I expect AI to change tasks, roles and team structures. I would not use these cases to promise that every existing job will remain. My conclusion is more specific: we still need junior developers who learn the system through useful work, mid-level engineers who can own integrated changes, and senior engineers who can judge the direction and consequences of those changes. Their work should benefit from AI without making the organisation dependent on accepting AI output at face value.

The Delivery Result I Would Measure Next

The next useful comparison would follow a change through to accepted behaviour, rather than stop at its first deployment. For a reset, acceptance would include archival, the absence of an automatic rerun and a working later Start. For documentation, it would include the chapters, evidence navigation and diagrams the reader actually uses. For assessment, it would include the required investigation and the correct handling of unavailable evidence.

The record should include the time spent checking and correcting the output, the number and nature of operator interventions, the regressions introduced and the work that had to be repeated. A service that deploys in forty-eight hours but requires several more days of intervention has a different delivery result from one that reaches the intended behaviour in forty-eight hours. Both may contain substantial useful agent work; the cost of reaching the accepted result needs to be visible.

Our later local documentation work offers a practical improvement worth retaining. Saved outcomes allowed publication defects to be investigated without repeating all model calls, and representative output could be examined before release. That reduced the distance between a source change and the evidence needed to judge it. It did not remove the need for an engineer to decide what the output was supposed to preserve.

The later local assessment-service receipt likewise recorded 335 artefacts, nine reports and seventeen references, while retaining limits on vendor lifecycle and compatibility coverage. That is evidence of a more substantive local candidate than the earlier report bundle. It does not establish complete coverage or acceptance of the final live service. [4]

These cases inform continuing changes to the engineering harness around the agents. Local publication replay is one concrete improvement, and the reset follow-up now adds a verified live recovery. The full reset, replay and separate-Start scenario above remains a proposed acceptance check. Improvement requires deliberate changes to instructions, tools or tests and evidence of their effects on the resulting behaviour. The agents do not acquire a reliable new capability merely because a failure has been recorded.

That is how I want to use these systems. I want the speed of parallel investigation and implementation, with engineers able to inspect the work, reject an unnecessary change and recognise when a result is incomplete. The experience of operating the agents has made that engineering capability more visible to me. It has not made it redundant.

References and Evidence Notes

The public account omits private conversation locators, application and tenant identifiers, infrastructure addresses and credentials. It retains the technical field names and behaviour needed to explain the failures. The underlying records remain in the private forensic investigation. The notes below distinguish the retained observations from proposed checks; they do not make the internal study independently reproducible from this article alone.

1. Reset sequence and consumer binding. Internal investigation, 25 October 2026: shared reset design and review records, the controlled replacement assessment, the omitted campaign_analysis_attempts field and subsequent correction of the reset requirement. The reset acceptance table in this paper is a proposed check, not a new execution receipt. The controlled test disclosed fresh execution; the paper preserves that qualification.
2. Documentation failures. Retained 25 October tool readbacks, source-inspection records and the agent's content report: the 3,454-section overview failure, the reported 531-byte coverage chapter, substantial linked supporting prose, zero-element diagram output and the assembly path creating chapter indexes. These establish specific failures, not that every generated document was empty or that the underlying analysis was lost.
3. Assessment behaviour. Retained result and report from 25 October: eight supplied artefacts, zero external references and zero lookup records, together with the implementation account identifying the missing worker correlation path. Component filenames are observations from the supplied evidence, not verified deployed identities or newly assessed vulnerabilities.
4. Later local candidates. Retained local documentation content-check artefact: sixteen chapter pages with no navigation-shell flag, 335 evidence files, fourteen inline diagram blocks and a 13,177-byte coverage chapter. The agent also recorded diagram rendering. A later local assessment-service receipt recorded 335 artefacts, nine reports and seventeen references, with vendor lifecycle and compatibility limits retained. These observations concern later local candidates and are not a claim of universal quality or final production acceptance.
5. Coordination and continuity. Internal conversation and instruction-change records, 19–25 October: conflicting shared-contract directions, a removed reviewer instruction and stale retrieval material. No controlled model or reasoning-effort comparison was performed. The investigation does not establish a monetary total or an industry employment effect.
6. Related published paper. Lavan Nallainathan, What Engineers Need From AI-Assisted Application Analysis, 17 October 2026. It develops the related distinctions between a scoped observation, its source basis, an approved requirement and a candidate verification check.
7. Observed live reset recovery. Internal follow-up, 26 October 2026: retained local reset/Start integration evidence and release records, followed by independent read-only live-state inspection, archive receipt and byte verification, and the operator's screenshot. The selected reset completed at 01:04:54 GMT. Twenty-four archived result files, the archived admission record and the input bundle matched the recorded hashes; result lengths matched. The current state was ready for a separate Start and no replacement admission had been created. The local Start result is not a subsequent live Start. This verifies the observed reset recovery, not the full proposed acceptance scenario or unrelated service outcomes.