People by day. Agents by night.

Morning: focus

From 9 to 11 it is focus time. The headphones go on, and there are no meetings. First we review what the agents built overnight. Then we shape the next tasks. What should the user be able to do, and how do we know it works?

After 11 we hold show and tell. It might be a good prompt, a new skill or a mistake we do not want to make again. What one of us learns quickly becomes the whole team's. This is also where we do the first spikes, and configure and prepare tasks for the AI agents.

Afternoon: people

From 12.15 there is time for collaboration and clients: customer journeys, interviews, concepts and spikes, which are short technical experiments. This is the work where you have to understand other people and make choices together. All the things AI cannot do.

When we go home, the agents carry on.

The agents run all night. It is extremely effective.

At night the agents work on the tasks we have shaped during the day. Every task runs in a loop:

1. Understands. The agent knows everything about the project. It sees the transcripts, the briefs and all the content created in the project: the sketches, the code, the minutes and the decisions already made. Through skills, we help the agents understand what matters and what to leave out.
2. Builds. The change is made according to the conventions written down in the code base.
3. Tests. Code style and types are checked, and the automated tests run both on the individual parts and all the way through, the way a user would.
4. Reviews. The agent reads its own change again with fresh eyes.
5. Fixes. Whatever the tests and the review find is fixed. Then the loop starts again.

A night leaves room for many rounds. The loop continues until all tests are green and the review finds nothing more. In the morning the change is ready for a person to judge, together with a log of what the agent has done.

At DSV Transport, for example, this means that a task shaped during the day can be ready to test on their own phones the next morning.

Why the agent rarely ends up in a dead end: ADRs

Many loops catch the mistakes. They do not save a task that points in the wrong direction, though. The context does that.

Our agents do not work from a short instruction. They have all of it: transcripts of the meetings, meeting minutes, briefs from the client and the decisions we have made along the way. So the agent knows why the task exists, and not just what it is.

On top of that come skills. A skill is a written recipe for how we do something specific. It might be how a task should be tested, or what matters most when two sources say different things. Skills make sure the agent prioritises the right things in all that context.

And a person always approves before anything reaches the users. An agent never releases anything on its own.

ADRs hold on to the context

In long development projects, AI tends to lose focus. A new session starts with no memory of the earlier ones, and a discussion settled three months ago can come up again. Then the solution slowly drifts away from what was originally agreed.

That is why we write our decisions down as ADRs, Architecture Decision Records. An ADR is a short note about one decision: what we chose, why, and what we ruled out. The ADRs live in the code base next to the code, and the agents read them before they build. It is not a new practice, but before AI it took a lot of time. Now it is having a renaissance.

It means that the context holds, even when the project is six months old, and even when a new developer or a new agent joins.

We focus on the part AI cannot solve. This is where we make a difference

Soon, anyone can have agents work at night. The difference is what they take with them.

The right input for the night comes from what we do during the day. AI cannot take that over:

Meeting the users. AI can summarise an interview. It cannot see where a user hesitates, or sense what goes unsaid.

Understanding the business. Goals, finances and organisation. Both what is in the brief and what is not.

Choosing and ruling out. Prioritising is judgement. Sometimes the best advice to a client is to leave something out.

Shaping the task. The night's work is never better than the day's task.

Seeing the whole. A product has to hang together, feel right and work for everyone, including people with disabilities.

Taking responsibility. A person approves every change and decides when it is released.

It leads to better products and supports the business

We try out more ideas. When a prototype costs a night rather than a sprint, we can test three solutions with real users instead of debating one. We choose based on what works, not on what sounded best in a meeting.

The time goes to the users. When the agents take on much of the building, there is more time for research, concept and testing within the same budget.

We test everything. The same tests and rules apply to every change. Quality does not depend on whether someone had a good day.

We use the same skills and the system "Brewale". What we learn in one project becomes skills in the next. We orchestrate all our skills across developers and agents in Brewale.

Focused time and quality, rather than long unfocused hours. We work 30 hours a week, because people with headspace deliver sharper solutions. The morning focus time makes the difference even bigger.

What you get from working with us

More for the money. When the agents build more of the solution, the client gets the gain. The hours go to where we conceptualise the solutions, not to the development itself.

Independence. The ADRs and skills live in the code base, and the meetings are written down. As our CTO, Hari, puts it: you do not just get a product, you get the system that builds the product. It does not live in the head of one developer. It is part of the solution, with AI agents in the code base, both during development and after launch.

We are keen to run it and work together for a long time

Independence does not mean we disappear. We would love to run and develop what we have built. We would just rather you stay because it makes sense than because it is difficult to switch.

We build systems that build products. And the system is yours.