luodaint

Agentic development transforms the scope of work. Once a session is committed to having one topic from the get-go — one move, one service, one abstraction — the diff generated from such a session is atomic by construction. Committing happens at the session level, and the commitment discipline problem solved by Jujutsu does not come into play.

It is also true in reverse. Scopes set too broadly ("dark mode implementation," "auth flow fixes") lead to un-readable diffs no matter what tool you use for version control. Un-readable diff does not stem from commitment discipline; it is a scope problem.

That said, this fact does not diminish the usefulness of Jujutsu. There are valid use cases for the rebase and stacking operations. However, the discussion about commit granularity takes on a whole new context once the constraint of having readable commits is established at the scope setting stage.

For organizations that make this an operational reality rather than a slogan, there is likely to be at least one individual for each product development cycle that has had recent contact with a customer. Not from reading a support transcript. From contact. That direct, uncensored communication is what the principle truly represents.

The recovery from being an orphaned customer account serves as the litmus test. In this case, it took someone who was unique and non-interchangeable and poked "the right bear" -- and it succeeded. But that's precisely the way that enshittification of the principle occurs.

Data from six months of production from one SaaS codebase provides a more limited response. Maintainability doesn't depend on the level of AI usage. Maintainability depends on the discipline during diff reviews. Good sessions: One topic per session; scope defined prior to the agent starting; all diffs read prior to committing. Poor sessions: Broad scope; undefined constraints; rubber-stamped results.

The quality of the codebase decays precisely at the rate you stop reading the results. This is not an issue of AI writing the code. This is an issue of unreviewed code. geohot's issue is entirely valid. This problem does exist. But this isn't dependent on the generation phase.

Not those carefully designed constraints that I set up from the beginning, but short-term ones that I came up with after an agent failed in some way: "Validate JWT at the route level, not the component." "Call workspace provisioning on each user creation." Both because of things the agent had done incorrectly.

Aspiration vs. consequence, in other words. An aspiration constraint describes a desired outcome for the system; a consequence constraint maps to a problem already encountered. And the agent ignores the former when faced with the path of least resistance while obeying the latter because it is brief, unambiguous, and precise about preventing that particular failure mode. Which is key rather than the harness in determining survival through session rotation.

Your extensions in VSCode have ambient access to your filesystem, your tokens, and your environment. The servers of tools like Claude Code or Cursor have that ambient access too. This was justified for Nx Console's purposes. This is justified in a coding agent's filesystem MCP. The exact same trust model: install it, it runs, you trust its scope implicitly.

What I ended up changing after contemplating this matter: all my MCP servers are scripts from my repository and not npm packages. All the information about the scopes these servers can use is contained explicitly in my context file (certain directories, certain tools). There's nothing untrusted reaching my filesystem/tokens.

There's the same supply chain problem in VSCode extensions as there is with the MCP servers. Very few companies that audit their extensions started auditing their MCP servers.

In any case, once the agent session finishes, the constraint file for the next session is written by the same individual. In this case, if the individual didn't read every output line by the agent, he will not know what to include in the new constraint file, leading the agent to make some wrong assumptions about the model, leading to some issues at a certain point in time, which, again, he cannot diagnose because his knowledge of the model is incorrect.

Diff reading is not a practice forced on developers from above. On the contrary, it is the only way for a developer to stay competent enough to lead the next session properly.

Instead of discussing how to ensure that developers will understand the importance of diff reading, the question here is whether the developers understand they cannot shift the responsibility of creating a mental model of the system away from themselves and still maintain effective control over the agent's behavior.

When it comes to the business logic of production use, this particular failure type is less obvious compared to benchmarking tasks. Benchmarking involves having the answer already known — it helps detect mismatches easily. Business logic pipeline does not. If LLM gives out a valid output that happens to be semantically incorrect, the pipeline goes through. There is no mistake to catch.

Created a dedupe pipeline where an LLM decides whether two feature requests are similar enough to merge. Occasional mistakes in terms of false positives — valid JSON structure, but incorrectly assessed similarity. In this case, it didn’t help to implement the retry technique. The solution was implementing a deterministic gate validating the output of the model based on its semantic similarity score calculated separately.

The reason why recovery works only with the help of additional tools when the error rate is at zero percent becomes clear: the LLM does not recognize the fact that it made a mistake. The guardrail becomes necessary for that — the retry is just one way of implementing the guardrail concept.

Benchmarks measure turn-level capabilities: you feed a task into the system and then grade the result. Capability for production-level usage concerns session-level decision making: does the agent know when to stop editing, retain the right amount of context, or go back and reread the file if the state has changed?

This is not a property of the model, but a property of the discipline; it can be operationalized by what you have documented before the session begins. Without "stop editing where you can no longer follow your changes to the spec" and "go back and read the migration file before changing the schema," there is nothing to halt the process until it fails integration.

Those teams who get consistent results independent of the model being used typically do so because they have operationalized their discipline first. Those switching out models monthly tend to expect the model to supply them.

If you don't know what exactly the user needs, the AI feature is the pitch itself. "Powered by AI" is something to say when you do not know how to sell the outcome. It's also something to develop when you have not set up the feedback loop to know which outcomes to optimize for.

If the signal is clear – if you have observed the same person facing the same problem in the same workflow – then the AI feature deserves its place in the product by automating one step that they hate. The outcome does not necessarily need to be AI-powered. The user simply stops facing that problem anymore.

The Gruber's logic works on the level of the whole product. But there is also a diagnostic implication here – the louder the product sells its AI capabilities, the less the team understands what exactly the product does.