Narration: The Feed's Lost and Found - 01
Quick Intro
Hi there! Since this is the first edition of the newsletter, I just wanted to get something out of the way. I am not an AI researcher nor do I have any AI specific degree. I'm a practitioner, in other words a tinkerer. I just like making computers do things.
My relationship with this topic started just few years after I began getting paid to code. Around 2018 I spent a few weeks building a WhatsApp bot with RasaSDK and ended up reading some basic NLU papers. Since then I started being interested and tracking AI developments.
That early exposure helped when ChatGPT hit. It made it easier to ignore hype from the big labs and doom from skeptics.
Since then, I have kept my interest in the field, mostly from a distance. Last year I realized this shift was actually going to happen at scale. When Dario Amodei claimed 90% of code could be written by AI, I could not shrug it off like many did.
My main interest was initially running LLMs on the edge, but since around June 2025 I started really leaning into the agentic-engineering side of it. So I started collecting the content I read online and writing about it.
Now this newsletter is another way to share that, like the a curated feed. I read the content, test the tools, and try to compress the content firehose. I share sources and my read on why they matter.
This week, what caught my attention the most was the convergence around some agentic-engineering practices.
How the Code Factory Keeps Agent Output on Track
Agentic coding is kinda like that. It writes solid code until it does not. The issue becomes spotting drift before you get an incoherent mess.
The bottleneck has moved to steering, keeping quality high as throughput increases, and containing the blast radius when it fails.
Having worked in platform engineering teams, I have seen this kind of work before, but there the job was steering human engineering output.
The idea of a platform team is to build essential infrastructure, shared libraries, and architecture guardrails so teams can move fast without drifting too far. There are many opinions on how to do this.
That same problem now exists at a much larger scale, because agents can write a lot of code nonstop.
OpenAI calls this Harness Engineering.
Which means that after Prompt engineering, Context Engineering, and Agentic Engineering, we now get a new label. I think the term is useful because it reveals the new leverage layer: the environment around the agent.
It is becoming clear we may write most (maybe all) of our code with LLMs in the near future. How to navigate this new engineering mode is still open ground for experimentation.
As more teams work on this, some approaches are starting to converge.
The repository is alive
OpenAI's Harness Engineering article shows how they instrumented their repository for working with agents. Thoughtworks' future of software development retreat highlighted similar points on codebase instrumentation. GitHub is already exploring Continuous AI.
The repository becomes an active platform, a kind of Code Factory, and this platform needs specific infrastructure to function.
1. Dual Instrumentation
Humans need project commands, skills, and custom agents tuned to the codebase. These codify day-to-day tasks and repeatable human-triggered workflows.
Agents need architecture diagrams, high-level component overviews, design system rules, and coding practices. This context should be actively managed and updated by humans and agents. If this is done poorly, agent quality degrades.
At some point you may keep shareable agent tooling in a separate repo, like Armin Ronacher does in agent-stuff.
2. Closed Feedback Loops
Agents need observability data to self-correct. Tests are the baseline. Then you layer linting, type checks, static analysis, UI/screenshot checks, logs, and database access. If the agent breaks it, the agent needs the tooling to see why it broke.
3. Persistent Memory
You need a system of record for design decisions, failure patterns, and remediation playbooks. Without this, the team and agents pay for the same confusion repeatedly. Past failures must become future context.
4. Entropy Control
Multiple agents writing code will increase drift quickly. We need a "garbage collection" system with cleanup routines and maintenance agents that keep the codebase and related context coherent.
5. Blast Radius Controls
You need scoped agent permissions and explicit risk assessment. Every incident or failure to follow instructions should trigger a harness upgrade so the same failure becomes harder to repeat.
We can use agents to help build this infrastructure. They can draft the policy checks, codify the runbooks, and update project skills. But humans still own the boundaries. We decide what controls are valid and what tradeoffs to accept.
Automating the loop
When you have that infrastructure in place, you can build reliable automation. Ryan Carson's Code Factory captures the operating model some teams are moving toward:
An agent opens or updates a PR.
Risk-aware checks run.
A review agent reports issues.
A remediation agent applies fixes on the same branch.
Checks run again.
A human merges when policy gates pass.
These repeatable control loops are what make results reliable.
New Challenges
The human bottleneck is cognitive debt
Margaret-Anne Storey explains really well something we've all been noticing since agentic coding started. Cognitive Debt.
AI acceleration increases throughput and context switching at the same time. You will run parallel threads all day and end with a team that has weaker shared understanding.
Technical debt lives in code, but cognitive debt lives in people and teams when delivery speed outruns understanding.
That's especially true considering how AI doesn't seem to reduce work, but rather intensifies it.
The middle loop is now core engineering
Thoughtworks describes a middle loop between inner loop (coding, debugging, writing tests) and outer loop deployment (ops).
The new loop is some kind of supervisory engineering: scoping work for agents, validating outputs, preserving architecture, and handling drift across parallel streams.
This is where platform engineering instincts become widely useful.
The job expands from writing code to steering a mixed system of humans and agents.
Ownership remains ours
Agents can write code, but humans still own intent, risk acceptance, and production decisions. Accountability for shipped outcomes remains explicit, and that is on us.
Conclusion
I think teams that master this Harness/Agentic Engineering layer will ship faster with fewer regressions and lower organizational drift. There is no one-size-fits-all at this point in time.
Everyone is figuring things out as they go, but at this speed no team can afford to ignore this shift. Start experimenting and find what works best for your team.