DEV Community: dqj

Running a high-end bakery in the age of industrialized code

dqj — Wed, 28 Jan 2026 14:16:03 +0000

When considering productivity, this analogy always comes to mind:
High-end bakeries vs. industrial bread factories.
High-end bakeries produce bread of superior quality. They are meticulous, skillfully crafted, expensive—and serve a relatively small customer base.
Factory bread, on the other hand, mass-produces "good enough" bread.

As artificial intelligence begins to generate massive amounts of production code in an industrialized manner, I can't help but wonder if the software industry is heading in a similar direction.

When AI can generate code that passes most code reviews in seconds, and most users won't even notice the difference, what does it mean that we spend ten times as much time writing elegant code?

Software engineers may be in a worse position than high-end bakeries.
Will anyone pay ten times more for your software simply because they appreciate its beautiful code?

I genuinely want to understand in what areas human effort can still create significant value, and in what areas might this effort quietly lose its due reward.

The full story on Medium

The Regression Bug Was the Most Important Result

dqj — Tue, 13 Jan 2026 09:55:20 +0000

The Feature Wasn’t the Point

Two AI systems successfully implemented the requested UI feature.

That part wasn’t interesting.

What mattered was what broke outside the requested scope.

The Regression

After the change:

Select text in the editor

Trigger the “Replace with” contextual action

Nothing happened.

No error.
No exception.
Just silent failure.

This is the most dangerous class of bug in production software.

Why This Happens with AI-Generated Code

From an engineering perspective, this failure is predictable:

The prompt emphasized new functionality

Existing behavior was implicit, not asserted

No test explicitly protected that interaction

AI systems optimize for local correctness,
not global behavioral invariants.

Where the Implementations Differed

A closer look at the code revealed meaningful trade-offs:

One approach prioritized UX richness and localization

The other emphasized modular helpers, safer selectors, and test coverage

A concrete example:

encodeURIComponent(...) vs CSS.escape(...)

Both work, but only one is designed for DOM and selector safety.

These choices matter months later, not minutes after generation.

Why Unit Tests Made the Difference

Only one implementation introduced unit tests covering:

State migration

Regex escaping

Replacement logic edge cases

Those tests didn’t just validate correctness —
they made the regression visible.

Without them, the bug would likely ship.

Takeaway

If you evaluate AI coding tools in real projects, ask:

What existing behavior is protected?

What assumptions remain implicit?

What breaks quietly?

Demos won’t answer those questions.
Production code will.

Final Thought

The most valuable result wasn’t the feature.

It was identifying where AI coding systems still fail like junior engineers —
and where they don’t.

That distinction is what matters in real-world software.

Why WebAuthn Feels Easy — Until You Try to Ship It

dqj — Thu, 08 Jan 2026 13:14:04 +0000

Every WebAuthn demo works. Production is where things quietly fall apart.

WebAuthn demos are dangerously convincing.

You follow a tutorial, register a passkey, authenticate successfully, and everything feels… solved.

No passwords. No OTPs. No friction.

Then you ship it.

And suddenly:

Users authenticate when they shouldn’t
Counters behave strangely
Different browsers disagree
Enterprise customers ask questions your demo never prepared you for

This gap — between “it works” and “it survives production” — is where most WebAuthn implementations fail.

After watching teams repeat the same mistakes for years, three gaps show up again and again.

Gap #1: Demo-Grade Database Access

Most WebAuthn demos include some version of this:

async function getUser(username) {
  const query = `SELECT * FROM users WHERE username = '${username}'`;
  return db.query(query);
}

It works in development.

It works in testing.

It even works in staging.

Until a real username contains a quote — or someone decides to try ' OR '1'='1.

This isn’t a WebAuthn problem.

It’s a production engineering problem that demos ignore.

Production systems parameterize everything, including dynamic IN clauses:

function buildInClause(values) {
  if (!Array.isArray(values) || values.length === 0) {
    return { clause: '(NULL)', params: [] };
  }

  const placeholders = values.map(() => '?').join(',');
  return {
    clause: `(${placeholders})`,
    params: Array.from(values)
  };
}

The difference isn’t elegance — it’s survivability.

Gap #2: “One-Call” Verification Illusions

Demo verification often looks like this:

await fido2.verify(response);

Clean. Minimal. Completely insufficient.

In production, this single call hides multiple attack surfaces:

Replay attacks
Counter rollback (cloned authenticators)
Origin spoofing
Challenge reuse across sessions
Native app origin edge cases

Real verification logic validates every layer:

if (counter <= prevCounter && counterSupported) {
  throw new Error("counter rollback detected");
}

if (origin !== expectedOrigin) {
  throw new Error("origin mismatch");
}

Counters, origins, encoding, challenge binding, RP ID — none of these are optional in production.

If you skip one, authentication still “works” — until it doesn’t.

Gap #3: The Myth of “Single-Domain” WebAuthn

Demos assume:

One RP ID
One domain
One policy

Production environments don’t.

Real systems need to handle:

Multiple subdomains
Wildcard RP IDs
Enterprise authenticator allowlists (AAGUID-based)
Device limits per user
Per-tenant timeouts
Device binding

Configuration stops being a constant and becomes data:

{
  "domain": ".example.com",
  "device_limit": 2,
  "registration_session_timeout": 999
}

This isn’t complexity for complexity’s sake.

It’s the minimum required to support real organizations.

What “Production-Ready” Actually Means

Area	Demo Reality	Production Reality
Database	String queries	Parameterized everywhere
Verification	Single function	Multi-layer validation
Domains	localhost	Wildcards & subdomains
Counters	Ignored	Rollback detection
Policy	Hardcoded	Per-tenant configuration

None of these failures are obvious in demos.

All of them show up after users trust your system.

The Hard Truth About WebAuthn

WebAuthn is easy to demonstrate.

It is hard to operate safely.

The problem isn’t the standard — it’s the illusion that a passing demo equals a shippable system.

If you’re planning to deploy passkeys beyond a prototype, treat demos as educational tools, not architectural references.

Because in authentication, failure rarely looks like an error.

It looks like success — for the wrong user.

I work on WebAuthn systems that need to survive real-world traffic, browsers, and enterprise constraints.

Most of the lessons above came from fixing things that “worked fine” — until they didn’t.