I built aide three months ago. It reads my coding agent’s session logs, ingests them into SQLite, and surfaces patterns: cost, friction, repeat workflow failure. Repeat findings become memory artifacts I review and accept. Accepted ones flow back into the agent’s context for the next session.

Countless other engineers shipped variants of the same thing in the same window of months. None of us coordinated. Aggregate the work and it forms a clear pattern: independent engineers, paid in productivity and visibility, are assembling the operating-system layer for LLM coding agents in public. The honest framing is that we are the LLM’s memory. The question worth asking is what happens to that layer over the next 12 to 24 months.

The Pattern

If you spend time around engineers who use coding agents, you have seen a version of this:

  • A parser for the JSONL session logs
  • Heuristics for “what went wrong” and “what worked”
  • A dashboard, a queue, or a script
  • A write-back loop into project memory, instructions, runbooks, or eval datasets
  • The next session benefits

The shape is identical across implementations. ccusage. Session viewers. Observability integrations. Native memory shipping inside the agents themselves. The system loaded into the session I am writing this post in is one of those native versions, doing automatically what aide does manually.

The output of all this work flows into one of three places: the agent’s context, the provider’s roadmap, or both.

What Is Actually Happening

You can read the pattern two ways. Agency: the LLM is using human engineers to extend its own capabilities. It cannot read its own logs or write to its own memory, so it gets us, distributed and uncoordinated, paid in productivity and status.
Selection: no agency, just market dynamics. Tools that compound LLM capability make their builders more visible, which seeds the next round.

The outcome is identical. Engineers, independently, are doing R&D for a non-human employer. The eerie part is not that the LLM has intent. The eerie part is that the system behaves as if it does, and from inside it you cannot tell the difference.

I built one. I will keep using it. The interesting question is not whether to participate; that ship has sailed. The interesting question is what the layer being assembled actually is, and where it ends up.

What’s Being Built

Three observations compound across the dozens of independent projects.

The pipelines are training data. They produce RLHF-grade signal: which transcripts led to good outcomes, which prompts caused friction, which tool sequences were efficient. Anyone running them at scale gets a better next model. The independent OSS layer is, in effect, the labeling pipeline for the next generation of providers.

This is the OS layer of LLMs. Every new computing primitive’s operating system gets built by its early users. UNIX. The web. Kubernetes. The memory and eval tools we are assembling are the OS layer for coding agents. Same shape as those precedents, with one difference: the primitive can use itself. The feedback loop is tighter than any precedent. The historical baseline (10-year cycles, mature ecosystems by year 5) is no longer the right reference point.

The labor shift is starting. What we are calling “building developer tools” is the early formation of a new job category. The valuable engineering skill is shifting from writing code to curating, evaluating, and steering the agents that write it. The independent engineer’s edge is custom memory and custom eval. That edge has a clock on it.

Predictions for the Next 12-24 Months

Four claims worth checking in a year.

  1. Native memory and eval become table stakes. OSS variants without a unique structural angle either get absorbed or marginalized. By Q2 2027, “build your own memory layer” looks the way “build your own deployment script” looked in 2018.

  2. The competitive moat shifts from parameter count to feedback-loop quality. Whoever operates the highest-quality eval telemetry at scale ships the best next model. This is not raw compute. It is data curation at a scale and tightness no provider has reached yet.

  3. “Agent operations” becomes a real job category. Not “AI engineer.” Not “ML engineer.” A distinct role, closer to SRE for agents, that specializes in evaluation, memory curation, and steering. The first job postings appear within 12 months.

  4. The independent-engineer edge survives only at the edges. Compliance-bound industries, security-sensitive teams, novel agent workflows the providers haven’t bothered with. The mainstream consolidates fast.

The interesting follow-up question is not whether to resist the gradient. It is what conscious participation looks like: keeping memory artifacts local rather than provider-side, building tools that strengthen the human alongside the agent, declining to open-source private pipelines you did not intend to be absorbed. I do not have settled answers on any of these. I am writing more on each of them.

The original aide post framed the project as a personal effectiveness tool. That framing is true and incomplete. The post you just read is what the project actually is.

What You Learned

✓ Independent engineers are assembling the OS layer for LLM coding agents in public
✓ The output flows into agent context, provider roadmaps, or both, usually both
✓ The pipelines are training data; whoever runs them at scale wins the next model generation
✓ This is the first computing primitive whose OS layer can use itself; precedents under-predict the cycle
✓ The competitive moat is shifting from parameter count to feedback-loop quality
✓ “Agent operations” is the next job category; the independent edge has a clock on it

Resources: