Where the work slowed down

Over the past months, we looked closely at how our engineering team works with AI. We saw five patterns:

• Code changes grew larger and more frequent every week, and reviewing them became harder.
• Engineers had to piece together decisions scattered across tickets, code repositories and discussions.
• Long review rounds mixed several issues together, so important points were easy to lose.
• Engineers had to keep too much in their heads at once.
• Checking that each change was safe ad secure took more and more effort.

A single release change showed us how quickly these patterns add up. It needed three rounds of review before it was ready. The first round found that the change could deploy the wrong build of our software. Once that was fixed, a later revision introduced a security risk, and the next round had to catch it. Every round sent the engineer back to request another review and follow the fixes through. AI was writing code faster than our team could review it.

By early summer, we knew that more effort on each review would not fix this. We needed a shared process, one that keeps the speed AI gives us while leaving engineers in full control, with full visibility into every step.

‍

Pulsar

At Nucs AI, we build AI for real workflows, where precision and human judgment matter. To build the process we needed, we applied the same thinking to our own software engineering. The result is Pulsar.

Pulsar is an agentic partner for Nucs AI engineers. Its AI agents carry out multi-step work on their own and hand every decision back to the engineer. Pulsar works across the whole Software Development Lifecycle (SDLC), the full path from an idea to released software, and builds our shared development practices into each phase of that path.

Pulsar’s central task is to turn a clear specification (spec), a written description of what a change must do, into a change request that is ready for focused human review. For the team, this means all AI-assisted development follows one safe and repeatable process, while engineers keep control of scope and final approval. New engineers also get a clear path to follow and a shared way to collaborate.

‍

How Pulsar works

Every change in Pulsar moves back and forth between the engineer and the agents, and each handoff has a reason. The work starts with the engineer, because the engineer knows what the change is really for. They shape the spec, and Pulsar’s agents turn it into an implementation plan. Before any code is written, Pulsar talks the plan through with the engineer and raises any gaps or open questions it has found. The work moves on only when the engineer approves the plan and what it will affect. This is the point where changing direction costs the least, so this is where we want the engineer’s attention.

From there, the agents take on the heavy lifting. They write the code, run the tests and automated checks, and put the work through an independent review. The agents fix whatever the review finds, and the cycle repeats until nothing is left to fix. The review-and-fix loop that wore down the engineer in our release change is now run by the agents.

What finally reaches the engineer is a PR that has already been planned, tested and reviewed. Their final review can focus on the question that matters most: is this the right change? At any point along the way, they can also open the plan, the code, the check results or the review findings, and step in.

‍

What changes for our engineers

Running every change through the same workflow addresses the patterns we saw earlier. We see the difference in four places: when problems are found, how review works, where context lives and how records read.

The first difference is that problems now surface before implementation. In one case, Pulsar found during planning that the requirements did not match the work, and that some information the feature needed did not yet exist. The agent raised both gaps with the engineer before writing any code. The engineer set the scope and decided how the feature should behave until the information was available, and the implementation followed those decisions.

Good planning prevents many problems, but some only show up in the finished work, which is why independent review stays in the loop. In one change involving sensitive data, the engineer approved the plan, and the agents built and checked the work before opening the PR. The independent review step then found that the written operating steps could process the same data twice. Pulsar corrected the steps before the change was merged.

Pulsar also writes down what was decided and why, and keeps that record with the change itself. Reviewers no longer must dig through tickets and chat threads to understand a change, because everything is in one place. In one case, the record included the steps for rolling out the change and for undoing it if something went wrong. Another engineer read those steps and spotted two problems in them, and both were fixed before the change was approved. The record stays with the change, so whoever works on it next knows where to start.

Those records also look the same every time. Every plan, PR and review follows the same format and sticks to what the reader needs. Reviewers know where to find things and spend less time reading. And because our practices are built into the format, every change follows them without anyone having to remember.

‍

Early results

Today, Pulsar supports our team in almost all engineering work. Our first observations are encouraging. Across two equal 20-day periods, the number of merged PRs rose by 165%, and the average time from opening a PR to merging it fell by 44%.

With these changes, our engineers review more coherent code changes, make better-informed decisions and contribute more effectively across functions.

These are early results, and we still have more to learn. Our goal is to make AI’s speed sustainable: standardize how we work, keep knowledge within the team, give new engineers a clear starting point, and leave the decisions that matter with people.

‍