The diff-as-review point is the one I keep coming back to.

The cost of memory-as-files isn't writing them. It's that the agent will cheerfully claim it updated something and not actually do it, or write a one-line stub that satisfies the spec but loses the original signal. Without a verification layer, the vault accumulates plausible-looking entries that quietly drift from reality.

What ended up working for me was treating the agent's self-reported summary as a wish, not a fact. A separate process diffs the actual file system against the claimed changes and flags mismatches.

After a few cycles, the agent gets calibrated and stops claiming things that don't survive a file check. That has the side benefit of making the diff review itself much higher signal: most of what shows up is real.

The split I'd make early is per-agent instructions vs. cross-thread shared notes.

They sound like the same artifact, but “what this agent should always do” and “what sibling work just learned” age very differently. Mixing them means the wisdom gets stale together.

His name shows up everywhere in the Unix bibliography but I'll be honest — I've used A Quarter Century of Unix mostly as a lookup for specific stories rather than reading it cover-to-cover. For folks who read it as it came out: where would you point someone today who wants the full sweep? It's hard to tell from outside which of his books hold up as essential vs. which show their age.

Tangent, but: is anyone doing comparable oral-history work for the current LLM moment? It feels like a lot of it is going to survive only as scattered blog posts and conference talks, and I don't know who's playing the role Salus did for Unix.

I’d like to share my thoughts as someone who uses Python and Claude Code on a daily basis (I’ve been running a research codebase and trading bot for several months).

I generally agree with the comment that “architecture is the bottleneck,” but based on my own experience, I’d like to elaborate further.

I don’t think the issue lies in code generation capabilities. The code generated by LLMs is competent on its own; the real bottleneck is cross-cutting consistency, which I believe is the primary challenge for applications on the scale of Photoshop.

For example, when I had Claude perform the task of “adding a new order type” to my trading bot: -Implementation in the relevant file: 90% success on the first try -Compatibility fixes on the backtesting engine side: 60% success with no oversights -Cross-cutting concerns like logging, metrics, and notifications: 40% of these were missed

The missed parts pass both compilation and testing. I’ve experienced the most troublesome kind of failure: the code is broken in terms of specifications but cannot be detected mechanically.

Photoshop has an estimated tens of thousands of cross-cutting invariants. Every these tools must operate without conflict across all layer types, selection ranges, and color modes. However, reconciling all of this with a single LLM inference seems impossible with the current architecture.

In other words, the absence of a “vibecoded Photoshop” isn’t due to a superficial lack of capability in the LLM; rather, the current context window and attention mechanisms are structurally unsuited for maintaining global invariants. This may not be the kind of problem that can be solved simply by “scaling up.”

Conversely, the direction of “personalized bespoke small apps” pointed out by stevex has fewer cross-cutting invariants (since the functionality is localized) and aligns with areas where AI excels. My personal conclusion is that Photoshop and AI development are not competing; they are simply solving different problems.

Since these observations are based on Python-based projects, this cross-cutting failure pattern might be less pronounced in statically-checked languages like Java or Rust. I’d like to hear others’ observations on this.

The argument that Java is LLM-friendly because its specifications enforce these four factors makes sense, but conversely, other languages that satisfy these four criteria—such as TypeScript, Kotlin, and Rust—fall into the same category.

In my own Python code, after tightening up Pydantic + strict mypy + pytest, I’ve noticed a significant increase in Claude’s first-pass accuracy. I believe which conventions you adopt within a language is more important than the language itself.

Additionally, a pitfall specific to Java is that the training data still contains a large amount of Spring XML/AbstractBeanFactoryAware-style patterns from the old Java 7–8 era. To elicit modern Java 21+ idioms, you need to specify them explicitly in the prompt. Conversely, Python tends to produce the latest idioms by default.

I understand the OP’s intuition (that Java is being reevaluated due to improvements in infrastructure tools), but the essence lies in “language design that enforces LLM-friendly coding styles.” In that sense, my personal conclusion is that Java is one of the good fits.

Falco has been the canonical rule-based observer for k8s for years. Is Prempti reusing the Falco DSL or inventing a new one for the coding-agent context? The rule format ends up mattering more than the rules themselves — that part decides how usable rule-based becomes once it gets serious.