Putting HELM to work at Salalem

Getting an agent to write a patch is a much smaller problem than knowing whether that patch should become part of your product.

At Salalem, a change can look reasonable in isolation and still be wrong for someone using the product. It can pass a test while missing what the person actually needed. It can solve the reported problem while quietly changing a behavior a client depends on.

Those are ordinary software problems. AI makes them harder to ignore because it can produce the next change before you’ve finished understanding the last one.

HELM, the Human-first Execution and Leadership Model, is the framework I created for working through this. Salalem is where I’ve been putting it to work, and where its ideas have had to deal with an existing product, clients, deadlines, and a team that cannot spend all day supervising agents.

I find it easiest to describe the adoption in a few stages. They overlapped. We didn’t finish one neatly and hold a ceremony before starting the next.

When the context was mostly in my head

The early attraction of working with agents is easy to understand. You can ask a question about unfamiliar code, try an approach, get a draft, and keep moving. Sometimes the result is genuinely useful. Sometimes you spend longer correcting it than you would have spent doing the work yourself.

In either case, quite a lot depends on what you know to tell it.

I’ve worked on Salalem through several versions. That gives me context about why something is shaped the way it is, which old behavior still matters, and which apparent shortcut has consequences elsewhere. An agent looking at the current files doesn’t automatically have that history. Neither does a teammate who joined later.

Take an illustrative example, not a Salalem incident: someone simplifies a familiar screen. The new version looks cleaner and passes its tests, but a person who relies on it can no longer find an action they use every day. The change makes sense to its author and still creates a problem for the user.

Understanding the existing use matters as much as understanding the proposed change. You have to know enough to ask what someone might lose, not only what the new version gains.

That dependence on personal context worried me. If useful agent work requires me to reconstruct the history in every conversation, the team hasn’t gained a reliable way of working. I’ve gained another activity to supervise.

Giving the next person a better starting point

The practical response was to make more of that context available to the people doing the work.

We put more effort into shared guidance and clearer expectations. A vague instruction to follow best practices isn’t enough when people need to understand an existing product and judge whether a change belongs in it.

Writing that guidance was its own kind of work. Something obvious to the person who made an earlier decision may need explaining to everyone else. It takes time to work out which context is useful and which is just history.

For a teammate or an agent, that is a better starting point than discovering the expectation after writing the patch.

Written guidance brings its own maintenance problem. Instructions can contradict each other. They can describe yesterday’s product. They can become so long that finding the relevant point takes more effort than doing the task.

I don’t think a large collection of instructions is a sign of maturity by itself. The useful question is whether it helps someone make the next decision correctly. Sometimes that means explaining more. Sometimes it means removing a duplicate or something that no longer applies.

This is also where HELM’s emphasis on team-wide adoption matters to me. I don’t want our process to depend on a few people being unusually good at talking to a model. The background, the limits, and the way we check the work should be available to the next person too.

The patch still has to prove something

Once agents can make changes across several files, review becomes a different kind of work. A convincing explanation isn’t much help if the implementation doesn’t do what it says.

Automated checks have become a more useful part of the work. They help us question a result rather than judge it only by how convincing the explanation sounds. But they take effort to maintain, and they can’t answer every question that matters.

The distinction I keep coming back to is between a passing test and a useful test. A result can satisfy the checks we’ve written while missing something we didn’t think to ask about. We still need to understand what the evidence does and doesn’t establish.

The same applies to product review. A screen can use the right components and still leave a person unsure what to do next. A technically correct permission check can enforce the wrong product decision. Engineering checks don’t settle those questions for us.

HELM gives this work a simple loop: Plan-Execute-Verify-Ship-Learn. Agree what we’re trying to do and how we’ll check it. Let the agent work within those limits. Review the result. Decide whether to release it. Use what happened to improve the next attempt.

The last part is easy to neglect when another task is waiting. But if we correct the same mistake in five conversations and never improve the shared instruction or check, we’re paying for the same lesson repeatedly.

There is a balance here. Every disappointing result doesn’t deserve a permanent rule. Some problems need a better task description. Some need a test. Some need a person to make a decision the agent was never qualified to make.

Ember made the handoffs concrete

Ember is the name of Salalem’s internal AI colleague. It helps with questions and selected work. For me, it made the adoption less abstract: there was something the team could work with, question, and review.

A name makes the system easier to refer to. It doesn’t make an answer correct or turn software into someone who can take responsibility for a decision.

The harder part was deciding what people should expect from Ember. A useful contribution still needs to be understood in the context of the work. It can help someone move forward without settling every question for them.

That is where the human-first part of HELM became practical for me. People still decide what matters and whether a result is good enough. Adding an AI colleague doesn’t make those decisions disappear.

It also brought ordinary expectations of software into focus. Something that looks useful in a demonstration has to be understandable and dependable enough for a normal working day. Getting there takes work beyond improving the answer it gives once.

The work doesn’t end when the agent stops

The managerial questions become clearer once there is a real workflow to point to.

Who decides what needs attention? Who reviews the result? Who checks that it settles the customer’s problem? And who tells the customer what happened?

An agent can finish its task without those later responsibilities being complete. Producing a change doesn’t establish that a customer’s problem has been settled. Someone still has to make that judgment and own what happens next.

That distinction sounds obvious written down. It’s easier to lose it when one screen says the agent has completed and another still needs someone to act.

Review capacity is another concern. Faster production of patches can leave a team with more work waiting for judgment. Product people still need to decide whether we’re solving the right problem. Designers still need to inspect the experience. Engineers still need to understand the change. Quality work still needs to consider what the implementation and its author may have missed.

I also don’t want agent adoption to become an unspoken test of enthusiasm. People should be able to ask whether a result is trustworthy, whether a task belongs with an agent, or whether the process is making their work harder. Those are useful questions, not resistance to be managed away.

For me, there is a particular tension around context and authority. Sharing what I know is useful, but my knowledge isn’t the whole team’s knowledge. Adoption should leave room for people to contribute their own understanding and disagree with a result.

We still have to agree what good work means and where a person remains responsible. Those conversations take longer than adding another tool, and they matter just as much.

Where we are at the end of September

In HELM’s maturity vocabulary, I’d describe our work as having substantial Level 3 / Integrated practices, with some bounded Level 4 / Autonomous execution. AI is part of how work gets done and checked, and some tasks can progress without someone directing every step.

I wouldn’t assign the whole organization a clean Level 4 badge. The levels help discuss how work happens; they aren’t a certification, and one capable workflow doesn’t establish the maturity of every team.

That assessment is narrower than saying we’ve solved adoption. The level of independence that makes sense varies with the task and its consequences. Doing useful work in one setting doesn’t establish that the same approach belongs everywhere.

I also don’t have a measured before-and-after result that would justify claiming a particular productivity gain or fewer defects. More activity alone can’t establish that.

What we do have is a clearer way to discuss the work: what we’re trying to achieve, how we’ll judge the result, and who remains responsible. Those are practical things to build on.

I still have questions about how much review effort this saves, where it merely moves that effort, and how well the process works when the person with the most context isn’t available. Salalem is giving me a place to test HELM against those questions rather than leave it as guidance on a website.

For now, I’m comfortable giving agents more of the work we can describe and check. I’m much less comfortable treating their ability to produce something as permission to decide what we should build or what risk we should accept. Keeping that distinction clear is part of the work, every time.

This account reflects the end of September 2026. The stages are a retrospective grouping. The screen example is illustrative, not a report of a Salalem incident.