DEV Community: Rotem Hermon

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.