When the workflow became another job

During early product development, I used coding agents to work through architectural choices, write specifications and plans, and implement them. But when we learned something that required a change of direction, I sometimes had to delete earlier decisions from our planning records to get the agent to stop following them.

Those decisions came from specs and plans we had written together. Depending on the workflow, we recorded them in repository files, GitHub issues, or pull requests. I had answered the questions, agreed to the scope, and let the agent carry out the work. A few rounds of implementation later, we would discover that the approach couldn’t support what we were trying to build. I would try to change direction, but the agent kept returning to the earlier agreement.

If I kept the old decisions in those records, I had to write prompts telling the agent to ignore them. Following the workflow had become another job.

TL;DR

• I wanted room to investigate architectural choices and revisit decisions as we learned. The workflows I tried made that harder than I expected.
• We’re developing Lusona AI Skills, a set of reusable instructions for coding agents, to give agents room to plan and investigate within clear boundaries.
• We ask agents to record gaps between the current implementation and the larger goal, with evidence and a next action. We decide which work to authorize and test how well our instructions hold up.

Making room to understand the architecture

I care about software architecture. I keep a library of books on the subject and turn to articles and research papers when I need to go deeper. I want to understand why an approach works, where it breaks down, and what it commits us to.

For this project, that meant digging into a technical domain I knew less well. I understood the larger outcome we needed, but I needed to research the available approaches before committing to an architecture. These were foundational choices, and I wanted to understand their consequences beyond the next implementation task.

In the workflows I was using, the agent interviewed me before producing a spec and a plan. It asked for decisions while I was working through their implications. I sometimes opened a separate AI session to explore a question from the first one. Other times, I interrupted the interview to ask whether we could talk through the subject, then had to steer the agent back to the original task.

Sometimes the agent left a promising approach out of the options it offered. I had to question the choices themselves before we could make a useful decision.

The skills emphasized keeping scope small and avoiding work we didn’t yet need. I understood the appeal. But the questions could become so narrow that we lost sight of whether the proposed work would support the larger goal.

We could reach a precise agreement with architectural questions unresolved. We recorded my answers as decisions, and the agent used them to guide subsequent work. By the time we found a limitation, we had several earlier decisions reinforcing the approach.

I had participated in making those decisions. I needed room to investigate the choices before committing to them, and a way to revisit them when we learned more.

What we started changing

That experience helped shape Lusona AI Skills, which we’ve been developing and using in our own work over several months.

We use skills to carry our working expectations across sessions. With newer models, I’m finding that we need to prescribe fewer steps and give more attention to how we want the agent to work with us: explore architectural tradeoffs before narrowing the scope, explain consequential choices, and check the result against the larger goal. We set firm boundaries around what the agent may change and what counts as finished, while learning how much procedural guidance each task needs.

OpenAI’s guidance for GPT-6 Astra echoes part of this shift: elaborate procedural instructions can hinder more capable models, while clear completion criteria and decision boundaries still matter.

The conversation was one place to start. If I don’t understand a choice, the agent should explain it and work through the consequences with me. It should challenge my assumptions when it has evidence, and reconsider its own proposed options when I question them. Sometimes that discussion will change the question we need to answer, or reveal that we need an experiment before we can decide.

We stopped requiring a separate planning document for new work. We keep the intended behavior, constraints, and acceptance criteria in a spec. The agent plans the execution, investigates uncertainties, and adjusts its approach as it learns. It can keep useful execution notes and evidence alongside the agreement.

This gives us fewer documents to reconcile. The agent can revise how it carries out authorized work; a discovery that changes what we’re trying to achieve needs a decision from us.

If the agent finds evidence that undermines an earlier decision, it should bring that conflict into the conversation so we can revise the agreement. After we agree to a change, it should update the affected records and work from the revised decision.

Finding the work we hadn’t anticipated

I find the change most useful in our work log. As we investigate and build, the agent helps identify gaps between the current implementation and the goal, then records proposed work for us to consider.

In one evaluation, we found several gaps we hadn’t covered in the original assignments and recorded them as separate work items. As we investigated, we split one problem into distinct changes and corrected an estimate of the expected benefit. We had counted some cases as potential gains even though our existing measurement included them. We recorded the correction alongside the finding.

We keep the evidence and uncertainty with each item in the log. Some findings need more investigation before we can judge their value. We defer others, recording a reason and a condition for revisiting them. We decide which work to authorize; identifying a gap gives the agent a proposal to bring back to us.

This lets us keep individual assignments small while continuing to think about the larger goal. We don’t have to anticipate every requirement in the first interview. After an assignment, we can examine what we learned and decide what remains before the result will be useful.

The agent can delegate specialist work to other agents. Each gets a bounded question or task, and the coordinating agent checks the results against the overall request. Agents can run independent investigations in parallel, but the coordinator must reconcile their findings before acting on them.

What we still have to judge

None of this guarantees that the model will follow the instructions or reach the right conclusion. Our own log contains corrections to earlier findings. We still have to supply direction and examine the evidence, including whether the checks we chose measure what we care about. The agent can help us understand unfamiliar territory, but we need enough understanding to judge what we accept.

We’re continuing to adjust Lusona AI Skills. Adding instructions can recreate the friction we were trying to remove, so we have to question our own rules.

Using the skills has improved my productivity, and that experience is why we’re sharing them. I can finish an assignment with a clearer account of what we learned, which decisions need another look, and what work remains toward the goal. That gives me something useful to act on when the original plan turns out to be incomplete.

You can find Lusona AI Skills on GitHub. Try them in your own work and let us know how it goes. We’d like to hear where they help and where you find yourself fighting the workflow.