Context

The app designs were approved by the client and were ready to be mocked out. However, with a huge firmware change coming, we had to redo a lot of how the app worked, meaning there would have to be multiple streams of work, one for just design and one for just restoring the Bluetooth functionality to the app. It became clear that it was going to be hard to keep track of what in the app would be usable, was being worked on, had only visual designs, or only had functionality.

While the backlog worked, it took time to sift through what was in there quickly, let alone explain to someone who wasn’t deep in the weeds. The Team came up with the idea to go old school to help keep track of the app refactor. We printed out all the Figma designs and taped them to a whiteboard. We utilized different colored and labeled sticky notes to keep track of the progress of that designed page. By being able to see the Figma designs and to see their current progress, it provided the team a lot more value than expected. It was able to keep track of which pages had the functionality behind them, while some pages were only designed in Storybook.

It was nice to take part of the old software world and use an actual whiteboard to track our work. It’s true that the Linear backlog we utilized was still extremely vital to the project, and none of it could have been done without Figma. But having a physical copy of what was inside Linear and inside Figma allowed us to make sure stories weren’t being missed.

Value #1: Improved Understanding

Sometimes a backlog can be overwhelming, especially when there are hundreds of stories. Having the visuals on the whiteboard made it easier to understand where a story was coming from or what was being worked on.

It was also a sanity check that you understood what a story meant. Oftentimes, when putting up the sticky note, you’d have to recall where it belonged. Sometimes you’d realize it’s not just in one place, or that the thing you are making could be used somewhere else, and it helped make clear what should be abstracted out versus specialized. It also helped others know where we were at and what a story meant as we would write the name of the story on the sticky note.

“The whiteboard made it easy to have conversations about progress on the roadmap in a tangible way. Sometimes, looking at pictures is much easier to wrap your head around than looking at a backlog’s list of stories.”

– Renee Liken, Delivery Lead

Value #2: Constant Visibility

Something about virtual tools that physical tools will always have the upper hand on is that they are there. This whiteboard allowed the team to gain context even when they weren’t looking at it.

You’d come in and be able to see out of the corner of your eye that there was more green, orange, or blue, and by that, you’d be able to just know that there was progress being made or that you should check the PR list.

“For me the biggest value is it’s something that’s in your face all the time so whenever you got to the office, you were able to glance at it and take a look at our progress and see where we’re at was nice to have a non-digital version available for the team to unite around”

– Bryan Elkus, Designer

Value #3: Improved Team Morale

One of the values the whiteboard provided was that it made it easier to see the wins the team was achieving. Being able to visibly see each state and page of the app made it easy to note and celebrate even the small stories getting done. That’s because they, too, got a green sticky note when they were done.

One of my favorite things when we were using the whiteboard was that when you finished a frustrating story, you got to take a beat to write DONE on a sticky note and take the In Review one down, crumple it up, and proudly display the done sticky note. It was a great way to take a second to appreciate the work being done before moving on to the next story that needed to be done.

Value #4: Effortless Updates

On our team, both our designer and delivery lead were on other projects in our office. That meant they were often balancing multiple plans, stories, and meetings, and often didn’t have time to do a full dive into our backlog.

Not only that, our client was balancing efforts with a firmware team and a hardware team. So, while he was co-located in our office, he often didn’t have the time to fully dive into our process unless we were in a meeting where that was relevant. The whiteboard provided those updates or check-ins without interrupting dev time or without the client having to ask as many questions. Being able to see what was in progress, in review, or done quickly was very valuable as the team grew busier.

“In our case, the physical board gave me peace of mind that our co-located clients could easily see our tracked progress at a glance and on a regular basis. Before it was set up, I would have to worry about whether they would actually keep up with our backlog.”

– Patrick Pale, Tech Lead

Value #5: Public Facing Accountability

As the Gripfusion team grew and we gained more people on the client side, the whiteboard made it easier to catch people up on what was happening with the project, where we were in the project, what you should have soon, what should be tested, etc. Having such a prominent tool gave the developer team clear accountability because we could point at an image and say, “This will be done this week” without getting lost in technical jargon, making the goal clear.

Moreso, it made it easier for others to ask about progress or issues with the app, being able to say, “I see here that this is marked as done. However it’s not behaving as I expected.” That makes it easier than having to open the backlog, find the developer’s story, check the progress, and then bring it to the developers.

“I liked it because it makes the concepts the teams are talking about visible in a way that’s public and open that gives accountability to everyone and to see progress in a tangible way.”

– Mason Ferlic, Gripfusion Co-founder + CEO

Wrapping Up

While in-person tools may not work for every project, the whiteboard proved vital for our project. It got the whole team involved, excited, and on the same page. While we also would not have been successful without well-defined stories and processes with our virtual backlog tool, I think combining the two proved to be surprisingly useful to our team.

I will concede that it was sometimes hard to remember to update, and that we didn’t use it every day. However, the fact that the goal that we were working toward was so clearly and proudly displayed helped with Visibility, Accountability, Morale, Understanding, and updates. I would highly recommend that any team that gets the chance to create a physical backlog tool for the team to use should do it.

The post The Value of In-Person Backlog Management Tools appeared first on Atomic Spin.

“What would the consequences be of putting higher performance shock absorbers in my car?”

Question One

He led me down an interesting conversation about the costs, the considerations, the damage it could do to my very simple Mazda CX-30. We chatted about it for about 5 minutes, realistically, with follow-ups and back-and-forth. In the end, I learned why I should probably just get the recommended shocks for my car until it dies, but also what it takes for other cars to get that smooth, uninterrupted ride on a pot-holey Michigan road.

If you’re curious, not only would it make it easier for me to roll over my car, but it could also cause wear on surrounding parts and be more costly than it’s worth. (It messes up all the physics… or something. I should ask him again.) I got to peek into one of my brother’s knowledge bases for a while and add it to mine.

More Questions

On a different day, I asked my friend Nicole, a medical assistant at a podiatrist’s office, what kinds of exercises I could do to strengthen my ankles, since they’d been hurting. She walked me through what they recommend at her office. My vacuum was purchased on the recommendation of a friend. I know what plants work best for my house from my mother. And, when I’m curious about something in urban planning, I know I can always ask my cousin, who’s in that field.

My encyclopedia is human. All the entries are from my friends! Everyone in my life holds things I can reference, and I know that, for many others, I do the same.

As I move through my career in both software and consulting, the lessons that stick the most with me are all the ones I’ve learned from other human beings. It’s always easier to try something new or see a new perspective when I outsource to a new set of hands, ears, and eyes. But also, seeing others for the knowledge they hold frees up space in my mind for the knowledge I must hold, because I know I can consult them.

Why and How

I think a few things allow me to enable this. For one, I love conversation. That base level joy surely adds to what I get out of any one experience. Another factor is that I love the people I have in my life. It makes me remember more easily what I’ve learned because I’ve attached it to a person I’m learning from.

In having a conversation, a person can also tailor how they deliver that knowledge to what they know about me and my use case, which helps make the knowledge more immediately practical. Google’s AI summary may be able to tell me what changing the shocks could do to any car, but may not tell me as well what could happen with my car specifically. My brother, on the other hand, has knowledge of vehicles in my car’s class and size, giving him an upper hand to apply that knowledge.

I love learning, getting my hands into things, and turning concepts into tangible objects. I love learning what others have learned. And, I love sharing my knowledge. As AI changes the landscape of information, I think that core feeling will remain. Even as it gives us more access to knowledge and patterns than ever, I still believe it is important to take human reasoning, past experience, and intuition to apply that knowledge correctly.

My encyclopedia is human.

The post My Encyclopedia is Human appeared first on Atomic Spin.

Separately, I’ve been subscribed to a couple of developer-focused newsletters, and there’s been a recurring theme around ‘just asking’ and all the benefits that come with it. While I agree, and there are innumerable benefits to asking more questions, I think there is an important caveat worth considering. That is the concept that not all questions are created equal.

Understanding when, where, what, and to whom to direct questions is an important skill to develop. It is powerful for your own growth and being a solid contributor on a team. I will go into a few simple tips I have learned along the way, with some gems from teammates who have a lot more experience than me.

Do the work before you ask.

Before bringing a question to a teammate or into a meeting, I first try to find the answer myself and exhaust my resources. This is especially true for technical questions or general curiosity like what is this? How does this work? These tend to be thinner questions that are worth trying to resolve on your own first, as there is usually a black-and-white answer out there. It’s absolutely okay to escalate them to a teammate if you hit a wall or it isn’t clicking. Building those exploratory skills before offloading the question is part of growing as a developer.

A related tool is that if you know what someone may respond with to your question, you should look into that before asking. For example, say they likely would say, “Have you looked at x yet?” You should look into x before asking! It will show that you are trying to solve your own problems before asking. It will go a long way with your team.

Know your audience and your setting.

Tied closely to the above is understanding who you’re asking and whether the question makes sense for that person. Knowing your audience is paramount so that you don’t waste other people’s time, but also to get an accurate answer.

This becomes even more critical in client or stakeholder-facing meetings, where impressions matter more. I personally do a quick review with a teammate of any question I’m thinking of raising in those settings beforehand as a sanity check. This makes sure the answer isn’t already available to me somewhere, or I am not missing something obvious, and it’s worth surfacing in one of those meetings.

The same concept applies to where and when you ask. Does the setting warrant the question? Asking the team how the new sprint ceremonies feel in a refinement meeting obviously would not be the place. Asking in the right environment increases your odds of getting a good answer, and being respectful to the purpose of the meeting. Being attuned to these nuances is a part of developing good instincts.

Write it down first.

Before asking a question, I write down the key context and points I want to hit in a bulleted list. These keep me on track, make sure I don’t forget anything important mid-conversation and give me a reference point. I’m a big fan of a good artifact, and this is one of the simplest ones you can make. I like to take notes during conversations and I can cross reference the list to make sure I got all the questions answered.

Decide on meeting-appropriate questions.

Bring thick questions into meetings. These are the questions that are genuinely valuable for the group and spark deep discussion. Think “why” questions. Or, “Have we considered X?” or, “Is Y a concern?” These kinds of questions open and encourage discussions instead of closing them. Bonus points if you have follow-up questions to dive deeper and expand upon ideas.

Does the team benefit from having this discussion? This is a crucial idea to consider for bringing up a question in a meeting setting. For most things development related absolutely the team should be in on it! Things like a new idea for a way forward or a bug to bring up would be great. Bringing up that I left a comment on someone’s PR to remove some import would not be right for a group setting.

Try the Diamond Strategy.

The basic idea is to open up with an easier thinner introductory question before diving into the deep stuff. It can be a powerful segue into deep conversation and makes gradual progress into good collaboration. It’s a simple tool, but it helps conversations flow smoothly. Here is an example of this strategy at work:

Thin opening question: How are we handling error states in this service?

Thick continuation question: Why are we catching every error? Should they bubble up? Do we really need an error state for that?

Thin closing question: So it’s better to let errors bubble up in this service so we preserve the full stack trace, is that right?

This is a pretty simple, clear-cut example of how a conversation with this framework in mind could work.

The goal of this post was not to make asking questions harder, but rather to give you tools to make you more effective at this. Asking more questions in general is good, but going in prepared with an artifact for reference, knowing your audience/setting, and letting the conversation flow progressively make these questions better for all involved. Like anything, these skills take time to improve at, and don’t let the fear of asking a bad question stop you from asking at all! I have asked many silly questions in my early career. Below is a paragraph of all the negative things I have experienced from asking non-perfect questions:

The post How to Ask Better Questions appeared first on Atomic Spin.

For the past few years, I have had the opportunity to serve on the planning committee for Merge, with Atomic Object participating as a conference sponsor. Helping plan and execute the conference gave me a chance to spend more time thinking not only about individual talks, but also about the broader themes emerging across the schedule. This year, I spent some time reflecting on the changes in the artificial intelligence landscape over the past year.

Last year, many conversations about AI in software development felt exploratory. Teams were experimenting with new tools, testing workflows, and trying to understand what generative AI might mean for the future of product development. The questions were broad: Should we adopt these tools? Where do they fit? Are we all becoming “vibe coders” now?

At Merge 2026, the tone felt noticeably different. AI wasn’t presented as a novelty or a future possibility. It was treated as a reality of the way we work now. The conversation has shifted from whether teams should use AI to how teams use it effectively. In my mind, that shift says a lot about where the industry is heading.

2025’s take on AI

Looking back at Merge 2025, many AI-related talks focused on helping teams approach AI thoughtfully amid the growing hype and lingering uncertainty. Talks had topics like “Smart Adoption, Not Blind FOMO,” framing AI as a trendy tool that still needed integration into existing workflows. The emphasis was on avoiding too much disruption, protecting team dynamics, and considering the tradeoffs that came with rapidly changing tooling and not falling into the trap of maximizing output at all costs.

Other talks approached AI through the lens of integration and collaboration. One talk described AI as a “universal translator” that could help bridge communication gaps between systems and teams. Another warned about the risks of runaway code generation and increasingly fragmented systems. Across these talks, a common thread emerged: teams were trying to figure out how AI fit into existing practices without destabilizing them.

The underlying question in 2025 seemed to be: How do we adopt AI responsibly?

That question reflected the broader feeling of the industry at the time. AI tools were rapidly improving, but many organizations were still experimenting at the edges. There was excitement, but also caution and uncertainty.

The AI Landscape of 2026

A year later, the conversation has changed quite a bit. At Merge 2026, speakers were no longer encouraging teams to adopt AI. Instead, they assumed AI was already integrated into day-to-day work and focused on the experiences and consequences of that reality.

The questions became more concrete:

• How do we maintain quality in AI-assisted workflows?
• How do we supervise increasingly autonomous systems?
• What happens to engineering discipline when code generation becomes cheap?
• How do teams preserve trust and shared understanding?

Several talks reflected on this transition directly. Drew Colthorp’s session on moving from “vibe coding” to “agentic engineering” focused on keeping humans in control of increasingly capable AI systems. Rather than treating AI as a replacement for engineering rigor, this talk emphasized the need for structure, oversight, and intentional workflows.

Another talk, provocatively titled “TDD is Dead! Quality Code in the Age of AI” argued that specifications and clear expectations become even more important when AI is involved. Ambiguity that might once have resulted in a small misunderstanding between developers can now generate entire layers of incorrect implementation faster than ever before.

The most interesting shift between 2025 and 2026 was not that AI became more capable. It was that the conversation became more disciplined.

The New Anxiety Is Trust

One theme that appeared repeatedly across this year’s talks was trust.
As AI systems become more integrated into software delivery, teams are wrestling with a new set of concerns:

• Can we trust generated code?
• Can we maintain architectural clarity?
• Can we identify hallucinations quickly enough?
• Who is accountable for mistakes?
• How do we avoid accumulating invisible complexity?

These concerns are different from the hype-driven conversations that dominated the industry a year ago. They reflect practical experience. Teams have now spent enough time using AI-assisted workflows to understand both the productivity gains and the hidden costs. AI can accelerate output, but it does not necessarily improve judgment.

That may explain why several Merge talks emphasized practices that experienced software teams already value:

• Clear communication
• Iterative feedback loops
• Testing
• Observability
• Architectural simplicity
• Collaborative review
• Shared understanding across disciplines

None of those practices became obsolete because of AI; instead, they became more important. As implementation becomes faster and cheaper, cross-team collaboration, clarity, and feedback cannot be undervalued.

AI Is Reshaping Collaboration More Than It Is Replacing People

Another interesting pattern across the Merge 2026 schedule was the new take on cross-functional collaboration. Several talks explored how AI is changing the boundaries between design, development, and product work. Developers can prototype interfaces more quickly. Designers can explore technical ideas more independently. Product teams can generate artifacts and synthesize information faster than before.

AI lowers the friction involved in crossing disciplines. But lowering friction is not the same thing as eliminating expertise. In practice, these tools seem to increase the importance of context, alignment, and decision-making. Teams still need shared understanding around user needs, product goals, architectural tradeoffs, and quality standards. One of the more compelling ideas in this year’s conference was that AI brings the disciplines of product, design and developement closer together.

What AI Adoption Looks Like in 2026

If there was a consistent message across Merge 2026, it was that the current state of AI adoption is less about maximizing automation and more about building disciplined systems around it. The teams most likely to succeed with AI probably are not the ones generating the most code or adopting the newest tools first. They are the ones creating strong feedback loops, maintaining accountability, and preserving space for human judgment.

Mature AI teams:

• Treat AI as augmentation rather than autonomy
•  Prioritize clarity and specification
• Preserve review and verification practices (aka testing)
• Invest in collaboration
• Recognize that velocity without validation creates fragility

That perspective felt noticeably more grounded than many AI conversations, even from just a year ago.

What encouraged me most about this year’s conference was not the excitement around AI itself, but the growing focus on collaboration, accountability, and craftsmanship. Conferences like Merge are valuable not because they predict the future perfectly, but because they help us compare notes as an industry while the future is still unfolding. I’m curious to see where the conversation goes next.

The post From AI Hype to AI Discipline at Merge 2026 appeared first on Atomic Spin.

Most CQRS explainers reach for a bank account aggregate. If you have read one more bank account example in your life, you are owed a refund.

This post uses an actual production system — the kind with a dozen-plus event types per aggregate, schema evolution, and side effects that cannot be allowed to block the UI — as its running example. No toy code.

A Motivating Puzzle

Here is a question worth holding onto for the whole post.

You ship a feature that lets an administrator approve a pending organization. The implementation is the natural one: UPDATE organizations SET status = 'active' WHERE id = ?.

Two weeks later, your product manager asks you a perfectly reasonable question: “Who approved this organization, and when, and why did we reject that other one last month — can you pull up the reasoning?”

You cannot. The row tells you what state we are in. It says nothing about how we arrived there. You saved the destination and bulldozed the road behind you.

That puzzle — and the fact that you cannot solve it by adding a few audit columns without making your life worse — is the itch that Event Sourcing was invented to scratch.

Pair it with CQRS, then sprinkle projections on top, and a number of other problems you did not realize were problems begin dissolving: temporal queries, retroactive bug fixes, new read models added years after the fact.

I am not here to sell you anything. These patterns have real costs, which we will discuss honestly. But when the fit is right, the fit is glorious.

The Production Stack

Our example system’s stack, for the record: NestJS as the framework, @nestjs/cqrs for command-handler plumbing, KurrentDB (the database formerly known as EventStoreDB) as the event log, PostgreSQL with Drizzle ORM on the read side, and a small fleet of projections that translate between the two.

This is for teams whose domain has a memory: approvals, rejections, assignments, migrations, corrections, compliance questions, and a business habit of asking why something is in its current state.

If your application is mostly simple profile edits and preference toggles, the honest recommendation is to enjoy your UPDATE statements and spend the complexity budget somewhere else.

The Thesis, in One Paragraph

It’s worth memorizing, because we will come back to it:

CQRS observes that reading data and writing data are different problems, and it is a form of violence to force one model to do both. Event Sourcing proposes that we store not the current state, but the sequence of facts that produced it. Projections are the bridge: they translate that stream of facts into whatever shapes the read side wants.

That is the entire idea. Everything else we do today is plumbing, and plumbing, as any homeowner will tell you, is where the interesting failures live.

Commands Describe Intent, not Data

On the write side of a CQRS system, the API does not accept “please make this row look like that.” It accepts commands — named, intentful requests like ApproveOrganization or RejectOrganization.

A command is a verb. It is a thing someone, or something, is trying to do.

In our codebase, every command extends a common base class carrying three fields: the entity ID it targets, the issuer (a user? the system? a migration?), and a timestamp. Specific subclasses add the rest:

export class CreateOrganizationCommand extends Command {
  constructor(
    id: string,
    issuer: Issuer,
    public readonly fields: OrganizationData,
  ) {
    super(id, issuer);
  }
}

export class RejectOrganizationCommand extends Command {
  constructor(
    id: string,
    issuer: Issuer,
    public readonly rejectReason: OrganizationRejectReason,
  ) {
    super(id, issuer);
  }
}

Notice what is present and what is absent. There is no status: 'approved' parameter anywhere. The command does not tell the system what the new row should look like.

Instead, it tells the system what the user is trying to accomplish. The system then decides whether that is a legal thing to do, and what state changes it implies.

This distinction is more important than it appears. When your write API speaks in verbs — approve, reject, invite — instead of nouns-with-mutations — PATCH the status field to “approved” — the code begins to speak the same dialect as the business.

Your product manager can read your command names. That is not cosmetic. It is a substantial reduction in translation cost between the people who decide what the software should do and the people who make it do it.

A well-named command set is, in effect, an executable glossary of your domain. If a business analyst cannot read your commands, your commands are poorly named.

The Aggregate is a State Machine

A command bus routes each command to a command handler. The handler’s job is to load the right aggregate — a domain entity with its full history rehydrated into memory — and hand the command to it.

In our system, the aggregate extends a class called PersistentEntity. It is, at heart, a state machine with one responsibility: given its current state and an incoming command, decide what events should fire.

export class Organization extends PersistentEntity<
  OrganizationCommand,
  OrganizationData,
  OrganizationEvent
> {
  static readonly eventMap = {
    [OrganizationCreatedEvent.TYPE]: OrganizationCreatedEvent,
    [OrganizationUpdatedEvent.TYPE]: OrganizationUpdatedEvent,
    [OrganizationApprovedEvent.TYPE]: OrganizationApprovedEvent,
    [OrganizationRejectedEvent.TYPE]: OrganizationRejectedEvent,
    [OrganizationDocumentAddedEvent.TYPE]: OrganizationDocumentAddedEvent,
    // ...more domain events
  } satisfies EventMapFor<OrganizationEvent>;

  static readonly stateMap = {
    [UninitializedOrganizationState.STATE_NAME]: UninitializedOrganizationState,
    [PendingOrganizationState.STATE_NAME]:       PendingOrganizationState,
    [ActiveOrganizationState.STATE_NAME]:        ActiveOrganizationState,
    [RejectedOrganizationState.STATE_NAME]:      RejectedOrganizationState,
    [InactiveOrganizationState.STATE_NAME]:      InactiveOrganizationState,
    [ClosedOrganizationState.STATE_NAME]:        ClosedOrganizationState,
  } satisfies StateMapFor<OrganizationState>;

  constructor() {
    super(new UninitializedOrganizationState());
  }
}

States are real objects.

An organization in Pending state is a genuinely different thing from one in Active state, and it accepts different commands. You cannot approve an already-approved organization. You cannot update a rejected one.

That rule does not live in an if statement buried in a service. It lives in the state class, where it cannot be forgotten. Invalid transitions become impossible, not merely improbable.

Exhaustiveness is enforced by TypeScript.

The phrase satisfies EventMapFor<OrganizationEvent> instructs TypeScript: “this object must cover every event type in the OrganizationEvent union.” Add another event to the union and forget to register it here? The compiler refuses to build.

This is our first encounter with a recurring theme: exhaustiveness checking. In an event-sourced system, the type system is the first, last, and best line of defense.

The pattern to internalize: use your language’s type system to make impossible states impossible. “Approve a rejected organization” should not be a bug you catch in code review. It should be a bug the compiler already caught while you were off doing something else.

Events are What Actually Get Saved

Here is where we diverge most sharply from the world of CRUD. The aggregate does not persist itself. It emits events, and the events are appended to a stream.

The aggregate’s in-memory state is merely a cached fold over the event history.

export class OrganizationApprovedEvent extends EntityEvent {
  static readonly TYPE = 'OrganizationApprovedEvent' as const;
  readonly type = OrganizationApprovedEvent.TYPE;

  constructor(
    entityId: string,
    issuer: Issuer,
    timestamp: Date = new Date(),
  ) {
    super(entityId, issuer, timestamp);
  }
}

An event is a fact about the past. It is immutable. It carries the minimum information needed to describe what happened — not a full snapshot of the world, just a delta.

OrganizationApprovedEvent does not serialize the entire organization. It says: this ID was approved, by this issuer, at the event timestamp.

When a command arrives, the aggregate validates it, constructs the appropriate events, and applies them to its own state. The framework then appends those events to the entity’s stream in KurrentDB with optimistic concurrency control.

In plain English: “I expect this stream to be at revision 42 when I write. If someone else got there first, fail loudly.”

async writeEvent<E>(
  streamName: string,
  eventType: string,
  eventData: E,
  expectedVersion?: number,
): Promise<void> {
  const event = jsonEvent({ id: uuid(), type: eventType, data: eventData as JSONType });

  expectedVersion !== undefined
    ? await this.client.appendToStream(streamName, event, { streamState: BigInt(expectedVersion) })
    : await this.client.appendToStream(streamName, event, { streamState: ANY });
}

Streams are named by entity: Organization-{uuid}, User-{uuid}, and so on. KurrentDB also provides virtual category streams.

For example, $ce-Organization contains every organization event across every organization, which is precisely what projections will want to subscribe to in a moment.

A reflective pause. The first time it lands that your database contains no rows describing organizations — only an append-only log of things that have happened to organizations — produces a mild vertigo.

You have written code that has never, not once in its life, issued an UPDATE. The word “update” does not appear in your write path. You may want to sit down.

Reconstructing the Present from the Past

How, then, does the aggregate know its current state when the next command arrives? By rereading its history.

When a command targets organization abc-123, the framework loads stream Organization-abc-123, instantiates a fresh Organization aggregate, and feeds every event through apply() in order.

After the final event, the aggregate’s state reflects the current state of the organization. Only then is the new command dispatched.

Snapshots keep replay cheap.

The natural objection: “You replay the entire history for every command? Every time?”

Yes. For a while, that is fine. Events are small, streams are short, and event stores are astoundingly fast at reading them.

Eventually, though, an aggregate gets chatty. An organization with 40,000 document-added events will let you know. The answer is snapshots.

A snapshot is a serialized copy of an aggregate’s state at a particular event revision. In our system, snapshots live in a PostgreSQL snapshots table, not in KurrentDB itself. That keeps the write path clean.

Every hundred events, the framework persists a snapshot; we retain the last five per entity. On rehydration we load the most recent snapshot and replay only the events after that revision. Two hundred thousand events collapse to forty.

Here is the subtle, critical point: snapshots are a performance optimization, not a source of truth. If a snapshot is corrupt, outdated, or written under an older schema, you discard it and replay from the events.

The log is always authoritative. This is one of Event Sourcing’s quiet superpowers: your caches are permitted to lie, because you always have something to fall back on.

Making Events Queryable

The question that always arises at this point: the UI needs to show a list of organizations, sorted by name, filtered by status, paginated. You cannot possibly be replaying every event on every page load.

So how does anyone actually query this thing?

Correct. We do not. Meet the projection.

A projection is a long-running subscriber that reads events off a category stream — for us, $ce-Organization — and translates them into whatever read model the UI needs.

Most of ours write to PostgreSQL via Drizzle. The read side of the system is, by design, a completely boring, indexed, joinable relational database. It is exactly the shape your frontend wants, because your frontend was born wanting rows.

export const organizations = pgTable(
  'organizations',
  {
    id: uuid('id').primaryKey(),
    subscriptionType: text('subscription_type').notNull(),
    name: text('name').notNull(),
    addressLine1: text('address_line_1').notNull(),
    // ...more
    status: text('status').notNull().default(OrganizationStatus.Pending),
    rejectReason: jsonb('reject_reason'),
    approvedAt: timestamp('approved_at', { withTimezone: true }),
    rejectedAt: timestamp('rejected_at', { withTimezone: true }),
    createdAt: timestamp('created_at', { withTimezone: true }).notNull(),
    updatedAt: timestamp('updated_at', { withTimezone: true }).notNull(),
  },
  (table) => ({ idIdx: index('id_idx').on(table.id) }),
);

This table is not where the organization’s data lives. This table is where a read-shaped reflection of that data lives, maintained by a projection that listens for organization events and keeps everything in sync.

A projection is a translator.

And the projection itself:

@Injectable()
export class OrganizationDbProjection
  extends AbstractDbProjection<OrganizationEventEnvelope> {

  protected readonly entityClass = Organization;
  protected readonly config: PersistentSubscriptionConfig = { startFrom: 'start' };

  protected async handleEvent(event: OrganizationEventEnvelope): Promise<void> {
    await match(event)
      .with({ type: OrganizationCreatedEvent.TYPE },  (e) => this.handleOrganizationCreated(e))
      .with({ type: OrganizationUpdatedEvent.TYPE },  (e) => this.handleOrganizationUpdated(e))
      .with({ type: OrganizationApprovedEvent.TYPE }, (e) => this.handleOrganizationApproved(e))
      // ...more
      .exhaustive();
  }
}

Four things to notice here, each worth sitting with for a moment.

• This is just pattern matching. We use ts-pattern’s .exhaustive(). Add a new event type to the union, forget to handle it here, and the build fails. Same exhaustiveness trick as in the aggregate.
• Each handler is a small SQL writer. handleOrganizationApproved sets status = 'approved' and approved_at = event.timestamp. That is all. There is no domain logic here; all of that already ran on the write side.
• startFrom: 'start' is a superpower. If we want to change the read model — add a column, split a table, index differently, add a completely new read model — we can replay every event from the beginning of time.
• The offset update is atomic with the write. The abstract base class wraps handleEvent() and the offset bookkeeping in a single PostgreSQL transaction. Either both succeed or both roll back.

Read models are rebuildable.

This is worth saying plainly: the read side is rebuildable. That changes the risk profile of database migrations more than any sentence of mine will convince you of until you experience it.

You cannot end up in a state where the event was projected but the offset was not saved. You also cannot advance the offset without applying the projection. This sounds obvious. It is not obvious. People get this wrong all the time, and then they wonder why production is weird.

The Read Side is Mercifully Boring

A small epiphany waits here. Once you have a projection maintaining a relational read model, the read side of your CQRS application stops being exotic.

Controllers inject an OrganizationRepository, the repository issues a Drizzle query, JSON comes out. There’s no QueryBus. No query handlers. No ceremony.

Some CQRS purists will insist that reads, too, should go through a query bus. I have built it both ways. A bus on the read side adds indirection without adding much value when your reads are mostly “give me the thing.”

A bus on the write side earns its keep, because commands have behavior: validation, state transitions, event emission. You want one place where all of that lives.

Asymmetry in architecture is a feature, not a bug. Do not make your system more symmetrical than your requirements.

Production Details that Tutorials Skip

Everything up to this point is standard CQRS and Event Sourcing — the stuff the textbooks describe. What follows is the set of pieces that tutorials gloss over.

In my experience, these are the difference between a proof-of-concept and something you can run a business on.

KurrentDB offers optimistic concurrency, plus a belt.

KurrentDB offers optimistic concurrency on writes: “I expect this stream to be at revision N.” If it is not, you receive a WrongExpectedVersionError, reload, and retry.

In practice, if two commands for the same entity arrive simultaneously, both threads load the aggregate, both build events at revision N+1, one wins, the other retries, reloads, and tries again. Under load, this gets ugly in a hurry.

So, for each entity, we acquire a PostgreSQL advisory lock keyed on the entity ID before executing the command. It is a FIFO serialization for that entity; other entities proceed in parallel, unaffected.

return this.lockService.withEntityLock(entityId, async (_tx: DrizzleTransaction) => {
  const entity = new entityClass();
  entity.receiveCommand(command);
  // ...persist events
});

This is cheap, database-local, and already installed. No Redis, no ZooKeeper, no distributed-lock fairy dust.

Entity-level serialization turns out to be a pleasant sweet spot: commands for the same entity queue up; commands for different entities run concurrently. Write throughput scales with entity count, which is almost always what you actually want.

Events evolve; upcasters help you survive.

Your events live forever. Your code does not. Eventually, you will need to add a field to an event, rename one, or quietly concede that the original shape was a mistake.

You cannot UPDATE the event log. That would defeat the entire point of the log.

The answer is the upcaster: a small function that reads an older event version, transforms it to the current shape, and passes it up the stack.

Each event class carries a SCHEMA_VERSION. When the stored version is less than the current one, the upcasters run in order until the payload is current.

export function upcastUserCreatedEventV1(data: Record<string, unknown>) {
  // v2 added a required `status` field; default old events to 'active'
  if ((data.schemaVersion ?? 1) >= 2) return data;
  return { ...data, status: 'active', schemaVersion: 2 };
}

This is a lightweight pattern, but one you must build in on day one. Retrofitting versioning onto a log of a million events is not a sprint you want on your calendar.

Put the ceremony in place before you need it. The first upcaster can simply return its input. The skeleton is what matters.

Idempotency is not optional

KurrentDB’s persistent subscriptions deliver events at least once. On a crash, redeploy, or deliberate retry, the same event can arrive twice. Your projection must not care.

We achieve this with a per-projection offset stored in PostgreSQL and an in-memory LRU cache of recently-processed event IDs. The cache catches the hot path at about a 99% hit rate when the projection is caught up; the offset table catches the cold path.

In either case, applying an event twice is a no-op. Assume duplicates. Design for duplicates. Duplicates are not an edge case; they are Tuesday.

The failure mode is painfully ordinary. A projection handles OrganizationApprovedEvent, updates the read model, and the process dies before the offset is committed.

On restart, the subscription redelivers the same event. If the projection increments counters, sends emails, or inserts child rows without an idempotency guard, congratulations: one approval just became two side effects.

This is why the offset write and read-model write share a transaction, and why side-effect projections need their own deduplication story.

There are two flavors of projection.

Some projections are the read model. They must be consistent enough that the UI can show the right thing after a write. Those run transactionally, as described above.

Many things, however, are not read model updates. Sending a welcome email. Auto-assigning a default profile when a user joins. Posting to a webhook. Notifying Slack.

These are side effects, and they should not share a transaction with your read model. If your email provider is having a day, your UI should not suffer.

So we run a second kind of projection: an async projection. It subscribes to the same category stream independently and handles side effects.

It can fail, retry, lag, and restart without touching the write side or the read model. Same machinery — a persistent subscriber with idempotency — different responsibilities.

This pattern is worth dwelling on, because it is the one newcomers to CQRS tend to underestimate. Once your side effects are modeled as projections over the event log, they stop being tangled into command handlers.

Adding a new one stops feeling dangerous. Want to notify Slack when an organization is approved? Write a projection. The rest of the system does not change. Nothing is refactored. Nothing is threaded.

You add new behaviors without modifying existing ones, which, as a gentleman named Meyer observed, is the whole ballgame.

Correlation IDs give you an audit trail.

When a command fires, we stamp a correlation ID onto the logging context. That ID rides along into every event the command produces.

Which means: when you are staring at a strange read-model state six months from now, you can find the events that caused it, trace back to the HTTP request that issued the command, and read every log line from that request.

The audit trail was not a feature we built. It fell out of the architecture.

Free features are the best features, and if you architect well, many of the features you pride yourself on shipping were never actually separate features at all.

An honest Accounting of the Costs

I like this architecture. I use it on real projects. That said, anyone who sells you a pattern without telling you what it costs is trying to sell you something.

It is more code.

For a trivial CRUD feature — “admins can edit their profile bio” — you do not want a command, an event, a state transition, and a projection handler.

You want a PUT endpoint and an UPDATE. If the majority of your application is features of that flavor, event sourcing will feel like formalwear at a backyard barbecue.

Eventual consistency is real.

After a write, the read model takes some milliseconds to catch up. Most of the time the user never sees it.

Sometimes they do, and you must design the UX to handle the gap: optimistic UI, explicit loading states, or, in rare cases, waiting for a projection checkpoint.

Pretending this problem does not exist is how you accumulate angry support tickets that say “I approved it but it still shows as pending.”

Cross-aggregate queries are harder.

“Show me all organizations whose primary contact has not logged in for 90 days” crosses two aggregates.

Projections can answer it — you build a joined read model for precisely that question — but that is another moving piece to design, populate, and maintain.

You trade the freedom of arbitrary joins for the discipline of purposeful read models.

The onboarding ramp is real.

New engineers need to internalize the write/read split, the immutability of events, the idempotency requirements, and the versioning story.

It is not difficult material, but it is unfamiliar, and unfamiliar costs you calendar days. Budget for them.

Here’s when the cost is worth it.

So when is formalwear the right call? When your domain is genuinely eventful — when “why is this thing in this state?” is a question the business asks, not just a question you ask at 2 a.m. during an incident.

Finance. Compliance. Healthcare. Logistics. Anything with a regulator or an auditor in its life.

Also: anywhere you suspect you will need read models you have not yet imagined. The ability to rebuild projections from the complete history is, frankly, a cheat code, and it is worth a lot of architectural weight.

7 Things Worth Taing Away

If nothing else from this post sticks, let these:

• Commands are intents, not payloads. ApproveOrganization, not UpdateOrganizationStatus. Your codebase will begin to read like your product spec, and this is a wonderful thing.
• Keep aggregates small. An aggregate is a consistency boundary. If a command handler is reaching across to other aggregates, you have drawn the boundary in the wrong place. Solve it with async projections (“when X happens, dispatch Y”), not bigger aggregates.
• Use the type system for exhaustiveness everywhere. Event maps, state maps, projection handlers. satisfies and .exhaustive() are load-bearing. The compiler catching a missed case is worth any ten tests you could write.
• Install event versioning on day one. The first upcaster can be a no-op. The machinery is what matters.
• Treat the event log as sacred. No deletions. No mutations, outside explicit redaction or privacy-retention policies. Everything else — snapshots, projections, caches — is rebuildable, and therefore disposable.
• Prefer projections over sagas. If “when X, do Y” can be a projection subscribing to X’s events, make it one. One fewer concept in the codebase. One more boring, idempotent, restartable piece of code.
• Advisory locks are almost always enough. You probably do not need a distributed lock service. You almost certainly have PostgreSQL. PostgreSQL already has what you need.

A Closing Thought

Here is the line I keep returning to: In a CRUD system, your database tells you what. In an event-sourced system, your database tells you what happened.

The difference sounds academic until the first time a stakeholder walks to your desk and asks why something is the way it is. With an event log, you can produce a perfectly ordered record of every decision, every actor, and every timestamp that conspired to produce this exact present.

That first time resembles magic. Once you have seen it, it becomes difficult to un-see.

CQRS and Event Sourcing are not right for every application. When they fit, though, they fit exactly. The more complex your domain becomes, the more precisely they fit.

If your business has a memory, your database should have one too.

Go read some event logs. Break something. Come back with better questions than the ones you started with.

The post CQRS and Event Sourcing in TypeScript: A Production Walkthrough appeared first on Atomic Spin.

That future gets a lot less fun when the device only works because a company’s cloud service is still around.

My rule for buying new smart home gear has become pretty simple: if the core functionality depends on a proprietary cloud service, I’m probably not interested. The manufacturer’s app can be useful. Cloud features can be useful. But the device should support an open, local-first protocol out of the box.

For most smart home devices, that means looking for Matter. For cameras, that usually means looking for RTSP and/or ONVIF support. There are also good exceptions outside of Matter, like Zigbee, Z-Wave, MQTT, ESPHome, and other local integrations. The important part is not that every device has to use the same protocol. The important part is that the device should not become useless just because the manufacturer gets bored, pivots, gets acquired, changes its subscription model, or shuts down a server.

Not Bricked, But Definitely Worse

Google’s support changes for older Nest Learning Thermostats are a good example of the problem. Starting October 25, 2025, Google says 1st- and 2nd-generation Nest Learning Thermostats no longer connect to or work in the Nest app or Google Home app. Those thermostats can still be controlled directly on the device, and existing schedules can continue to run.

So, no, they were not turned into wall-mounted paperweights. That part matters.

But a lot of what made them “smart” went away: remote control from the app, notifications, phone-based settings changes, third-party assistants, Home/Away Assist, multi-device Eco mode control, and software/security updates. That is not nothing. If you bought the device because it was connected, programmable, and integrated with the rest of your home, losing those features is a meaningful downgrade.

This is the smart home trap. The physical device can still function, while the product you thought you bought quietly stops existing.

The App Should Be a Bonus, Not the Foundation

I do not think every smart home device needs to be fully open source, and I do not think every manufacturer app is bad. Sometimes the app is the easiest way to set up the device. Sometimes it exposes extra features. Sometimes it handles firmware updates in a clean way.

That is fine.

The problem starts when the app and cloud service are the only way to use the device. At that point, you are not just buying hardware. You are buying hardware plus an ongoing promise that the company will continue to care about that hardware.

That promise has a shelf life.

A better model is “cloud optional.” Use the manufacturer’s app if it helps. Use the cloud feature if it gives you something valuable. But the basic control path should still exist locally. A light switch should still switch lights. A thermostat should still integrate with your home. A camera should still expose a video stream. Your house should not need to ask a remote server for permission to behave like your house.

Why Matter Helps

Matter is not magic, but it is a useful step in the right direction. It gives smart home devices a common language that can work across ecosystems. Instead of buying something that only really belongs to Apple Home, Google Home, Amazon Alexa, SmartThings, or some vendor-specific app, you can buy something designed to be understood by multiple controllers.

That flexibility matters.

Maybe today you use Apple Home. Maybe next year you want to move more automations into Home Assistant. Maybe you have family members who prefer Alexa. Maybe you just do not want to make a 10-year device purchase based on your current phone brand. Matter makes that less painful.

This is where Home Assistant is especially useful. It is very good at acting as the central place where different devices, protocols, and automations meet. If your devices support local standards, Home Assistant can often become the hub that ties them together without forcing everything through one company’s cloud.

Atomic Spin has covered this general direction before in Home Automation in 2024: What’s New?, especially around Matter, Thread, and the slow move away from piles of vendor-specific apps. That post also points out an important reality: vendor apps are still here, and Matter does not expose every possible feature for every device. Energy monitoring, RGB animations, and firmware updates may still require a manufacturer app.
That is annoying. It is not a deal-breaker.

The goal is not perfection. The goal is an exit path.

Cameras Are Their Own Special Case

Security cameras deserve separate treatment because they are often some of the most cloud-dependent devices in the house. Video storage, event detection, person recognition, package alerts, and remote viewing are all obvious places for companies to sell subscriptions.

Again, cloud features are not automatically bad. But a camera that only works through a proprietary app is a risky purchase.

For cameras, I want to see RTSP and/or ONVIF support. RTSP gives other systems a way to consume the camera’s video stream. ONVIF helps with discovery, camera control, and integration. Together, they make the camera much more likely to work with Home Assistant, a local NVR, Frigate, Blue Iris, Synology Surveillance Station, or tools like Scrypted.

That last one is a good example of why open video paths matter. Scrypted can take camera feeds and make them available to other smart home ecosystems. But that only works if there is something useful to ingest in the first place. If the camera’s only output is “open our app,” your options are much thinner.

A camera should be a camera, not just a viewing window into a subscription service.

The Counterarguments Are Real

There are fair arguments against being this picky.

The first is convenience. The manufacturer app is usually easier. You scan a QR code, tap through a few screens, and the device appears. No hub decisions. No protocol research. No fiddling with integrations. That is true, and I do not think convenience should be dismissed. But easy setup and local control are not opposites. A good smart home device should have both: a pleasant setup flow and a durable local control path underneath it.

The second argument is that cloud services often provide better features. Also true. A cloud-backed camera may have better object recognition. A thermostat may have better weather-aware scheduling. A vendor app may provide cleaner dashboards than a generic hub. But those should be enhancements, not load-bearing walls. If the cloud goes away, the device should degrade gracefully. Losing fancy object detection is one thing. Losing the ability to view your own camera feed locally is another.

The third argument is that Matter is still imperfect. Very true. Device support is still uneven. Some categories are better covered than others. Some manufacturers technically support Matter but still keep their best features in their own app. Thread networks can introduce their own troubleshooting fun. Anyone who has spent time with home automation knows that “standard” does not always mean “effortless.”

Still, imperfect interoperability is better than no interoperability. I would rather have a device that exposes 80% of its functionality through a local standard than one that exposes 100% through a cloud service that can disappear.

What to Look For on the Box

When buying new smart home gear, I’d treat these as positive signs:

• Matter support for lights, plugs, switches, sensors, locks, thermostats, and similar devices.
• Thread support for low-power devices, as long as Matter is also supported.
• Zigbee or Z-Wave support if you already have a compatible hub.
• Clear Home Assistant compatibility, especially for local integrations.
• MQTT or ESPHome support for more DIY-friendly devices.
• RTSP and/or ONVIF support for security cameras.
• A local API or explicit local control mode.
• Setup codes, QR codes, or pairing flows that work with standard hubs.

And I’d treat these as warning signs:

• “Works with our app” is the only integration listed.
• Remote control requires an account with no local fallback.
• The camera feed cannot be accessed outside the vendor app.
• Basic automations require a subscription.
• The product page talks a lot about AI features but says nothing about local control.
• Reviews mention that the device stops working when the internet is down.

This does not mean you have to turn every purchase into a research project. Just add one more question before buying: “What happens if this company’s service shuts down?”

If the answer is, “The device keeps doing its main job,” that is a good sign.

If the answer is, “I guess I’ll buy a replacement,” keep walking.

Buy Devices That Can Outlive Their Apps

Smart home devices live in weird territory. They are physical objects installed in your home, but many of them behave like rented software. That mismatch is where the trouble starts.

A light switch should last a long time. A thermostat should last a long time. A camera should not need to be replaced just because a product team decided the old app is inconvenient to maintain.

Open, local-first protocols are not just a hobbyist preference. They are a practical way to protect yourself from product churn. They let you change hubs, mix ecosystems, move more control into Home Assistant, or keep basic functionality running when a cloud service goes away.

The best smart home device is not the one with the flashiest app. It is the one that still makes sense five years from now, after you change phones, rebuild your automations, switch platforms, or the manufacturer moves on.

Your smart home should belong to you. Not to a server you do not control.

The post Your Smart Home Shouldn’t Need Its Manufacturer to Stay Alive appeared first on Atomic Spin.

Introducing simple-import-sort

simple-import-sort is an ESLint plugin that can be installed as an npm package. It allows ESLint to automatically sort and format your imports.

As seen in this example above, simple-import-sort allows us to set up rules to automatically format our imports on save. This allows us to keep clean and organized imports throughout our entire repo.

Installation

Before we can install simple-import-sort, the plugin requires ESLint to be installed in your repository. If you haven’t installed ESLint yet, follow the setup instructions in the ESLint Docs.

Once installed we can install the plugin by running the following command from your terminal:

npm install --save-dev eslint-plugin-simple-import-sort

Setup

After installing the plugin locate the eslint.config file in the root of your repository. Inside your config file, you will need to add the simple-import-sort config.

import simpleImportSort from 'eslint-plugin-simple-import-sort';                                                                                                                                
                                                          
export default [
    {
        files: ['**/*.ts', '**/*.tsx', '**/*.js'],
        plugins: {                                                                                                                                                                              
            'simple-import-sort': simpleImportSort,
        },                                                                                                                                                                                      
        rules: {                                        
            'simple-import-sort/imports': 'warn',                                                                                                                                               
            'simple-import-sort/exports': 'warn',
        },                                                                                                                                                                                      
    },                                                  
];

This is the most basic config for simple-import-sort that will enable automatic sorting of your imports. By default the plugin groups side-effect imports, then external packages, then everything else, then relative imports — alphabetized within each group.

Custom Grouping

Beyond the default groupings, we can optionally customize the import grouping further. You can customize this further by adding additional rules to the ESLint config. Let’s add the groups object to the 'simple-import-sort/imports' object in the config.

'simple-import-sort/imports': [                                                                                                                                                                 
    'warn',                                             
    {
        groups: [                                                                                                                                                                               
            ['^@angular'],                    // 1. Framework
            ['^@?\\w'],                       // 2. External packages                                                                                                                           
            ['^@app', '^@shared'],            // 3. Internal aliases
            ['^\\.'],                         // 4. Relative imports                                                                                                                            
        ],                                              
    },                                                                                                                                                                                          
],   

This config groups your imports according to the rules you define. Adjust the groups to match your project’s import paths.

Enabling Automatic Import Sorting

The magic of this plugin happens when the imports can automatically fix themselves. Let’s look at a couple ways to do this.
1. Run eslint --fix from the command line. This will automatically run import formatting on all of the files on your project.
2. Setup autofix on save. Locate your .vscode/settings.json file and include this in the config.

"editor.codeActionsOnSave": {                                                                                                                                                                   
    "source.fixAll.eslint": "explicit"
}  

Once you add this config, VSCode will automatically apply the formatting whenever you save the file. Other editors will have equivalent settings for formatting on save.

A Small Note

Keep in mind that this plugin doesn’t work alongside any other import sorting plugin. This will cause the two plugins to get stuck in a loop, each reformatting the other’s output.

This includes ESLint’s default import sorter sort-imports. If you see this included in your plugins array, then you will need to remove it when adding simple-import-sort.

Enjoy Hassle-Free Import Sorting

That’s it! Give this a try and enjoy never sorting imports manually again. Keep in mind that this may require some trial and error, as every project is different, but this is a basic guide on how to get started with simple-import-sort.

The post How to Auto-Sort Your Angular Imports appeared first on Atomic Spin.

So how’d we get here?

We had a feature with a generous estimate and a runway that was definitely not generous. So we decided to try spec-driven development with Get Shit Done (GSD), an open-source tool that turns research and context into structured, executable development plans. Pair that with Claude Opus 4.6 as the coding agent and a disciplined review process, and you get a workflow where the agent writes the first draft of an implementation, and the team takes it the rest of the way. What surprised me wasn’t the speedup. It was where the slow part went.

The thing about getting faster

When people talk about AI making software development faster, they usually mean writing the code. That’s the part you can put on a stopwatch. Our shortest time from pickup to pull request was 21 minutes. Great headline.

And it’s true. We saw it. The writing part got dramatically faster. So fast that work the team had estimated in months came together in weeks. We finished in a fraction of the time the original plan called for, and that wasn’t a rounding error. The time savings were real, and they were big.

Here’s the part no one warned me about. When writing gets that fast, it stops being the longest part of the work.

On our team, the median time from picking up a story card to having a pull request open dropped to about a day. And then? The PR sat for three days waiting on review. Then it sat for three more days in QA. Writing time collapsed. Review time didn’t. So even as the whole pipeline got faster, the shape of where time goes flipped completely.

The bottleneck didn’t go away. It moved.

What it feels like from inside

This is the part I didn’t expect to be a feeling thing, but it absolutely was.

I’m a developer. I’ve spent two decades writing software. I love writing software. When the agent started producing the first draft of every implementation, what was left for me was reviewing, redirecting, testing, and refactoring. All of those are skills. All of those are valuable. None of them feel the same as writing the code yourself.

The word that came up for me, once I sat with it, was grief. I was mourning the job I used to have. The craft I’d built over years of writing code. The skills I’d worked hardest to build, and was proudest of, suddenly weren’t the ones the work was asking for. Watching an agent do the part you used to be best at, faster than you can, is not nothing. It’s a real loss, even when you know the trade is worth making.

You can’t wave that off. What I’ll say is the work didn’t go away. It became different work. Reviewing agent-generated code well is its own craft. You have to know what good looks like, what your team’s standards actually are, and where the agent’s blind spots tend to be. Spoiler: it has plenty.

The hard parts didn’t disappear. They just stopped being the initial generation.

When the bottleneck moves, look at it honestly

Here’s the thing about a bottleneck. When you remove the one in front of you, you don’t get a frictionless world. You get a new bottleneck. And usually it’s one you’d never had reason to look at, because the old one was bigger.

For us, the new bottleneck was the review pipeline. Code review, QA, the back-and-forth between developers and reviewers. It was fine before, because writing the code took longer than reviewing it. Now? The review pipeline was the constraint.

That’s actually useful information. The writing speedup is real, and it showed up in our cycle times. What it also did was make the review pipeline the biggest chunk of time left. Not as a problem, but as the new place where humans add the most value.

What stays the same

The work changed shape. The principles underneath it didn’t.

Every line of code we shipped, a human signed off on. Reviewed it. Ran it. Tested it against the running application. Pushed back when something wasn’t right. That’s two agile principles holding their ground at once: individuals and interactions still matter more than the tools we hand them, and continuous attention to technical excellence still defines what’s worth shipping. If anything, both got more important.

Spec-driven development pushed the thinking earlier and the judgment later. The thinking part (what are we building, why, what does done look like) has to be done up front, because the agent is going to take you at your word. The judgment part (is this what we actually want, does it hold up, would I be proud to ship it) has to happen on every PR, because the agent will happily produce code that’s technically correct and contextually wrong.

It’s still humans, top to bottom. It’s just humans doing different things.

The honest takeaway

We delivered the feature in a fraction of the estimated time. That’s the headline, and I’m not going to pretend it isn’t.

The quieter thing we learned, and the thing I’m carrying forward, is what the work has become. The typing got cheap. The judgment didn’t. Knowing what good looks like, holding the bar, catching what the agent gets wrong. That’s the developer’s work now. The team that wins isn’t the one that writes the most code. It’s the one that knows what to do with it.

Speed was the prize, and we got it. What’s stuck with me is a clearer picture of where the work actually lives now.

The post When Code Becomes Cheap, What’s Left? appeared first on Atomic Spin.

After a year of genuinely integrating AI into my daily work, not just experimenting with it, here’s what I’ve actually learned. These aren’t my original ideas. Some I picked up from people smarter than me, some I arrived at through trial and error. I can’t say I follow all of them perfectly, and it’s easy to slip when things get busy. But they’ve shaped how I try to work, and I keep coming back to them.

Lesson 1: The First and Last 10% Are Yours

I first came across this framing in a LinkedIn post by Matt Przegietka, and it clicked immediately. The idea: think of AI-assisted work in three unequal parts.

The first 10% is yours: the framing, the strategic thinking, the definition of what actually needs to happen. This is where you decide what problem you’re solving, why it matters, and what “done” looks like. AI can’t do this for you, and it’s tempting to think it can. But this is critical thinking, judgment, and human intelligence. It’s the stuff that sets everything else up for success or failure.

The middle 80% is where AI can do the heavy lifting. Research, drafting, synthesizing, iterating, generating options. All of it is on the table. This is where it genuinely earns its place in a workflow.

The last 10% is yours again: the review, the refinement, the final judgment call. Does this make sense? Is it true? Is it good? AI will produce confident, polished output that is sometimes subtly wrong, occasionally embarrassingly wrong, and sometimes genuinely excellent. You can’t tell the difference without showing up at the end.

This only works if you’re using tools that let you take outputs somewhere and do something with them. When you stay trapped in a chat window, handing everything back to the AI with each iteration, you end up in an endless loop, essentially like asking an intern to push pixels around while you hover over their shoulder. They fix one thing and break something else. You lose control of the work, and the last 10% never really happens. Getting that final stretch right means pulling the output out of the generative tool and finishing it yourself, in a space where you’re actually in charge.

The temptation is to skip the edges entirely: hand AI a vague goal, accept whatever it spits out, and call it done. I’ve done it. The results are rarely something I’m proud of, and often something I have to quietly fix later anyway.

Lesson 2: Stop Chasing the 10x Hype

I’m skeptical of the big productivity numbers I hear thrown around. Not because AI doesn’t make you faster. It does. But not in the way the hype would have you believe. A study out of Stanford and MIT found that AI tools boosted productivity for knowledge workers by about 14% on average. Real, and worth celebrating. Not a revolution, but real.

In my experience, 2x is achievable and repeatable. With the right setup and a task that plays to AI’s strengths, I can genuinely get roughly twice as much done in the same amount of time. It compounds over weeks and months.

Three times is possible sometimes, usually on narrow, well-defined tasks where I’ve done the upstream work carefully and I’m reviewing just as carefully.

Beyond that, I get skeptical. Five times starts to feel like cutting corners and rushing past the parts of work that actually matter. And 10x? If someone tells you they’re 10x more productive with AI, they’ve either redefined what “done” means or they’re not reviewing their work closely enough. My hunch is it’s probably both.

The real risk isn’t underusing AI. It’s chasing a multiplier that sets you up to produce more output in less time without actually improving the quality of what you’re making. That’s a trap. More shit, faster, should not be the goal.

Set realistic expectations. Celebrate 2x. Build the habits that make it sustainable.

Lesson 3: Avoid the Multitasking Trap

This one surprised me, not because I didn’t know multitasking was bad, but because AI made the temptation so much worse.

When you have an agent running in the background, it’s easy to think: I’ll just kick off three things at once and get ahead. So you do. You’re half-reviewing one output, half-crafting another prompt, half-reading a Slack thread. And technically, technically, you can do all three. Nothing stops you. But here’s the thing: your brain is paying for all of it, and the work shows it.

Multitasking isn’t just inefficient, it’s neurologically impossible. The brain doesn’t run two cognitive tasks in parallel; it switches between them rapidly, and every switch carries a cost. The American Psychological Association cites research showing that task-switching can eat up to 40% of productive time. Psychologist Sophie Leroy’s work on “attention residue” shows that even after you’ve moved on to the next thing, part of your brain is still stuck on the previous one. You’re never fully present on what’s in front of you.

AI doesn’t fix this. It makes it worse because the faster you can generate output, the more pressure you feel to keep all the plates spinning. The result is three tasks done poorly instead of one done well, and then extra time spent fixing all three.

My colleague Rachael Hodder wrote a helpful post on this recently. Her framing is useful—the “agent wait” is a real category of time now, and it deserves intentional use. But her most important point is buried in the last section: “The best thing you can do with the wait is stay one step ahead of the agent. Review the last output. Queue the next prompt. Plan the verification.”

That’s the key. When an agent is running, you don’t have to sit still. But if you decide to keep going, you should connect to the work at hand. Re-read what you’ve been prompting. Review the context you’ve gathered. Draft your next prompt. Prepare how you’ll verify what comes back. This keeps you in the work rather than escaping it, and it means you’ll be sharp and ready when the output lands instead of scrambling to reorient. It can also truly help to just step away and take a much-needed human break. AI is supposed to free up time in our lives, not keep us glued to a never-ending, artificial productivity cycle.

The alternative—pinging three Slack channels, opening a totally different project, catching up on email—isn’t rest, and it isn’t progress. It’s the worst of both.

Good Human Habits, Better AI Outcomes

I don’t follow these perfectly. Some days I catch myself running too many things at once, or accepting a draft I know deserves another pass, or jumping straight into prompting before I’ve actually thought through what I want. The craze around AI makes it easy to slip. There’s always pressure to move faster, do more, and squeeze another percentage point of efficiency out of everything. These lessons are my pushback against that pressure, even when I don’t manage to live up to them.

The tools are only as useful as the habits around them. Without mindful, human judgment guiding the process, all we’re really doing is automating mediocrity and making more work for ourselves.

The post Hard-Won Lessons From a Year of Using AI appeared first on Atomic Spin.

When we onboarded two delivery leads to the Ann Arbor office last year, we experimented with a lightweight informal feedback framework. This framework allowed us to make space for conversations on what was going well, what support was needed, and where expectations might be unclear. This fits really well with our continuous improvement mindset at Atomic. We know there’s always room for everyone involved to learn and grow!

Many feedback frameworks exist, but they felt overly complex for what we needed to check in regularly with our onboarding delivery leads. The Liked Best/Next Time framework is a tool we learned about at a ZingTrain seminar. It’s similar to the mindsets we bring to a team retrospective conversation, but with a much smaller scope.

Overview of Liked Best/Next Time

Liked Best / Next Time is a lightweight feedback framework from ZingTrain that keeps feedback positive, specific, and future-focused. Instead of framing feedback as what someone did right or wrong, it asks people to reflect on what worked well and what they want to try differently the next time they face a similar situation. ZingTrain contrasts this with the “compliment sandwich.” The useful feedback is not hidden between niceties, and the conversation stays focused on learning from the experience rather than judging the person.

Breaking it Down

In a one-on-one training context, the person being trained goes first:

• What did they like best about their own performance?
• What did the trainer like best, including any additional positive observations?
• What would the trainee do differently next time?
• What specific suggestions or expectations does the trainer want them to focus on next time?

That order matters because it gives the trainee space to notice and own both their strengths and their opportunities for improvement before the trainer adds more. The trainer’s role is to reinforce what went well, help prioritize the “next times” and keep the feedback concrete enough to act on. “Do better” is not a behavior; “smile before picking up the phone” or “practice using the hold button” is.

The same pattern can scale to groups, projects, events, or team changes. A facilitator asks the group what they liked best and what they want to make sure to repeat, then asks what they might do differently next time. A note-taker captures the discussion in a shared place, often with initials so people can clarify later. The goal in the first pass is brainstorming, not debate: get the feedback visible, look for themes, then decide who will review it and what actions or proposals should come out of it.

The bigger cultural idea is that feedback becomes less scary when it is frequent, expected, and tied to shared goals. LB/NT gives teams a common language for continuous improvement: acknowledge what is working, name what could work better, and turn that into practical next steps.

If you’d like to read more, ZingTrain offers a free-to-access webinar on the topic!

How we implemented it

Our incoming delivery leads were already paired with a fellow delivery lead onboarding buddy. So we tried out this framework as part of the scheduled time-based check-ins. You could use it at any time, but we targeted weekly for the first month, and then monthly for the rest of the new team members’ first 90 days, at the end of the:

• First week
• Second week
• Third week
• Fourth week
• Second month
• Third month

We found it gave us useful insights not just for the new team members’ progress, but also for our onboarding process in general. If your team runs onboarding similarly, we’d love to hear how you structure feedback check-ins!

The post Liked Best/Next Time: A Lightweight Feedback Framework for Onboarding appeared first on Atomic Spin.