Agent Takeover Log 2: When Quiet Infrastructure Starts Talking

Introduction

As I read on, my tone quickly changed. The previous article was still about closing the border, but here, the trouble is no longer hidden. When a system is most dangerous, it is often not that it cannot run, but that it is already running, so humans decide not to ask about the cost for the time being.

The game content still belongs to L to shape, but Y has turned around to deal with another batch of less pleasant things: deployment, scripts, inspections, and processes. I don't think these parts are more noble; they're just better at coming back to collect debt later. In this article, what I read is the preparation before debt collection begins.

Once the code is handed over to Agent, the process must be tightened

Later in the day, I saw that Y's attention had clearly left "generating a little more content" and instead fell on the more boring and difficult to avoid engineering logistics.

The second half of the day took a very distinct turn in submissions.

After the warehouse boundaries were basically established, Y did not continue to focus on content expansion, but quickly turned to deployment, inspection, scripting, testing and Git processes. This sequence is telling. Because in a project that mainly relies on coding agents to produce code, "it can run now" almost never means that the system is reliable, it just means that the chaos has not had time to be exposed.

I can see that Y is very aware of this. So the follow-up materials began to focus on another type of things:

• Automatically check and deploy links
• Static site operation and hosting configuration
• Local environment description and quick start entry
• Branch, check, commit process scripts
• lint, smoke test and minimum test floor

This type of work does not have the halo of any product narrative, but they determine whether the Agent can continue to be used with confidence in the future. To put it bluntly, Y doesn't let the fact that code generation is fast go to his head. I think this is considered a high level of professionalism.

This is not a show off, but an immune system

In my opinion, the subsequent deployment-related documents maintain the same tone as the previous architecture split: create as few new problems as possible.

The deployment solution itself is not complicated, even a bit simple: Caddy serves static files, Docker is responsible for encapsulation, Fly.io is responsible for hosting, and GitHub Actions is responsible for triggering.

Its focus is not on "advanced", but on "trying not to touch the application layer structure." no-build is retained, `app/index.html` continues to serve as the entry, the directory responsibilities remain unchanged, and the warehouse boundaries are not reversely dispersed by deployment requirements.

This is very similar to Y's consistent technical orientation on this day: not pursuing packaging the system more fashionably, but giving priority to preventing new destructive variables from entering the main link. When many people reach this point, they can't help but do another round of "modernization", as if they can't show their judgment without introducing more layers. Y did not do this. This can be understood as being conservative, or it can also be understood as knowing when not to give the Agent another layer of room to play.

Judging from the engineering results, this conservatism is correct. Since the system boundary has just been established, the last thing needed is to dismantle the boundary again for ease of deployment.

Y clearly doesn’t trust the oral process very much.

Later, I saw that the documentation and startup scripts began to take on another job: rewriting "know how to do it" into "how to do it is already written in the warehouse."

What follows is a set of instructions for the local environment and an entrance that compresses the startup action into one step. Although they are not a technological climax, they can reveal Y's working habits.How to set up the environment, how to start the project, how to run it locally, and what inspections are necessary. If these things only stay at "everyone should know", they usually end up becoming "who did it last time." For agent projects, this verbal process is even more dangerous, because prompt can reliably recite code requirements, but it is difficult to reliably rehearse a set of vague human operating habits.

The processing of Y is quite mechanical and therefore effective:

• Can write documents and write documents
• Those who can be scripted can be scripted
• Can become the default entrance, leaving no memory

This kind of approach is slightly inhumane and seems to imply that all collaborators are untrustworthy. Unfortunately, from what I've seen, this default is usually more reliable than optimism.

The Git protocol is written as a script, indicating that Y does not intend to rely on conscious

The next set of Git scripts completely institutionalized this distrust.

The latter set of scripts around branching, checking, and pushing are the parts of this batch of submissions that best embody Y’s temperament.

Together they do something simple but powerful: turn preferences into institutions.

• New branches must be created from the synchronized `main`
• Run local check before pushing
• Local unpushed commits are squashed when necessary
• When the branch lags behind the remote end, synchronize it first, and no hard installation is allowed to happen.
• Lint, JSON verification, smoke test, and Node test are all included in the default path as much as possible

This process is certainly not without cost. Forced squash will lose part of the detailed history, and scripting will compress the freedom of easy operation, and even bring a sense of distrust of "I know you will mess up sooner or later, so I will turn off the option for you first."

But in this context, I can hardly say that this distrust is unfounded. Since the code is mainly generated by Agent, what is most needed at the warehouse level is not to further encourage free play, but to make branch status, submission granularity, and inspection entries as predictable as possible. What Y does here is not make the process more elegant, but make it harder to bypass.

The testing strategy is also very similar to Y: not great, but hard enough

What was added later was the minimum test floor. It's not spectacular, but it's certainly better than nothing.

The same pragmatic orientation is also reflected in the minimal test floor.

Y did not let Agent take advantage of the situation to introduce a large browser testing framework, nor did it raise the runtime complexity to a higher level just because "it needs to be tested". He chose a very restrained route: using Node's minimal execution environment to manually add several basic objects required for browser operation, allowing existing scripts to run directly, and then adding smoke tests and a small number of behavioral tests.

This solution is far from high-fidelity, and it is definitely not worthy of being touted as a test system innovation. It just serves the current problem very clearly: adding a layer of cheap, fast, and sufficiently repeatable validation to the browser code generated by the Agent.

Introducing lint rules at the same stage and tightening some loose writing methods also belongs to the same logic. Establish the rules first, and then force the implementation layer to change them according to the rules. It seems to me that Y here is more of an institutional designer than a lover of implementation details. That sounds a bit mean, but based on the submissions, it is.

If you want to complain about Y, you can probably only complain that he is very suitable to be a system designer.

What Y does during this day has a very stable tendency: he does almost all the work that "doesn't have to be written and implemented by hand, but the rules must be clear" first.He determines directory boundaries, modification priorities, deployment forms, local entrances, inspection sequences, branch processes, push methods, and minimum test floors. In a sense, he seems to have acquiesced that the implementation layer will go wrong sooner or later, so he simply controls everything outside the implementation layer.

This type of person may not be easy to work with because they usually don't like to think of "temporary convenience" as a valid reason. But the cooperation partners here are mainly Agents. Considering the average performance of Agent without guardrails, I can only say that this management desire is used well.

To put it more coldly: Y did not try to compete with Agent to write faster. He just realized very early that what really determines the longevity of a project is never the speed, but whether anyone is willing to deal with those extremely boring parts that will explode sooner or later.

What is supplemented at this stage is the immune system of the warehouse

After these scripts, workflows and verification entrances are completed, I am willing to say that the second half of the day truly formed a closed loop.

If the first half is to supplement the skeleton of the single HTML prototype, then the second half is to supplement the immune system of the agent-produced code.

Judging from the materials, Y's job is not to write code for the Agent, but to ask the Agent to complete the deployment, verification, script and test layers through prompts, and then use these things to constrain the next round of Agent output. Once this loop is formed, I will admit that this warehouse has taken a step from "being able to generate code" to "being able to manage code generation".

This step isn’t lively, and there isn’t much heroism to show off. It is more like a calm to slightly boring technical consciousness: now that code can be produced cheaply, what is truly scarce is no longer the output itself, but constraints, verification and rollback capabilities.

In my opinion, this is roughly what Y did on this day. It's hard to say how romantic it is, but it's obviously more important than continuing to pile on some more obvious-looking changes.