After 15+ years mostly reading here, I’m going to start sharing what I build. I’m a software engineer focused on AI agents—especially context, memory, provenance and practical multi-agent workflows. Expect small experiments, code, and honest results.
This looks useful, but I’m not sure I always want ELI5.
I’d like the agent to explain something based on what it already knows about me: my background, what I already understand, and what I’ve been working on recently.
If I’m learning TypeScript after working with Java for years, it should use Java as the bridge instead of starting from basic programming concepts.
I’ve started trying this with a separate mentor agent. Other agents leave it short notes about what I need to learn, and it explains those things later using what I already know.
I’ll try to write more about this because I think it is a crucial topic.
Maybe what I want is not only “explain this simply”, but “explain this to me”.
a skill people at Anthropic have been using a lot recently: ELI5
/eli5 <what you want explained>
"explain like I'm someone who knows nothing about this topic, using a HTML artifact with big pictures and few words"
Recently, I’ve been thinking about giving agents more awareness of, and control over, their own context instead of leaving everything to external compaction and pruning.
My intuition is that the model, given the current task and context, may be better able to judge what matters than fixed pruning rules alone. It could keep relevant material in focus, move other information out, leave a compact record of what moved, and recover it later if needed.
There is already related work in this area, including VISTA and MemGPT. I’m going to explore the idea through a small experiment with the Pi coding agent and share the results here, whether it works or not.
In the early days of ChatGPT becoming popular, people talked about “prompt engineer” becoming a common role.
I think skills are one of the things making a version of that happen. People like @mattpocockuk can now package and share their experience and workflows as skills that agents can use. I would probably call someone doing this a prompt engineer, although it is more than just writing prompts.
In the past, authors mostly used books to share their knowledge with a human audience. Now I think agents are becoming a new audience for experts and authors through skills.
Every time I see @unclebobmartin point someone towards his Clean Code book, I have the same thought: wouldn’t it be great if there were an official Clean Code skill written for agents?
I don’t mean copying the book into a prompt. I mean turning its principles into instructions, examples and checks that an agent could apply while writing or reviewing code.
It would still take effort and judgment, but probably much less than writing the original book. And instead of only being read, those ideas could be applied directly by agents while they work.
I think there is a real opportunity here for experts to write not only for humans, but for agents too.
@steipete I have been doing this for a while with screenshots and visual explainer and hero screenshots automatically in pr description. Ir is a raise pr skill instead of instructions in agent.md though. Demo video for ui changes totally makes sense👍
@kunchenguid that is true, same for the deterministic hand driven compactions as well.
I all boils down to the frequency of the removing and recalling and also amount of context that gets pushed out. it is measurable though.
thanks for reminding me of "context as a variable" 👍
It might look counterintuitive however having multiple copies of repo per domain or stream of work and then using work trees to work on those domain, could mitigate it quite a lot.
@jthomasINKL7 I’ve started using Herdr and I like what I’ve seen so far. My current workflow has a few existing integrations around it, so I probably won’t shift everything at once. But I’m planning to use Herdr more for personal projects and see where it fits.
This is very close to my experience, although I’m not ready to stop reading code entirely.
About 18 months ago, after working with an early coding agent, I started to believe that IDEs as we know them would no longer be at the centre of software development. It seemed clear to me that the way we build software was going to change.
Two years ago, at Atlassian, I built a Kotlin library called UniLLM. It provided an abstraction for working with different LLMs, including tool calling, events and observability. I was already thinking about new ways for software to interact with models, but I was still doing most of my programming inside an IDE.
Then I went on parental leave for four months. When I returned, Cursor was available at Atlassian. I tried it for around a week and found it useful.
Around the same time, I heard about an early coding agent that @kunchenguid was building. It was still rough, but the interaction model immediately felt different. Instead of helping me edit code faster, it let me work at a higher level. I switched to it and never really went back to the IDE as my main workspace.
Later, I joined Kun and the team building Rovo Dev.
The important change was not that code became irrelevant. The unit of work changed.
My loop became:
• describe the outcome
• let the agent explore the codebase
• inspect its intent and plan
• review the changes, tests and behaviour
• steer or correct it
Today, I no longer use an IDE in my normal workflow. I work with agents and usually review the generated PR in Bitbucket or GitHub. Occasionally I open a file, but that’s about it. I don’t use the debugger, autocomplete, refactoring tools, or most of the other features that once made an IDE essential.
We need developer environments built around context, delegation, visible intent, permissions, verification and traceability.
The next IDE may not look like an IDE at all.
I'm officially done reading AI-generated code.
It's been two weeks since I looked at any of it.
I think the IDE is officially on its way to the graveyard. The job is no longer about "writing code," so we need new tools that better reflect this new reality.
While reviewing the code, I realized my only complaints were stylistic, and I wasn't finding any obvious bugs anymore.
The more code I generated, the harder it became to keep track of every line. I found that my time is better spent designing ways to verify that the overall system works than looking at the code.
State-of-the-art coding agents are better at writing code than I'd ever be, and I'm going to stop pretending otherwise.
I still think these coding agents can't go too far without an experienced human guiding them, but we're past the point where we need to check every line of code.
This feels even more relevant now with coding agents. The axe is the harness.
But we can spend forever sharpening it instead of building. I’ve done that too. Now I try to improve the harness only when real work shows me what’s missing.
@dhh Yup that is super exciting time. On the other hand many ideas get obsolete very quickly. So there is gonna be heaps of abandoned,reshaped and merged ideas