A maintainer created an API token in a package registry, copied it into a CI secret store, and allowed a workflow to use it every time a release was published. The token might remain valid for months or years. It might have access to one package, several packages, or an entire organization.

The model was simple.

It was also fragile.

A reusable publishing token can leak through logs, compromised dependencies, malicious workflow changes, exposed build environments, copied configuration, or a maintainer's local machine. Once stolen, it can often be reused from somewhere else until it expires or someone notices and revokes it.

That risk is no longer theoretical enough to ignore.

Package registries and CI platforms are moving toward a different model called trusted publishing. Instead of storing a permanent registry credential, the release workflow proves its own identity using OpenID Connect, or OIDC. The registry verifies claims about the CI provider, repository, workflow, environment, and other context. It then issues a short-lived, tightly scoped credential for that release.

The workflow does not need to remember a registry password.

It proves what it is.

This model is already available across npm, PyPI, RubyGems, NuGet, and other ecosystems. npm trusted publishing reached general availability in 2025 and supports GitHub Actions, GitLab CI/CD, and CircleCI. In 2026, npm added staged publishing, allowing CI to submit a package into a review queue while requiring a human maintainer with two-factor authentication to approve the final release.

This is more than a token replacement.

Software publishing is becoming an identity, policy, and provenance system.

Why package publishing outgrew static tokens

Long-lived tokens became common because automation needed a non-interactive credential.

A human maintainer could authenticate with a password and two-factor authentication, but a release workflow needed something it could use without waiting for a person. Registries solved this by issuing API tokens.

The CI configuration usually looked like this:

- name: Publish package
  run: npm publish
  env:
    NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

The workflow was automated, but the security model was still based on possession of a secret.

Whoever had the token could act as the publisher.

A static secret has a long attack window

A long-lived token may remain usable long after it is copied.

If an attacker steals it today, they may be able to use it tomorrow, next week, or next month. The registry usually cannot tell whether the request came from the intended CI workflow or from an unrelated machine.

A registry can reduce the risk with scoped tokens, expiration dates, two-factor authentication, and secret scanning. Those controls help, but they do not change the basic model.

The token is still a reusable bearer credential.

If you possess it, the registry may trust you.

Rotation creates operational debt

Security teams often respond to reusable credentials by requiring regular rotation.

That sounds simple until an organization publishes hundreds of packages through many workflows.

Every token has a lifecycle:

• Creation

• Scope assignment

• Secret storage

• Distribution to the correct workflow

• Rotation

• Revocation

• Incident response

• Offboarding

• Audit

Rotation can fail in several ways.

A new token is created but not installed in every workflow. An old token remains active after replacement. A package is maintained by a team that no longer exists. A release job silently depends on a token nobody remembers. A token with organization-wide access is reused because per-package management feels too expensive.

The more packages an organization owns, the more credential management starts to look like infrastructure.

Secrets are copied into systems that do not need permanent authority

A release job may run for a few minutes.

Why should it hold a credential that remains valid for months?

The mismatch is important.

A workflow needs temporary permission for one action. A long-lived token gives it persistent authority before, during, and after the release.

Trusted publishing closes that gap.

Token scope often grows for convenience

Maintainers know least privilege is important.

Real workflows still drift toward broad access.

One token may publish many packages. One organization secret may be shared across repositories. A token may have bypass-two-factor privileges because CI cannot complete an interactive challenge. An old automation token may keep write access after the workflow is retired.

This is not always negligence. It is often a usability problem.

When secure credential management is hard, teams choose the path that keeps releases working.

A better publishing model should reduce both risk and maintenance.

Package publishing is a high-value supply chain boundary

A package release is not an ordinary API call.

A compromised release can reach thousands or millions of downstream users. A malicious version may be installed automatically through dependency updates, build pipelines, developer machines, and production deployments.

That makes publishing credentials unusually valuable.

The attacker does not need to compromise every consumer. They only need to compromise the publisher once.

The software supply chain turns one publishing action into widespread distribution.

That is why package registries are moving away from credentials that can be copied and reused anywhere.

How trusted publishing changes authentication

Trusted publishing replaces secret possession with workload identity.

The CI platform becomes an identity provider. During the release job, it creates a short-lived OIDC token containing signed claims about the running workload.

The package registry verifies those claims against a policy configured by the package owner.

If the identity matches, the registry issues temporary publishing authority.

The important change is that the release authority is created just in time.

There is no permanent registry secret sitting in the repository settings.

OIDC tokens describe the workload

An OIDC identity token can include claims such as:

• Token issuer

• Intended audience

• Repository owner

• Repository name

• Workflow file

• Commit reference

• Branch or tag

• Environment

• Job identity

• CI project or pipeline identifier

The exact claim set depends on the provider.

A registry policy might say:

Allow the workflow release.yml in repository acme/payments-sdk to publish package @acme/payments-sdk when the workflow runs in the npm-production environment.

That is much more specific than:

Allow anyone with this token to publish.

The workflow identity is cryptographically signed by the CI platform. The registry verifies it without sharing a permanent secret with the workflow.

Short-lived credentials reduce replay value

PyPI documents that the API tokens created through its trusted publishing flow expire no more than 15 minutes after authorization. NuGet describes temporary API keys valid for one hour and issued through a one-token, one-key exchange.

The exact lifetime varies by registry.

The principle is the same.

A stolen short-lived credential has a small reuse window. It is also scoped to the publishing operation and package policy.

This does not make theft harmless. OIDC tokens and temporary credentials are still sensitive. An attacker who steals one quickly may use it before expiration.

But the damage window is much smaller than with a token that remains active for months.

npm trusted publishing is now a practical workflow

npm trusted publishing currently supports:

• GitHub Actions on GitHub-hosted runners

• GitLab CI/CD on GitLab.com shared runners

• CircleCI Cloud

npm's current documentation requires npm CLI 11.5.1 or later and Node.js 22.14.0 or later for trusted publishing.

A package owner configures the trusted publisher in npm by selecting the CI provider and identifying the allowed repository and workflow. npm can also restrict the relationship to direct publishing, staged publishing, or both.

A minimal GitHub Actions publishing workflow looks like this:

name: Publish package

on:
  release:
    types: [published]

permissions:
  contents: read
  id-token: write

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: npm-production

    steps:
      - name: Check out source
        uses: actions/checkout@v6

      - name: Set up Node.js
        uses: actions/setup-node@v6
        with:
          node-version: 24
          registry-url: https://registry.npmjs.org

      - name: Install dependencies
        run: npm ci

      - name: Test package
        run: npm test

      - name: Build package
        run: npm run build

      - name: Publish package
        run: npm publish --access public

There is no NPM_TOKEN secret.

The id-token: write permission allows GitHub Actions to request an OIDC token for the job. npm detects the supported OIDC environment and performs the trusted publishing exchange.

The workflow still needs protection. Removing the registry token does not make the workflow safe by itself.

Trusted publishing is spreading across ecosystems

This is not an npm-only feature.

PyPI calls the model Trusted Publishers and supports identity exchange from providers including GitHub Actions, GitLab CI/CD, Google Cloud, and ActiveState. RubyGems supports trusted publishing from GitHub Actions. NuGet is rolling out a similar trusted publishing policy based on GitHub Actions OIDC.

The OpenSSF has published guidance for package repositories to adopt the same architecture.

The implementations are not identical, but the architectural direction is consistent.

Registries are learning to trust workload identities instead of stored credentials.

The CI workflow becomes part of the authorization boundary

With a static token, the main security object is the secret.

With trusted publishing, the main security object is the workflow identity and the code that can invoke it.

This changes what maintainers need to protect.

The release workflow file, branch protection, environment rules, tag creation, repository permissions, and reusable workflow dependencies all become part of the publishing authorization path.

That is not a drawback. Those controls were already important.

Trusted publishing makes the real trust boundary explicit.

Identity is not integrity

Trusted publishing answers an important question:

Did this publishing request come from the workflow identity that the package owner authorized?

It does not answer every supply chain question.

It does not prove that the source code is safe. It does not prove that the dependencies are safe. It does not prove that the workflow built the intended files. It does not guarantee that a maintainer's repository account was not compromised.

Authentication is one layer.

A mature publishing pipeline also needs provenance, review, and verification.

Provenance links a package to its build

Build provenance is signed metadata describing how an artifact was produced.

It may include:

• Source repository

• Commit SHA

• Workflow

• Build environment

• Triggering event

• Artifact digest

• Build instructions

npm can automatically generate provenance attestations when trusted publishing is used with supported providers. Its documentation currently lists GitHub Actions and GitLab CI/CD for provenance generation.

GitHub artifact attestations use OIDC identity and Sigstore to create signed claims about build artifacts. For public repositories, the generated bundle is also recorded in a public transparency log.

Provenance lets consumers verify that the package was built by the expected workflow from the expected repository and commit.

It does not prove the code was good.

It makes the origin inspectable.

Trusted publishing and provenance solve different problems

These controls reinforce each other.

Trusted publishing without provenance authenticates the publisher but gives consumers less information about the artifact.

Provenance without verification creates metadata nobody uses.

A signed artifact without a protected build workflow may faithfully prove that an attacker-controlled workflow produced it.

Supply chain security depends on connected controls.

Staged publishing adds proof of presence

npm staged publishing became generally available in May 2026.

Instead of making a package immediately installable, the CI workflow uploads the prebuilt package tarball into a stage queue. A maintainer reviews and approves it with two-factor authentication before the version becomes public.

This separates automation from final release authority.

The CI system can build and submit the package, but it cannot silently make it public if the trusted publisher is configured for stage-only access.

A recommended npm design is:

1. Configure a trusted publisher that allows npm stage publish but not direct npm publish.

2. Let CI build, test, and upload the package to the stage queue.

3. Require a maintainer to inspect and approve the exact staged artifact.

4. Publish the already staged tarball without rebuilding it.

This provides two different assurances:

• The package came from the authorized workflow.

• A human maintainer was present for the final release.

Build once and promote the same artifact

A common release mistake is rebuilding at every stage.

The artifact tested in CI may not be byte-for-byte identical to the artifact published later. Dependency resolution, timestamps, environment differences, generated files, or compromised release infrastructure can change the result.

A stronger pipeline builds once, records the digest, stages that artifact, and promotes the same bytes.

The package digest becomes the identity of the release artifact.

The release pipeline should not quietly replace it after approval.

Provenance becomes valuable when policy checks it

GitHub's artifact attestation documentation is clear that generating attestations alone does not create the full security benefit. Consumers or deployment systems need to verify them.

A policy might require:

• Artifact digest matches the downloaded package

• Provenance issuer is GitHub Actions

• Repository belongs to the expected organization

• Workflow is an approved reusable workflow

• Build originated from a protected branch or signed tag

• Environment matches production release policy

• Attestation is present and cryptographically valid

  

This is where publishing security starts to connect with deployment security.

A package is not trusted merely because it exists in a registry. It is accepted because its identity and provenance match policy.

What trusted publishing does not solve

Trusted publishing removes one dangerous class of long-lived publishing secret.

It does not make the release pipeline invulnerable.

The attack surface moves from token storage toward source control, workflow authorization, CI execution, and dependency integrity.

Teams need to understand that shift.

A malicious workflow can still publish malicious software

If an attacker can modify the authorized workflow or the source code it builds, the workflow identity may still be valid.

The registry sees the correct repository and workflow. It cannot know that the workflow was changed maliciously unless surrounding controls prevent or detect that change.

Protect release workflows with:

• Branch protection

• Required pull-request reviews

• CODEOWNERS for workflow files

• Protected tags

• Restricted release permissions

• GitHub environment approvals where appropriate

• Minimal repository write access

• Audit logging

• Security review for reusable workflows

Trusted publishing should be paired with source control governance.

Third-party actions and build dependencies remain powerful

A release workflow often runs code from:

• GitHub Actions

• Build plugins

• Package managers

• Compilers

• Test tools

• Release automation libraries

• Shell scripts

Any of these may influence the package contents or steal temporary credentials during the short window when they exist.

Short-lived does not mean inaccessible.

Reduce risk by:

• Pinning third-party actions to immutable commit SHAs

• Reviewing action source and permissions

• Keeping id-token: write limited to the publish job

• Running untrusted tests in a separate job without publishing authority

• Avoiding secret access in pull-request workflows from forks

• Using lockfiles and deterministic dependency installation

• Separating build and release roles where practical

The release job should be small and boring.

OIDC trust policy can be misconfigured

A trusted publisher policy that is too broad can authorize more workflows than intended.

Risky configurations include:

• Trusting an entire organization without workflow restrictions

• Allowing an unprotected branch

• Omitting an environment condition where one is available

• Trusting a reusable workflow that many unreviewed repositories can call

• Allowing both direct and staged publishing when only staged publishing is needed

• Keeping old trusted publisher policies after repository migration

Treat trust policy like an API authorization rule.

Review it regularly.

Temporary credentials are still credentials

PyPI warns that OIDC tokens and the short-lived API tokens exchanged from them are sensitive.

An attacker who intercepts one may use it before expiration.

Do not print tokens to logs. Do not pass them through unnecessary steps. Do not expose them to untrusted build scripts. Do not assume a fifteen-minute credential cannot cause damage.

The shorter lifetime reduces impact.

It does not remove the need for isolation.

Private dependencies may still require secrets

Trusted publishing solves authentication to the destination registry for publishing.

The build may still need credentials to download private dependencies, access a private artifact store, query a signing service, or read release metadata.

Those credentials need their own security model.

Use workload identity for those systems where possible. When tokens remain necessary, keep them short-lived, narrowly scoped, and isolated from untrusted steps.

Do not celebrate a tokenless publish while leaving organization-wide package-read tokens exposed to the same job.

Self-hosted runner support varies

npm's current trusted publishing documentation supports hosted environments from GitHub Actions, GitLab CI/CD, and CircleCI Cloud. It states that self-hosted runners are not currently supported.

This limitation matters for organizations with private networks, custom hardware, compliance requirements, or internal build farms.

Do not work around it by silently restoring a broad permanent token.

Consider:

• Building on self-hosted infrastructure, then publishing from a small hosted release job

• Using staged publishing so hosted CI can submit an already verified artifact

• Keeping a narrowly scoped expiring token as a temporary exception

• Using an internal registry that supports workload identity

• Tracking provider support and revisiting the design later

Migration may need an interim architecture.

Trusted does not mean safe

The word trusted can be misleading.

A trusted publisher is an authorized workload identity. It is not a guarantee that the package is free from malware, vulnerabilities, backdoors, or unsafe behavior.

PyPI's documentation explicitly makes this distinction. GitHub says artifact attestations establish origin and integrity claims, not that the artifact is secure.

Consumers still need:

• Dependency review

• Vulnerability scanning

• Malware analysis

• Version pinning

• Lockfiles

• Update policy

• Runtime controls

• Incident response

Authorization is not endorsement.

A practical migration roadmap

Moving away from long-lived publishing tokens should be a controlled identity migration.

The goal is not only to delete a secret. The goal is to make the release path easier to understand, harder to impersonate, and more accountable.

Step one: inventory every publishing credential

Find all credentials that can upload or modify packages.

Search:

• CI secret stores

• Organization secrets

• Repository secrets

• Local .npmrc, .pypirc, and equivalent files

• Password managers

• Release scripts

• Container images

• Infrastructure configuration

• Old automation systems

• Maintainer documentation

For each credential, record:

You cannot remove credentials you do not know exist.

Step two: map package ownership and release identity

Decide which repository and workflow should be allowed to publish each package.

One package should have a clear release source.

Questions to answer:

• Which repository owns this package?

• Which workflow builds the release?

• Which branch or tag starts publishing?

• Is a deployment environment used?

• Who can edit the workflow?

• Who can create the release tag?

• Who approves production releases?

• Does the package need direct or staged publishing?

This is a governance exercise as much as a technical one.

Step three: make the workflow deterministic and reviewable

Before adding publishing authority, simplify the release job.

A good release workflow should:

1. Check out a reviewed commit.

2. Install dependencies from a lockfile.

3. Run tests.

4. Build the package.

5. Inspect the package contents.

6. Generate or attach provenance.

7. Stage or publish the exact artifact.

For npm, include a package inspection step:

- name: Preview package contents
  run: npm pack --dry-run

This helps catch credentials, source maps, test fixtures, local files, and oversized output before release.

Step four: configure the trusted publisher

For npm, configure the relationship in the package settings or through the npm trust command.

Bind the policy to the exact CI identity:

• Provider

• Repository or project

• Workflow file or pipeline definition

• Environment where supported

• Allowed action

Prefer stage-only access for sensitive or widely used packages.

Delete obsolete trust relationships after repository or workflow changes.

Step five: remove the permanent publish token from CI

Update the release workflow to request OIDC identity and publish without the registry token.

For GitHub Actions, keep permissions explicit:

permissions:
  contents: read
  id-token: write

Do not give broad repository permissions to the publishing job unless it genuinely needs them.

Remove:

env:
  NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

After a successful test release, revoke the old token rather than leaving it as an undocumented fallback.

A credential that remains active is still an attack path.

Step six: add staged publishing where the risk justifies it

Use staged publishing for:

• Popular public packages

• Security-sensitive libraries

• Organization-wide SDKs

• Packages used in production infrastructure

• Releases with many downstream consumers

• Maintainer teams that want proof of human presence

The workflow command becomes:

npm stage publish --access public

The maintainer then approves the package from npm after reviewing the staged contents and metadata.

This gives CI automation and human review separate roles.

Step seven: generate and verify provenance

Confirm that the published package includes provenance where the registry and provider support it.

Check that provenance points to:

• Correct repository

• Correct commit

• Correct workflow

• Correct package version

For internal deployment systems, define policy for consuming packages and containers.

Examples:

• Only install packages with expected repository provenance.

• Only deploy containers built by approved reusable workflows.

• Reject artifacts without an attestation in production.

• Record verified digests in release metadata.

Provenance becomes useful when automated systems check it.

Step eight: harden the release source

Once the package registry trusts a workflow, secure the path that controls that workflow.

Recommended controls:

• Require pull requests for the default branch.

• Require reviews from package owners.

• Add .github/workflows/ or equivalent paths to CODEOWNERS.

• Protect release tags.

• Restrict who can create releases.

• Use environment reviewers for production publishing.

• Pin third-party actions.

• Separate test jobs from the OIDC-enabled publish job.

• Avoid running untrusted pull-request code with release authority.

• Review reusable workflow callers.

The registry now trusts your CI identity.

Make that identity difficult to hijack.

Step nine: monitor publishing as a security event

Publishing should create a clear audit trail.

Track:

• Package name and version

• Artifact digest

• Source commit

• Workflow run

• Publisher identity

• Provenance status

• Stage approver

• Approval time

• Release time

• Failed publishing attempts

• Trust policy changes

• Credential creation and revocation

Alert on unusual events:

• Release from an unexpected workflow

• Publishing outside normal branches or tags

• Package version created without provenance

• Direct publish when stage-only is expected

• Trusted publisher configuration changes

• New owner or maintainer added

• Repeated failed token exchanges

A release is a production change.

Observe it like one.

Step ten: scale the model across many packages

Large organizations need reusable release architecture.

Possible pattern:

A shared workflow can standardize:

• Node and package manager versions

• Test requirements

• Package inspection

• Provenance

• Staged publishing

• Release metadata

• Notifications

• Audit collection

Be careful with reusable workflows. They become high-value infrastructure. Protect their repository, review changes carefully, and version them safely.

The target architecture

A mature release path has several layers of trust.

No single control carries the whole security model.

• Source review protects the code and workflow.

• OIDC authenticates the publishing workload.

• Short-lived credentials reduce replay value.

• Provenance records origin and build context.

• Staging adds human presence.

• Verification lets consumers enforce policy.

This is the larger change behind trusted publishing.

Software release is moving away from a secret copied into CI.

It is becoming a chain of verifiable identities and decisions.

A long-lived token says:

Whoever holds me may publish.

A modern publishing pipeline says:

This approved workflow, from this repository, running in this protected environment, may submit this exact artifact, with this provenance, for this package, for a short period of time, under this release policy.

That is a much stronger statement.

And it is quickly becoming the new baseline for publishing software.

References

• npm trusted publishing documentation

• npm staged publishing documentation

• npm provenance documentation

• GitHub changelog, npm trusted publishing with OIDC

• GitHub changelog, npm staged publishing

• GitHub changelog, npm CircleCI trusted publishing support

• GitHub artifact attestations

• GitHub OpenID Connect documentation

• PyPI trusted publishing documentation

• PyPI trusted publishing security model

• RubyGems trusted publishing guide

• NuGet trusted publishing documentation

• OpenSSF trusted publishers for package repositories

• OpenSSF principles for package repository security

• SLSA supply chain levels

For years, the replacement story was always just around the corner. Biometrics would replace passwords. Security keys would replace passwords. One-time codes would replace passwords. Password managers would make passwords painless enough that we could stop worrying about them.

Yet passwords stayed.

They stayed because they were universal. Every browser understood them. Every device could type them. Every support team knew how to reset them. Every application already had a password field, a database column, a recovery flow, and years of operational knowledge built around the same flawed credential.

Passkeys are different because they are no longer just a promising security standard. They have reached the point where billions of credentials are in use, every major platform supports them, enterprise identity systems can deploy them, and users increasingly encounter them in normal account flows.

The FIDO Alliance reported in May 2026 that an estimated 5 billion passkeys were in active use. Its consumer survey found that 90 percent of respondents were familiar with passkeys and 75 percent had enabled them on at least some accounts. In the workforce survey, 68 percent of organizations said they were deploying, piloting, or rolling out passkeys for employee authentication.

That is not the end of passwords.

It is the start of a serious migration away from them.

The interesting question is no longer whether passkeys work. They do.

The interesting questions are harder:

• How do passkeys actually prevent phishing?

• What happens when a user loses a device?

• Are synced passkeys safe enough for enterprise use?

• How should applications support users who are not ready?

• What happens to account recovery?

• How do teams migrate without creating a confusing login page?

• When should a company require device-bound credentials instead?

• Does password fallback cancel the security benefit?

This article looks at those questions from a product and engineering perspective.

Why passkeys crossed the mainstream threshold

Passkeys did not become mainstream because one company launched a new login button.

They became mainstream because several parts of the ecosystem matured at the same time.

The major platforms now agree on the model

Passkeys are built on the FIDO2 stack, which combines Web Authentication, usually called WebAuthn, with the Client to Authenticator Protocol, or CTAP.

WebAuthn defines how a website or application creates and uses public-key credentials. CTAP defines how a client platform communicates with authenticators, including built-in device authenticators, phones, and hardware security keys.

Apple, Google, Microsoft, browser vendors, password managers, and identity providers now support the same basic model.

Apple supports passkeys through iCloud Keychain and external credential providers. Google Password Manager syncs passkeys across Android and Chrome environments. Windows provides native passkey creation and management. Microsoft Entra supports both device-bound and synced FIDO2 passkeys. Third-party password managers can store passkeys on supported systems.

That shared platform support matters more than any single product announcement.

Authentication is an ecosystem problem. A credential only becomes practical when it works across browsers, operating systems, applications, credential managers, and devices.

Passwords won because they worked everywhere.

Passkeys are now close enough to that level of availability to become a default rather than an experiment.

The adoption numbers are no longer small

The FIDO Alliance's 2026 report surveyed 11,000 consumers and 1,400 workforce decision-makers across ten countries. It reported:

The details matter.

Awareness is not the same as understanding. Enabling a passkey on one account is not the same as abandoning passwords. Piloting passkeys is not the same as completing an enterprise migration.

Still, these are mainstream adoption signals.

Passkeys are no longer limited to security teams, developers, and users carrying hardware keys.

They are becoming part of normal account creation and sign-in.

User experience finally became competitive

Security improvements often fail when they make login harder.

Passkeys have a chance because the secure action can also be the easier action.

A user can sign in by unlocking a device with a fingerprint, face scan, PIN, or pattern. The relying party does not receive the biometric data. The local device uses that gesture to unlock the private key and produce a cryptographic signature.

Microsoft reports that, in its Entra experience, synced passkeys were significantly faster and more successful than legacy password plus MFA flows. Its documentation says users completed synced passkey sign-in in about 3 seconds compared with 69 seconds for a password plus traditional MFA combination, with a 95 percent sign-in success rate compared with 30 percent for the legacy flow.

Vendor-reported measurements need context, but the direction is believable. Passkeys remove several fragile steps:

• Remember a password

• Enter the password correctly

• Wait for a code

• Switch apps

• Copy the code

• Return to the login screen

• Hope the code has not expired

• Repeat after a mistake

A case study published by Google reports that Dashlane saw a 92 percent conversion rate when users were offered an available passkey, compared with 54 percent for automatic password sign-in opportunities. Dashlane also reported a 63 percent conversion rate for passkey registration opportunities compared with roughly 25 percent for password-save prompts.

Passkeys are succeeding because they are not merely more secure.

When the flow is designed well, they are easier.

Portability and management are improving

Early passkey criticism focused heavily on ecosystem lock-in.

A passkey saved to one platform account did not necessarily move easily to another credential manager. A user switching ecosystems could end up with confusing recovery paths or duplicate credentials.

That problem is not completely gone, but the ecosystem is improving.

Apple now describes support for secure passkey import and export between password managers. W3C work on passkey endpoints aims to make enrollment and management pages discoverable to credential managers. Password managers increasingly support passkey storage, synchronization, and cross-device use.

The result is a system that feels less like a credential trapped on one phone and more like an authentication method that can survive device changes.

Mainstream does not mean complete

The 5 billion figure is a milestone, not proof that passwords are gone.

Many services still keep passwords as fallback. Many users do not know where their passkeys are stored. Cross-platform behavior can still be confusing. Recovery can still fall back to weak channels. Enterprise requirements vary. Shared-device and regulated environments need stronger controls.

Passkeys are mainstream because the default path is now viable.

The next phase is about making the whole account lifecycle secure.

How passkeys actually work

The best way to understand passkeys is to forget the fingerprint for a moment.

A fingerprint is not the passkey.

Face ID is not the passkey.

A device PIN is not the passkey.

Those are local methods used to unlock the authenticator.

The passkey itself is a public-key credential.

Registration creates a key pair

When a user creates a passkey, the application asks the browser or operating system to create a WebAuthn credential.

The authenticator creates a cryptographic key pair:

• A private key, which stays with the authenticator or protected credential provider

• A public key, which is sent to the relying party and stored with the user's account

The server does not receive the private key.

It also does not need the user's fingerprint, face data, or device PIN.

The server stores data such as:

• Credential ID

• Public key

• User handle

• Signature counter where applicable

• Authenticator metadata where applicable

• Creation time

• Friendly device or provider label

• Backup and transport-related flags where available

The exact implementation depends on the WebAuthn library and policy.

Authentication proves possession of the private key

During sign-in, the server generates a fresh random challenge.

The authenticator signs that challenge with the private key after the user unlocks it locally. The server verifies the signature using the stored public key.

The challenge prevents replay.

An attacker cannot capture one successful response and reuse it later because the next login uses a different challenge.

Origin binding blocks normal phishing flows

This is the feature that makes passkeys fundamentally different from passwords and one-time codes.

A password is a shared secret. The user can type it into the real site or a fake site. The fake site can steal it.

A one-time code is also transferable. A phishing page can ask for the code and relay it to the real service.

A passkey is scoped to a relying party.

A credential created for example.com cannot be used by examp1e.com, even if the fake site looks identical.

The browser and authenticator jointly enforce this relationship.

This is why passkeys are described as phishing-resistant.

The protection is not based on the user noticing a suspicious URL.

The credential itself will not authenticate to the wrong relying party.

The biometric never goes to the server

Passkey interfaces often display Face ID, fingerprint, Windows Hello, or a device unlock screen. That leads some users to assume the website receives biometric information.

It does not.

The biometric is handled by the local platform. Its job is to authorize use of the private key.

Google's passkey documentation explicitly notes that biometric material never leaves the user's device. The server receives a signed cryptographic assertion, not a fingerprint image or facial template.

This separation matters for privacy.

The application does not become a biometric database.

Synced passkeys and device-bound passkeys are different

The word passkey covers more than one storage model.

A synced passkey is often the right choice for normal consumer accounts. It reduces the chance that device loss becomes account loss.

A device-bound passkey may be more appropriate for administrators, regulated users, privileged employees, or environments that need attestation and stronger device provenance.

Microsoft recommends FIDO2 security keys for highly regulated industries and elevated users, while describing synced passkeys as a practical option for most normal users.

This is a risk decision, not a debate about which type is universally better.

Cross-device authentication fills the gaps

A passkey does not need to exist on the device where the user is signing in.

Cross-device authentication lets a phone act as the authenticator for a laptop or another nearby device. A common flow uses a QR code and proximity checks, with the user approving the sign-in on the phone.

This improves practical interoperability.

A user can sign in on a borrowed or newly set up computer without manually copying a secret.

What passkeys solve and what they do not

Passkeys solve important authentication problems.

They do not solve identity as a whole.

That distinction is essential.

They remove reusable server-side password secrets

Traditional password systems store password hashes, not plaintext passwords when implemented correctly. Still, password databases are valuable targets because weak, reused, or cracked passwords can lead to account compromise.

With passkeys, the relying party stores public keys.

A stolen public key does not let an attacker authenticate.

That reduces the value of a credential database breach.

It does not make the entire account database harmless. Attackers still care about personal data, sessions, reset tokens, API keys, recovery methods, authorization records, and application vulnerabilities.

Passkeys reduce one major category of risk.

They do not remove the need for application security.

They resist credential stuffing

Credential stuffing depends on password reuse.

An attacker obtains an email and password pair from one breach, then tests it across many services.

Passkeys are unique to the relying party. There is no shared secret to reuse across sites.

This removes the basic economic model of credential stuffing for passkey-only accounts.

They remove many OTP phishing attacks

SMS codes, email codes, and authenticator-app codes can be phished because they are values a user can transfer to an attacker.

Passkeys are origin-bound.

That provides stronger phishing resistance than password plus SMS or password plus TOTP.

This does not mean all session theft disappears. Malware, compromised devices, malicious browser extensions, stolen session cookies, authorization bugs, and social engineering can still cause harm.

Authentication is one layer.

They reduce password reset volume

Password resets are expensive.

They create support costs, frustration, abandoned sign-ins, and security risk. Recovery flows are also common attack targets because they often use weaker verification than normal authentication.

Passkeys can reduce reset frequency because users do not need to remember a site-specific secret. Synced passkeys can survive device replacement when the credential provider restores them securely.

That is a major operational benefit.

But it only works if applications avoid rebuilding a weak password-reset system under a different name.

They do not prove the user is the person you think they are

A successful passkey authentication proves control of a credential bound to an account.

It does not automatically prove a legal identity, employee status, age, citizenship, license, or real-world person.

Identity proofing and authentication are separate processes.

Passkeys can strongly authenticate an enrolled account. They do not tell you whether the original enrollment was legitimate.

They do not replace authorization

A passkey answers:

Is this user in control of a valid credential for this account?

It does not answer:

Is this user allowed to refund $50,000?

Can this employee read this customer record?

Should this administrator be allowed to rotate production keys?

Authorization rules still matter.

High-risk actions may also require step-up authentication, transaction confirmation, approval, or device policy.

They do not automatically secure account recovery

This is the biggest design trap.

A service may advertise phishing-resistant passkeys while keeping a password, SMS code, or weak help-desk flow that can fully recover the account.

An attacker will use the weakest path.

If a phishable fallback can replace the passkey, the account is still phishable.

Passkeys can still improve everyday sign-in, but the service has not achieved full phishing resistance.

They do not remove device security

A passkey is only as safe as the environment that can unlock it.

If an attacker can unlock the device, control the operating system, compromise the credential provider account, or steal an active session, the account may still be at risk.

Passkeys reduce remote phishing and password attacks.

They do not make endpoint security irrelevant.

The hard parts are migration and recovery

The cryptography is not the hardest part of passkey adoption.

The account lifecycle is.

A production rollout has to support new users, existing users, multiple devices, lost devices, platform changes, shared devices, fallback, customer support, credential deletion, account recovery, and policy differences.

Do not force a sudden passwordless cutover

The safest rollout usually starts by adding passkeys to existing accounts.

A practical consumer migration looks like this:

Google's UX guidance recommends letting users authenticate through the familiar flow, clearly offering passkey creation, using the operating system dialog, and confirming successful creation without blocking the user's main task.

That is better than forcing users to understand passkeys before they can continue.

A migration should feel like an upgrade, not a security lecture.

Conditional UI makes mixed-mode sign-in cleaner

During migration, applications often support:

• Passwords

• Passkeys

• Federated sign-in

• Security keys

• Recovery paths

A poor login screen turns this into a wall of buttons.

Conditional UI lets the browser or credential manager offer a passkey inside a familiar account field or autofill flow. The user can select an available credential without navigating to a separate "use passkey" screen.

This creates a smoother transition while passwords still exist.

The product goal should be one coherent sign-in experience, not separate authentication worlds.

Passkey creation needs clear language

Many users still do not know what a passkey is.

Do not assume the operating system prompt explains the whole concept.

A good setup message should say:

• A passkey replaces the need to type a password on supported devices

• It uses the device's normal unlock method

• The website does not receive biometric data

• The user should only create it on a personal or trusted device

• The user can manage or remove passkeys later

Avoid technical explanations at the exact moment the user wants to continue.

Give a short explanation, then link to more detail.

Let users register more than one authenticator

A resilient account should not depend on one device.

For higher-value accounts, encourage users to register multiple authenticators:

• Synced passkey through a credential provider

• Second device-bound passkey

• Backup hardware security key

• Managed enterprise passkey

• Another approved phishing-resistant authenticator

NIST guidance for syncable authenticators recommends binding multiple authenticators at higher assurance levels to support recovery.

That is a better recovery strategy than falling back to SMS.

Recovery is part of the threat model

Recovery needs the same design attention as sign-in.

A good recovery model might combine:

• Another registered passkey

• Trusted device approval

• Strong identity re-verification

• Enterprise administrator workflow

• Recovery codes stored offline

• Delayed recovery for sensitive accounts

• Notifications to existing devices

• Temporary restrictions after recovery

• Human review for high-risk cases

A weak recovery model might rely on:

• Email alone

• SMS alone

• Easily guessed personal questions

• A support agent asking for public information

• Immediate replacement of all authenticators

• No notification to existing sessions

NIST warns that cloud sync-account recovery represents a potential weakness for synced authenticators. It recommends strong recovery controls, multiple authenticators, notifications, and careful protection of the sync fabric.

The key principle is simple:

Recovery should not be dramatically weaker than normal authentication.

Synced credentials move some trust to the provider account

Synced passkeys solve a real problem.

People lose phones. They replace laptops. Devices fail. Without synchronization, strong credentials can create painful recovery incidents.

But synchronization changes the trust model.

The passkey is encrypted and protected by the credential provider, but the security of that provider account and its recovery process becomes important.

For many consumer accounts, this is still a major improvement over passwords and SMS.

For high-assurance enterprise environments, the organization may prefer:

• Device-bound credentials

• Hardware security keys

• Managed device enrollment

• Attestation requirements

• Restricted credential providers

• Stronger administrator-controlled recovery

The correct choice depends on risk.

Shared devices need extra care

A passkey can be unlocked by anyone who can unlock the device.

That makes shared devices a special case.

Applications should clearly warn users not to create personal passkeys on public or shared devices. Managed environments need policies for user profiles, device ownership, credential storage, and local account separation.

Google's own user guidance warns people to create passkeys only on devices they personally own and use.

This is not a flaw in passkey cryptography.

It is a consequence of using local device access as the activation factor.

Credential management cannot stay buried

Users need a clear place to:

• View registered passkeys

• See creation dates

• See provider or device labels

• Rename credentials

• Remove lost or old credentials

• Add backup authenticators

• Review recent authentication activity

• Understand the impact of deletion

The W3C passkey endpoints work addresses a practical problem: enrollment and management pages are often hidden deep inside account settings. Standardized discovery could let credential managers direct users to the correct enrollment and management pages.

This may sound minor.

It is not.

Authentication systems fail operationally when users cannot manage their credentials.

Deleting a passkey may have side effects

Some applications can use WebAuthn extensions to derive secrets for encryption or related functionality.

If deleting a passkey affects access to encrypted data, the user needs a clear warning.

The W3C passkey endpoints draft includes a mechanism for relying parties to describe passkey use beyond authentication so credential managers can warn users during deletion.

This is a reminder that passkeys are becoming application infrastructure, not just login buttons.

Enterprise rollout needs segmentation

Not every employee needs the same credential policy.

A practical enterprise model might look like this:

The goal is not to choose one credential type for everyone.

The goal is to match assurance, convenience, cost, and support requirements.

Keep authentication and session security connected

A perfect passkey login can still lead to an insecure session.

Teams must still secure:

• Session cookies

• Token rotation

• CSRF protection

• Device and session management

• Reauthentication for sensitive actions

• Logout and session revocation

• Suspicious login detection

• Authorization checks

• Account change notifications

Passkeys strengthen the front door.

They do not secure every room inside the application.

A practical implementation roadmap

Passkey support should be treated as an identity migration, not a frontend feature.

The work spans product, backend, mobile, web, security, support, and operations.

Phase one: understand your current authentication system

Before writing WebAuthn code, map the real account lifecycle.

Document:

• Current sign-up methods

• Current sign-in methods

• MFA methods

• Password reset

• Account recovery

• Device changes

• Session management

• High-risk action verification

• Support-assisted recovery

• Account deletion

• Enterprise SSO interactions

• Fraud and abuse controls

This will reveal where the weakest paths are.

A team that adds passkeys without understanding recovery may create a strong login button attached to the same weak account system.

Phase two: define the relying party model

WebAuthn credentials are scoped to a relying party ID.

That decision affects domains and applications.

Teams need to decide:

• Which domain is the relying party ID?

• Which subdomains should share credentials?

• How do native apps associate with the web domain?

• Are there separate consumer and enterprise accounts?

• Do multiple brands share one account backend?

• Will a future domain migration be required?

This is architecture work.

A careless relying party design can create long-term migration pain.

Phase three: choose credential policy

Decide which authenticators are accepted.

Questions include:

• Are synced passkeys allowed?

• Are device-bound passkeys required for some roles?

• Are hardware security keys supported?

• Is attestation required?

• Are specific authenticator models allowed?

• Is user verification required?

• Can users register multiple credentials?

• Are resident discoverable credentials required?

• How are credentials named and managed?

Do not copy the strictest policy for every user.

A policy that creates too much friction will drive fallback use and support requests.

Phase four: implement registration correctly

A registration flow should:

1. Authenticate the user through an acceptable existing method.

2. Generate a fresh server-side challenge.

3. Bind the challenge to the user and session.

4. Provide the correct RP ID and origin expectations.

5. Request an appropriate authenticator configuration.

6. Verify the returned registration data.

7. Store the public credential and metadata.

8. Confirm successful creation.

9. Notify the user of the new authenticator.

10. Provide a direct link to credential management.

Use a maintained WebAuthn library where possible.

WebAuthn parsing and verification contain details that are easy to get wrong.

Phase five: implement authentication correctly

An authentication flow should verify:

• Challenge matches the server-issued value

• Challenge is fresh and single-use

• Origin is allowed

• RP ID hash is correct

• Credential belongs to the account or resolves to the correct user

• Signature is valid

• User presence requirements are satisfied

• User verification requirements are satisfied

• Authenticator flags are handled according to policy

• Session is created securely

Pseudocode for the server-side shape:

type StoredCredential = {
  credentialId: string;
  publicKey: Uint8Array;
  userId: string;
  signCount: number;
};

async function verifyPasskeyAuthentication(
  response: AuthenticationResponse,
  expectedChallenge: string,
  expectedOrigin: string,
  expectedRpId: string,
  credential: StoredCredential,
): Promise<boolean> {
  const result = await webauthn.verifyAuthenticationResponse({
    response,
    expectedChallenge,
    expectedOrigin,
    expectedRPID: expectedRpId,
    credential: {
      id: credential.credentialId,
      publicKey: credential.publicKey,
      counter: credential.signCount,
    },
    requireUserVerification: true,
  });

  if (!result.verified) {
    return false;
  }

  await updateCredentialCounter(
    credential.credentialId,
    result.authenticationInfo.newCounter,
  );

  return true;
}

The exact API depends on the library.

The important point is that verification belongs on the server.

Phase six: add mixed-mode UX

During migration, support existing users without making passkeys feel secondary.

Good patterns include:

• Offer passkey creation after successful sign-in

• Use conditional UI where supported

• Prefer passkeys when an available credential exists

• Keep fallback discoverable but not dominant

• Explain device unlock clearly

• Confirm which account is being used

• Avoid forcing users to choose technical authenticator types

• Show clear errors when cross-device authentication fails

• Provide a management page

The user should not need to understand WebAuthn terminology.

They need to know how to sign in.

Phase seven: redesign recovery

Do this before removing passwords.

Create a recovery matrix.

Recovery should create audit events and notifications.

Sensitive accounts may need delays or temporary restrictions after recovery.

Phase eight: monitor the rollout

Measure the full experience.

Useful metrics include:

• Passkey creation offer rate

• Passkey creation success rate

• Passkey sign-in success rate

• Cancellation rate

• Cross-device authentication success

• Fallback use

• Password reset volume

• Support tickets

• Recovery rate

• Authentication latency

• Account takeover rate

• Phishing-related incidents

• Credential deletion rate

• Number of users with backup authenticators

Do not measure only the number of created passkeys.

A passkey that is never used does not represent a successful migration.

Phase nine: reduce weak fallback gradually

Once passkey adoption and recovery are healthy, reduce password dependence.

Possible steps:

1. Make passkey the default sign-in option.

2. Stop asking passkey users to type passwords during normal sign-in.

3. Require stronger verification before adding fallback methods.

4. Remove SMS fallback from high-risk accounts.

5. Require phishing-resistant authentication for privileged roles.

6. Let users opt into passkey-only accounts.

7. Eventually make passkey-first or passwordless the default for new accounts.

Do not remove fallback simply to claim passwordless status.

Remove it when the replacement lifecycle is ready.

A reference architecture

The architecture should separate:

• Credential verification

• User account data

• Session creation

• Risk decisions

• Recovery

• Credential management

• Notifications

• Audit logging

That separation makes the system easier to test and evolve.

Testing should include the awkward cases

A serious test plan needs more than successful registration on one laptop.

Test:

• Registration on Android, iOS, macOS, Windows, and major browsers

• Synced passkey use on another device

• Cross-device authentication by QR code

• Multiple accounts on one device

• Multiple passkeys for one account

• Shared-device warning

• Credential cancellation

• Expired challenge

• Replayed assertion

• Wrong origin

• Wrong RP ID

• Deleted credential

• Lost device

• User changes credential provider

• Password fallback

• Recovery with no remaining authenticators

• Enterprise policy restrictions

• Account offboarding

• Accessibility with keyboard and assistive technology

Authentication bugs lock users out.

Treat compatibility and recovery tests as production-critical.

The final security model must be honest

A service should not claim to be phishing-resistant if a phishable recovery path can fully replace the passkey.

A service should not claim passwordless if users still need passwords for routine account maintenance.

A service should not claim biometric authentication if it does not explain that biometrics remain local.

A service should not claim enterprise-grade passkeys without a plan for lifecycle, offboarding, attestation, and recovery.

Passkeys are strong enough that weak surrounding systems become more visible.

That is a good thing.

It pushes identity teams to improve the entire account lifecycle.

Passkeys are finally becoming mainstream because the ecosystem is ready enough for normal users.

The next challenge is not proving that public-key authentication works.

It is making migration, recovery, support, and policy work just as well.

Passwords survived because they were familiar and recoverable, even when they were insecure.

Passkeys will replace them only when they become equally dependable without inheriting the same weak fallbacks.

The industry is closer than it has ever been.

This time, the passwordless future does not feel like a slogan.

It feels like an implementation plan.

References

• FIDO Alliance, The State of Passkeys 2026

• FIDO Alliance, Passkeys overview

• W3C Web Authentication Level 3

• W3C Passkey Endpoints

• Google for Developers, Passkeys

• Google passkey developer guides

• Google passkey user journeys

• Google and Dashlane passkey case study

• Apple Developer, Passkeys

• Apple Developer, What is new in passkeys

• Microsoft Learn, Passkeys in Microsoft Entra ID

• Microsoft Learn, Windows passkey support

• NIST SP 800-63B

• NIST guidance for syncable authenticators

• Passkeys.dev specifications

• Passkeys.dev device support

At first, it sounded like another name for DevOps. Then it became almost synonymous with developer portals. Then every tooling vendor started using it. For a while, it was hard to tell whether platform engineering was a real discipline or just a nicer phrase for internal tooling.

Now the picture is clearer.

Platform engineering is entering its practical era.

The useful version is not about buying a portal and hoping developers become more productive. It is about building a reliable internal platform that gives teams safe, repeatable, self-service ways to ship software.

That means golden paths. Templates. Environments. CI/CD. Observability. Security policy. Cost controls. Service catalogs. Secrets. Rollbacks. Documentation. Runtime standards. AI guardrails. All the boring pieces that make software delivery less chaotic.

The goal is simple.

Developers should not need to become part-time cloud infrastructure specialists just to ship a normal service.

They should have a paved road.

Not a cage. A road.

Why platform engineering became necessary

DevOps changed software delivery for the better.

It broke down the old wall between development and operations. It made teams care about deployment, reliability, monitoring, and production ownership. It pushed software teams closer to users and closer to real systems.

But DevOps also created a hidden problem.

Over time, developers were expected to understand everything.

They needed to know application code, cloud infrastructure, Kubernetes, CI/CD, secrets, observability, IAM, databases, queues, networking, security scanning, incident response, cost management, Terraform, YAML, dashboards, alerts, service mesh, container images, feature flags, and deployment strategies.

That is a lot.

For a senior backend engineer, some of this may be normal. For every product team, all the time, across every service, it becomes expensive.

The result is cognitive load.

Developers spend time figuring out how to ship instead of what to ship. Platform engineering exists to reduce that friction without removing ownership.

The CNCF Platforms White Paper defines a cloud native platform as an integrated collection of capabilities presented to meet the needs of its users. It also describes platforms as a cross-cutting layer that gives teams a consistent way to acquire and integrate common capabilities such as templates, portals, and self-service APIs.

That definition matters because it keeps the focus on user needs.

A platform is not a tool.

A platform is a product used by developers.

If developers avoid it, work around it, or do not trust it, the platform has failed.

Platform engineering is not DevOps replacement

Platform engineering is often described as the next evolution of DevOps. That framing is useful, but it can also be misleading.

DevOps is a culture and operating model. It is about collaboration, ownership, automation, and fast feedback between development and operations.

Platform engineering is more specific.

It builds the internal systems that make those DevOps ideas easier to practice at scale.

The CNCF blog describes platform engineering as a discipline focused on building and maintaining software development platforms that provide self-service for developer teams. That self-service can cover development, testing, documentation, deployment, rollback, and application provisioning.

That is the difference.

DevOps says teams should own production.

Platform engineering asks: what internal platform helps them do that safely?

The practical era of platform engineering starts when teams stop debating whether it replaces DevOps.

It does not.

It makes DevOps scalable.

Without a platform, every team builds its own version of delivery. One team writes custom Terraform. Another writes Helm charts. Another manually configures cloud services. Another copies a CI file from an old repo. Another forgets alerts. Another ships without cost tags. Another exposes a secret in the wrong place.

That is not autonomy.

That is fragmentation.

A good platform gives teams autonomy inside useful boundaries.

The portal is not the platform

A developer portal can be useful.

Backstage, Port, Cortex, OpsLevel, Roadie, and similar tools can help teams discover services, owners, docs, scorecards, APIs, deployments, and operational maturity. That is valuable.

But a portal alone is not a platform.

A portal is often the front door.

The platform is everything behind it.

If a developer clicks "create service" and only gets an empty repository, that is not enough.

A practical platform should help create the full delivery path:

• Repository

• Service ownership

• Runtime configuration

• CI/CD pipeline

• Container build

• Environment setup

• Secret wiring

• Observability defaults

• Security checks

• Cost tags

• Deployment strategy

• Rollback path

• Documentation starter

• On-call metadata

The portal is useful when it connects these pieces.

It is weak when it only displays them.

This is one reason some internal developer platform efforts fail. The team spends months polishing a catalog while the real developer pain remains unchanged.

Developers do not want a prettier list of broken services.

They want fewer broken paths.

Golden paths are the real product

A golden path is an approved, supported, low-friction way to build and ship something.

It does not need to cover every possible case. It should cover the common case well.

For example:

• Create a REST API service

• Create a scheduled worker

• Create a frontend app

• Create a data pipeline

• Create an internal tool

• Create a model inference endpoint

• Create a queue consumer

Each golden path should encode the team's best current knowledge.

This is where platform engineering becomes practical.

A golden path turns architecture decisions into reusable workflows.

Instead of every team asking the same questions again, the platform answers them once:

• Which base image should we use?

• How do we structure a service?

• Where do secrets come from?

• How do we deploy?

• What metrics are required?

• How do we expose an endpoint?

• How do we configure health checks?

• How do we tag cloud resources?

• How do we roll back?

• What security checks must pass?

A good golden path saves time.

A great golden path also prevents common mistakes.

The point is not standardization for its own sake.

The point is to make the right thing easier than the wrong thing.

Self-service is the practical unlock

Self-service is one of the most important ideas in platform engineering.

It does not mean developers can do anything they want.

It means they can do approved things without waiting for another team to manually complete every step.

That matters because waiting destroys flow.

A developer who needs a test environment, a queue, a database, or a deployment pipeline should not always need a ticket that sits in another team's backlog for a week.

Platform engineering replaces ticket queues with safe workflows.

The important part is the policy check.

Self-service without guardrails becomes chaos.

Guardrails without self-service become bureaucracy.

A good platform combines both.

Examples:

• Developers can create preview environments, but with expiration dates.

• Teams can provision databases, but only approved sizes.

• Services can deploy automatically, but only after tests and security checks pass.

• Teams can expose APIs, but only through approved ingress patterns.

• Engineers can request higher resource limits, but the request is visible and reviewed.

• AI-generated infrastructure changes can be proposed, but not applied without policy validation.

This is the difference between platform engineering and old-school operations.

The platform team does not become the bottleneck.

It builds the system that removes the bottleneck.

The platform team should think like a product team

The strongest platform teams do not treat developers as ticket submitters.

They treat them as users.

That changes everything.

A platform team should do product discovery. It should watch how developers work, identify repeated pain, measure adoption, remove friction, and improve the platform based on feedback.

The CNCF platform maturity model emphasizes that every organization already has some kind of internal platform, even if it is only documentation on how to use third-party services. The important work is making that platform intentional and improving it toward outcomes that matter for the organization.

That is a product mindset.

This is where many teams go wrong.

They begin with tools instead of developer pain.

They start with questions like:

• Should we use Backstage?

• Should we use Crossplane?

• Should we use Argo CD?

• Should we use Terraform or OpenTofu?

• Should we use Kubernetes?

Those are real questions, but they are not the first questions.

Better first questions are:

• What slows developers down today?

• Where do teams copy and paste infrastructure?

• Which deployments fail most often?

• Which services lack ownership?

• Where do security reviews block delivery?

• Which environments are painful to create?

• Which tasks require too many tickets?

• Where are incidents repeating?

• Where is cloud cost invisible?

The platform should solve real pain.

If it does not, developers will avoid it.

And they should.

Kubernetes and IaC became the baseline

Platform engineering does not always require Kubernetes.

A small company can build a useful platform on a PaaS, a serverless provider, a VM-based setup, or a managed application platform.

But in many cloud native organizations, Kubernetes and Infrastructure as Code have become the baseline.

PlatformEngineering.org's 2026 platform tooling guide says Kubernetes and Terraform or OpenTofu are the table stakes foundation for platform engineering in 2026. Kubernetes remains the common runtime for container orchestration, while Terraform and OpenTofu remain common ways to manage infrastructure as code.

That does not mean every developer should write Kubernetes YAML or Terraform modules.

In fact, the practical platform engineering move is often the opposite.

The platform team uses Kubernetes and IaC behind the scenes, while developers interact with higher-level workflows.

The developer should express intent:

I need a public HTTP service with Postgres and staging plus production environments.

The platform turns that intent into implementation:

• Cloud resources

• Kubernetes workloads

• Secrets

• Network policy

• Deployment pipeline

• Observability

• Cost metadata

• Runtime policy

That separation is powerful.

It lets platform experts handle infrastructure complexity once, instead of forcing every application team to rediscover it.

Policy should be built into the path

Security teams often become blockers when policy is checked too late.

A team builds a service. Then, near release, someone discovers missing encryption, weak IAM, no audit logging, exposed secrets, missing container scans, unclear ownership, or no data classification.

Now delivery stops.

Everyone is frustrated.

Platform engineering can move policy earlier.

Instead of security being a manual review at the end, the platform can encode rules into the path.

Examples of platform-level guardrails:

• Every service must have an owner.

• Every production service must emit logs and metrics.

• Every container image must be scanned.

• Every deployment must include rollback metadata.

• Every cloud resource must have cost tags.

• Public endpoints must use approved ingress.

• Secrets must come from the approved secrets system.

• Production changes must pass policy checks.

• Databases must use backup policies.

• Sensitive workloads must use stricter network rules.

Tools like Kyverno, OPA Gatekeeper, Conftest, Snyk, Trivy, Sigstore, Cosign, and policy engines in CI/CD can support this pattern. The specific tool matters less than the principle.

Policy should be close to the developer workflow.

A policy that explains itself early is useful.

A policy that surprises people at the end becomes bureaucracy.

Observability should come by default

A platform that deploys services but does not make them observable is incomplete.

Developers need to know whether their software is working.

That means logs, metrics, traces, alerts, dashboards, ownership metadata, and runbooks should not be optional extras that each team invents.

They should be part of the golden path.

This is especially important as systems become more distributed.

If every service has different logging conventions, different dashboards, different alert rules, and different ownership metadata, incident response becomes painful.

A platform can standardize the basics:

• Request latency

• Error rate

• Saturation

• Deployment events

• Health checks

• Dependency status

• Resource usage

• Cost signals

• SLO templates

• Trace propagation

• Dashboard layout

The goal is not to remove team-specific observability.

The goal is to make the baseline automatic.

A team should not need to remember to add the minimum set of production signals.

The platform should provide them.

FinOps is becoming part of the platform

Cloud cost used to feel like a finance problem.

Now it is clearly an architecture and platform problem.

Developers make decisions that affect cost every day:

• Instance size

• Database tier

• Log volume

• Retention period

• Cache strategy

• Region count

• Storage class

• Queue depth

• Build frequency

• AI model choice

• GPU usage

• Data transfer path

If the platform hides all cost information until the monthly bill arrives, developers cannot make better decisions.

A practical platform surfaces cost earlier.

PlatformEngineering.org's FinOps tooling guidance frames FinOps through reporting, recommendations, remediation, and retention of cost-aware behavior. That maps well to platform engineering because the platform already controls many delivery paths.

A platform can help by:

• Enforcing cost allocation tags

• Showing cost by service and team

• Setting default resource limits

• Creating expiration dates for preview environments

• Warning about expensive resources before deployment

• Providing cheaper golden paths

• Supporting autoscaling patterns

• Tracking AI and GPU usage

• Sampling logs where full retention is unnecessary

• Giving teams budget alerts

Cost control should not mean shaming teams.

It should mean making cost visible enough to be designed.

AI makes platform engineering more important

AI coding tools are increasing code output.

That creates pressure on delivery systems.

More generated code means more pull requests, more tests, more security checks, more CI runs, more review work, more infrastructure changes, and more potential production changes.

If the delivery system is weak, AI makes the weakness louder.

This is one reason platform engineering is becoming more important now.

Humanitec's State of Platform Engineering Volume 4 says platform teams face a dual mandate: they are expected to deliver AI-powered platforms that improve developer productivity, while also building platforms for AI workloads such as deployment, training, and scaling.

That is a huge shift.

Platform teams now need to support two related problems:

1. Developers using AI to ship software faster.

2. Teams deploying AI-enabled applications and infrastructure.

   

AI also changes the platform interface.

A future platform may not only have a portal. It may have an assistant that helps developers create services, explain failures, generate infrastructure proposals, search runbooks, and understand deployment status.

But that assistant needs boundaries.

It should not apply infrastructure changes without policy checks. It should not create cloud resources without cost controls. It should not bypass approval. It should not invent standards.

AI makes the platform more valuable because it gives AI tools a safer operating environment.

The platform becomes the guardrail layer for faster software creation.

The platform should encode organizational memory

Every engineering organization has knowledge that lives in people's heads.

How do we create a service?

How do we deploy?

Which cloud account should we use?

How do we request a database?

What is the naming convention?

Which metrics matter?

Who owns this API?

How do we handle secrets?

What does production-ready mean here?

If this knowledge is only in Slack threads and senior engineers' memory, the organization is fragile.

A platform turns that knowledge into workflows.

This is why platform engineering is not only a technical movement.

It is knowledge management.

A good platform captures decisions and makes them reusable. That helps new engineers, reduces interruptions, and lowers the chance of mistakes.

It also helps during growth.

When a company has five engineers, informal knowledge can work.

When it has fifty, it becomes painful.

When it has five hundred, it becomes impossible.

Platform engineering is how teams scale delivery without requiring every engineer to know every internal detail.

A practical reference architecture

A practical internal developer platform does not need to start huge.

But it should have a clear shape.

The pieces can vary by company.

A Kubernetes-heavy organization may use Backstage, Argo CD, Terraform or OpenTofu, Crossplane, OPA, Kyverno, Prometheus, Grafana, OpenTelemetry, Vault, and cloud provider services.

A smaller team may use a managed platform, GitHub Actions, Terraform Cloud, a simple internal CLI, hosted observability, and a few templates.

Both can be platform engineering.

The important question is not whether the platform looks impressive.

The important question is whether it reduces friction and improves safety.

Start small or it will fail

Platform engineering can easily become overbuilt.

A platform team may try to solve every problem at once:

• Every language

• Every runtime

• Every cloud

• Every deployment model

• Every team preference

• Every compliance case

• Every environment

• Every possible architecture

That usually fails.

A practical platform starts with one painful, repeated workflow.

For many teams, the best first golden path is "create a new service."

That one workflow can include:

• Repository creation

• Basic app template

• CI pipeline

• Build and scan

• Deployment to staging

• Logs and metrics

• Service ownership

• Basic docs

• Rollback instructions

Then improve it.

Do not start by trying to build the perfect platform. Start by making one common task much better.

Good first platform capabilities:

• New service template

• Preview environment creation

• Standard CI/CD pipeline

• Central service catalog

• Secrets integration

• Production readiness checklist

• Default observability

• Cost tagging

• Deployment rollback

• Runbook template

Bad first platform goals:

• Replace every tool

• Support every team preference

• Build a portal before solving workflows

• Force adoption without feedback

• Create standards no one can follow

• Measure success only by number of services onboarded

The practical era rewards narrow, useful wins.

Measure outcomes, not platform vanity

Platform teams need metrics.

But the wrong metrics can create the wrong behavior.

Counting portal visits is not enough. Counting number of templates is not enough. Counting services in the catalog is not enough.

Those are activity metrics.

Better platform metrics focus on outcomes.

The best platform metric is often time saved from repeated work.

If creating a service used to take three days and now takes twenty minutes, the platform is doing something real.

If developers can deploy without asking three teams for help, the platform is doing something real.

If services get logs, alerts, cost tags, and security checks by default, the platform is doing something real.

Adoption should be earned.

If the platform is genuinely better, developers will use it.

If adoption requires force, the platform probably needs work.

What small teams should do

Platform engineering can sound like something only large companies need.

That is not true.

Small teams also have platforms. They are just less formal.

A small team's platform might be:

• A starter repository

• A README

• A Makefile

• A GitHub Actions workflow

• A Terraform module

• A deployment script

• A dashboard template

• A runbook template

• A shared Docker Compose file

That is enough to start.

A small team does not need a full developer portal. It needs repeatable paths.

For a small team, the platform goal should be simple:

Can a new developer create, run, test, deploy, observe, and roll back a service without asking five people?

If the answer is no, platform work can help.

Small teams should avoid heavy platform projects. They should build lightweight paved roads:

• One service template

• One deploy path

• One observability pattern

• One secrets pattern

• One environment pattern

• One documented rollback path

That is practical platform engineering.

No committee required.

What platform engineering is not

Because the term is popular, it is worth being clear about what platform engineering is not.

It is not just Backstage.

It is not just Kubernetes.

It is not just Terraform.

It is not just a DevOps team with a new name.

It is not a reason to centralize every decision.

It is not a way to remove developer ownership.

It is not a portal that no one uses.

It is not a ticket system with nicer branding.

It is not a platform team building tools for itself.

The point is developer enablement with guardrails.

A platform should reduce friction, not move friction into a different interface.

It should make teams faster and safer.

If it only adds process, it is not working.

The cultural change matters most

Platform engineering fails when it becomes a control project.

It succeeds when it becomes an enablement project.

That requires trust between platform teams and application teams.

Application teams need to trust that the platform helps them ship. Platform teams need to trust application teams enough to design self-service workflows. Security and operations teams need to trust the platform guardrails. Leadership needs to understand that platform work is product work, not invisible plumbing.

This is a cultural change.

The platform team becomes a product team.

Developers become users.

Security becomes policy as code.

Operations becomes paved-road design.

Leadership measures outcomes.

The best platforms feel almost boring.

Developers do not think about them all day. They just use them. New services have the right defaults. Deployments are predictable. Dashboards exist. Rollbacks work. Cost ownership is visible. Security checks are early. The path is clear.

That is the goal.

Not a flashy internal portal.

A calmer engineering organization.

The practical era is about boring leverage

The first era of platform engineering was about naming the problem.

The second era was about tools.

The practical era is about leverage.

Can the platform turn one good practice into a default for every team?

Can it make the secure path the easy path?

Can it make the observable path the default path?

Can it make cost visible before the bill arrives?

Can it make AI-assisted delivery safer?

Can it help developers ship without memorizing the entire cloud stack?

That is practical platform engineering.

Not a buzzword.

Not a dashboard.

Not a replacement for DevOps.

A working internal product that helps teams deliver software with less friction and fewer mistakes.

The platform does not need to be perfect.

It needs to be useful.

Start with one golden path. Make it good. Watch how developers use it. Improve it. Add the next path. Keep policy close to the workflow. Make cost visible. Make observability automatic. Treat the platform like a product.

That is how platform engineering becomes real.

That is why it is entering its practical era.

References

• CNCF Platforms White Paper

• CNCF, What is platform engineering

• CNCF Platform Engineering Maturity Model

• PlatformEngineering.org, Platform engineering tools you need to know in 2026

• PlatformEngineering.org, State of Platform Engineering Report Volume 4

• Humanitec, State of Platform Engineering Report Volume 4 PDF

• PlatformEngineering.org, Platform tooling landscape

• PlatformEngineering.org, FinOps tools platform engineers should evaluate for 2026

• Infisical, Best platform engineering tools in 2026

• Octopus Deploy, Platform engineering tools

A blank box.

You type something. The model replies. Maybe it uses tools. Maybe it searches. Maybe it edits a file, drafts an email, fills a form, or schedules something. But the interface still looks like chat.

That made sense at first. Chat is flexible. It is easy to ship. It gives users one place to ask for anything.

But agentic software is not only about answering questions.

It acts.

That changes the interface.

When software can take steps on your behalf, the UI has to do more than collect prompts and show responses. It has to show intent, progress, uncertainty, permissions, risks, memory, tool use, and recovery paths. It has to let the user steer the agent before something goes wrong, not only approve a final result after the important choices have already been made.

This is why agentic user interfaces are coming.

Not because every app needs a chatbot.

Because the old UI model was built for users clicking buttons. Agentic systems are built around users delegating goals.

That is a different design problem.

The prompt box is not the final interface

The first wave of AI products looked conversational because conversation was the easiest way to expose model capability.

A chat box gives users room to describe messy intent. It also gives teams a low-friction product surface. You do not need to design fifty workflows if the user can ask for anything.

That is useful.

It is also limited.

A prompt box hides too much. It hides what the system can do, what it is about to do, what data it will use, what tools it may call, what it cannot do, when the user needs to intervene, and how to recover from mistakes.

Figma's 2026 web development trends report lists agentic user interfaces as a major web trend and says users are getting used to tools that perform complex workflows on their behalf. The same report also warns that simply putting a prompt box everywhere may be a shallow pattern, not the future of AI-inspired UX.

That warning is important.

The future is not "chat on top of every app."

The future is interfaces where AI is embedded into the product flow.

The difference is visibility.

A chat interface says, "Tell me what you want."

An agentic interface says, "Here is what I understood, here is what I plan to do, here is what I am doing, here is where I need your approval, and here is how you can change course."

That is a much stronger product experience.

Agents change the shape of interaction

Traditional UI is built around direct manipulation.

You click a button. You choose an option. You drag an item. You fill a form. The system responds to your action.

Agentic UI is built around delegation.

You state a goal. The system decides steps. It may use tools. It may ask for clarification. It may work in the background. It may pause for approval. It may return with a result and a trace of what happened.

That creates a new interaction loop.

This is not the same as a normal workflow.

A normal workflow has a fixed path. An agentic workflow has a goal and a changing path.

That variability is powerful, but it makes design harder.

A designer cannot always map one exact screen flow. A product manager cannot always write one fixed happy path. An engineer cannot treat the UI as a thin layer over predictable backend states.

The system needs to expose the agent's state in a way users can understand.

That means the UI needs new primitives:

• Goal input

• Plan preview

• Tool visibility

• Progress timeline

• Approval gates

• Mid-task steering

• Memory controls

• Action history

• Undo and rollback

• Escalation to humans

• Confidence and uncertainty signals

These primitives are becoming as important to agentic products as buttons, forms, and navigation were to traditional software.

The user should see the plan

A good agentic interface should not jump from prompt to action.

It should show the plan.

The plan is the bridge between user intent and agent execution. It gives the user a chance to catch misunderstandings before the agent spends time, uses tools, or changes data.

Imagine a travel agent inside a booking app.

Bad interface:

"Plan my trip to Tokyo."

Then the agent silently searches, books, and returns.

Better interface:

"I will compare flights, find hotels near Shinjuku, keep total hotel cost under $900, avoid overnight layovers, and draft a 5-day itinerary. I will not book anything without asking."

That second version gives the user control.

Plan previews should include:

• What the agent understood

• What steps it intends to take

• Which tools or systems it may use

• What information it needs

• What it will not do

• Which actions require approval

• What the expected output will be

The plan does not need to be perfect. It needs to be inspectable.

This is especially important in business software.

If an agent is going to update a CRM, generate a contract, file a support ticket, change a deployment setting, send an email, or query customer data, the user should understand the plan before execution.

A visible plan turns an agent from a black box into a collaborator.

Visible work beats a thinking spinner

The most common AI loading state is still vague.

"Thinking..."

"Working on it..."

"Generating..."

That might be fine for a short answer. It is not enough for an agent doing a multi-step task.

When an agent works for 30 seconds, 2 minutes, or 10 minutes, users need to know what is happening. Otherwise they do not know whether the system is progressing, stuck, confused, or doing something risky.

OpenAI's ChatGPT agent announcement describes users being able to pause or take over tasks, and its system card describes confirmations and Watch Mode for sensitive contexts. That product direction shows the same design pressure: when agents act in the world, users need more visibility and control than a normal chat response provides.

A useful agentic UI should show work as a timeline.

A visible work panel might show:

This is not only about trust.

It is about usability.

If the agent is about to search 300 files but the user only wanted the latest document, the user should be able to stop and correct it early.

If the agent is waiting for an approval, the UI should make that obvious.

If the agent is blocked by missing credentials, the UI should say so.

A vague spinner hides all of that.

Agentic products need perceptible background work.

Approvals need better design

Human approval is becoming one of the core patterns in agentic UI.

Microsoft's AG-UI documentation describes human-in-the-loop approval workflows where an agent requests approval before executing sensitive operations. The client displays the approval request, the user approves or rejects it, and the agent continues based on that response.

That pattern is important.

But many approval flows are too weak.

A bad approval UI says:

The agent wants to continue. Approve?

That is not meaningful control.

A good approval UI says:

The agent wants to send this email to three customers. It used these account records, generated this message, and will log the action in the CRM. Review the recipients and message before approving.

Approval should include:

• Action summary

• Exact target

• Inputs used

• Expected change

• Risk level

• Reversibility

• Alternatives

• Edit option

• Reject option

• Audit record

Approvals should also be placed at the right moment.

If the agent asks for approval too early, the user has no context.

If it asks too late, the user becomes a rubber stamp.

The best approval point is usually right before an irreversible or high-impact action.

Examples:

Approval UI is not friction for the sake of friction.

It is how users stay accountable while agents become more capable.

Mid-task steering is the missing pattern

Most interfaces give users control at the start and end.

Agentic interfaces need control in the middle.

A user should be able to interrupt, redirect, narrow, expand, or pause the agent while it works. This is especially important for tasks that take time or involve exploration.

Magentic-UI, an open-source research interface for human-agent interaction, focuses on human-in-the-loop mechanisms such as co-planning, co-tasking, action guards, and long-term memory. That research points toward a more interactive model where users are not just prompt writers and final approvers. They are active collaborators during execution.

Mid-task steering might look like this:

This pattern matters because users often discover what they really want while the task is happening.

A user might start with:

"Clean up this spreadsheet."

Then realize they want:

"Actually, keep the old customer IDs."

Or:

"Only deduplicate rows with the same email and phone number."

Or:

"Do not change anything yet. Just show me the proposed edits."

A chat-only interface can handle this awkwardly. A real agentic UI should make it natural.

Useful mid-task controls include:

• Pause

• Resume

• Stop

• Edit goal

• Edit constraints

• Skip step

• Retry step

• Ask why

• Inspect data

• Change tool

• Escalate to human

• Convert action into draft mode

This is where agentic UI starts to feel different from automation.

Automation says, "The workflow is running."

Agentic UI says, "The system is working, and you can still steer it."

Memory needs a real interface

Agent memory is powerful.

It is also risky.

If an agent remembers preferences, projects, files, people, decisions, approvals, and past tasks, users need a way to inspect and control that memory.

Memory cannot be a hidden side effect.

A useful memory UI should answer simple questions:

• What does the agent remember?

• Where did that memory come from?

• When was it last used?

• Can I edit it?

• Can I delete it?

• Is it personal, team-level, or organization-level?

• Will it be used automatically?

• Can I turn it off for this task?

  

The 2025 paper on UI-based AI agent governance identifies UI as a practical surface for agent transparency and control. It specifically argues that interface elements can help enforce governance requirements, such as making agent memory editable.

That idea is right.

If memory influences future actions, memory needs user control.

A CRM agent that remembers "this customer is difficult" can create bias.

A coding agent that remembers an old architectural decision can produce stale recommendations.

A personal assistant that remembers sensitive details can create privacy risk.

A team agent that stores one user's preference as a team norm can confuse everyone.

Memory should be visible, scoped, and editable.

In many products, the memory screen may become as important as settings.

Action history is the new audit log

Traditional UI has logs, but users rarely see them.

Agentic UI needs user-facing action history.

When an agent acts, the user should be able to answer:

• What did it do?

• When did it do it?

• Why did it do it?

• Which tools did it call?

• Which data did it use?

• Who approved it?

• What changed?

• Can it be undone?

This is not only for enterprise compliance. It is basic trust.

A good action history might look like this:

The key is that users should not have to infer what happened from the final answer.

They should be able to inspect the trajectory.

This is also useful for debugging.

If the agent made a bad recommendation, you can see whether it used the wrong source, called the wrong tool, skipped a constraint, or misunderstood the goal.

For high-stakes workflows, this becomes mandatory. For everyday workflows, it still builds confidence.

A transparent agent is easier to trust.

It is also easier to improve.

Agentic UI needs undo by design

Undo is one of the most important features in software.

It becomes even more important when software acts on your behalf.

If users cannot undo or recover from agent actions, they will avoid giving agents meaningful work. That limits the product.

Agentic UI should separate actions by reversibility.

Examples:

Undo is not only a button.

It is an architecture decision.

To support undo, the system may need:

• Version history

• Change diffs

• Idempotent actions

• Transaction logs

• Rollback commands

• Draft states

• Soft deletes

• Approval records

• Simulation mode

A product that wants agentic UI should ask this early:

If the agent is wrong, how does the user recover?

If there is no good answer, the agent should not take that action yet.

The interface should show uncertainty without being annoying

AI systems are uncertain.

But users do not need a wall of caveats after every sentence.

They need useful uncertainty.

A good agentic UI should show uncertainty where it affects decisions.

For example:

• "I found three possible matches. Please choose one."

• "This source is older than the policy document I found later."

• "I am not confident these records refer to the same customer."

• "This action cannot be undone."

• "I need your approval because this changes billing data."

• "I could not verify this from the provided sources."

  

The goal is not to make the interface anxious.

The goal is to help users decide when to trust, verify, edit, or stop.

Uncertainty should be attached to specific claims and actions.

Bad:

"AI may make mistakes."

Good:

"I found conflicting refund policies. The 2026 policy says refunds expire after 30 days. The older 2024 policy says 60 days."

The second message helps the user act.

Agentic UI should turn uncertainty into a design signal.

Agentic UI is not always conversational

Conversation is useful, but it is not always the right interface.

Some agentic features should look like forms.

Some should look like timelines.

Some should look like checklists.

Some should look like dashboards.

Some should look like diffs.

Some should look like command palettes.

Some should look like workflow builders.

Some should look like notifications.

Some should be almost invisible until the user needs them.

A legal document assistant may need a diff view.

A deployment assistant may need a run timeline and rollback button.

A sales assistant may need a CRM sidebar with suggested next actions.

A personal scheduling assistant may need calendar previews.

A data cleaning assistant may need a spreadsheet-like preview.

A coding assistant may need a file tree, patch view, tests panel, and terminal output.

The mistake is assuming agentic means chat.

Agentic means goal-directed.

The UI should match the task, not the hype.

Interfaces must work for agents too

There is another side to agentic UI.

Humans will use agents through interfaces. Agents will also use software interfaces themselves.

The 2026 paper "From Human Interfaces to Agent Interfaces" argues that software is increasingly invoked not only by humans, but also by AI agents through structured interfaces. It frames invocable capabilities as a key building block of AI-native software.

That means applications may need two interface layers:

1. A human interface for people.

2. A machine-readable interface for agents.

This does not mean the human UI disappears.

It means products need to expose capabilities in ways agents can understand and safely call.

For example, a support product might expose:

• Search tickets

• Summarize thread

• Draft reply

• Add internal note

• Escalate ticket

• Request refund approval

• Close ticket

Each capability should have a clear schema, permission model, and expected behavior.

This is better than making agents click through a fragile human UI when a structured interface would be safer.

At the same time, human interfaces should remain accessible. Agents that control screens often rely on the same cues as assistive technologies: labels, semantic structure, keyboard navigation, and predictable states. Designing accessibly helps humans and makes software easier for agents to operate.

Agentic UI is not only a visual design problem.

It is an interface contract problem.

A practical architecture for agentic UI

A production agentic UI needs more than a frontend component and a model call.

It needs state, policies, traces, approvals, and tool boundaries.

Core components:

The UI should not be a passive display of the final answer.

It should be part of the control system.

It should send approvals, edits, interrupts, clarifications, and cancellations back into the workflow.

This architecture also helps teams avoid a common mistake: letting the model directly hold too much power.

A safer pattern is:

• The model proposes.

• The policy layer checks.

• The UI asks for approval when needed.

• The server executes approved actions.

• The trace store records the result.

That keeps the agent useful without making it unbounded.

Design patterns that will matter

Agentic UI needs a new pattern library.

Here are some patterns that will likely become common.

Goal card

A structured version of the user's intent.

It shows the task, constraints, expected output, and risk level.

Plan preview

A short, editable plan before execution starts.

This helps users correct misunderstandings early.

Work timeline

A visible sequence of agent steps.

It replaces vague loading states with understandable progress.

Approval card

A review surface for risky actions.

It shows what will happen, why, what data was used, and what can be edited.

Action diff

A before-and-after view of proposed changes.

This is essential for code, documents, records, settings, and database-like updates.

Memory panel

A place to view, edit, disable, or delete what the agent remembers.

This supports trust and privacy.

Tool drawer

A view of tools the agent can use for the current task.

This helps users understand capability and risk.

Intervention bar

A persistent control strip with pause, stop, steer, and ask why.

This gives the user control during long-running tasks.

Result receipt

A final summary of what happened.

It includes actions taken, sources used, approvals, cost, time, and next steps.

These patterns are not decoration.

They are safety and usability features.

The biggest mistake is fake autonomy

Many products will ship fake agentic UI.

It will look powerful, but it will not give users real control.

Signs of fake autonomy:

• A prompt box with no capability boundaries

• A thinking spinner for long-running tasks

• Approvals that do not explain impact

• No way to inspect tool calls

• No memory controls

• No undo path

• No task history

• No mid-task steering

• No clear error recovery

• No distinction between draft and action

• No explanation of what the agent can and cannot do

This creates a bad trust cycle.

The product promises autonomy. The user tries it. The agent makes a confusing choice. The user cannot see what happened. The user stops trusting it.

The problem is not that the agent made one mistake.

The problem is that the interface gave the user no way to understand or recover.

Good agentic UI does the opposite.

It makes autonomy legible.

The user should know when the agent is drafting, when it is deciding, when it is using a tool, when it is waiting, when it is blocked, when it is asking for trust, and when it has changed something.

Where agentic UI will appear first

Agentic UI will not arrive everywhere at once.

It will appear first in products where workflows are complex, repetitive, and tool-heavy.

Good early categories:

These areas have enough structure for useful automation, but enough variation that fixed workflows can feel limiting.

That is where agents help.

The agent can adapt to the case, while the UI keeps the user in control.

What product teams should build first

If you are adding agentic UI to a product, do not start with full autonomy.

Start with a narrow workflow.

Pick one task where users already spend time moving between screens, copying information, checking rules, or making routine decisions.

Then design the interface around the full task lifecycle.

A good first agentic feature might be:

• "Draft a support response from this ticket and our docs."

• "Summarize this pull request and flag risky files."

• "Prepare a weekly project update from completed tasks."

• "Find duplicate customer records and propose merges."

• "Generate a migration plan, but do not apply it."

• "Analyze these incidents and draft a timeline."

Notice the pattern.

The agent drafts, proposes, summarizes, prepares, or analyzes before it acts.

That gives users value without giving the system too much power too early.

A practical launch checklist:

• Can the user see the plan?

• Can the user edit the plan?

• Can the user see progress?

• Can the user pause or stop?

• Are risky actions gated?

• Does approval show enough context?

• Is memory visible and editable?

• Is there an action history?

• Is there an undo or rollback path?

• Is there a fallback to manual workflow?

• Are errors understandable?

• Are sources and data shown where needed?

If the answer is no to most of these, the product may not need an agent yet.

It may need better workflow design first.

Agentic UI will make designers more important

A common fear is that AI will reduce the need for product designers.

Agentic UI suggests the opposite.

As systems become more autonomous, design becomes more important. The designer is no longer only arranging screens. They are shaping delegation, trust, control, risk, interruption, recovery, and accountability.

That is hard work.

Designers will need to ask:

• What should the agent do automatically?

• What should require approval?

• What should never be automated?

• What should be visible during execution?

• Where can the user steer?

• How does the user recover?

• What does the agent remember?

• How does the interface prevent overtrust?

• How does the interface avoid annoying users with constant confirmations?

• How does the product explain uncertainty?

• How does the experience stay accessible?

This is not just visual design.

It is systems design.

The best agentic products will come from teams where design, product, engineering, security, and operations work together early.

The UI cannot be added at the end.

It is part of the safety model.

The future is not less UI

Some people say agents will replace interfaces.

That is too simple.

Agents may reduce the need for some screens. They may replace some repetitive navigation. They may turn some multi-step flows into goals. They may make software feel more conversational.

But they will not remove the need for UI.

They will change what UI does.

The old UI helped users operate software.

The new UI will help users delegate work safely.

That means the interface becomes less about exposing every feature and more about managing intent, context, action, and trust.

Agentic user interfaces are coming because users will not accept black-box automation for important work.

They will want the speed of agents and the confidence of good software.

The products that win will not be the ones with the biggest prompt box.

They will be the ones that make agents understandable, steerable, accountable, and safe.

That is the design challenge.

And it is a good one.

References

• Figma, 12 defining web development trends for 2026

• Figma, Top web design trends for 2026

• Figma Help Center, Release notes roundup May 2026

• OpenAI, Introducing ChatGPT agent

• OpenAI, ChatGPT Agent System Card

• OpenAI Help Center, ChatGPT agent

• Microsoft Learn, Human in the loop with AG-UI

• Microsoft Learn, Using function tools with human in the loop approvals

• Magentic-UI, Towards human-in-the-loop agentic systems

• Human-AI Coordination Zones

• On the regulatory potential of user interfaces for AI agent governance

• From human interfaces to agent interfaces

• Augmenting interface usability heuristics for reliable computer-use agents

• Human oversight-by-design for accessible generative IUIs

The reason is simple. Modern cloud bills are shaped by design decisions long before finance sees the invoice. A cache miss can become a database bill. A logging decision can become an observability bill. A region choice can become a data transfer bill. A serverless function can become expensive because of memory, runtime, retries, cold starts, and traffic shape. An AI feature can turn one user request into ten model calls, three vector searches, and a pile of stored traces.

The bill is not separate from the system.

The bill is the system, expressed in dollars.

Flexera's 2025 State of the Cloud research reported that 84 percent of respondents considered managing cloud spend a top cloud challenge. AWS treats cost optimization as one of the six pillars of its Well-Architected Framework. Google Cloud's architecture guidance says teams should align cloud spending with business value and build a culture of cost awareness. Microsoft describes FinOps as a discipline that combines financial management with cloud engineering and operations.

That is the shift.

Cloud cost is not just an accounting issue. It is a design constraint, like reliability, security, and performance.

The cloud made spending programmable

Cloud changed infrastructure by turning hardware into an API.

That was the magic. A developer could provision a database in minutes. A team could deploy globally without buying servers. A product could scale without waiting for procurement. A startup could use the same infrastructure patterns as a large company.

But programmable infrastructure also made spending programmable.

Every architecture decision can now create cost automatically:

• A function scales with traffic.

• A queue retains messages.

• A log pipeline stores every request.

• A database charges for storage and I/O.

• A GPU endpoint sits idle between jobs.

• A backup policy keeps data for years.

• A cross-region design moves data repeatedly.

• A Kubernetes cluster reserves more CPU than it uses.

In the data center era, waste was often hidden in capital expense. You bought too much hardware, but the cost was paid up front. In the cloud era, waste is continuous. It follows traffic, retries, storage growth, and design habits.

This is why cloud cost surprises feel unfair.

The team did not always make one obviously expensive decision. They made many reasonable decisions that multiplied together.

A product manager asks for file previews. Engineers add object storage, thumbnails, background workers, CDN caching, and logs. Later, customers start sharing large files. A few months after that, data transfer becomes a real cost center.

Nothing was wrong in isolation.

The architecture created a new cost shape.

That is the phrase every engineering team should learn: cost shape.

The cost shape of a system is how spending changes as traffic, data, users, regions, and features grow.

A system can be cheap at 1,000 users and painful at 100,000 users. A feature can be affordable when used once per session and expensive when placed on every page load. A model call can be fine for admin users and unaffordable for public traffic.

Architecture decides that shape.

Cost is now part of the architecture triangle

Software teams already know the tradeoff triangle between performance, reliability, and security.

Cost belongs in that triangle.

In practice, every cloud architecture balances at least four forces:

• Reliability

• Performance

• Security

• Cost

You rarely optimize all four at once.

A multi-region database may improve availability, but it can increase replication and data transfer cost. More logs may improve debugging, but they can increase storage and ingestion cost. Bigger instances may reduce latency, but they can waste capacity during normal traffic. More caching may reduce database cost, but it can create invalidation complexity.

The goal is not to make everything cheap.

Cheap systems can be fragile. A system that fails during a launch is not cost optimized. A system that loses customer data is not cost optimized. A system that saves money by removing observability can cost more during incidents.

The real goal is value.

AWS defines the cost optimization pillar as running systems to deliver business value at the lowest price point. Google Cloud uses similar language around aligning cloud spend with business value. Microsoft says the goal of FinOps is not simply to save money, but to maximize business value through cloud decisions.

That is the right frame.

Cost optimization is not cutting.

It is matching spending to value.

The bill follows the request path

A useful way to understand cloud cost is to follow one request.

Imagine a user opens a dashboard.

That request may touch a CDN, an edge function, an application server, a cache, a database, a queue, an object store, a metrics pipeline, a log pipeline, a trace exporter, and maybe an AI service.

One user action became many billable events.

That does not mean the architecture is bad. It means the architecture needs cost visibility.

For each request path, teams should understand:

A request path is also a cost path.

Once teams see that, architecture reviews change.

Instead of asking only, "Will this scale?" the team also asks, "How will this spend?"

Serverless did not remove cost design

Serverless changed how teams think about infrastructure.

It reduced operational work. It made scaling easier. It let teams ship without managing servers. For many workloads, it is an excellent model.

But serverless did not remove cost design.

It changed where cost design happens.

With serverless, teams pay for usage. That sounds ideal. It can be ideal. But usage-based pricing means architecture mistakes scale directly with traffic.

A serverless function that does too much work per request becomes expensive. A function that retries aggressively becomes expensive. A function that uses too much memory becomes expensive. A function that runs in a hot path becomes expensive. A function that calls another function in a chain can make cost harder to predict.

Serverless can be cheap when work is bursty, light, and well bounded.

It can be expensive when work is constant, chatty, long running, or hard to predict.

This does not make serverless bad. It makes it another architecture choice with tradeoffs.

A good serverless architecture needs:

• Clear timeout limits

• Memory sizing discipline

• Idempotent handlers

• Controlled retries

• Queue backpressure

• Observability sampling

• Per-feature cost tracking

• A plan for steady workloads

The mistake is treating serverless as an escape from capacity planning.

It is not.

It is capacity planning with a different interface.

Observability can become a hidden tax

Logs, metrics, and traces are essential.

They are also not free.

Modern observability pipelines can produce huge volumes of data. High-cardinality metrics, verbose logs, full request traces, debug-level events, and long retention windows can turn observability into a major cost center.

This creates an uncomfortable tradeoff.

You need enough visibility to operate the system. You do not need to store everything forever at full fidelity.

A cost-aware observability strategy usually includes:

• Log levels that mean something

• Sampling for high-volume traces

• Shorter retention for noisy data

• Longer retention for important audit events

• Cardinality controls for metrics

• Redaction before ingestion

• Separate handling for security logs

• Dashboards that show telemetry cost by service

Datadog's cloud cost material frames cost observability as a way to bring engineering and FinOps teams into the same conversation. That is the right approach. Engineers need to see how system behavior creates cost. FinOps teams need the technical context behind the numbers.

A log line is not just a log line.

At scale, it is storage, indexing, retention, access control, and money.

Data transfer is an architecture smell detector

Data transfer cost is one of the least intuitive parts of cloud architecture.

Teams usually think about compute and storage first. Network cost appears later, especially when systems cross zones, regions, providers, or storage boundaries.

A few patterns create surprise:

• Moving data across regions

• Sending large objects from storage repeatedly

• Pulling data from one cloud into another

• Using chatty microservices across availability zones

• Sending full datasets to analytics tools

• Replicating logs and traces to multiple systems

• Serving large downloads directly from object storage

Cloudflare's R2 product page is built around this pain. It markets object storage without egress fees and says teams can download data without the egress bill scaling one-to-one with growth. Cloudflare's broader explanation of data egress fees also frames egress as a major cost and lock-in concern.

The architecture lesson is not that every team should use R2.

The lesson is that data movement is a cost dimension.

A simple rule helps:

Put compute near the data, and put data near the user only when the value justifies it.

This is why CDNs matter. It is why regional design matters. It is why analytics pipelines need careful boundaries. It is why multi-cloud architectures should not be adopted casually.

Multi-cloud can be valuable for resilience, negotiation, compliance, or workload placement. But if data moves constantly between providers, the network bill can become the architecture's loudest critic.

Kubernetes made cost harder to see

Kubernetes gives teams a powerful abstraction.

It also hides cost behind layers.

In a traditional VM world, a team might know which instance belongs to which application. In Kubernetes, workloads share nodes. Namespaces share clusters. Pods come and go. Autoscalers change capacity. Persistent volumes appear. Load balancers get created. GPUs may be allocated but underused.

The bill often arrives at the cluster level, while ownership lives at the application level.

That mismatch is painful.

OpenCost exists because of this exact problem. It describes itself as a vendor-neutral open source project for measuring and allocating cloud infrastructure and container costs in real time. The CNCF blog introducing OpenCost says it can break down cloud assets behind Kubernetes deployments by nodes, persistent volumes, load balancers, and other resources.

That visibility matters.

Without it, teams optimize the wrong thing.

A platform team sees a large cluster bill. Product teams see no direct signal. Developers request too much CPU and memory because it feels safe. Idle environments stay alive because no one owns them. GPU nodes stay warm because startup is slow.

Kubernetes cost architecture needs:

• Namespace cost allocation

• Resource requests and limits discipline

• Cluster autoscaling

• Horizontal Pod Autoscaling

• Event-driven autoscaling with tools like KEDA

• Idle workload detection

• Environment lifecycle policies

• GPU utilization tracking

• Storage and load balancer ownership

• Cost dashboards by team and service

Kubernetes is not expensive by default.

Invisible Kubernetes is expensive.

AI made the cost problem sharper

AI workloads changed the cloud cost conversation.

A normal web request may use compute, storage, database, and logs. An AI request may add model tokens, embeddings, vector search, reranking, prompt caching, tool calls, traces, feedback storage, and evaluation runs.

One product feature can now create several cost paths.

AI cost is tricky because it often scales with behavior, not just traffic.

Two users can submit one request each, but one request may be short and the other may trigger a long agentic workflow. One AI support answer might need one model call. Another might search documents, call tools, retry, summarize, and ask a second model to judge the answer.

This is why AI features need budgets.

AI also changes architecture decisions around model routing.

Not every task needs the largest model. Not every request needs RAG. Not every answer needs a second judge. Not every user action needs an AI call in the hot path.

A cost-aware AI architecture routes work by value.

The architecture should make expensive behavior explicit.

Otherwise, AI becomes a blank check hidden behind a friendly text box.

Storage cost is not just gigabytes

Storage pricing looks simple until the system grows.

Teams often think of storage as cost per GB. In practice, storage cost can include:

• Stored data

• Requests and operations

• Retrieval charges

• Data transfer

• Replication

• Snapshots

• Backups

• Versioning

• Lifecycle mistakes

• Indexes

• Analytics scans

• Long retention

A logging bucket, a user upload bucket, a backup bucket, and a data lake have different cost shapes.

Good storage architecture starts with data classification.

Lifecycle policies are architecture.

Retention is architecture.

Backup frequency is architecture.

Indexing strategy is architecture.

If storage never expires, the cloud bill becomes a historical record of every decision the team avoided making.

Caching is a cost control tool

Developers usually think of caching as a performance technique.

It is also a cost technique.

A cache hit can avoid compute, database I/O, network transfer, AI calls, and downstream service usage. A cache miss can trigger the expensive path.

Cost-aware caching asks different questions than performance-only caching.

Performance caching asks:

How do we make this faster?

Cost-aware caching also asks:

What expensive work can we avoid repeating?

Good candidates include:

• Public pages

• Product metadata

• Permission-aware dashboard fragments

• Expensive search results

• AI summaries

• Embeddings

• Feature flags

• API responses with stable data

• Report exports

Caching has its own complexity. Stale data can hurt users. Cache invalidation can be hard. Permission-sensitive caching can leak data if done badly.

But when designed carefully, caching is one of the best cloud cost controls because it reduces work instead of merely moving it.

The cheapest request is the one your origin never has to process.

Architecture reviews need cost questions

Most teams have some form of architecture review.

They ask about reliability, security, scalability, data model, deployment, observability, and migration.

Cost should be part of that review.

Not as a final checkbox. As a design dimension.

Here is a practical cost review checklist.

Traffic and scaling

• What is the expected request volume?

• What happens if traffic grows 10x?

• Which parts scale with users, data, or background jobs?

• Is scaling automatic, manual, or fixed?

• Can the system scale down?

Compute

• Is this workload steady, bursty, or scheduled?

• Is serverless, container, VM, or managed service the best fit?

• Are CPU and memory requirements known?

• Can work move off the synchronous request path?

• Are retries bounded?

Data

• How much data will be stored per user?

• How long is data retained?

• How often is it read?

• Does data move across regions or providers?

• Are backups and replicas included in estimates?

Observability

• What logs are required?

• What traces are sampled?

• What metrics have high cardinality?

• How long is telemetry retained?

• Can cost be broken down by service?

AI usage

• How many model calls happen per user action?

• Which model is used for each task?

• Is there a cheaper fallback model?

• Are prompts and retrieved context bounded?

• Are traces and evals sampled?

Ownership

• Which team owns the cost?

• Which dashboard shows it?

• What budget alert exists?

• Who responds to cost anomalies?

• What is the rollback plan if cost spikes?

This review does not need to be bureaucratic.

It can be a one-page section in a design doc.

The point is to make cost visible while architecture is still flexible.

The reference architecture for cost-aware systems

A cost-aware architecture does not mean a cheap architecture.

It means an architecture where cost signals are designed into the system.

The important pieces are not exotic.

They are practical:

• CDN in front of repeated traffic

• Cache for expensive repeated work

• Queue for asynchronous jobs

• Right-sized compute

• Storage lifecycle rules

• AI gateway for model routing and budgets

• Observability sampling

• Cost allocation by team and service

• Budget alerts

• Architecture review feedback loop

This architecture does not belong to one cloud provider.

It is a way of thinking.

Every component should answer two questions:

1. What value does this provide?

2. How does its cost grow?

If the team cannot answer the second question, the architecture is not finished.

FinOps belongs in engineering culture

FinOps is often misunderstood as a finance team function.

That is too narrow.

FinOps is a collaboration model. The FinOps Foundation describes it as a practice for people who manage the value of technology. Microsoft describes it as combining financial management principles with cloud engineering and operations.

That means developers are part of it.

Not because developers should become accountants. Because developers make the design choices that create the bill.

A healthy FinOps culture gives engineers visibility and context.

Engineers should be able to see:

• Cost per service

• Cost per environment

• Cost per customer or tenant where possible

• Cost per feature for major features

• Unit cost per request, job, report, or AI run

• Cost changes after deployment

• Waste from idle resources

• Forecasts for expected growth

  

The loop matters.

If engineers only hear about cost once a quarter, nothing changes. If they see cost after every major release, they learn.

Cost awareness should feel like performance awareness.

Nobody says performance is only the performance team's job. The same should be true for cost.

Unit economics make cloud cost real

Cloud bills are hard to reason about when they are only monthly totals.

A bill of $50,000 means little by itself.

A cost of 0.02 per report, 0.001 per API request, 0.15 per AI conversation, or 4 per active customer per month is easier to understand.

That is unit economics.

Useful unit metrics depend on the product.

Unit cost helps teams make better tradeoffs.

If an AI feature improves conversion enough to justify.

If an AI feature improves conversion enough to justify 0.10 per run, it may be worth it. If it runs on every page load and users ignore it, it is waste. If a report costs 3 to generate and is used by one enterprise customer, maybe that is acceptable. If every free user can generate it repeatedly, maybe it is not.
Cost needs product context.

That is why architecture, finance, and product need to talk to each other.

Cost-aware architecture is not premature optimization

A common objection is that teams should not optimize too early.

That is true.

Premature optimization is still a problem. But cost-aware architecture is not the same thing as premature optimization.

Premature optimization says:

Spend weeks reducing a cost that does not matter yet.

Cost-aware architecture says:

Do not design a system with unknown or unlimited cost growth.

Those are different.

You do not need perfect cost models on day one. You do need to understand the obvious cost drivers.

For a new feature, a lightweight estimate is enough:

This is not overengineering.

It is basic design hygiene.

The expensive mistake is not failing to predict every dollar.

The expensive mistake is building a cost shape nobody understands.

When spending more is the right answer

Cost-aware architecture does not always choose the cheapest option.

Sometimes the right choice costs more.

A managed database may cost more than self-hosting, but it can reduce operational risk. A larger instance may cost more, but it can protect latency during peak traffic. A second region may cost more, but it may be required for availability or compliance. Better observability may cost more, but it can reduce incident duration.

The question is value.

Good cost architecture protects money without starving the product.

Bad cost cutting removes the things that make the system safe.

Do not remove backups to save storage.

Do not remove logs to save ingestion.

Do not reduce redundancy without understanding reliability impact.

Do not choose a smaller model if it creates bad user outcomes.

Do not move critical workloads to the cheapest region if latency or compliance suffers.

The goal is not low cost.

The goal is efficient value.

A practical maturity model

Teams do not become cost-aware overnight.

A maturity model helps.

Most teams should first move from reactive to visible.

You cannot optimize what you cannot see.

Then move from visible to accountable.

A shared dashboard without ownership becomes wallpaper.

Then move from accountable to architectural.

That is where the real change happens.

Cost stops being cleanup.

It becomes design.

The developer checklist

Here is a practical checklist developers can use before shipping a cloud feature.

Request path

• What services does one request touch?

• What is the expensive path?

• What is cached?

• What happens on retry?

• What happens during failure?

Scaling

• What grows with users?

• What grows with data?

• What grows with traffic?

• What grows with background jobs?

• Can it scale down?

Data

• How much data is created?

• How long is it retained?

• Is it replicated?

• Is it indexed?

• Does it cross regions?

AI

• How many model calls happen?

• Which models are used?

• Are prompts bounded?

• Are outputs cached?

• Are expensive workflows rate limited?

Observability

• What logs are emitted?

• Are traces sampled?

• Are metrics high-cardinality?

• What is retained and for how long?

• Can cost be traced to this feature?

Ownership

• Which team owns the cost?

• Which dashboard shows it?

• What alert fires if cost spikes?

• What is the rollback plan?

• What is the expected unit cost?

This checklist will not catch everything.

It will catch more than silence.

The future of cloud architecture is cost-aware

Cloud is still powerful.

It still lets small teams build quickly. It still gives companies global infrastructure, managed services, high availability patterns, and access to advanced capabilities that would be hard to build alone.

But the easy cloud era is over.

The next era is more disciplined.

Teams will still use serverless, Kubernetes, managed databases, AI APIs, object storage, CDNs, and observability platforms. They will just be more careful about where these tools sit in the architecture and how their costs grow.

Cloud cost will become part of design docs.

AI features will have budgets.

Kubernetes clusters will have cost allocation by namespace and team.

Observability pipelines will be sampled by design.

Storage will have lifecycle rules from day one.

Architects will ask about egress.

Developers will see cost after deployments.

Product teams will compare feature value against unit cost.

Finance will stop being the first team to notice technical waste.

That is the point.

Cloud cost is becoming an architecture problem because architecture creates cost.

The teams that understand this will not simply spend less. They will spend better.

They will build systems where cost, performance, reliability, and security are discussed together.

They will know which expensive choices are worth it.

They will know which cheap choices are dangerous.

And they will know when the cloud bill is not just a bill.

It is feedback from the architecture.

References

• Flexera 2025 State of the Cloud press release

• Flexera 2026 State of the Cloud report

• AWS Well-Architected Framework, Cost Optimization Pillar

• AWS Well-Architected Framework, cost optimization design principles

• Google Cloud Architecture Framework, cost optimization

• Microsoft FinOps overview

• IBM, What is FinOps

• OpenCost official site

• CNCF, OpenCost sandbox project announcement

• Kubernetes Horizontal Pod Autoscaling documentation

• KEDA official site

• Cloudflare R2 product page

• Cloudflare R2 pricing

• Cloudflare, what are data egress fees

• Datadog, State of Cloud Costs

• Datadog Cloud Cost Management

A developer can now ask for a component, a migration, a test file, a refactor, a parser, a GitHub Action, a Terraform module, or a bug fix and get something useful in seconds. Not always correct. Not always safe. Not always maintainable. But useful enough to move faster.

That speed is real.

It is also incomplete.

Software does not become stable because code was written quickly. It becomes stable because teams understand requirements, review changes carefully, test behavior, control releases, observe production, respond to incidents, and learn from failures.

AI helps with some of that. It can also overload the rest of it.

That is the real problem.

AI is making software faster at the point of code generation, but many teams have not upgraded the systems around code generation. Review, testing, CI, deployment, observability, security, and rollback are still built for a slower world.

So the bottleneck moves.

The code appears faster. The risk appears later.

The speed is real

It would be dishonest to pretend AI coding tools do not help.

They do.

They are good at scaffolding. They are good at translating examples into code. They can explain unfamiliar APIs. They can generate tests. They can help with repetitive refactors. They can make a developer less blocked on syntax, boilerplate, or first drafts.

GitHub's Octoverse 2025 describes AI, agents, and typed languages as one of the biggest shifts in software development in more than a decade. It also reports large activity levels across GitHub, including millions of issues closed and tens of millions of pull requests merged per month in 2025.

Google's DORA team also reports that AI adoption among software development professionals has surged. In Google's summary of the 2025 DORA report, AI adoption reached 90 percent among software development professionals, and workers reported spending a median of two hours per day with AI tools.

The point is not that every generated line is good.

The point is that AI is now inside the normal development workflow.

This changes engineering economics.

When code is cheaper to produce, teams produce more of it. When drafts are easier to create, more ideas become pull requests. When agents can work in parallel, more branches appear. When test generation is easy, test files multiply. When refactors are easier, old code gets touched more often.

Some of this is excellent.

But every change still creates risk.

A faster authoring loop does not automatically create a safer delivery loop.

That distinction matters.

The stability problem is showing up downstream

The most important pattern in AI-assisted development is not "developers are faster."

It is this:

AI moves work from writing code to validating code.

That is not a small shift.

TechRadar recently summarized research claiming that heavy AI tool users deploy more frequently, but also report more frequent issues and slower recovery. The report said 45 percent of frequent AI users deploy daily compared with 15 percent of occasional users, while 69 percent of heavy AI users reported frequent deployment issues. It also described the downstream burden moving into QA, remediation, and infrastructure work.

Harness describes a similar pattern in its State of AI in Software Engineering research. Its public summary highlights more deployment failures, rising manual toil for QA and operations teams, and unpredictable costs.

DORA's 2025 report gives a more careful version of the same idea. It says AI acts as an amplifier. It can magnify an organization's strengths, but it can also magnify weaknesses. Google's announcement of the report states that AI adoption continues to have a negative relationship with software delivery stability.

That is the center of this article.

AI does not remove the need for engineering discipline.

It increases the need for it.

The system does not fail at the prompt.

It fails at the handoff between generation and production.

That handoff is where most teams are underprepared.

More code is not the same as more progress

There is a quiet assumption behind many AI coding claims:

If developers produce more code, the organization moves faster.

Sometimes that is true.

Often it is not.

Progress is not measured by lines of code. It is measured by working behavior in production. A feature is not done when the code compiles. It is done when users can use it safely, the team can operate it, and the business can trust it.

AI can increase code output without increasing product progress.

This happens when generated code creates hidden work:

• Reviewers need more time to understand changes.

• QA needs more time to test edge cases.

• Security needs more time to inspect dependencies.

• DevOps needs more time to fix pipeline failures.

• Senior engineers need more time to correct architecture drift.

• Incident responders need more time to debug unfamiliar code.

• Product teams need more time to clarify behavior that AI guessed.

The pull request is not free because the first draft was cheap.

This is why teams can feel both faster and more tired.

They are writing less boilerplate, but reviewing more uncertainty.

They are shipping more changes, but cleaning up more failures.

They are using better tools, but carrying more coordination load.

The work did not disappear.

It moved.

The trust gap is part of the architecture

Stack Overflow's 2025 Developer Survey shows the trust gap clearly. AI tool usage and planned usage remain high, but trust in AI accuracy is weak. Stack Overflow's public reporting says 46 percent of developers do not trust AI output accuracy, while only 33 percent do.

That is not because developers are anti-AI.

It is because developers have used the tools enough to know their shape.

AI can produce correct-looking code that is wrong. It can use outdated APIs. It can ignore project conventions. It can invent tests that assert implementation details. It can miss security issues. It can overfit to examples. It can confidently explain a bug while missing the real cause.

This creates a new kind of review problem.

Traditional review asks:

• Is this logic correct?

• Is the design reasonable?

• Are tests enough?

• Does this fit our codebase?

AI-assisted review adds more questions:

• Did the model invent behavior?

• Did it copy an outdated pattern?

• Did it add a dependency we do not need?

• Did it weaken a test?

• Did it hide complexity behind generated code?

• Did it produce code the author fully understands?

• Did it change behavior outside the requested scope?

That last question is huge.

AI tools are often helpful, but they are not careful in the same way a responsible engineer is careful. They may touch too much. They may "clean up" code that should not be changed. They may improve style while altering behavior.

So trust cannot be a feeling.

Trust must be built into the delivery system.

You do not trust AI-generated code because it looks good.

You trust it because it survived the same engineering process as every other change.

Code review becomes a pressure point

AI makes it easier to create pull requests.

It does not make it easier for humans to review all of them.

This is one of the biggest practical problems in AI-assisted software development. Teams celebrate faster code creation, then discover that review capacity did not increase at the same rate.

Senior engineers become the bottleneck.

They now need to review:

• More code

• Larger diffs

• More generated tests

• More dependency changes

• More unfamiliar patterns

• More subtle behavior changes

• More code written by people who may not fully understand it

That creates fatigue.

And fatigue is dangerous.

A tired reviewer starts approving changes based on surface quality. The code is formatted. The tests pass. The description sounds plausible. The author says AI helped. The reviewer has ten more PRs waiting.

That is how risk enters production.

A good AI-era review process needs more structure.

The reviewer should not need to guess which parts were AI-generated.

Teams should normalize saying:

AI helped draft this. I reviewed the logic, changed these parts, and I need extra attention on the auth flow.

That is not weakness.

That is good engineering communication.

Tests matter more, not less

AI can generate tests quickly.

That does not mean the tests are good.

Many AI-generated tests are shallow. They check the happy path. They mock too much. They assert implementation details. They duplicate the bug. They pass because they test what the code does, not what the code should do.

This is a serious problem.

If AI writes the code and AI writes weak tests for that code, the pipeline can create a false sense of safety.

The result is green CI with fragile behavior.

Teams need better testing habits, not just more tests.

A useful AI-era testing strategy includes:

• Unit tests for core logic

• Integration tests for important boundaries

• Contract tests for APIs

• Regression tests for past bugs

• Property-based tests where logic has many input combinations

• End-to-end tests for critical user flows

• Security tests for authentication and authorization

• Load tests for high-traffic paths

• Manual exploratory testing for risky product behavior

AI can help write these.

But humans need to decide what matters.

A good test starts with a risk question:

What would be bad if this change were wrong?

Then write tests around that.

For example:

AI can draft tests, but the team must define the danger.

CI pipelines were not built for this volume

AI increases the number of changes. That increases load on CI.

More pull requests mean more builds, more test runs, more preview environments, more security scans, more containers, more artifacts, more cache misses, and more flaky failures.

If the CI system was already slow, AI makes it worse.

A slow CI system creates bad behavior:

• Developers skip tests locally.

• Reviewers approve before checks finish.

• Teams rerun flaky tests without fixing them.

• Pull requests sit for hours.

• Small changes batch into large changes.

• Engineers avoid refactoring because feedback is too slow.

AI does not solve slow feedback loops. It makes them more painful.

The answer is not only "buy more runners."

That may help, but CI design matters too.

A modern AI-era CI system should:

• Run fast checks first

• Split tests by risk and speed

• Cache dependencies aggressively

• Detect and quarantine flaky tests

• Run security checks early

• Avoid rebuilding unchanged parts

• Use preview environments for risky UI changes

• Keep main branch protected

• Make failure messages clear

• Track CI cost and duration over time

Fast code generation needs fast verification.

Otherwise the team creates code faster than it can prove the code works.

Feature flags become more important

When change volume increases, release control matters more.

Feature flags help separate deployment from release. The code can be deployed while the feature remains off, limited to internal users, or rolled out to a small percentage of traffic.

LaunchDarkly describes feature flags as a way to control production behavior in real time, target releases precisely, and recover quickly. That is exactly what AI-assisted teams need.

The key idea is simple:

Deploy safely before exposing widely.

Feature flags do not make bad code good.

They reduce blast radius.

That matters because AI-assisted development can increase the number of small changes reaching production. If every change is released to everyone at once, instability spreads quickly.

A good feature flag practice includes:

• Flags for risky behavior changes

• Clear flag owners

• Expiration dates for temporary flags

• Monitoring tied to rollout

• Fast disable path

• Cleanup process after release

• No long-term flag mess

Feature flags are not only a product tool.

They are a stability tool.

They let teams move faster without pretending every change is safe.

Rollback is not optional anymore

If AI increases change velocity, rollback becomes a core design requirement.

A rollback is not a failure. A rollback is a safety mechanism.

Teams should be able to answer:

• Can we turn this feature off?

• Can we revert this deployment quickly?

• Can we restore changed data?

• Can we undo a migration?

• Can we identify which change caused the issue?

• Can we reduce traffic to the broken path?

• Can we fail over to a simpler behavior?

The harder it is to rollback, the more dangerous frequent deployment becomes.

Different changes need different rollback plans.

AI-assisted teams should make rollback part of pull request review.

Ask:

If this goes wrong, how do we safely undo it?

If nobody knows, the change is not ready.

Observability has to cover the whole path

Production stability depends on knowing what changed and what happened after it changed.

For AI-assisted software, observability needs to connect several layers:

• Code changes

• CI runs

• Deployment events

• Feature flag changes

• Runtime errors

• Latency

• Logs

• Traces

• User behavior

• AI model calls

• Token usage

• Agent tool calls

• Cost

OpenTelemetry's GenAI work is important because AI systems introduce new telemetry needs. The OpenTelemetry project has been defining semantic conventions for generative AI operations, including model attributes, token usage, latency, prompts, completions, tool calls, and tool results where teams opt in.

That matters because AI-generated features often fail in ways normal logs do not explain.

An AI feature may be slow because a model call used too many tokens. It may be wrong because retrieval returned stale context. It may be expensive because retries multiplied. It may be unsafe because a tool was called with bad arguments.

You need traces that show the path.

Good observability answers:

• Which deployment introduced the problem?

• Which feature flag was on?

• Which model version was used?

• Which prompt version was used?

• Which tool was called?

• How many retries happened?

• Which users were affected?

• What was the cost?

• Did rollback fix it?

If the team cannot answer these questions, AI will feel unpredictable even when the root cause is ordinary software failure.

Security review gets harder

AI-generated code can introduce normal security bugs.

It can also introduce them at a higher volume.

Common risks include:

• Missing authorization checks

• Weak input validation

• Unsafe dependency choices

• Secret leakage in logs

• SQL injection in generated query code

• Insecure file handling

• Overly broad cloud permissions

• Broken tenant isolation

• Dangerous default configurations

• Generated code copied from outdated examples

OWASP's LLM application guidance focuses on risks like prompt injection, excessive agency, sensitive information disclosure, supply-chain vulnerabilities, and insecure output handling. Those risks matter when AI is part of the application. But ordinary application security still matters when AI is part of development.

AI does not remove the OWASP Top 10.

It gives teams more code where those risks can appear.

A practical security rule:

AI can suggest code, but it cannot approve security risk.

Security gates should be automated where possible, but human review is still needed for sensitive paths:

• Authentication

• Authorization

• Payments

• Admin features

• Data exports

• Customer data

• Cloud permissions

• AI tool execution

• Dependency changes

• Infrastructure changes

The more AI speeds up code creation, the more important it becomes to make security checks part of the default path.

Security cannot be a meeting at the end.

AI changes the meaning of developer productivity

Traditional productivity measures are already flawed.

AI makes them worse.

Lines of code, number of commits, pull requests created, and tickets closed can all increase while product quality decreases.

A developer who generates five pull requests that need heavy rework is not necessarily more productive than a developer who ships one careful change.

A team that deploys daily with constant incidents is not healthier than a team that deploys weekly with confidence.

Productivity must include stability.

Better measures include:

This is where DORA's framing is useful. Software delivery performance is not just deployment frequency. It includes lead time, change failure rate, failed deployment recovery time, and reliability.

AI should improve the whole system.

Not just the typing speed.

Platform engineering becomes the safety layer

As AI accelerates development, platform engineering becomes more important.

Not because every company needs a huge internal platform.

Because teams need safe defaults.

A good platform gives developers:

• Approved templates

• Standard CI pipelines

• Secure deployment paths

• Built-in observability

• Feature flag integration

• Secret management

• Dependency scanning

• Cost visibility

• Environment creation

• Rollback tools

• Documentation

• Golden paths

AI can generate code inside those boundaries.

Without boundaries, AI generates variety. Variety can be useful in exploration, but it is dangerous in production systems.

The goal is not to limit developers for no reason.

The goal is to make the safe path the easy path.

If the easiest way to create a service includes logging, metrics, auth, tests, deployment, rollback, and security scanning, AI-generated code has a better chance of landing in a stable system.

If every team invents its own pipeline, AI will amplify inconsistency.

Platform engineering turns AI speed into repeatable delivery.

The new delivery pipeline

The old mental model was simple:

Write code. Review. Test. Deploy.

The AI-era pipeline needs more explicit checkpoints.

This pipeline does not reject AI.

It assumes AI is part of the work.

But it prevents AI from skipping the work that makes software reliable.

A strong AI-era pipeline includes:

• Human planning before generation

• Small scoped changes

• Clear PR descriptions

• Automated linting and formatting

• Type checks

• Unit and integration tests

• Dependency review

• Secret scanning

• Security checks

• Code ownership rules

• Feature flags for risky changes

• Canary or staged rollout

• Observability and alerts

• Rollback path

• Post-release validation

That may sound heavy.

It is lighter than cleaning up production failures caused by unreviewed acceleration.

A practical checklist for teams

Here is a realistic checklist for teams adopting AI coding tools.

Before coding

• Write the expected behavior in plain language.

• Define what should not change.

• Identify risky files and systems.

• Decide whether AI should draft, explain, test, or refactor.

• Keep the task small enough to review.

During coding

• Ask AI for small changes, not giant rewrites.

• Review generated code before running it.

• Avoid accepting dependency additions casually.

• Keep generated code aligned with project conventions.

• Make the author explain the final code.

Before merge

• Check scope carefully.

• Run tests locally or in CI.

• Review generated tests for real signal.

• Check authorization and data access.

• Check logs for secret leakage.

• Check performance-sensitive paths.

• Add regression tests for bug fixes.

• Require owner review for critical systems.

Before release

• Use feature flags for risky behavior.

• Deploy gradually where possible.

• Confirm dashboards and alerts exist.

• Confirm rollback path.

• Monitor errors, latency, and user impact.

• Watch cost changes for AI features.

After release

• Add production failures to regression tests.

• Update prompts or templates if they caused issues.

• Track review load and CI load.

• Remove stale feature flags.

• Share patterns that worked.

• Fix platform gaps instead of blaming individuals.

This is the boring work.

It is also the work that lets teams use AI safely.

What good AI adoption looks like

Good AI adoption does not look like everyone generating as much code as possible.

It looks like better flow.

Developers spend less time on boilerplate and more time on design. Reviewers see smaller changes with clearer intent. Tests become more focused. CI becomes faster. Releases become safer. Observability gets better. Incidents become easier to debug. Teams learn which AI use cases help and which create cleanup work.

Good AI adoption has constraints.

Examples:

• AI can draft tests, but humans define test strategy.

• AI can write migrations, but migrations must be backward compatible.

• AI can draft security-sensitive code, but owners must review it.

• AI can suggest dependencies, but dependency review must approve them.

• AI can help with incidents, but humans own decisions.

• AI can write feature code, but rollout is controlled by flags.

• AI can refactor, but behavior must be protected by tests.

The goal is not to make AI powerless.

The goal is to make AI useful inside a system that understands risk.

The future is faster and more disciplined

AI will keep getting better at writing code.

That does not mean software delivery will become automatically stable.

The opposite may be true for teams without strong engineering systems. As code gets easier to produce, the limiting factor becomes everything after code generation.

Review.

Testing.

Security.

Deployment.

Observability.

Rollback.

Ownership.

User trust.

The teams that benefit most from AI will not be the teams that generate the most code. They will be the teams that convert AI speed into reliable product changes.

That requires discipline.

It requires small changes. Strong tests. Fast CI. Feature flags. Good logs. Good traces. Security gates. Rollback paths. Platform defaults. Honest metrics. Human accountability.

None of that sounds as exciting as an AI agent writing a feature from a prompt.

But it is what makes the feature safe to ship.

AI is making software faster.

Whether it makes software better depends on the engineering around it.

References

• DORA, State of AI-assisted Software Development 2025

• Google Cloud, Announcing the 2025 DORA Report

• Google Blog, How are developers using AI?

• Stack Overflow 2025 Developer Survey, AI

• Stack Overflow 2025 Developer Survey press release

• GitHub Octoverse 2025

• GitHub Blog, Octoverse 2025

• Harness, The State of AI in Software Engineering

• TechRadar, AI has slashed coding time but sacrificed software stability

• OpenTelemetry, AI Agent Observability

• OpenTelemetry, Semantic conventions for generative AI systems

• OpenTelemetry, Inside the LLM Call

• OWASP Top 10 for LLM Applications

• LaunchDarkly, Feature flags

• LaunchDarkly, Managing AI risk with runtime control

Building a chatbot over your documents? Use a vector database.

Building semantic search? Use a vector database.

Building RAG? Use a vector database.

Building product recommendations? Use a vector database.

That answer is sometimes correct. It is also incomplete.

A vector database is a useful tool, but it is not the whole retrieval system. It does not fix bad chunking. It does not understand your permissions model. It does not know which source is stale. It does not magically make retrieval accurate. It does not replace keyword search. It does not remove the need for ranking, filtering, evaluation, or good product design.

Most teams do not actually need "a vector database" first.

They need a search system.

That search system may include vectors. It may include Postgres. It may include BM25. It may include metadata filters. It may include reranking. It may include a dedicated vector database later. But if you start with the tool before understanding the retrieval problem, you can easily add infrastructure without improving the product.

This article is a practical guide to that decision.

Not anti-vector database.

Anti-overbuilding.

What vector databases actually solve

A vector database stores and searches embeddings.

An embedding is a list of numbers that represents the meaning of something: a sentence, paragraph, image, product, user profile, document, code snippet, support ticket, or audio clip. Items with similar meaning should end up close together in vector space.

That lets you search by meaning instead of only matching words.

If a user searches for:

How do I reset my password?

A semantic search system can still find documents that say:

Recover access to your account

A keyword search system might miss that because the exact words are different.

That is the real value of vector search.

Vector databases are built to make this kind of search fast at scale.

They usually provide:

• Vector storage

• Approximate nearest neighbor search

• Metadata filtering

• Indexing

• APIs for insert and query

• Scaling and replication

• Monitoring and operational tooling

Dedicated products like Pinecone, Weaviate, Qdrant, and Milvus exist because vector workloads can become large and demanding. Pinecone describes itself as a fully managed vector database built for AI, with automatic indexing and fast queries at scale. Qdrant supports dense and sparse vector approaches and documents hybrid search patterns. Weaviate supports vector search, keyword search, and hybrid search using BM25F and vector fusion.

So yes, vector databases solve real problems.

But they solve a specific layer of the problem.

They help you find similar vectors quickly.

That is not the same as building reliable retrieval.

Similarity is not relevance

This is the first trap.

Vector search finds semantic similarity. Product search, document search, and RAG need relevance.

Those are not the same thing.

A result can be semantically similar and still be wrong.

A support article can talk about billing, but not the billing issue the user has.

A code snippet can look similar, but use the wrong framework version.

A policy document can match the question, but be outdated.

A product can be similar, but unavailable in the user's country.

A paragraph can be close in vector space, but miss the exact keyword that matters.

This is why pure vector search often disappoints in production.

It feels impressive in demos because it understands fuzzy intent. But real users search for exact things too.

They search for:

• Error codes

• Invoice numbers

• API names

• Product SKUs

• Policy IDs

• Function names

• Legal terms

• Version numbers

• Customer names

• Acronyms

Dense embeddings are not always good at exact matching. A vector search system may understand that two documents are related while still failing to prioritize the one with the exact identifier the user typed.

That is why keyword search still matters.

PostgreSQL's full text search documentation describes the classic search pipeline: convert documents into a searchable tsvector, convert user input into a tsquery, rank results by relevance, and display the matches usefully. That may sound old compared with embeddings, but it solves a real problem that embeddings do not replace.

Search is not one technique.

It is a ranking problem.

And ranking usually needs more than one signal.

Hybrid search is usually the better default

The better default for many products is hybrid search.

Hybrid search combines semantic search with keyword search. The goal is simple: use vectors to understand meaning and use lexical search to preserve exact matching.

Weaviate's documentation describes hybrid search as combining vector search and keyword search, often BM25, then fusing the result sets. Qdrant describes hybrid search as combining dense vectors for semantic understanding with sparse vectors for precise word matching. Elastic recommends reciprocal rank fusion, or RRF, for combining semantic and lexical result rankings.

The reason is practical.

Users do not search in one mode.

Sometimes they describe meaning.

Sometimes they type exact words.

Sometimes they do both.

Hybrid search handles both sides better.

This matters a lot for RAG.

A language model can only answer well if the retrieval system gives it the right context. If retrieval misses the exact document, the final answer may still sound confident. That is worse than a normal search failure because the user may not know retrieval failed.

Hybrid search reduces that risk.

It does not guarantee correctness.

But it gives your system more ways to find the right thing.

Reranking is where quality often improves

Many teams stop at vector search.

A better retrieval pipeline usually has at least two stages.

First, retrieve a broad set of candidates.

Then rerank them.

The first stage needs speed. The second stage needs quality.

This is common in modern search systems because the fastest retrieval method is not always the best final judge.

A vector index is optimized for quickly finding approximate neighbors. A reranker can compare the query and candidate documents more carefully. It can account for task-specific relevance, exact wording, freshness, source quality, and other signals.

Reranking is especially useful when:

• Many chunks are semantically similar

• Documents are long

• Search results come from multiple sources

• Queries are ambiguous

• The answer depends on exact context

• You need fewer but higher quality chunks for an LLM

Without reranking, teams often stuff too many chunks into the context window. That increases cost and can reduce answer quality because the model has to sort through noisy context.

A smaller set of better chunks is usually better than a larger set of weak chunks.

This is one reason "just use a vector database" is not enough.

The vector database may get you candidates.

It does not finish the ranking job by itself.

pgvector is enough more often than people think

If your application already uses Postgres, start by seriously considering pgvector.

pgvector adds vector similarity search to Postgres. Its official repository describes support for exact and approximate nearest neighbor search, including HNSW and IVFFlat indexes. This means you can store embeddings next to relational data and query them with SQL.

That is a big deal.

For many teams, the hardest part of retrieval is not vector math. It is product logic.

You need to filter by tenant, user permissions, document status, language, region, product, organization, plan, freshness, and visibility.

That data often already lives in Postgres.

Keeping vectors in the same database can simplify the system.

The advantages are boring but important.

This is especially useful for:

• Internal tools

• Early RAG systems

• SaaS knowledge search

• Support search

• Product catalogs with moderate scale

• Documentation search

• Multi-tenant apps that already depend on Postgres permissions

• Teams that do not yet know their retrieval workload shape

Does pgvector replace Pinecone, Qdrant, Weaviate, Milvus, or OpenSearch for every use case?

No.

But it can delay the need for another moving part. That delay has value.

Every new database adds operational work: migrations, backups, security, observability, access control, local development, incident response, data consistency, and cost monitoring.

If Postgres can serve the first version well, start there.

You can move later when the problem is clearer.

A dedicated vector database makes sense at real scale

Dedicated vector databases exist for a reason.

There are situations where Postgres is not the right retrieval engine anymore.

You may need a dedicated vector database when:

• You have tens or hundreds of millions of vectors

• You need very low latency at high query volume

• You need heavy concurrent writes and reads

• You need vector-native scaling and replication

• You need advanced filtering at vector scale

• You need multi-modal search across text, image, audio, or video

• You need managed operations for a large retrieval workload

• You need search features your current database cannot provide cleanly

  

The mistake is not choosing a dedicated vector database.

The mistake is choosing one before you know why.

If the reason is "we are building AI", that is not enough.

Better reasons sound like this:

• Our vector index no longer fits our latency target.

• We need higher recall at much larger scale.

• We need operational isolation from the primary database.

• Our retrieval workload is growing faster than the app database.

• We need hybrid search features that are better supported elsewhere.

• We need managed scaling because our team cannot operate this layer.

That is a real decision.

Not hype.

Chunking can matter more than the database

Many RAG systems fail before the vector database is even involved.

They fail during chunking.

Chunking is the process of splitting documents into smaller pieces before embedding them. If chunks are too small, they lose context. If chunks are too large, they become noisy and expensive. If chunks ignore document structure, retrieval becomes messy.

A vector database can only search what you give it.

Bad chunks create bad retrieval.

Good chunking usually respects structure.

For example:

• Keep headings with their sections.

• Avoid splitting tables carelessly.

• Preserve code blocks.

• Keep policy clauses intact.

• Add document title and source metadata.

• Include timestamps and version information.

• Consider parent-child retrieval for long documents.

Bad chunking looks like this:

• Split every 500 characters blindly.

• Remove headings.

• Mix unrelated sections.

• Drop source metadata.

• Ignore document versions.

• Embed duplicate or stale content.

This is why teams can switch vector databases and see no improvement.

The problem was never the database.

The problem was the shape of the indexed knowledge.

Metadata is not optional

A vector without metadata is rarely enough.

Real retrieval needs filters.

Metadata lets you ask not only "what is similar?" but "what is similar and allowed, current, relevant, and useful?"

Useful metadata includes:

• Tenant ID

• User access level

• Source system

• Document type

• Created date

• Updated date

• Version

• Language

• Region

• Product

• Department

• Sensitivity level

• Status

• Authoritative source flag

  

Metadata is also where security enters retrieval.

If a user cannot access a document directly, your RAG system should not expose it through an LLM answer. This is one of the easiest ways to create an accidental data leak.

The permission filter must happen before the answer is generated.

Not after.

A bad pipeline retrieves everything, lets the model answer, and hopes the answer does not reveal sensitive information.

A safer pipeline filters by access before the model sees the content.

This is another reason Postgres can be a strong starting point. Many applications already model users, roles, organizations, and permissions in Postgres. Keeping retrieval near that data can reduce accidental mismatch.

Dedicated vector databases can also support metadata filtering, but you still need to design the permission model carefully.

A vector database is not an authorization strategy.

Freshness beats cleverness

RAG systems often fail because they retrieve old information.

The answer may be semantically perfect and practically wrong.

A pricing document from last year.

An old API guide.

A deprecated policy.

A support article that was replaced.

A legal clause that only applies to one region.

A vector database will not automatically understand that one document is stale unless you model freshness.

Add freshness signals.

Freshness should affect ranking and filtering.

Sometimes you should keep older documents, but label them clearly.

For example, if a user asks about policy history, old documents are relevant. If the user asks what rule applies now, old documents are dangerous.

Search systems need product logic.

Vector similarity alone cannot answer "which source should win?"

The retrieval stack has layers

A serious retrieval system has more layers than most diagrams show.

The vector database is only one box.

Each layer can fail.

When a RAG system performs badly, do not immediately blame the vector database.

Inspect the pipeline.

Most failures hide upstream.

Evaluate retrieval before changing databases

A common mistake is to switch infrastructure when the team has not measured retrieval quality.

Before moving from Postgres to a vector database, or from one vector database to another, build an evaluation set.

You need examples.

Start with 100 to 300 realistic queries.

For each query, label:

• The ideal document

• The ideal chunk

• Acceptable alternative documents

• Bad but tempting documents

• Whether exact keywords matter

• Whether freshness matters

• Whether permissions matter

Then measure the retrieval system.

Useful metrics include:

This gives you a basis for decisions.

If recall is bad, maybe chunking or embeddings are wrong.

If exact matches are bad, add keyword search.

If good results are retrieved but ranked poorly, add reranking.

If latency is bad at scale, improve indexes or evaluate a dedicated vector database.

If stale results appear, fix metadata and freshness ranking.

If restricted content appears, fix permissions immediately.

Without evals, architecture discussions become opinions.

With evals, they become engineering.

Cost is part of the search design

Vector search has costs that are easy to ignore early.

There is embedding cost.

There is storage cost.

There is indexing cost.

There is query cost.

There is reranking cost.

There is context window cost when retrieved chunks are sent to an LLM.

A bad retrieval system can be expensive even if the database is cheap.

For example, if your search returns noisy chunks, you may send too much context to the model. If you embed duplicate documents, you pay more to store and search them. If your reranker runs on too many candidates, latency and cost rise. If you choose a managed service too early, you may pay for scale you do not yet need.

Cost-aware retrieval design includes:

• Deduplicating documents

• Not embedding drafts unless needed

• Re-embedding only changed content

• Keeping chunks meaningful but not huge

• Retrieving enough candidates, not too many

• Reranking only the top candidates

• Caching common queries when appropriate

• Measuring context token usage

• Using smaller embedding models when quality is acceptable

• Starting with existing infrastructure when it is good enough

This is where "vector databases are not always the answer" connects to architecture.

The best retrieval system is not the fanciest one.

It is the one that gives good enough results at a cost and complexity your team can operate.

A practical decision framework

Here is a simple way to decide.

Start with the question:

What kind of search problem do we actually have?

Then choose based on real conditions.

A good rule:

Start with the simplest retrieval system that can be evaluated.

Not the simplest one that feels good.

The simplest one that can be measured.

If pgvector plus Postgres full text search gets strong retrieval metrics, keep it. If it fails for clear reasons, upgrade the right layer.

Common mistakes teams make

Here are the mistakes I see most often.

Mistake 1: Treating RAG as vector search plus prompt

RAG is not just retrieve chunks and paste them into a prompt.

It is ingestion, cleaning, chunking, embedding, indexing, retrieval, filtering, ranking, context construction, generation, citation, evaluation, and monitoring.

Skipping those layers creates fragile systems.

Mistake 2: Ignoring keyword search

Vector search is not a replacement for exact matching.

If users search for error codes, order numbers, SKUs, function names, or policy clauses, keyword search matters.

Mistake 3: No permissions at retrieval time

Filtering after generation is too late.

The model should not see documents the user cannot access.

Mistake 4: No eval dataset

Without labeled queries, you cannot tell whether a database migration, embedding model change, chunking change, or reranking step improved anything.

Mistake 5: Bad metadata

Metadata is how retrieval becomes useful in real products.

Without metadata, you cannot filter by tenant, source, freshness, language, status, or permissions.

Mistake 6: Overusing the context window

Long context windows are helpful, but they do not remove the need for retrieval quality.

More context can mean more noise.

Mistake 7: Choosing infrastructure before understanding workload

A dedicated vector database may be the right answer.

But not because a tutorial used one.

Choose it when scale, latency, features, or operations justify it.

What a sane first version looks like

For many teams, a sane first version looks like this:

This version is not glamorous.

It is useful.

It gives you:

• Fewer systems

• SQL joins

• Permission-aware retrieval

• Hybrid search

• Measurable results

• A migration path later

Start here when the scale is reasonable and your data already lives in Postgres.

Then improve based on evidence.

Possible next steps:

• Add better chunking

• Add query rewriting

• Add reranking

• Add feedback capture

• Add freshness ranking

• Add source quality weights

• Add caching for common queries

• Move hot retrieval paths to a dedicated search system

• Move vectors to a dedicated vector database if needed

This is how you avoid premature infrastructure.

You do not refuse complexity.

You make it earn its place.

When the dedicated vector database wins

A dedicated vector database wins when vector search is not a feature inside your product, but a major workload of your product.

For example:

• An AI search product

• A recommendation platform

• A multi-modal media search engine

• A large RAG platform serving many teams

• A marketplace with huge semantic search volume

• A security analytics product using embeddings at scale

• A company-wide knowledge platform with strict latency targets

At that point, the vector layer deserves specialized infrastructure.

You may want:

• Better vector indexing at scale

• Easier horizontal scaling

• Managed operations

• Vector-native APIs

• Advanced hybrid search

• Better observability for retrieval

• Separation from the transactional database

• Search-specific replication and availability

That is a good reason.

The point is not "never use Pinecone" or "always use pgvector".

The point is to avoid confusing categories.

Postgres is a great application database with vector search capabilities.

A dedicated vector database is a specialized retrieval system.

A search engine is a ranking and discovery system.

A RAG pipeline is an application architecture.

Those are related, but they are not the same thing.

The architecture should match the product

Search for a legal document is different from search for a sneaker.

Search for code is different from search for support tickets.

Search for medical policies is different from search for blog posts.

Search for internal company knowledge is different from public ecommerce search.

The architecture should match the risk, user expectation, and data shape.

This is why generic RAG tutorials can be dangerous.

They make every retrieval problem look the same.

Real retrieval is domain-specific.

A legal assistant should be conservative.

A shopping search can be fuzzy.

A code assistant needs exact symbols.

A support assistant needs escalation logic.

A vector database cannot decide those priorities for you.

Your architecture has to encode them.

The boring answer is usually better

The boring answer is not "do not use vectors".

The boring answer is:

• Use keyword search where exact matching matters.

• Use vector search where meaning matters.

• Use metadata where product rules matter.

• Use reranking where quality matters.

• Use evals where decisions matter.

• Use a dedicated vector database when scale or features justify it.

• Use Postgres when it is good enough and already central to your app.

That is less exciting than a new database logo.

It is also how better systems get built.

The teams that win with RAG and semantic search will not be the teams that collected the most AI infrastructure. They will be the teams that understood their retrieval problem clearly.

They will know what users search for.

They will know which documents are trusted.

They will know how permissions work.

They will know whether exact terms matter.

They will know when freshness beats similarity.

They will know how to measure quality.

Only then will the database choice become obvious.

Vector databases are useful.

They are just not always the answer.

Sometimes the answer is Postgres.

Sometimes it is hybrid search.

Sometimes it is better metadata.

Sometimes it is reranking.

Sometimes it is better chunking.

Sometimes it is an eval set.

And sometimes, yes, it is a dedicated vector database.

The hard part is knowing which problem you actually have.

That is where architecture starts.

References

• pgvector official GitHub repository

• PostgreSQL full text search documentation

• Weaviate hybrid search documentation

• Weaviate hybrid search concepts

• Qdrant hybrid queries documentation

• Qdrant sparse vectors article

• Elastic reciprocal rank fusion documentation

• Elastic hybrid search documentation

• OpenSearch reciprocal rank fusion for hybrid search

• Pinecone official website

• LangChain retrieval documentation

• Neon PostgreSQL full text search guide

• TigerData pgvector guide

Pick a framework. Build the app inside it. Let that framework decide routing, data loading, state management, rendering, forms, and deployment patterns.

That model still works. Next.js, Nuxt, SvelteKit, Remix, Angular, and other full-stack frameworks are not going away. But a different pattern is becoming harder to ignore.

Instead of one framework owning everything, many teams are assembling applications from smaller, sharper, type-safe primitives.

A router that understands search params.

A query library that treats server data as server data.

A table library that gives you logic but not markup.

A form library that cares about type safety and validation.

A full-stack framework that grows out of those primitives instead of hiding them.

That is what people mean by the TanStack-ification of frontend development.

It is not only about TanStack as a brand. It is about a wider architectural shift. Frontend developers are moving toward composable building blocks that solve one hard problem well, work across frameworks where possible, and give teams more control over how the final application is shaped.

This article is a practical look at that shift.

Not hype. Not fanboying.

Just the architecture trend underneath it.

What TanStack actually is

TanStack is an open-source application stack for web development. Its best-known project is TanStack Query, formerly React Query, but the ecosystem now includes Router, Table, Form, Virtual, Start, Store, DB, Config, and more.

The official TanStack site describes the stack as a set of open-source tools for building web applications. TanStack Start, for example, is a full-stack React framework powered by TanStack Router. Its docs describe support for full-document SSR, streaming, server functions, bundling, and deployment across hosting providers and runtimes.

That matters because TanStack is no longer just a useful data-fetching library.

It is becoming a way to think about frontend architecture.

Each piece has a focused job.

The key idea is not that every team must use every TanStack package.

The key idea is separation of concerns.

A router should be great at routing. A query library should be great at server state. A table library should not force your design system. A form library should not assume your component style. A full-stack framework should not make data fetching, routing, and server calls feel like unrelated problems.

TanStack represents a growing preference for tools that are powerful but not visually opinionated.

That is a big shift.

The old frontend stack was too tangled

To understand why TanStack-style tools are attractive, it helps to remember what many frontend apps became.

A lot of React apps started simple. Components, props, state, and fetch calls.

Then the app grew.

Suddenly the team needed caching, loading states, pagination, optimistic updates, route params, URL state, tables, filters, form validation, server errors, retries, authentication, permissions, and background updates.

At that point, teams often mixed several different ideas into one messy layer.

This works for a while.

Then the bugs appear.

• Data refetches too often.

• Data does not refetch when it should.

• Loading states are inconsistent.

• Form errors are duplicated.

• URL filters fall out of sync with UI state.

• Tables become custom state machines.

• Pagination logic is copied across pages.

• Mutations update the server but not the UI.

• Search params are strings everywhere.

• Types exist, but they do not protect the full flow.

The problem is not React. The problem is that the app has many kinds of state, and they are not the same.

Client state is not server state.

Form state is not URL state.

Table state is not authentication state.

Cached data is not source-of-truth data.

A frontend app gets easier to reason about when each state type has a proper home.

This is the heart of the TanStack-ification trend.

Not more libraries for the sake of more libraries.

Better boundaries.

Server state is not client state

TanStack Query became popular because it named a problem many developers were already fighting.

Server data is different from client state.

A sidebar open or closed flag lives in the browser. The browser owns it.

A list of invoices comes from the server. The server owns it. The client has a cached view of it.

Those are not the same thing.

TanStack Query's docs describe it as a library for asynchronous state management and server-state utilities. It handles fetching, caching, updating, refetching, pagination, infinite scroll, mutations, background updates, and more.

That is why it became so important.

It gave frontend developers a vocabulary and a tool for server state.

Without a tool like this, teams often rebuild the same behavior by hand.

They write loading state. Then error state. Then retry logic. Then cache invalidation. Then refetch-on-focus. Then pagination. Then mutation updates. Then optimistic UI. Then race condition fixes.

At that point, the team has accidentally written a worse server-state library.

TanStack Query also changed how teams think about global state.

For years, many apps put server data inside global client state stores. Redux, MobX, Zustand, and similar tools can hold data, but TanStack Query's docs are clear that Query is a server-state library, while Redux, MobX, Zustand, and others are client-state libraries.

That distinction improves architecture.

The result is calmer code.

The component asks for data. The query layer manages the messy lifecycle.

That is the kind of boring abstraction frontend apps need.

Routing became a type system problem

Routing used to feel simple.

A path maps to a page.

Then apps became more complex.

Routes started carrying data dependencies, search params, layout boundaries, loading states, pending states, auth requirements, error boundaries, and nested UI structures.

A modern route is not just a URL.

It is an application boundary.

TanStack Router leans into that idea. The TanStack site describes it as offering fully type-safe APIs, first-class search params for managing state in the URL, and integration with the React ecosystem.

The important phrase is search params.

Many apps store important state in the URL:

• Current page

• Search query

• Sort order

• Active filters

• Selected tab

• Date range

• View mode

When that state is typed poorly, bugs follow.

/users?page=2&sort=created_at&status=active

In many apps, those values are read as strings, parsed manually, and passed around loosely.

That creates hidden problems.

• Is page a number or string?

• What happens if page=abc?

• Is status optional?

• Which sort values are allowed?

• Does the URL match the table state?

• Does changing filters reset pagination?

A type-safe router makes this more explicit.

This is one reason TanStack Router is interesting. It treats routing, search params, and data dependencies as connected problems.

That fits where frontend is heading.

The URL is not just navigation anymore. It is part of application state.

When URLs are typed, shareable, and validated, the app becomes easier to debug and easier to use.

A filter-heavy admin dashboard is the perfect example.

If filters live only in React state, the user cannot share the view. If filters live in the URL as untyped strings, the code gets fragile. If filters are typed route state, the UI, data fetching, and navigation can agree.

That is a small architectural win that compounds across an app.

Headless UI won because design systems won

TanStack Table is one of the clearest examples of a broader frontend trend: headless libraries.

A headless library gives you behavior without forcing markup or styling.

TanStack Table's official docs describe it as a headless UI library for building powerful tables and data grids across several frameworks. It gives you table logic while letting you control markup and styles.

That matters because tables are deceptively hard.

A serious data table often needs:

• Sorting

• Filtering

• Pagination

• Row selection

• Column visibility

• Column resizing

• Grouping

• Expansion

• Virtualization

• Editable cells

• Server-side data

• Accessibility

• Custom actions

• Design system integration

You can buy a full data grid that includes UI. Sometimes that is the right choice.

But many teams already have a design system. They do not want a table that looks and behaves like a separate product inside their app.

They want table logic that adapts to their UI.

This pattern explains why headless libraries became popular.

They respect the separation between behavior and presentation.

The same idea appears in Radix UI, Headless UI, Ariakit, React Aria, and many other libraries.

TanStack Table fits this movement perfectly.

It says: here is the hard table logic. You bring the UI.

For teams building product interfaces, that is often the right tradeoff.

Forms are still hard

Forms are where frontend architecture goes to be humbled.

A form looks simple until it has real requirements.

Then it needs default values, dirty state, touched state, nested fields, arrays, async validation, server validation, conditional fields, optimistic submission, reset behavior, field-level errors, form-level errors, accessibility, localization, and type safety.

Many teams underestimate forms because HTML forms look simple.

Business forms are not simple.

TanStack Form's docs describe it as a headless, performant, type-safe form state management library for multiple frameworks. It focuses on form state, validation, and workflows while letting teams bring their own UI.

That fits the TanStack pattern.

Logic without visual lock-in.

The larger trend is type safety across the full form lifecycle.

A good form system should help answer:

• What fields exist?

• What values are valid?

• What errors can appear?

• What does the submit handler receive?

• What does the server return?

• Which fields are dirty?

• Which fields should re-render?

This is where frontend and backend start to blur.

A form is not only UI. It is a contract between user input, validation logic, server rules, and persisted data.

That is why form libraries are moving closer to schema validation tools like Zod, Valibot, ArkType, and others.

The direction is clear.

Frontend code wants stronger contracts.

Not because developers love types for their own sake, but because real apps are full of small data-shape bugs.

Full-stack frameworks are changing shape

TanStack Start is the piece that makes the trend feel larger than a collection of libraries.

Its docs describe it as a full-stack React framework powered by TanStack Router, with full-document SSR, streaming, server functions, bundling, and deployment flexibility through Vite.

That places TanStack inside the same broad conversation as Next.js, Remix, Nuxt, SvelteKit, SolidStart, and other meta-frameworks.

But the design philosophy feels different.

Many full-stack frameworks start as a complete application framework, then expose lower-level primitives.

TanStack started with primitives, then moved toward a framework.

That difference matters.

TanStack Start is not just "another React framework" in the abstract. It is a framework built around ideas TanStack has already pushed for years:

• Type-safe routing

• Explicit server state

• Search param state

• Headless control

• Server functions

• Streaming

• Framework-level data loading

• Deployment flexibility

LogRocket's 2026 web development trends article explicitly lists the "TanStack-ification of frontend development" as one of the trends that will define web development in 2026. It also mentions wider adoption of TypeScript and server functions for backendless apps.

That combination is important.

Server functions are one of the reasons frontend architecture is changing.

A frontend developer can now write code that feels close to the UI but runs on the server. That reduces some API boilerplate, but it also increases the need for clear boundaries.

This can be cleaner than manually wiring REST endpoints for every interaction.

It can also become confusing if teams do not understand what runs on the client and what runs on the server.

So the future is not "no backend".

The future is tighter integration between frontend and backend boundaries, with better types and fewer manual seams.

The composable stack is replacing the one-stack mindset

The biggest change is philosophical.

Frontend teams are moving from a one-stack mindset to a composable-stack mindset.

The older question was:

Which framework should we use?

The newer question is:

Which primitives should own each problem?

That changes the architecture discussion.

This gives teams more flexibility.

It also gives them more responsibility.

A batteries-included framework can protect a team from making many decisions. A composable stack asks the team to make those decisions intentionally.

That is powerful when the team has experience.

It can be overwhelming when the team does not.

This is the tradeoff at the center of TanStack-style development.

Neither side is always better.

A startup building a standard content site may not need TanStack Router, Query, Table, Form, and Start. A team building a complex B2B dashboard may benefit from all of them.

The key is to match the tool to the shape of the product.

Why this matters for AI apps

TanStack-ification also connects to AI app development.

AI applications are often data-heavy, stateful, and workflow-heavy. They need conversation state, tool call state, streaming responses, background jobs, file uploads, retrieval results, evaluation traces, billing state, and user controls.

That kind of app benefits from strong frontend primitives.

An AI app may need:

• Streaming UI

• Server state caching

• Tool execution history

• Trace tables

• Prompt version forms

• URL-shareable filters

• Dataset management

• Evaluation dashboards

• Admin review queues

• Human approval interfaces

That is not a simple chat box anymore.

It is a product interface.

This is where TanStack-style tools become practical.

AI apps are not only about calling a model. They are about managing many states around the model.

The model returns data. The UI streams it. The server stores it. The user edits it. The admin reviews it. The team evaluates it. The billing system counts it.

That is a lot of frontend work.

A composable stack helps because each concern can have a clear owner.

The downside is real

TanStack-ification is not free.

A composable stack can become its own kind of complexity.

Instead of one framework with strong conventions, a team may end up with five powerful libraries that need to be wired together correctly.

That creates risks.

• Too many decisions for new developers

• Multiple mental models

• Version compatibility concerns

• More custom architecture

• Less copy-paste documentation for your exact stack

• More responsibility for app conventions

• Potential overengineering for small apps

There is also a supply-chain lesson here.

In May 2026, several TanStack npm packages were compromised as part of a broader Mini Shai-Hulud supply-chain attack. Snyk and OpenAI both published responses discussing the incident. That does not mean TanStack is uniquely unsafe. It means popular packages become high-value targets.

A popular composable ecosystem creates real dependency risk.

This is not a reason to avoid TanStack. It is a reason to treat dependencies seriously.

Teams should use:

• Lockfiles

• Dependency review

• Package provenance where available

• CI checks

• Trusted registries where appropriate

• Version pinning for critical apps

• Security alerts

• Minimal dependency surfaces

Composable frontend development still needs security discipline.

The more your stack depends on open-source packages, the more your software supply chain becomes part of your architecture.

That is now normal.

When TanStack-style architecture is a good fit

TanStack-style architecture works best when the product has enough complexity to justify focused primitives.

It is a strong fit for:

• SaaS dashboards

• Admin panels

• Analytics tools

• AI product interfaces

• Internal platforms

• Data-heavy B2B apps

• Workflow tools

• Developer tools

• Apps with complex filters and URL state

• Apps with tables, forms, and server state everywhere

It may be too much for:

• Small static sites

• Simple blogs

• Basic landing pages

• Very small CRUD apps

• Teams that need maximum convention over configuration

• Projects where one full-stack framework already solves the problem cleanly

A decision tree helps.

The rule is simple.

Do not adopt the whole stack because it is fashionable.

Adopt the primitive that solves the problem you actually have.

How I would build with this pattern

If I were building a modern data-heavy SaaS app today, I would start with clear boundaries.

For example:

• TanStack Router for route and search param state

• TanStack Query for server state

• TanStack Table for complex data tables

• TanStack Form for serious forms

• Zod or Valibot for schema validation

• A design system built with headless components

• A server layer through TanStack Start, Remix, Next.js, or a typed API

• A database layer with explicit validation and authorization

The architecture would look like this.

The important thing is not the exact tool list.

The important thing is ownership.

• Routes own navigation and URL state.

• Query owns server state.

• Forms own form state.

• Tables own table state.

• The server owns business rules.

• The database owns persistence.

• The design system owns presentation.

That separation keeps the app understandable.

It also makes AI-assisted development easier. When architecture has clear boundaries, AI tools have fewer chances to put logic in the wrong place.

What this says about the future of frontend

Frontend development is not becoming simpler in the sense that there are fewer things to know.

It is becoming more explicit.

The hidden problems are being named:

• Server state

• URL state

• Form state

• Table state

• Async state

• Streaming state

• Server functions

• Type-safe boundaries

• Headless behavior

• Design system integration

TanStack did not invent all of these problems. It made a lot of them easier to model.

That is why the ecosystem matters.

The future frontend stack may look less like one giant framework and more like a set of well-defined layers.

Frameworks will still matter.

But the best frameworks may be the ones that compose strong primitives instead of hiding everything behind magic.

That is the deeper meaning of TanStack-ification.

It is a move away from frontend as a pile of components and effects.

It is a move toward frontend as a set of typed, observable, composable systems.

The practical takeaway

The TanStack-ification of frontend development is not a command to rewrite your app.

It is a signal.

Frontend applications have grown into serious software systems. They need better boundaries. They need better server-state handling. They need typed routing. They need headless logic that works with design systems. They need forms that do not collapse under real business rules. They need full-stack patterns that reduce boilerplate without hiding the architecture.

TanStack is popular because it meets that moment.

It gives developers tools that are powerful without being visually controlling. It lets teams compose the stack around the product instead of forcing the product into one framework's worldview.

That freedom is useful.

It also requires discipline.

Use TanStack Query when server state is becoming messy.

Use TanStack Router when URL state and routing need stronger types.

Use TanStack Table when table logic is becoming a product feature.

Use TanStack Form when forms are no longer simple.

Evaluate TanStack Start when you want a full-stack React framework built around those primitives.

But do not use all of it just to feel modern.

The best frontend architecture is not the one with the trendiest stack.

It is the one where every part has a job, every boundary is understandable, and the team can still move fast six months later.

That is what TanStack-ification gets right.

It is not about making frontend development more complicated.

It is about giving the complexity a proper shape.

References

• TanStack official website

• TanStack Start overview

• TanStack Query documentation

• TanStack Query server state guide

• TanStack Router documentation

• TanStack Table documentation

• TanStack Form documentation

• LogRocket, The 8 trends that will define web development in 2026

• JavaScript Rising Stars 2025

• Snyk, TanStack npm packages hit by Mini Shai-Hulud

• OpenAI, response to the TanStack npm supply chain attack

• shadcn/ui Data Table guide using TanStack Table

A team designed the product. Developers built the features. DevOps prepared deployment. Then, near the end, someone asked the security team to review it.

That model no longer works.

Modern systems move too fast. They depend on open source packages, cloud identity, APIs, CI pipelines, third party services, containers, infrastructure as code, managed databases, AI tools, and internal automation. A single product is no longer just an app. It is a chain of trust across code, people, platforms, vendors, secrets, data, and runtime behavior.

When security is added at the end, it becomes expensive and weak.

The better approach is security first architecture.

This does not mean every developer must become a full time security engineer. It does not mean slowing down teams with endless approval meetings. It means the system is designed so that secure behavior is the default path.

Security is not a gate at the end.

It is part of the architecture.

Why this shift is happening now

Security first architecture is not appearing because security teams suddenly became louder. It is appearing because the shape of software changed.

A modern application has more entry points than before:

• Web and mobile clients

• Public APIs

• Internal APIs

• Admin dashboards

• Background workers

• Webhooks

• Cloud storage

• CI and CD pipelines

• Package registries

• Infrastructure as code

• AI agents and internal tools

• Third party integrations

Each entry point creates trust decisions.

Who can call this API?

Which data can they see?

Which service can talk to which service?

Can this build artifact be trusted?

Can this dependency be trusted?

Can this AI tool access production data?

Can this container run with these permissions?

Can this employee action be audited later?

Traditional security reviews struggle with this because they happen too late. By the time the architecture exists, changing trust boundaries is painful.

CISA's Secure by Design initiative captures this shift clearly. It pushes software makers to take ownership of customer security outcomes, make secure defaults normal, and treat security as a product responsibility rather than a burden pushed onto users.

NIST's Secure Software Development Framework makes a similar point from the process side. It describes secure development practices across preparation, protection, production, and response. The important part is that security work starts before release.

The lesson is simple.

You cannot scan your way out of bad architecture.

Security first does not mean security only

Security first architecture can sound extreme.

It is not.

It does not mean security is the only priority. Products still need usability, speed, cost control, delivery pace, developer experience, and business value.

Security first means security is considered early enough that the team can make good tradeoffs.

A good system is not just secure. It is useful and secure.

The difference is timing.

If authentication is considered after the app is built, the team may bolt on identity in awkward ways. If identity is part of the architecture from day one, authorization, auditing, tenancy, session handling, and data boundaries can be designed cleanly.

If secrets are considered after deployment, they end up in environment variables, local files, CI logs, and shared chat messages. If secret handling is designed early, the team can use vaults, short lived credentials, and scoped access from the beginning.

If supply chain security is considered after incidents, the team may not know what code was built, which dependencies were included, or who approved the release. If it is designed early, the build system can produce signed artifacts, provenance, SBOMs, and clear audit trails.

Security first architecture is mostly about avoiding painful retrofits.

The goal is not to make every feature slow.

The goal is to make secure design normal.

Threat modeling is architecture work

Threat modeling often sounds formal and heavy.

It does not have to be.

At its core, threat modeling means asking what can go wrong before you build the system. That is architecture work.

A simple threat model asks:

• What are we building?

• What can go wrong?

• What are we doing about it?

• Did we do a good job?

That is enough to catch many design problems early.

Imagine a file upload feature.

A product view says:

Users can upload documents.

A security first architecture view asks more:

• What file types are allowed?

• Where are files stored?

• Are files scanned?

• Can users access files from another tenant?

• Are signed URLs time limited?

• Can uploaded files execute code?

• Are metadata fields trusted?

• Are files encrypted at rest?

• Are downloads logged?

• What happens if a file contains sensitive data?

Same feature. Different depth.

Threat modeling is not only for security teams.

Developers understand the system. Product managers understand user behavior. Operations teams understand failure modes. Security teams understand attack patterns. A useful threat model needs all of those views.

The best version is lightweight and regular.

Do it when:

• Designing a new feature

• Adding a public API

• Changing authorization

• Adding a third party integration

• Handling sensitive data

• Creating admin functionality

• Introducing AI tools or agents

• Changing deployment architecture

A 30 minute threat model before implementation can save weeks of rework later.

Identity is the new perimeter

Old security architecture trusted the network.

If something was inside the corporate network, it was treated as safer. If something was outside, it was treated as less trusted.

That model breaks down in cloud native systems.

Services run across regions. Developers work remotely. APIs connect to vendors. CI pipelines deploy to production. Workloads move between nodes. Users access apps from everywhere. AI agents may call internal tools. The network boundary is no longer enough.

NIST's Zero Trust Architecture guidance describes a shift from static network based perimeters toward protecting users, assets, and resources. That does not mean buying one product called Zero Trust. It means designing systems around continuous verification and least privilege.

In practice, identity becomes the control point.

Not just user identity.

Service identity too.

Security first systems ask:

• Who is the user?

• What role do they have?

• Which tenant do they belong to?

• Which device are they using?

• Which service is making this request?

• Which data is being accessed?

• Which action is being performed?

• Is this normal behavior?

• Should this require approval?

Authorization becomes a design concern, not a route level afterthought.

This is especially important for APIs.

OWASP's API Security Top 10 lists broken object level authorization as the first risk. The pattern is simple: an attacker changes an object ID in a request and accesses something they should not access.

This is not a fancy attack.

It is an architecture failure.

A security first API never trusts object IDs from the client. Every access is checked against the authenticated user, tenant, role, and policy.

Bad pattern:

GET /api/orders/1024

Then the backend simply returns order 1024.

Better pattern:

GET /api/orders/1024

Then the backend checks:

• Is the user authenticated?

• Does this order belong to the user's tenant?

• Does the user have permission to view orders?

• Is this field allowed for this role?

• Should this access be logged?

The endpoint looks the same.

The architecture is different.

Secure defaults beat security documentation

Security documentation is useful.

Secure defaults are better.

A platform should make the safe path easier than the unsafe path. If every team has to remember every security rule manually, the system will fail. People forget. Deadlines pressure teams. New developers copy old code. One unsafe example spreads quickly.

Security first architecture moves controls into shared defaults.

This is where platform engineering and security meet.

A good internal platform can provide:

• Project templates with authentication included

• Standard authorization middleware

• Secure logging defaults

• Secret management integration

• Dependency scanning

• Container scanning

• Signed build artifacts

• Policy as code

• Infrastructure templates

• Observability dashboards

• Incident runbooks

  

Developers should not need to reinvent security for every service.

They should inherit good defaults.

That is the real promise of DevSecOps when done well. Not more meetings. Better paved roads.

Supply chain security is part of architecture

Modern software is assembled as much as it is written.

Your production system may include:

• Open source packages

• Container base images

• Build scripts

• GitHub Actions

• CI runners

• Cloud IAM roles

• Package registries

• Infrastructure modules

• Internal libraries

• Generated code

• AI suggested code

• Vendor SDKs

Every piece is part of the supply chain.

Verizon's 2025 DBIR reported that third party involvement in breaches doubled to 30 percent, highlighting growing partner and supply chain risk. That is why supply chain security can no longer be treated as a separate compliance task.

It belongs in the architecture.

A security first supply chain answers:

• Which source code produced this artifact?

• Which dependencies were included?

• Who triggered the build?

• Which CI runner built it?

• Was the artifact signed?

• Was provenance generated?

• Was the image scanned?

• Was deployment policy checked?

• Can production verify the artifact before running it?

SLSA, which stands for Supply chain Levels for Software Artifacts, provides a framework for improving supply chain integrity. Sigstore provides tooling for signing and verifying software artifacts such as container images, binaries, release files, and SBOMs.

The key idea is evidence.

Not just "we think this artifact is safe."

Instead:

This artifact was built from this source, by this workflow, with these dependencies, at this time, and it was signed before deployment.

A practical baseline looks like this:

Supply chain security is not only for big companies.

Small teams depend on packages too.

Small teams use CI too.

Small teams leak secrets too.

The difference is that small teams need simple defaults, not complex bureaucracy.

Runtime security matters because prevention fails

Secure design reduces risk.

It does not eliminate failure.

Dependencies still have vulnerabilities. Credentials still leak. Humans still make mistakes. Attackers still find paths no one expected.

That is why runtime security matters.

A security first architecture assumes some controls will fail and designs for detection, containment, and recovery.

Runtime controls include:

• Logging and audit trails

• Security monitoring

• Anomaly detection

• Rate limiting

• Service mesh policies

• Container runtime restrictions

• Read only filesystems

• Network policies

• Egress controls

• Cloud permission boundaries

• Workload identity

• Backup and restore testing

• Incident runbooks

The cloud native security model requires automation because infrastructure changes constantly. CNCF's cloud native security guidance describes the need for automation across the application security lifecycle and secure by design architectures such as Zero Trust.

In Kubernetes, for example, runtime security may include:

• Pod security standards

• Network policies

• Admission controllers

• Image signature verification

• Runtime threat detection

• Secrets management

• RBAC hardening

• Audit logs

• Resource limits

• Namespace isolation

The goal is not to make runtime security noisy.

The goal is to make abnormal behavior visible.

A service that suddenly calls an unknown external domain should be noticed.

A container that starts a shell unexpectedly should be noticed.

A workload that reads secrets it never used before should be noticed.

A user account that downloads thousands of records at midnight should be noticed.

Security first architecture does not assume perfect prevention.

It assumes failure must be contained.

Data boundaries must be designed early

Security often fails at data boundaries.

Data flows through logs, caches, analytics events, backups, queues, third party APIs, AI tools, local development databases, and support dashboards.

A team may secure the primary database but leak sensitive data through logs.

It may protect the API but send private data into analytics.

It may encrypt production storage but copy real customer data into development.

It may restrict user access but allow internal tools to bypass authorization.

Data security starts with classification.

Not every piece of data needs the same controls.

Once data is classified, architecture decisions become clearer.

Important questions:

• What data do we collect?

• Why do we collect it?

• Where is it stored?

• Who can access it?

• Is it copied into logs?

• Is it sent to third parties?

• Is it used for AI features?

• How long do we keep it?

• How do users request deletion?

• How do we prove access later?

AI makes this more important.

Teams are adding AI features, copilots, chat interfaces, and agent workflows. These systems often pull context from many places. Without clear data boundaries, sensitive information can flow into prompts, traces, third party model providers, or long term memory.

A security first AI feature asks:

• Is this data allowed in the prompt?

• Is the model provider allowed to process it?

• Are prompts and responses logged?

• Are logs redacted?

• Can the AI tool access data across tenants?

• Can the AI tool call write actions?

• Can retrieved content inject instructions?

• Can users see why the model answered?

Security first architecture treats AI as another integration with data risk.

Not magic.

Not exempt.

Memory safety is becoming an architecture decision

Some vulnerabilities come from logic mistakes.

Others come from memory unsafe code.

CISA and NSA have repeatedly pushed the industry to reduce memory safety vulnerabilities. Their 2025 guidance on memory safe languages gives a balanced view: adopting memory safe languages is not always simple for large existing codebases, but reducing memory safety bugs requires knowing where memory safe languages are appropriate and how to adopt them.

This is architecture too.

Language choice is not only a developer preference. It affects security properties.

A security first architecture may choose:

• Rust instead of C or C++ for new low level components

• Java, Go, C#, Kotlin, Swift, or TypeScript for memory safe application services

• Wasm sandboxing for plugin systems

• Process isolation around unsafe native code

• Fuzzing for parsers and protocol handlers

• Strong boundaries between trusted and untrusted inputs

  

This does not mean rewriting everything in Rust.

It means being intentional.

If you are building a parser, network service, file processor, security agent, browser component, embedded system, or high privilege infrastructure tool, memory safety deserves architectural attention.

Security first architecture asks not only "Can we build this?"

It asks "What class of bugs can we remove by design?"

That is the strongest form of security.

AI changes the security architecture conversation

AI is now part of the software architecture.

Not just as a feature. As a development tool, support tool, operations tool, and automation layer.

This creates new security questions.

AI coding assistants may suggest insecure code.

AI agents may access internal tools.

Employees may paste sensitive data into unapproved AI services.

Model outputs may be trusted too much.

Prompt injection may turn retrieved content into malicious instructions.

AI generated code may introduce dependencies no one reviewed.

AI traces may store sensitive prompts and responses.

Security first architecture must include AI boundaries.

Practical controls include:

• Approved AI tools list

• Data classification for AI usage

• Prompt and response redaction

• AI tool access logging

• Human approval for risky actions

• Read only defaults for agents

• Evals for unsafe behavior

• Guardrails for tool calls

• Dependency review for AI generated code

• Clear policy for customer data and model providers

This is not about fear.

It is about treating AI like any other powerful integration.

A database connection needs permissions.

A payment API needs controls.

A deployment pipeline needs approvals.

An AI agent that can access tools needs the same level of architectural respect.

Security first architecture for a web app

Let us make this concrete.

Imagine a modern SaaS product.

It has:

• Web frontend

• Backend API

• Admin dashboard

• Postgres database

• Object storage

• Background workers

• CI and CD pipeline

• Third party email provider

• AI support assistant

• Monitoring and logging

A traditional architecture diagram may focus on traffic flow.

A security first diagram focuses on trust boundaries.

Now the architecture can be reviewed with better questions.

Identity

• Where does authentication happen?

• Are sessions secure?

• Is MFA required for admins?

• Are service accounts scoped?

• Are workload identities used instead of static cloud keys?

Authorization

• Is authorization centralized or scattered?

• Are tenant boundaries enforced in every data access path?

• Are object level checks tested?

• Can admins bypass controls accidentally?

Data

• Which data is sensitive?

• Is sensitive data logged?

• Is data encrypted at rest and in transit?

• How are backups protected?

• How is data deleted?

Supply chain

• Are dependencies scanned?

• Are builds reproducible enough to trust?

• Are artifacts signed?

• Is deployment limited to trusted artifacts?

• Can CI access production secrets?

Runtime

• Are containers restricted?

• Are network egress paths controlled?

• Are logs and alerts useful?

• Is suspicious behavior detected?

• Is there a kill switch?

AI

• What data can the AI assistant access?

• Are prompts logged safely?

• Can the assistant perform write actions?

• Are retrieved documents trusted?

• Does risky output require review?

This is what security first architecture looks like.

Not fear.

Clarity.

The secure architecture checklist A practical checklist helps teams move from theory to design.

1. Define trust boundaries Identify users, services, admins, vendors, and automated systems. Mark public, private, and internal interfaces. Document where data crosses boundaries. Review every boundary for authentication, authorization, validation, logging, and rate limits.

2. Design identity early Use a real identity provider. Avoid custom authentication unless necessary. Require MFA for high privilege roles. Use short lived credentials where possible. Prefer workload identity over static secrets.

3. Centralize authorization Avoid one off permission checks scattered everywhere. Use policy functions, middleware, or a policy engine. Test object level authorization. Test tenant isolation. Log high risk access.

4. Protect secrets Store secrets in a vault or managed secret system. Never commit secrets to source control. Rotate secrets regularly. Limit CI secret exposure. Use secret scanning.

5. Secure the supply chain Pin dependencies. Review dependency changes. Scan for known vulnerabilities. Generate SBOMs where useful. Sign build artifacts. Verify artifacts before deployment. Restrict CI permissions.

6. Build runtime guardrails Run containers as non root. Use least privilege cloud permissions. Restrict network egress. Add rate limits. Monitor unusual behavior. Keep audit logs.

7. Design for recovery Test backups. Prepare rollback paths. Create incident runbooks. Keep contact paths clear. Practice recovery, not just prevention.

Include AI in the model Approve AI tools. Classify data before AI use. Redact logs where needed. Restrict agent tools. Require approval for risky AI actions. Evaluate unsafe behavior.

What teams get wrong

Security first architecture is easy to misunderstand.

Here are common mistakes.

Mistake 1: Treating security as only compliance

Compliance may require controls, but compliance is not the same as security.

A system can pass a checklist and still have poor authorization, weak logs, exposed secrets, and fragile recovery.

Use compliance as a floor, not the goal.

Mistake 2: Buying tools before designing boundaries

Security tools help when the architecture has clear boundaries.

They are less useful when no one knows what should be allowed.

A scanner can find vulnerable packages. It cannot decide whether your admin dashboard should be reachable from the public internet.

Mistake 3: Giving CI too much power

CI systems are often overpowered.

They can read secrets, build artifacts, deploy to production, publish packages, and modify infrastructure. If compromised, they become an attacker's deployment platform.

Treat CI as production infrastructure.

Mistake 4: Trusting internal traffic too much

Internal does not mean safe.

Services should authenticate each other. Sensitive actions should be authorized. Network access should be limited. Internal APIs should still validate input.

Mistake 5: Logging everything

Logs are useful, but logs can become data leaks.

Do not log secrets, tokens, full payment data, sensitive personal data, or private prompt content without controls.

Mistake 6: Ignoring recovery

Prevention gets attention. Recovery gets neglected.

A secure architecture needs backups, rollback, incident response, and clear ownership.

Security is not only stopping bad things.

It is surviving them.

A maturity model for security first architecture

Not every team can implement everything at once.

That is fine.

A maturity model helps teams improve without pretending they can become perfect overnight.

The goal for most teams is not perfection.

The goal is steady movement from reactive security to secure defaults.

A small team can start with:

• Authentication from a trusted provider

• Central authorization checks

• Secret scanning

• Dependency scanning

• Basic threat modeling

• Backups and restore tests

• Audit logs for sensitive actions

• Signed containers for production

• Human approval for high risk admin actions

That is already a strong start.

What this means for developers

Security first architecture is not only for security teams.

Developers make security decisions every day.

When you choose how to model tenants, you make a security decision.

When you decide where validation lives, you make a security decision.

When you add a dependency, you make a security decision.

When you expose an admin route, you make a security decision.

When you log a request body, you make a security decision.

When you let an AI tool access internal data, you make a security decision.

This can feel heavy.

It does not have to.

Developers do not need to memorize every security framework. They need a few habits:

• Ask what can go wrong.

• Treat user input as untrusted.

• Check authorization close to data access.

• Keep secrets out of code and logs.

• Use least privilege.

• Prefer secure defaults.

• Make risky actions visible.

• Leave evidence for future debugging.

Security first architecture works best when developers are supported by good platforms, clear patterns, and helpful security teams.

The worst model is security as blame.

The best model is security as enablement.

What this means for architects and leaders

For architects and engineering leaders, the message is bigger.

Security is now part of system quality.

It belongs beside reliability, performance, cost, and maintainability.

A system that is fast but leaks data is not a good system.

A system that ships quickly but cannot be audited is not a mature system.

A system that scales traffic but cannot verify its own artifacts is not ready for serious operations.

Security first architecture requires leadership choices:

• Fund platform security work.

• Give teams secure templates.

• Track architectural risk, not only vulnerabilities.

• Reward prevention, not only incident response.

• Make security reviews early and collaborative.

• Keep security requirements testable.

• Treat CI, identity, and data access as core architecture.

• Include AI tools in governance.

Security is not free.

But late security is more expensive.

The cheapest time to design a boundary is before the system depends on the wrong one.

The future is secure by default

The direction of travel is clear.

CISA is pushing secure by design.

NIST provides secure development and Zero Trust guidance.

OWASP keeps turning common failure patterns into developer friendly standards.

CNCF treats cloud native security as a lifecycle and architecture concern.

SLSA and Sigstore are making software supply chain trust more concrete.

AI is forcing teams to rethink data boundaries, tool permissions, and automated action.

All of this points to the same conclusion.

Security is moving earlier.

It is moving deeper.

It is moving into architecture.

The teams that adapt will build systems where security is not a panic button. It will be part of the product's shape.

The login flow will be designed with identity risk in mind.

The API will be designed with authorization in mind.

The CI pipeline will be designed with provenance in mind.

The runtime will be designed with containment in mind.

The data model will be designed with privacy in mind.

The AI assistant will be designed with permissions in mind.

That is security first architecture.

Not perfect security.

Better defaults. Better boundaries. Better evidence. Better recovery.

And most importantly, better software.

References

• CISA Secure by Design

• CISA, NIST SP 800-218 Secure Software Development Framework

• NIST SP 800-207 Zero Trust Architecture

• OWASP Top 10 2025

• OWASP Secure by Design Framework

• OWASP Application Security Verification Standard

• OWASP API Security Top 10 2023

• CNCF Cloud Native Security Whitepaper

• SLSA Supply-chain Levels for Software Artifacts

• Sigstore overview

• Verizon 2025 Data Breach Investigations Report

• NSA and CISA, Reducing Vulnerabilities in Modern Software Development

A simple dashboard could become a maze of client state, server state, API routes, GraphQL schemas, edge functions, background workers, managed queues, Redis, object storage, frontend build pipelines, hydration bugs, auth callbacks, preview deployments, and five different places where the same type had to be defined.

Some of that complexity was useful.

A lot of it was not.

Now something interesting is happening. Developers are not going back to 2008. They are not rejecting React, TypeScript, serverless, edge platforms, or modern frameworks. But many are asking a quieter question:

What if most web apps do not need this much machinery?

That question is bringing boring web development back.

Server-rendered pages. Monoliths. HTML-first thinking. Postgres. SQLite. Rails. Laravel. Django. Phoenix. HTMX. Alpine. Server components. Fewer microservices. Fewer moving parts. Fewer background services. Fewer things to monitor at 2 AM.

This is not a trend about being old fashioned.

It is a trend about being tired of accidental complexity.

Boring does not mean bad

The word boring needs defending.

In software, boring is often used as an insult. It sounds slow, stale, and unimaginative. But boring technology usually means something else.

It means the failure modes are known.

Dan McKinley's classic essay, Choose Boring Technology, made this point clearly. New technology has a cost. You need to learn it, operate it, test it, debug it, upgrade it, secure it, and teach it to the rest of the team. That cost does not disappear just because the tool is exciting.

Boring technology is not always the best technology. It is the technology whose tradeoffs are visible.

That matters because most software teams do not fail from lack of novelty. They fail from too much complexity, too little time, unclear ownership, fragile systems, and slow feedback loops.

Boring web development is not about avoiding modern tools. It is about asking every tool to justify itself.

The return of boring web development is really the return of this mindset.

Before adding a queue, ask if a database table is enough.

Before adding a separate frontend app, ask if server-rendered templates are enough.

Before adding a microservice, ask if a module inside the monolith is enough.

Before adding a new database, ask if Postgres is enough.

Often, the answer is yes.

And when the answer is yes, you should enjoy that.

The old frontend bargain got expensive

Modern frontend development solved real problems.

It made interfaces more interactive. It improved component reuse. It gave teams stronger patterns for large applications. React, Vue, Svelte, Solid, Angular, and the ecosystems around them changed what developers could build in the browser.

But the bargain had a cost.

The browser became an application runtime. The server became an API. The client became responsible for routing, rendering, state, caching, validation, error handling, retries, authentication state, and sometimes even business logic.

For many apps, that was too much.

This architecture can work well. It is also easy to overuse.

A marketing site does not always need it.

An admin panel does not always need it.

A CRUD app does not always need it.

A documentation portal does not always need it.

An internal tool definitely does not always need it.

The performance cost is also real. Modern server-side rendering often sends HTML first, then hydrates it on the client. That improves first paint, but hydration can still add JavaScript work before the page becomes fully interactive. Research on adaptive hydration in React and Next.js describes hydration as a performance bottleneck that modern rendering strategies try to reduce, not ignore.

The ecosystem knows this.

That is why we now have React Server Components, islands architecture, resumability, partial hydration, streaming SSR, server actions, and edge rendering. These are attempts to claw back simplicity and performance after years of pushing too much work to the client.

That is not a failure of frontend engineering.

It is a correction.

The web is remembering that HTML is already a good delivery format.

HTML-first is not nostalgia

HTML-first development sounds like a throwback until you look closely.

The argument is simple. Start with the web platform. Use HTML for structure, CSS for presentation, and small amounts of JavaScript for behavior. Move business logic to the server when possible. Add client-side complexity only where it improves the product enough to justify the cost.

That does not mean no JavaScript.

It means JavaScript is used with intent.

The 2026 paper The Case for HTML First Web Development argues that the gap between the web platform and framework-heavy development has narrowed as web standards have improved. It also notes that HTML-oriented development can reduce code size and conceptual complexity, especially when combined with hypermedia and server-side logic.

That matches what many developers are feeling.

HTML is not weak. It is stable, cacheable, accessible by default when used correctly, easy to inspect, and understood by every browser.

HTMX became popular because it gave developers a way to build dynamic interfaces without turning the whole app into a client-side application. Instead of sending JSON and rebuilding UI in JavaScript, the server sends HTML fragments.

This looks almost too simple.

That is the point.

In many apps, the server already knows how to render the UI. The server already has access to the session, permissions, data model, translations, and validation rules. Sending HTML directly can remove an entire layer of duplication.

Compare the two approaches.

Neither is always right.

The boring web development argument is not that HTML-first wins every time. It is that HTML-first should be considered first more often.

Server rendering never disappeared

Server rendering did not come back because it never fully left.

Django, Rails, Laravel, Phoenix, ASP.NET, Spring MVC, WordPress, and many other systems kept shipping server-rendered applications while the frontend world moved through wave after wave of JavaScript architecture.

What changed is perception.

For a while, server-rendered apps were treated as less modern. A "real" app was a single-page app. A "modern" team separated frontend and backend. A "scalable" architecture split things early.

That belief is weaker now.

The State of Django 2025 report from JetBrains says React and jQuery are still the most common JavaScript frameworks used with Django, but HTMX and Alpine.js have gained momentum. It also says Django usage has shifted back toward server-side templates since the survey began in 2021, with HTMX growing from 5 percent in 2021 to 24 percent and Alpine.js from 3 percent to 14 percent.

That is a useful signal.

Django developers did not forget how to build SPAs. They are choosing smaller tools where they fit.

Rails has been moving in a similar direction with Hotwire, Turbo, Stimulus, and Rails 8 defaults. Rails 8 includes an authentication generator, comes preconfigured with Kamal 2 for deployment, and ships with database-backed Solid Queue, Solid Cache, and Solid Cable options. The Rails 8 release notes describe Solid Cache as a database-backed cache store and Solid Cable as a database-backed Action Cable adapter.

Laravel has also leaned into a flexible middle path. Its starter kits support Livewire for server-driven UI and Inertia for teams that want React, Vue, or Svelte while keeping Laravel routing and controllers. Laravel's documentation describes Livewire as a starting point for building Laravel applications with a Livewire frontend, and Inertia as a way to build modern single-page React applications using classic server-side routing and controllers.

The pattern is not one framework.

The pattern is a return to integrated stacks.

Integrated does not mean primitive.

It means fewer seams.

Fewer seams often mean faster development.

The monolith is having a quiet comeback

Microservices were never supposed to be the default for small teams.

They were a solution to specific organizational and technical problems: independent deployment, team autonomy, scaling boundaries, fault isolation, and large systems with many domains.

But the pattern became fashionable. Many teams split systems before they had the problems that microservices solve.

The result was predictable.

Distributed systems arrived early.

Now one feature required multiple repositories, multiple deployments, multiple API contracts, multiple monitoring dashboards, multiple network calls, and multiple ways for things to fail.

A monolith avoids many of those costs.

Not always. But often.

A good monolith is not a ball of mud. It can still have modules, boundaries, tests, clear domain concepts, background jobs, and good deployment practices.

The difference is operational simplicity.

One deploy.

One runtime.

One primary database.

One place to follow a request.

One codebase to search.

One local development environment.

This matters more than teams admit.

Local development is part of architecture. If a new developer needs two days to run the app, the architecture has a cost. If every feature requires coordinating three services and two deployment pipelines, the architecture has a cost.

Boring web development treats those costs as first-class concerns.

A modular monolith is often the right default because it keeps complexity local until the system earns the need to split.

This is not anti-microservice.

It is anti-premature-distribution.

The database is getting simpler too

For years, web stacks tended to accumulate specialized data systems.

Postgres for relational data.

Redis for cache.

Elasticsearch for search.

Kafka for events.

A queue service for jobs.

A separate analytics store.

A vector database for embeddings.

Object storage for files.

Some products need this. Many do not, at least not at the beginning.

The boring web development movement asks another uncomfortable question:

Can the database we already have do more?

Postgres has become the obvious answer for many teams. It handles relational data, JSON, full-text search, constraints, indexing, transactions, extensions, geospatial workloads, and vector search through pgvector. It is not the best tool for every one of those jobs, but it is good enough for many of them.

SQLite is also getting more serious attention, especially for small apps, local-first apps, single-server deployments, embedded use cases, and simple self-hosted products. SQLite's own site describes it as small, fast, self-contained, high-reliability, full-featured, and the most used database engine in the world.

Rails 8 made this conversation louder by embracing database-backed pieces like Solid Queue, Solid Cache, and Solid Cable. That does not mean every Rails app should use SQLite in production. It means the framework is actively exploring how far a database-backed default can go before teams need extra infrastructure.

This is the boring database stack:

The benefit is not that one database is magically perfect.

The benefit is fewer systems to operate.

This is not about refusing infrastructure.

It is about delaying infrastructure until the problem is real.

Every extra database adds backups, monitoring, access control, data modeling, local setup, migrations, network behavior, failure modes, and security concerns.

Sometimes that cost is worth it.

Sometimes it is just resume-driven architecture in a nicer jacket.

Deployment got too clever

Deployment used to be boring in a good way.

Build the app. Put it on a server. Run it behind a web server. Point a domain to it. Monitor it. Back it up.

Then deployment got easier and more complicated at the same time.

Modern platforms gave us preview deployments, serverless functions, edge runtimes, global caching, managed databases, automatic HTTPS, autoscaling, branch deploys, and push-to-deploy workflows. These are real improvements.

But many teams also ended up with deployment architectures they barely understood.

One app might include:

• Static assets on a CDN

• Serverless API routes

• Edge middleware

• A managed database

• A queue service

• A cron service

• A background worker platform

• Object storage

• Secret management

• Build caching

• Preview environments

• Multiple regions

• Observability add-ons

That can be fine for a product that needs it.

It can be absurd for a small SaaS, an internal dashboard, a content site, or a simple marketplace.

The return of boring web development is also a return to simple deployment.

Rails 8's Kamal integration is part of this story. Kamal helps deploy containerized apps to servers, including cloud VMs or your own hardware. The point is not that everyone should use Kamal. The point is that "just deploy to a server" is becoming respectable again.

This architecture is not glamorous.

It can run a real business.

A single server is not enough for every app. But it is enough for more apps than people think, especially early on.

The same is true for platform choices. A managed platform can be a good boring choice if the team understands it and it reduces operational load. A VPS can be a good boring choice if the app is simple and the team wants control.

Boring is contextual.

The key is not the server. The key is whether the deployment model is understandable.

If no one on the team can explain how a request reaches production and where it can fail, the deployment is too clever.

AI is making boring more valuable

AI coding tools are another reason boring web development is coming back.

This may sound backwards. AI feels like the least boring thing in software right now. But AI makes boring stacks more useful because boring stacks have clearer patterns.

LLMs are better when the framework has strong conventions.

They are better when there is one obvious place for a controller, one obvious way to validate a form, one obvious way to write a test, one obvious way to query data, and one obvious way to render a page.

A convention-heavy Rails, Laravel, Django, or Phoenix app can be easier for AI tools to navigate than a custom stack with clever architecture scattered across many services.

That does not mean AI writes perfect code in these frameworks. It does not. But boring structure reduces the search space.

This matters because AI-generated code already creates review work. The more custom and distributed the architecture is, the more context the model needs and the more ways it can be subtly wrong.

Boring stacks help humans too.

If the app follows standard conventions, a human reviewer can spot mistakes faster. A new teammate can learn the code faster. A bug can be traced faster. Documentation can be shorter.

AI does not remove the need for architecture.

It rewards architecture that is easy to explain.

Boring frontend does not mean ugly frontend

One objection comes up often:

But users expect rich interfaces.

Yes. They do.

Boring web development is not an argument for bad UX. It is an argument for choosing the simplest implementation that delivers the UX.

Sometimes that means React.

Sometimes that means server-rendered templates with small JavaScript.

Sometimes that means HTMX.

Sometimes that means Livewire.

Sometimes that means Inertia.

Sometimes that means a full client-side app because the product is actually interactive enough to need one.

The mistake is assuming the most complex frontend architecture is the most professional.

A polished UI can be server-rendered.

A fast dashboard can use HTML fragments.

A form-heavy app can feel modern without becoming an SPA.

A marketing site can be mostly static.

A SaaS admin panel can use progressive enhancement.

The decision should come from the product.

Not from status.

If the user cannot tell whether the app uses React, HTMX, Livewire, or templates, the stack choice should optimize for the team.

That means speed, reliability, accessibility, maintainability, hiring, testing, and deployment.

Users care about outcomes.

Developers should too.

The cost of complexity shows up later

Complexity is easy to ignore at the beginning.

At the beginning, every tool feels like progress. The build passes. The demo works. The architecture diagram looks serious.

The cost arrives later.

It shows up when:

• A dependency breaks the build.

• A deployment fails in only one environment.

• A small UI change touches four packages.

• A bug crosses frontend and backend boundaries.

• The test suite needs too much mocking.

• Local development becomes slow.

• Onboarding becomes a week-long task.

• The team avoids changes because the system is fragile.

• Every incident requires knowledge of five services.

• Nobody knows whether a feature belongs on the client or server.

Boring web development is a bet against that future.

It asks teams to optimize for the full lifecycle, not the first sprint.

Most code is maintained longer than it is written.

That is why boring choices often win.

A familiar stack with known limits can be better than a perfect stack no one understands.

When boring is the wrong choice

Boring is not a religion.

Sometimes boring technology is the wrong choice.

If you are building a highly interactive design tool, a real-time multiplayer editor, a complex offline-first app, or a browser-based IDE, you probably need serious client-side architecture.

If you are building global low-latency infrastructure, you may need edge compute.

If you are processing huge event streams, you may need Kafka or another specialized system.

If search quality is core to the product, you may need a real search engine.

If your workload has independent scaling boundaries, microservices may be correct.

If your team has deep expertise in a tool, that tool may be boring for your team even if it looks exotic to others.

That last point matters.

Boring is local.

Elixir and Phoenix may be boring for a team that has used them for years. Rails may be risky for a team with no Ruby experience. Kubernetes may be boring for a platform team and absurd for a two-person SaaS.

A good decision depends on context.

The best boring web developers are not stubborn.

They are disciplined.

They know when to keep things simple, and they know when the problem has outgrown the simple answer.

A boring stack for a modern app