Quality engineering belongs inside the development loop

When development gets faster, quality engineering can become the place where all the unfinished thinking arrives.

More changes reach the queue. More combinations need investigation. The people validating the product have to reconstruct what each change intended, which assumptions it made, and how to exercise the relevant behavior.

If I respond only by asking that group to move faster, I have missed the design problem.

At Samsara, my responsibilities include quality engineering and automation alongside the firmware and systems work. I see that combination as an opportunity to improve the development loop itself.

Design the path to evidence

I want a change to arrive with a clear statement of the behavior it affects and an appropriate way to examine it. That might involve an isolated check, a simulator, an emulator, a device, or an interaction with backend services.

Each environment supplies a different kind of evidence. The goal is to find important failures early without pretending that one environment answers every question.

For device software, actual hardware matters. It is also a resource that requires thoughtful automation, reliable setup, and ownership. The useful engineering work includes making the environment repeatable enough that a failure tells us something about the change.

An unreliable setup can teach teams to distrust the signal. That is an expensive form of noise.

Agents make test design more important

An agent can help create scenarios and exercise a system. It can also generate tests that reproduce the same misunderstanding as its implementation.

I want the intended behavior and consequential failure cases to remain explicit. The question is not only whether a test passes. It is whether it would fail for the reason we care about.

This is why the right guardrails can support speed. A clear acceptance boundary lets implementation proceed with fewer interruptions. A useful failure signal brings the work back while the context is still available.

Human review should concentrate on decisions where judgment is necessary. Automation should make the repetitive evidence easier to obtain. Neither becomes better merely by being applied everywhere in the same way.

Give QE influence over the system

Quality engineers often see patterns that individual feature teams encounter only occasionally: difficult setup, recurring ambiguity, fragile transitions, and failures that escape local checks.

I want those observations to shape the development interfaces and the tooling backlog. A recurring testing burden may be evidence that the product is hard to observe or that ownership is unclear.

Fixing that structure can help more than adding another manual step at the end.

There will still be independent validation and release judgment. Bringing quality into the loop does not eliminate those responsibilities. It gives them a better starting point.

Measure the complete feedback path

The measures I care about include how quickly a change reaches useful feedback, how often a failure can be reproduced, and how much rework appears after acceptance. I want to understand the cost carried by the people reviewing and validating the result, not just the time spent producing it.

My independent game work gives me a smaller place to practice the same principle. Direct routes, harnesses, and repeatable captures make it easier to judge an agent’s work while it is still a small change.

In both settings, the objective is a development system that helps people discover the truth about a change sooner. That is a more durable source of speed than making the final queue work harder.