AI won’t function unless you give it a purpose (at least for now). Isn’t it crucial, then, that we define that purpose as specifically as possible?
Both AI and humans make mistakes. What they have in common is that review is necessary.
This is because Internet search has stopped working, and there is a possibility that it will also stop working for AI summaries in the future.
I feel that, due to SEO strategies, the link between search results and ads has become stronger, making it difficult to find the information I’m actually looking for.
I use multiple AI tools simultaneously, and I feel that Claude has gradually adopted a more explanatory tone following updates around March and July.
As for loss of context, it’s particularly problematic and can occur after just a few back-and-forth exchanges.
The user experience changes with every update for every AI tool, so I feel there are more downsides to sticking with the same one indefinitely.
Ultimately, the current copyright debates and the search for a boundary between “AI-generated” and “non-AI-generated” content are nothing more than a farce aimed at forcibly prolonging the life of *the vested interests (power structures) of an era when value lay in the “physical, manual labor of writing code”* into the AI era.
Essential creativity and intellectual value reside in “design (architecture and specification definitions),” and if the design is sound, the code is merely the inevitable, optimized result of that design.
As long as we remain fixated on indistinguishable boundaries or establish rules based on the futile self-reporting of “where humans made changes,” the law will continue to be completely left behind by the evolution of our times.
Railway had a similar reliability issue two weeks ago when an AI agent deleted a customer's production database via their API — no confirmation step, no environment scoping. Now this. Both incidents suggest the same pattern: infrastructure decisions made without thinking through failure modes, fixed reactively after damage is done.
The kill switch is another layer on top of the same pattern.
When my AI agent couldn't resolve a Git issue, it suggested deletion as the fix. I ran it. The repo was gone. The suggestion was statistically reasonable — deletion solves the immediate problem reliably. That's exactly why it gets proposed.
The PocketOS incident is the same structure, except the agent executed without asking. The difference is who pulled the trigger, not what was decided.
Now we're adding kill switches. But a kill switch is itself a deletion — of the agent's action. We're solving the problem of irreversible actions by adding another layer of control, which will eventually need its own layer.
This is what spagetti code remediation looks like too. Complexity accumulates, then gets deleted and rebuilt. The pattern repeats at every level.