I see what Martin is saying here, but you could make that argument for moving up the abstraction layers at any point. Assembly to Python creates a lot of Intent & Cognitive debt by his definition, because you didn't think through how to manipulate the bits on the hardware, you just allowed the interpereter to do it.
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.
I've tried a bunch of these "memory" systems and they aren't there yet.
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.
I find a lot of these IDEs are simply not as useful as a CLI. When I'm running a full agentic workflow, I don't really need to see the contents of the files at all time, I'd actually say I often don't need to at all, because I can't really understand 10k lines of code per hour.
So most messaging apps rely on a phone number or centralized server to provide a means of making atleast the initial connection. In a purely P2P messaging system, how do I, as a user, find the other person I might want to talk to?
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?
You could certainly build that today, mario tennis had ai controlled virtual tennis players 20+ years ago. You would simply need to put two of them opposite each other and you could create this. It's just not very compelling to watch two video game npcs do things.
That doesn't seem terribly surprising, a human can quickly look through a grid of shirts to find one they like. ChatGPT would be guessing what they might want and the human would probably get a bad experience there with some regularity.