My counter is that technical intent, in the way he is describing it, only exists because we needed to translate human intent into machine language. You can still think deeply about problems without needed to formulate them as domain driven abstractions in code. You could mind map it, or journal about it, or put post-it notes all over the wall. Creating object oriented abstractions isn't magic.

There is, currently, a tension between memory, and context pressure on the coding agent. There have been multiple studies now that tools like codex and claude code get worst at coding as their context window fills up.

As you start adding skills, memory systems, plugins and then a large code base on top of it, I've personally seen the agent start to flounder pretty quickly.

We need a way for agents to pull adhoc memory as they are going along, in the same way we do, rather than trying to front load all the context they might need.

1) Reading the changes, as a human, is not easy, having a document with a bunch editing marks in it, especially at the rate AI can make edits to things, would be very hard to keep track of, atleast that's how I feel.

2) Since you are tracking the context change forever, as a project developed over time, wouldn't the size of the context grow over time, with no upper bound. Would this cause memory pressure issues once we are talking about a huge codebase and a huge Changedown context?

One thing I'm trying to understand from the docs. I have 100s of playwright based BDD tests in my projects, especially the ones that are purely AI written. How does this interface with my existing tests? Does it scan the repo or is it meant to have it's own stand alone folder?

Simple functions in small code bases, will probably work.

Once you get large code bases and more complex work, you'd have issues with the small LLM having the context it needs to actually solve the issue.