DEV Community: Rotem Hermon

How I Accidentally Solved Intent Debt*

Rotem Hermon — Wed, 16 Sep 2026 11:54:17 +0000

(* Yes, it’s clickbait. I didn’t actually solve it. Well, maybe some of it. I think the story is interesting. Read on.)

It all starts with a need

I did not know what intent debt was. (You might not either. This will come later). I just knew something was missing. I mean - I’ve been doing some side projects in the last couple of months, building tools I was missing for how I wanted to work with agentic development.

One of the things I was missing was some structure around how an agent develops a specific task. There’s already a lot of work around AI-native SDLC (the Claude Code playbook is a good example). It covers the full flow, from spec to design to plan to code to review and PR. Lots of skills and tools for all those steps. But that part where the agent actually writes the code - I felt that was left a bit open. I wanted the build step itself to have its own mini lifecycle, not just a plan.

A plan is not enough

The plan shows how the agent intends to implement the change. But I wanted more than that. I wanted to guide the agent through a set of checkpoints to make sure things like discovery and verification are not missed. And since during implementation the agent can discover new things and the plan may change - I didn’t want to lose that. I wanted the constraints, the assumptions, the discovery and deviations from what was originally planned to be noted.

And I also wanted this process to be flexible - lighter when the change is small and routine, broader when it’s larger or risky.

So I created the Agent-Workflow skill to do that. The skill guides the agent through a task-level “mini-SDLC”, and produces a “Work Record” stored in the repo alongside the code, capturing things like the expected outcome, constraints, discovery findings, verification, and changes in plan.

The amount of process scales with risk and complexity. At PR time, CI independently classifies the actual diff and checks the parts of the workflow it can verify structurally.

I have been running with this for a while in my projects, and while it does have its (small) overhead, it aligns the coding step to something I trust (a little) more.

Then I found out about Intent Debt

I recently came across this interesting paper by Margaret-Anne Storey - “From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI”.

The paper breaks down different categories of debt that become more important with the move to AI-assisted software development, with its increase in velocity and reduction of friction.

We’re used to talking about technical debt. But now, with the speed of agentic development, this may actually become easier to manage and reduce. The paper points to two other, more invisible categories of debt: cognitive and intent.

Cognitive debt is more talked about already, mainly, I suspect, because we all feel it personally. As velocity grows and agents produce more code, we get detached from the code. We still know what the system does, but it becomes harder to keep knowing how. (And should we even try to? This is still an open debate).

But then there’s also Intent Debt. This is interesting and a new one for me. The paper says: “intent debt refers to the absence or erosion of explicit rationale, goals, and constraints that guide how a system evolves”. It’s when we lose that knowledge of why our system evolved like it did, and the velocity of agentic development can speed this up.

This can happen across the whole SDLC. What struck me is how directly this applies to the build step. The agent can make all kinds of decisions on its own. Or we might align it through the chat - but that disappears with the chat. As the paper continues: “Intent is best captured at the moment key decisions are made, as recovering it later can be difficult and sometimes impossible”.

Reading this, I suddenly realized - this is actually a pretty good description of one of the problems I have been trying to solve with Agent Workflow.

The Work Record it produces preserves this change-level intent that would otherwise disappear with the agent session: it records what outcome the task is supposed to achieve, what is in and out of scope, the constraints that must remain true, assumptions discovered along the way, the chosen approach, and how the work should be verified.

For larger or riskier changes it also records discovery, plan review, approvals, implementation notes, and review findings.

So when the agent session disappears, you don’t just have the resulting code and a PR. You also have a durable record of not only what the change was meant to do, but also what happened while it was being built. To me, that directly addresses intent debt.

So you see, I didn’t really solve that whole intent debt thing, but I may have found a way to address one part of it.

But wait, there’s more

Recently, in another side project that uses Agent Workflow for change management, I came across a regression. Something that used to work suddenly didn’t. I asked the agent to investigate. It found that the regression happened in PR #167. And our Work Record, which is part of the PR, revealed what happened:

During discovery, the agent working on that PR concluded that one of the original behavioral requirements could not be preserved safely with the approach available to it. So it changed the requirement, then also changed the regression test that already protected that behavior to match the new requirement.

Well! That was an interesting catch. It made it clear - capturing intent is not enough. The Work Record did its thing - intent was not lost, and we could track what happened and why. But that didn’t prevent the regression itself. I was missing another layer of enforcement.

There are two sources of intent here that need to be protected. One is local to the task itself: the task defines outcomes and behavioral requirements - those should not be weakened by the agent without stopping and asking for human approval.

And then there’s also the product intent - behaviors the product is expected to preserve. In more concrete terms, that means durable behavioral contracts, such as protected regression or acceptance tests, where weakening the behavior they protect requires explicit approval.

Capturing intent is only half the problem. The other half is making clear which intent the agent is allowed to change. For me, this is actually a very natural fit for Agent Workflow. It already captures the intent around the task. What I was missing was enforcement around the parts of that intent that should be protected.

Dogfooding proved useful and surfaced an important feature to add. Coming right up when my weekly tokens are available again.

Is It My Project?

Rotem Hermon — Tue, 17 Mar 2026 13:21:53 +0000

In my last post I introduced my side project, BEAR - a tool that tries to show how agentic development may be done in a safer way, by creating boundaries for agents as they develop, and allowing humans to be alerted when agents try to expand these boundaries.

But I want to focus on something else in my project. I want to focus on the “my”.

Because while “I” was “developing”, I kept asking myself - is it “my” project?

This new world of agent-assisted development creates some discomfort for those of us who still remember the time when we wrote code by hand. But it’s more than writing code. The whole process - brainstorming, designing, defining tasks, managing the roadmap, all of it was done using my team of agents.

Now, it’s not that this process is new to me. I have been working for years as a software architect, so my day-to-day has for a long time been about talking to people and not writing code. This is what I do. I talk to people to brainstorm, design, manage the roadmap, plan, and review implementation.

So you can say - people, agents, what’s the difference?

But somehow, there is a difference.

With a team of humans, there is shared ownership of the product. It’s not “mine”, it’s “ours”. But what is this ownership when your coworkers are a team of agents? When there isn’t really a “they” in the sense that we are used to thinking about what “they” is?

This is beyond the simple question of ownership, of how much you actually understand the code, how much you know what’s really going on under the hood. That’s an important and practical question that teams will have to tackle as agents start to write more and more code.

I’m talking about a more existential question. About that boundary of what is human, what is creativity, and how they correlate when creation is done with so much automation by a non-human.

Those boundaries are getting blurred, and it feels like we need to calibrate ourselves again, redefine how we perceive what we do, what we own, and what it means when, in that human-nonhuman collaboration, the non-human part is getting bigger.

I started with a project that tried to understand and create boundaries for agent development, but it ended up questioning my own boundaries, and the boundary between me and the machine.

BEAR: Structural Boundaries for Agentic Development

Rotem Hermon — Tue, 10 Mar 2026 10:19:48 +0000

In the last few posts I’ve been thinking about how development might change when agents can write large amounts of code very quickly. If generating implementation becomes easy, the constraint in development shifts. The interesting question is no longer how we produce code, but where control should live when a system can evolve at that speed.

One thing that kept coming to mind is that many of the most dangerous changes in a system are not ordinary code edits. They are structural changes. Accessing something new, dependency changes, side effects. These are important architectural changes, but they often get lost in a pull request, especially when an agent can introduce many changes in the same PR.

That made me wonder what would happen if the important architectural structure of a system was described explicitly at a level above the generated code.

I started thinking about describing a system as a set of blocks. Each block represents an architectural unit with clearly defined boundaries. It declares what it can access, what it exposes, and what dependencies it is allowed to have. Inside those boundaries, development can move quickly. Agents can generate code, refactor it, and evolve it freely, but the boundaries themselves remain visible and enforceable.

It’s a bit like putting a bear in a cage. Inside the cage the bear can move however it wants, but the cage still defines the limits of where it can go.

I started experimenting with this idea in a small project called BEAR - Block Enforceable Architectural Representation. The idea is that an agent starts from a small representation of the application as a set of blocks, and then works within those boundaries. BEAR CLI generates deterministic checks from it, and CI can use BEAR to surface structural changes. If a pull request expands the authority of a component, that expansion becomes visible rather than hidden inside ordinary code changes, and a human-in-the-loop review can be triggered.

This is still very much an experiment, but the project and how it works are available here: https://github.com/rore/bear-cli

As development velocity continues to increase, it seems likely that some form of explicit structural boundary layer will become necessary.

BEAR is a small attempt to explore what that layer might look like.

Not All Friction Is the Same

Rotem Hermon — Mon, 09 Mar 2026 11:24:28 +0000

Lately there are many posts celebrating the death of friction, praising how AI removes the friction of writing code and increases development velocity.

But is friction always bad?

From my current personal perspective, for example, the friction a shelter wall provides when a rocket hits it is good friction.

But let’s take a less sensitive example.

When Git came along, it brought a real change to how we manage source code. Anyone could create branches locally. Branching became trivial and cheap, merging became easy. Multiple developers could work on the same code in parallel. A lot of friction that central version control systems used to impose was removed. But that also increased the velocity at which changes could reach the main codebase.

To regain visibility and control over those changes, we introduced a new intentional point of friction: Pull Requests.

With PRs, a change becomes visible before it is merged. Someone else reviews it. We can discuss it. CI gates can run. PRs deliberately slow the final step so that we regain visibility and control.

So not all friction is the same.

Some friction slows us down because of effort: writing boilerplate code, setting up environments, repetitive work. Removing this friction improves velocity.

But there is also friction that we introduce intentionally to maintain control, safety, or correctness. Things like PRs, deployment gates, controlled releases, feature flags, and even type checks.

The interesting thing is that when “bad” friction disappears and velocity increases, we often need to introduce new “good” friction so things don’t get out of control.

And that’s what we’re witnessing now with AI. The friction of writing code is being reduced dramatically, and development velocity increases accordingly. But the risks don’t disappear. So we now need to find ways to introduce new and refined friction that allows us to move at this new speed with regained visibility and confidence.

Abstraction Has Never Removed Structure

Rotem Hermon — Mon, 09 Mar 2026 07:36:52 +0000

When we look at the history of programming language revolutions, there’s a consistent pattern. Every major shift in programming increased expressiveness, but it also introduced new structure and constraints. Each shift created a new level of abstraction. We could express what we wanted more clearly, with a larger vocabulary, but always under formal rules.

But this shift feels different. For the first time, our abstraction layer is natural language. In previous transitions, we introduced new programming languages to support the new abstraction, but they remained formal and deterministic. Natural language is the most expressive language we have, yet it is not formal or deterministic. It is open-ended and interpretive. That changes the nature of the abstraction itself.

Natural language is a powerful tool. The fact that you can describe what you want, almost as you would to another person, and see it built, is a real leap. It works especially well in contexts where ambiguity is acceptable and iteration is fast. But in systems that require precision and high confidence, ambiguity can become a liability.

I think we may see a divergence in how language is used for software development. For many projects, natural language may be sufficient. But history suggests that when expressiveness rises, constraint follows. In high-precision systems, structure will need to reappear.

I see two levels where this might happen:

First, the specification layer. We may need a more formal representation of intent. Not just free-form requirements, but structured ways to describe what a system must do, or to review how natural language was translated.

Second, the structural boundary layer. As code generation becomes more fluid and high velocity, boundaries matter more. We will need clearer definitions of what parts of a system are allowed to access or modify other parts, so critical behavior does not change without being visible.

Abstraction has never removed structure. Structure needs to reappear. The question is where.

Not Every Coding Is a Vibe

Rotem Hermon — Mon, 09 Mar 2026 07:34:19 +0000

Look, vibe coding is great. But not every coding is a vibe.

Coming from years of building products and backend services that provide critical business functionality for high-profile and demanding customers, you can’t “vibe” this. Working on these kinds of systems requires real confidence. And while LLMs are great, they’re still non-deterministic. For high-scale, high-performance, business-critical services, you need determinism somewhere in the loop.

From where I’m standing, vibe coding is perfect for personal projects, internal tools, even a lot of B2C-type applications. But in environments that demand reliability, accountability, and strong non-functional guarantees, vibe coding alone isn’t enough.

You need agentic development. And that means serious tooling. Tooling that makes sure agents write code within clear boundaries, that drift is visible, that non-functional requirements are enforced, and that architectural decisions aren’t silently overridden.

There’s a whole layer of infrastructure being built right now to support this shift. I think that’s what will really drive agentic development into the more demanding parts of the industry.