DEV Community: Emma Schmidt

Your Developers Are Wasting 40% of Their Week and It's Not on Bugs

Emma Schmidt — Fri, 10 Jul 2026 08:50:32 +0000

Here's an uncomfortable truth. Most engineering teams in 2026 are still losing a huge chunk of their sprint capacity to something that has nothing to do with writing features: waiting. Waiting on environment provisioning. Waiting on access approvals. Waiting on a DevOps engineer to spin up infrastructure that should take two minutes but takes two days.

If that sentence made you wince, you already know why platform engineering has become the defining shift in how modern teams ship software this year.

This post breaks down what an internal developer platform (IDP) actually is, why the market is growing so fast, how to build your first golden path with real code, which tools to consider, and where teams commonly get it wrong.

Why This Is Blowing Up Right Now

For years, DevOps promised speed. What it actually delivered, in a lot of orgs, was a pile of YAML files, ticket queues, and tribal knowledge locked inside one overworked infra person's head.

Platform engineering flips that model. Instead of developers filing tickets and waiting, they get a self-service layer, a golden path, that lets them provision databases, spin up environments, and deploy without needing to understand the underlying Kubernetes cluster or cloud config.

The growth here isn't just anecdotal. The global infrastructure as code market is on track to jump from $908.7 million in 2023 to $3.3 billion by 2030, with North America holding nearly 40% of the market. That kind of trajectory only happens when a category solves a real, expensive problem.

What You're Actually Building

An internal developer platform typically has four layers:

Layer	Purpose	Common Tools
Self-service portal	Where developers request resources	Backstage, Port, Cortex
Golden paths	Pre-approved templates for common workflows	Backstage Scaffolder, Humanitec
IaC backend	Actually provisions the infrastructure	Terraform, Pulumi, Crossplane
Guardrails	Enforces security and compliance automatically	OPA, Sentinel, Kyverno

Step-by-Step: Building Your First Golden Path

Step 1: Pick One Painful Workflow

Don't try to platform everything at once. Find the single workflow that causes the most friction across your team, usually "spin up a new service" or "get me a staging database," and start there. Interview two or three developers about what they dread doing most. That's your starting point.

Step 2: Define the Golden Path as Code

# golden-path.yaml
name: new-service
description: Scaffold a new backend service with database and CI pipeline
inputs:
  service_name: string
  language: [node, python, go]
  database: [postgres, none]
  team_owner: string
steps:
  - scaffold_repo
  - provision_infra
  - register_in_catalog
  - setup_ci_pipeline

Step 3: Wire It to Infrastructure as Code

Your golden path should never touch the cloud directly. It should trigger a versioned module underneath so every provisioned resource is auditable and reproducible.

# modules/service/main.tf
module "service_database" {
  source        = "./modules/postgres"
  service_name  = var.service_name
  instance_size = "db.t3.small"
  team_owner    = var.team_owner
  tags = {
    provisioned_by = "golden-path"
    environment    = "staging"
  }
}

Running this through a golden path instead of a manual terraform apply means every database that exists in your account can be traced back to a request, an owner, and a timestamp.

Step 4: Add a Software Catalog

This is where Backstage earns its popularity. Every service gets a catalog-info.yaml so ownership, dependencies, and docs live in one searchable place instead of a stale wiki page.

# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: payments-service
  description: Handles payment processing and refunds
spec:
  type: service
  owner: team-payments
  lifecycle: production
  dependsOn:
    - resource:payments-db

Step 5: Bake in Guardrails, Not Roadblocks

Use policy as code so security and compliance checks run automatically at provision time instead of sitting in someone's manual review queue.

# policy/no-public-buckets.rego
package platform.security

deny[msg] {
  input.resource_type == "storage_bucket"
  input.public_access == true
  msg := "Public storage buckets are not allowed without security team approval"
}

The goal is zero manual approval for the 90 percent of requests that are routine, so your security team only reviews genuine exceptions.

Step 6: Measure the Actual Impact

Track two numbers before and after rollout:

Time-to-first-deploy for a brand new service
Mean time to provision a standard resource like a database

If those numbers don't move, the platform isn't working yet, regardless of how polished the portal looks.

A Quick Example: Before and After

A mid-sized team running twelve microservices used to take an average of four days to spin up a new service, mostly waiting on a shared infra engineer to configure networking, IAM roles, and a database by hand. After building a single golden path for "new service with Postgres," that same request dropped to roughly twenty minutes of automated provisioning plus a five minute review. The infra engineer went from being a bottleneck on every request to reviewing policy exceptions a few times a week.

That's the entire value proposition of platform engineering in one before-and-after.

Where Most Teams Get This Wrong

Teams often try to build a full "platform" before they've mapped a single existing workflow. The result is an over-engineered internal product that nobody adopts because it solves problems developers weren't actually complaining about. Start narrow, prove value on one workflow, then expand based on what people actually ask for next.

This is also exactly where a lot of teams choose to bring in outside expertise for cloud architecture, DevOps automation, and platform engineering support, especially when the in-house team is stretched thin trying to ship features and build internal tooling at the same time. Getting the golden path architecture and guardrails right early saves months of rework later, and experienced hands can shortcut a lot of the trial and error described above.

FAQ

Do I need Kubernetes to do platform engineering?
No. Golden paths work on top of any infrastructure, serverless, VMs, or containers. Kubernetes just happens to be common in orgs where this pattern emerged.

Is this the same as DevOps?
No. DevOps is a culture and set of practices. Platform engineering is the product layer that makes those practices self-service instead of ticket-based.

How small a team can justify this?
Even a five person engineering team benefits from a single golden path if provisioning is currently manual and repetitive. You don't need a dedicated platform team to start, just one well-documented, automated workflow.

The Bottom Line

Platform engineering isn't a buzzword layered on top of DevOps. It's a direct, measurable response to developers losing time on friction that has nothing to do with actual engineering work. Start with one painful workflow, wrap it in a golden path, add guardrails instead of gatekeepers, and measure the time you get back.

If your team ships its first internal golden path this quarter, you're already ahead of most orgs still stuck in ticket queues.

What's the most painful manual workflow on your team right now? Drop it in the comments, there's a good chance someone here has already automated it.

The End of Passwords: A Developer's Complete Guide to Passkey Authentication in 2026

Emma Schmidt — Thu, 09 Jul 2026 09:44:01 +0000

Introduction

Password-based authentication has outlived its usefulness. Credential stuffing attacks, phishing kits, and massive data breaches have made the traditional email-and-password login one of the weakest links in modern software security. In 2026, passkeys have moved from experimental to expected, backed by the FIDO Alliance, adopted by every major platform, and increasingly demanded by end users who are simply tired of managing passwords.

This guide breaks down what passkeys are, why they matter at a technical and business level, and exactly how to implement them in a production application, along with the architectural decisions that separate a proof of concept from a system ready for real users at scale.

1. Why Passwords Fail and What Replaces Them

Passwords rely on a shared secret model. The same string exists on the user's device and inside your database. That single design flaw is responsible for nearly every large-scale credential breach in the last decade. Reused passwords, weak entropy, and phishing all exploit this same weakness.

Passkeys eliminate the shared secret entirely. Instead of storing something a user knows, your system stores a public key. The private key never leaves the user's device, which means there is nothing meaningful to steal even if your database is compromised.

Key advantages over passwords:

Factor	Passwords	Passkeys
Phishing resistance	Low	High
Server-side breach risk	High	Minimal
User friction	High (memorization, resets)	Low (biometric tap)
Cross-device sync	Manual	Native (via platform providers)
Compliance alignment	Weak	Strong (FIDO2, WebAuthn)

2. How Passkeys Actually Work

Passkeys are built on two open standards working together:

WebAuthn (Web Authentication API): the browser-level API that handles credential creation and assertion
FIDO2 / CTAP: the protocol that governs communication between the browser and the authenticator (a device, biometric sensor, or security key)

The flow involves three parties:

Relying Party: your application server, which requests and verifies credentials
Client: the browser or app that mediates the exchange
Authenticator: the device component that generates and holds the private key

During registration, the authenticator generates a unique key pair for your domain. The public key is sent to your server and stored against the user's account. During login, your server issues a challenge, the authenticator signs it with the private key, and your server verifies that signature against the stored public key. No secret ever crosses the network.

If your team is still mapping out where passkeys fit into your broader identity architecture, this is usually a good point to loop in application security consulting support, since getting the trust model right at the design stage saves significant rework later.

3. Implementation Walkthrough

Step 1: Install Dependencies

npm install @simplewebauthn/server @simplewebauthn/browser

Step 2: Generate Registration Options on the Server

const { generateRegistrationOptions } = require('@simplewebauthn/server');

const options = await generateRegistrationOptions({
  rpName: 'Your App Name',
  rpID: 'yourapp.com',
  userID: user.id,
  userName: user.email,
  attestationType: 'none',
  authenticatorSelection: {
    residentKey: 'required',
    userVerification: 'preferred',
  },
});

// Store options.challenge against the user's session before responding

Step 3: Trigger Registration on the Client

import { startRegistration } from '@simplewebauthn/browser';

const attestationResponse = await startRegistration(options);
// POST attestationResponse to your verification endpoint

Step 4: Verify Registration on the Server

const { verifyRegistrationResponse } = require('@simplewebauthn/server');

const verification = await verifyRegistrationResponse({
  response: attestationResponse,
  expectedChallenge: storedChallenge,
  expectedOrigin: 'https://yourapp.com',
  expectedRPID: 'yourapp.com',
});

if (verification.verified) {
  const { credentialPublicKey, credentialID, counter } = verification.registrationInfo;
  // Persist these fields against the user record
}

Step 5: Authentication Flow

const { generateAuthenticationOptions, verifyAuthenticationResponse } = require('@simplewebauthn/server');

// Generate options, send to client, receive signed assertion, then verify:
const authVerification = await verifyAuthenticationResponse({
  response: assertionResponse,
  expectedChallenge: storedChallenge,
  expectedOrigin: 'https://yourapp.com',
  expectedRPID: 'yourapp.com',
  authenticator: storedCredential,
});

Teams building this on a tight timeline often lean on custom software development services at this stage, since a partner who has already shipped WebAuthn flows in production can shortcut a lot of the trial and error covered above.

4. Handling Edge Cases in Production

Real-world rollout introduces complications a tutorial rarely covers:

Multi-device support: users expect a passkey created on their phone to work on their laptop through platform sync (iCloud Keychain, Google Password Manager)
Account recovery: what happens when a user loses every device tied to their passkeys
Cross-subdomain configuration: your RP ID must be scoped correctly if you operate across multiple subdomains
Browser and OS fragmentation: Face ID, Windows Hello, and Android biometrics each behave slightly differently and need to be tested independently

Catching these issues before launch usually comes down to disciplined QA and test automation services, since device and browser fragmentation is exactly the kind of edge case that slips past manual testing but shows up fast once real users log in.

5. Security Considerations

Always validate the signature counter to detect cloned authenticators
Enforce userVerification: 'required' for sensitive account actions, not just login
Log and monitor failed verification attempts as you would any authentication endpoint
Never treat passkeys as a silver bullet. Session management, rate limiting, and server-side authorization checks still matter just as much

6. Migration Strategy for Existing Applications

Adding passkeys to a greenfield project is straightforward. Migrating a production application with an existing user base, active sessions, mobile clients, and compliance obligations is a materially harder problem. Teams doing this well typically:

Roll out passkeys as an additive option before deprecating passwords
Track adoption metrics to time the eventual password sunset
Coordinate the rollout with existing identity providers and SSO systems rather than building in isolation

This is often the stage where organizations bring in a partner offering dedicated cloud and DevOps engineering support to handle the architecture review, phased rollout, and integration with legacy identity systems, since a security-critical migration done incorrectly is more costly than the passwords it was meant to replace.

7. Frequently Asked Questions

Are passkeys phishing-proof?
Yes, by design. Since authentication is bound to the origin domain, a passkey created for yourapp.com cannot be used on a lookalike phishing domain.

What happens if a user loses their device?
If passkeys are synced through a platform provider, they typically remain available on other signed-in devices. Applications should still offer a secure recovery path as a fallback.

Do passkeys work on older browsers?
Support is broad across modern browsers, but applications should maintain a fallback authentication method during the transition period.

8. Conclusion

Passkeys represent the most meaningful shift in authentication in over a decade, not because they are trendy, but because they solve the fundamental design flaw that has made passwords a permanent liability. Implementing them correctly takes more than a weekend tutorial, but the payoff, in security posture, user trust, and reduced support overhead, is substantial.

If you have implemented passkeys in production, share what surprised you most in the comments. Real-world lessons here are more valuable than any spec document.

I Let AI Agents Run My Entire Dev Workflow for 30 Days. Here's What Actually Broke (and What Didn't)

Emma Schmidt — Wed, 08 Jul 2026 12:26:36 +0000

If you're still treating AI as "autocomplete on steroids," you're already behind. In 2026, the real shift isn't AI writing code for you, it's AI agents planning, executing, and fixing multi-step tasks without you babysitting every prompt.

I spent the last month wiring agentic workflows into a real production pipeline: code generation, testing, documentation, even issue triage. Some of it was magic. Some of it nearly shipped a broken auth flow to prod. Here's the honest breakdown, plus a step-by-step you can copy today.

Why This Matters Right Now

Failure rates for teams using AI-driven pipelines are dropping into single digits, while teams still doing everything manually are seeing failure rates several times higher. That gap is only going to widen. If your workflow still looks like 2023, you're not just behind on tools, you're behind on architecture decisions.

Step 1: Stop Using AI as a Single Assistant

The old model was one chat window, one task at a time. The new model is orchestration: multiple agents handling different stages of the SDLC in parallel.
Agent A → generates feature code
Agent B → writes tests against it
Agent C → reviews for security gaps
Agent D → drafts documentation

Each agent has a narrow job. This is the biggest mindset shift. You're not prompting, you're managing a small team. This is exactly the space that specialized AI agent development services have moved into lately, building autonomous agents that don't just answer questions but actually navigate software, update databases, and manage workflows end to end, with human-in-the-loop checkpoints for anything high stakes.

Step 2: Set Guardrails Before You Set Goals

This is where most people get burned. Agentic AI will happily execute a bad plan just as fast as a good one. Before turning agents loose:

Define what tasks are fully autonomous vs. what needs human sign-off
Lock down deployment permissions separately from code generation permissions
Version everything an agent touches, no exceptions

I skipped this step in week one. An agent "helpfully" refactored a config file that took down a staging environment for two hours. Lesson learned.

Step 3: Pick Tasks That Are Easy to Verify First

Don't start with your most complex architectural decision. Start with things you can sniff-check quickly: bug fixes, test coverage gaps, small script automation. Build trust in the system before handing over anything conceptually heavy.

Step 4: Bake Security In From the Start, Not After

DevSecOps isn't optional anymore when agents are writing and shipping code faster than humans can review line by line. Every agent-generated pull request in my pipeline now runs through automated threat scanning before a human even looks at it. Catching a vulnerability at the PR stage costs minutes. Catching it in production costs days and trust.

Step 5: Know When to Bring in Outside Expertise

Here's the part nobody likes to admit: not every team has the bandwidth to build and maintain a full agentic pipeline internally. Setting up orchestration, guardrails, and secure CI/CD around AI agents is its own specialized skill set. A lot of teams scaling fast end up leaning on custom software development services to get enterprise-grade architecture, API integrations, and secure cloud infrastructure right the first time, instead of learning through expensive trial and error like I did in week one.

What Actually Broke

An agent looped on a failing test for 40 minutes before flagging it (fixed by adding a hard retry limit)
Documentation agents drifted from actual code behavior after a few iterations without human review checkpoints
Multi-agent coordination without clear ownership caused two agents to "fix" the same bug in conflicting ways

What Didn't

Test coverage went up noticeably with almost zero extra effort from me
Routine PRs that used to take a day were reviewed and merged same afternoon
Bug triage that used to eat my mornings now takes minutes

The Real Takeaway

Agentic AI isn't a feature you bolt on. It's an architectural decision, the same way choosing microservices or serverless was a few years back. Treat it that way from day one: define ownership, set guardrails, verify before you trust, and don't be afraid to bring in outside expertise for the parts that aren't your core competency.

The teams winning in 2026 aren't the ones using the most AI. They're the ones using it with the most discipline.

Have you rolled out agentic workflows on your team yet? What broke for you? Drop it in the comments.

The Silent Shift That's Already Rewriting How Software Gets Built

Emma Schmidt — Thu, 02 Jul 2026 07:47:50 +0000

Eighty four percent of developers now use or plan to use AI tools in their development process, and 51% of professional developers are using them every single day. That number alone should stop you. But the bigger story isn't adoption, it's what's being adopted. In 2026, the conversation moved past "AI writes code" into something more consequential: AI agents that plan, execute, and correct entire workflows with minimal human input. If your team hasn't adapted to this shift, you're not behind by months. You're behind by an architecture.

This guide breaks down exactly how to build your first production ready AI agent using the Model Context Protocol (MCP), the standard now being adopted across major platforms as the common language between AI models and real world tools.

Why This Matters More Than Any Framework Release This Year

MCP solves a problem every engineering team has quietly struggled with: connecting AI models to internal tools, APIs, and data sources without writing a custom integration for every single use case. Instead of dozens of one off connectors, you get one protocol that scales across your entire stack.

This isn't a niche trend confined to research labs. Adoption of LLM SDKs across public codebases has grown sharply over the past year, and industry survey data consistently shows daily AI usage among professional developers holding steady above 50%. It's infrastructure now, not an experiment.

At the same time, the same surveys carry a warning worth sitting with. A large share of developers say AI often produces output that looks correct but isn't reliable, and a similar share admit they don't fully trust AI generated code to be functionally correct. That gap between adoption and trust is exactly why agent architecture matters. An agent with no guardrails just automates the mistakes faster.

Step 1: Set Up a Clean Foundation

mkdir mcp-agent-demo
cd mcp-agent-demo
npm init -y
npm install @modelcontextprotocol/sdk

Resist the urge to add every dependency upfront. Agent systems get complex fast, and a lean starting point makes debugging significantly easier six weeks in. Every extra library is one more thing that can silently break your agent's tool calls later.

Step 2: Build Your MCP Server

Your server exposes callable tools the agent can use to take real action, not just generate text.

import { Server } from "@modelcontextprotocol/sdk/server/index.js";

const server = new Server({
  name: "file-search-agent",
  version: "1.0.0"
});

server.tool("searchFiles", async ({ query }) => {
  const results = await runSearch(query);
  return { results };
});

This single function is the foundation of what separates an agent from a chatbot: the ability to act, not just respond. A chatbot describes what it would do. An agent does it, which means every tool you expose is also a permission you're granting.

Step 3: Give the Agent Repository Context

The strongest agents today don't just see isolated code snippets. They understand the relationships across an entire codebase, a capability industry researchers are now calling repository intelligence.

server.tool("readRepoStructure", async () => {
  const structure = await scanDirectory("./src");
  return { structure };
});

Consider extending this further with dependency graphs and recent commit history, so the agent understands not just what the code does but how it got there. An agent that can see the last ten commits to a file behaves very differently from one that only sees the current state.

server.tool("getRecentChanges", async ({ filePath, limit = 10 }) => {
  const history = await git.log({ file: filePath, maxCount: limit });
  return { commits: history };
});

Step 4: Build Guardrails Before You Build Autonomy

This is the step most tutorials skip entirely, and it's the one senior engineers care about most. Define explicitly what your agent can execute without approval and what requires a human checkpoint.

A practical pattern is a tiered permission model:

const TOOL_TIERS = {
  readOnly: ["searchFiles", "readRepoStructure", "getRecentChanges"],
  requiresApproval: ["writeFile", "runMigration", "deployToStaging"],
  neverAutomated: ["deployToProduction", "deleteResource"]
};

function canExecuteWithoutApproval(toolName) {
  return TOOL_TIERS.readOnly.includes(toolName);
}

Teams that skip this step aren't moving faster, they're accumulating risk they haven't priced in yet. It's the same lesson every major cloud outage postmortem eventually lands on: the failure wasn't that automation existed, it's that nobody drew a line around what automation was allowed to touch unsupervised.

Step 5: Validate With Real Production Tasks

Toy examples teach you syntax. Real tasks teach you failure modes. Run your agent against an actual bug fix or feature request and observe where it hesitates, misreads context, or needs a boundary you hadn't considered.

Keep a simple evaluation log while you do this:

const evalLog = {
  task: "Fix null pointer in checkout flow",
  toolsUsed: ["searchFiles", "readRepoStructure"],
  correctSolution: true,
  requiredHumanCorrection: false,
  timeToComplete: "4m12s"
};

Over ten or twenty real tasks, patterns emerge fast. You'll usually find the agent is strong at localized fixes and weak at anything touching more than two or three files at once, which tells you exactly where your guardrails need to be tightest.

The Gap Between a Demo and a Reliable System

Here's what separates the demos flooding your feed from systems that actually hold up in production: testing rigor, evaluation pipelines, and integration discipline. Most internal teams underestimate this gap significantly, in part because the failure data backs it up. Independent surveys have found that a majority of teams running AI-assisted code at scale report a measurable rise in bugs and a drop in system stability when review discipline slips.

It's exactly why many organizations bring in an experienced software development and AI engineering partner to handle MCP integrations, agent orchestration, and scalable AI native architecture, rather than absorbing months of trial and error internally while competitors ship faster. The teams that get this right treat agent rollout the same way they'd treat a major infrastructure migration: staged, monitored, and reversible at every step.

The Real Takeaway

The developers who lead in 2026 aren't the ones typing the most code. They're the ones designing systems where AI operates with proper context, clear boundaries, and measurable outcomes. Start with one tool, one workflow, one guardrail. Scale from there.

What's the first task you'd hand off to an agent, and what would you never let it touch without review?

From Vibe Coding to Production: A Step-by-Step Guide to Shipping AI-Generated Code Safely in 2026

Emma Schmidt — Wed, 01 Jul 2026 06:15:17 +0000

Here's an uncomfortable truth nobody wants to admit out loud: most teams can generate a working app in minutes now, but almost none of them can ship it to production without breaking something important. Only a small fraction of organizations have actually moved their AI-built systems past the pilot stage. The gap between "it works on my machine" and "it works for real users" has never been wider, and closing that gap is quickly becoming the single most valuable skill a developer can have this year.

If you have been prompting your way to a working prototype and then hitting a wall when it's time to actually deploy, this guide walks through exactly how to close that gap, with working examples at every step.

Why This Matters Right Now

Vibe coding, meaning describing what you want in plain language and letting an AI model scaffold the implementation, has gone from a novelty to a default workflow. Developers are shipping REST APIs, auth flows, and full CRUD apps with a single well-written prompt. But speed of generation is not the same as readiness for production. Untested edge cases, missing validation, weak error handling, and security gaps show up constantly in AI-generated code because the model optimized for "looks correct" rather than "survives real traffic."

The developers who stand out this year are not the ones who can generate code fastest. They are the ones who know how to validate it, harden it, and integrate it responsibly. Below is a practical checklist you can apply to any AI-generated codebase before it touches a real user.

Step 1: Treat the AI Output as a First Draft, Not a Final Answer

Say your AI assistant generates this login handler:

\javascript // AI-generated first draft app.post('/login', async (req, res) => { const { email, password } = req.body; const user = await db.query(SELECT * FROM users WHERE email = '${email}'); if (user.password === password) { res.json({ token: generateToken(user) }); } }); \\

Looks functional. It is also a SQL injection vector, stores passwords in plaintext comparison, and has no response when login fails. A structural review pass catches this before it ever reaches a pull request.

Checklist for the first pass:

Hardcoded secrets or placeholder API keys left in by the model
String-concatenated queries instead of parameterised ones
Missing else or fallback branches, like the silent failure above
Dependencies pulled in that are unmaintained or have known CVEs

Hardened version after review:

\javascript app.post('/login', async (req, res) => { const { email, password } = req.body; if (!email || !password) { return res.status(400).json({ error: 'Missing credentials' }); } const user = await db.query('SELECT * FROM users WHERE email = $1', [email]); if (!user || !(await bcrypt.compare(password, user.passwordHash))) { return res.status(401).json({ error: 'Invalid credentials' }); } res.json({ token: generateToken(user) }); }); \\

A five-minute scan here saves hours of debugging later, and it's the single highest-leverage habit you can build.

Step 2: Add a Real Test Layer, Not a Token One

AI-powered testing tools have matured enough that you can generate a solid baseline test suite quickly, but you still need to direct them toward the cases that actually matter.

\Prompt example: "Generate unit tests for this authentication middleware, covering expired tokens, malformed headers, and rate-limit edge cases." \\

A weak, AI-default test looks like this:

\javascript test('login works', async () => { const res = await request(app).post('/login').send({ email: 'a@b.com', password: '123' }); expect(res.status).toBe(200); }); \\

A real test suite covers the failure modes that break production:

\`javascript
describe('POST /login', () => {
test('rejects missing credentials', async () => {
const res = await request(app).post('/login').send({});
expect(res.status).toBe(400);
});

test('rejects invalid password without leaking user existence', async () => {
const res = await request(app).post('/login').send({ email: 'real@user.com', password: 'wrong' });
expect(res.status).toBe(401);
expect(res.body.error).not.toMatch(/user not found/i);
});

test('rejects expired tokens on protected routes', async () => {
const expiredToken = generateToken({ id: 1 }, { expiresIn: '-1s' });
const res = await request(app).get('/dashboard').set('Authorization', Bearer ${expiredToken});
expect(res.status).toBe(401);
});
});
`\

Don't accept the first batch of AI-generated tests blindly. Read them. Make sure they assert on behavior and edge cases, not just that a function returns a 200.

Step 3: Wire In Observability Before You Need It

This is the step most tutorials skip, and it's the one that matters most once real users show up.

\`javascript
// Structured logging at a service boundary
logger.info('login_attempt', {
email: hashForLogging(email),
ip: req.ip,
timestamp: Date.now(),
});

try {
const result = await aiAgent.call(prompt);
logger.info('ai_call_success', { latencyMs: Date.now() - start, model: 'agent-v2' });
} catch (err) {
logger.error('ai_call_failed', { error: err.message, latencyMs: Date.now() - start });
throw err;
}
`\

Three things to instrument from day one:

Structured logs at every service boundary, not just top-level errors
Error tracking that surfaces failures immediately instead of silently swallowing them
Latency tracked separately for any AI or agent calls, since model response times vary far more than typical API calls and can quietly become your slowest endpoint

Step 4: Secure the AI-Specific Attack Surface

If your app calls an LLM or agent at runtime, you have a new category of risk: prompt injection, data leakage through model responses, and unchecked tool access in agentic workflows.

\javascript // Vulnerable: user input goes straight into the prompt and the agent has open tool access const response = await agent.run(User request: ${userInput}, { tools: allTools }); \\

\javascript // Hardened: input is sanitized, and tool access is explicitly scoped const sanitizedInput = sanitizePromptInput(userInput); const response = await agent.run(User request: ${sanitizedInput}`,
{ tools: [readOnlyDbTool, publicApiTool] } // no write access, no shell access
);

if (containsUnexpectedInstructionPattern(sanitizedInput)) {
logger.warn('possible_prompt_injection', { input: sanitizedInput });
return res.status(400).json({ error: 'Request could not be processed' });
}
`\

Rules that hold regardless of framework:

Sanitize anything user-supplied before it reaches a prompt
Scope agent tool permissions tightly, and never grant write or execute access by default
Never let a model-generated response execute code or touch a database without a validation layer sitting in between

Step 5: Move From Pilot to Production Deliberately

This is where most projects stall, and it's rarely a code problem. It's an infrastructure and process problem: environment parity between staging and production, a real rollback plan, and load testing under realistic traffic rather than a demo's worth of requests.

A basic pre-launch checklist that catches most of what breaks in the first week:

Run load tests at 3 to 5 times expected peak traffic before launch
Confirm your rollback path works by actually triggering it once in staging
Verify environment variables and secrets are consistent across all environments, not just copied once and forgotten
Set alert thresholds before launch, not after the first incident

If you're building this solo, budget real time for this stage rather than treating it as an afterthought. If your team doesn't have deep experience taking AI-assisted builds across that finish line, this is exactly the kind of gap that dedicated software engineering and AI integration services are built to close. Bringing in experienced product engineering support for the deployment and hardening phase, while keeping your own team focused on features, is a pattern more teams are leaning on this year rather than trying to solve every infrastructure problem from scratch.

Step 6: Document the Prompt Trail

Future you, and your teammates, will want to know how a given piece of code came to exist. A lightweight log turns "why does this work this way" into a two-minute lookup instead of an afternoon of archaeology.

\`markdown

prompt-log.md

auth-middleware.js

Prompt: "Generate JWT auth middleware with refresh token rotation and rate limiting on failed attempts"
Model: agent-v2, reviewed and hardened 2026-06-14
Changes made after review: added parameterized queries, added rate limit on /login specifically
`\

Keep it in the repo, next to the code it describes. It costs almost nothing to maintain and pays for itself the first time someone asks "why is this here."

The Takeaway

AI can get you to a working prototype faster than ever before, but production readiness still comes down to the fundamentals: input validation, real test coverage, observability, scoped permissions, and a deployment process you've actually rehearsed. The developers and teams thriving in 2026 aren't the ones generating the most code. They're the ones who know exactly what to check before that code touches real users.

What's your current process for reviewing AI-generated code before deployment? Drop it in the comments, I'd love to compare notes.

Why Your Next.js App Is Slower Than Your Old Express Server (And How to Actually Fix It)

Emma Schmidt — Tue, 30 Jun 2026 07:01:15 +0000

You migrated to Next.js for performance. Six months later your Time to First Byte is worse than the monolith you replaced. You're not alone, and you're not doing anything obviously wrong. You just hit the problem nobody warns you about until it's in production.

Here's the real issue, why it happens, and the actual fix.

The Problem Nobody Talks About in the Marketing Docs

Server Components were supposed to make everything faster by default. In practice, a huge number of teams ship apps where every navigation triggers a full server round trip because of one misunderstanding: not knowing where the client/server boundary actually sits in their component tree.

The symptom looks like this. You add "use client" to fix a hydration error, and suddenly half your tree that should've stayed on the server is now shipping JavaScript to the browser and re-fetching data client side. Your bundle grows, your TTFB stays high, and you have no idea why because the app "looks" like it's using Server Components correctly.

Step 1: Actually Audit Your Client Boundary

Most people guess where their client components start. Stop guessing.

npx next build

Look at the build output. Every route shows you whether it's static, dynamic, or server rendered. If routes you expected to be static are showing up dynamic, that's your first clue something upstream is forcing the whole tree client side.
Route (app) Size First Load JS
┌ ○ / 142 B 87.3 kB
├ ● /dashboard 5.2 kB 194 kB
└ ƒ /dashboard/[id] 8.1 kB 201 kB

ƒ means server rendered on demand. If you expected static (○) and you're seeing ƒ, something in that tree is forcing dynamic rendering, often a single misplaced "use client" directive or an uncached fetch call.

Step 2: Find the Actual Culprit

The most common offender is putting "use client" at the top of a file that contains both interactive AND static content, instead of isolating just the interactive piece.

Bad:

"use client"

export default function Dashboard({ data }) {
  return (
    <div>
      <StaticHeader title={data.title} />
      <StaticChart data={data.chartData} />
      <InteractiveFilters onFilter={handleFilter} />
    </div>
  )
}

This forces the entire component, including the static header and chart, to render client side, even though only the filters need interactivity.

Fixed:

// Dashboard.jsx - stays a server component
export default function Dashboard({ data }) {
  return (
    <div>
      <StaticHeader title={data.title} />
      <StaticChart data={data.chartData} />
      <InteractiveFilters /> {/* this one is "use client" */}
    </div>
  )
}

// InteractiveFilters.jsx
"use client"

export default function InteractiveFilters() {
  const [filter, setFilter] = useState('all')
  return <FilterControls onChange={setFilter} />
}

Isolate the interactivity. Don't let one client component drag its parent tree down with it.

Step 3: Fix Your Caching Strategy Explicitly

The second biggest cause of slow Next.js apps is relying on default fetch caching behavior without understanding what it's actually doing. The caching defaults have changed across versions, and teams running mixed environments often have inconsistent behavior between dev and prod without realizing it.

Be explicit instead of trusting defaults:

// Force static caching for data that rarely changes
const data = await fetch('https://api.example.com/products', {
  next: { revalidate: 3600 } // revalidate every hour
})

// Force dynamic for genuinely real-time data
const liveData = await fetch('https://api.example.com/stock-price', {
  cache: 'no-store'
})

Audit every fetch call in your app. If you can't explain why it's cached the way it is, that's a bug waiting to surface under load.

Step 4: Measure, Don't Assume

Add real instrumentation instead of guessing where the slowness is coming from.

export async function generateMetadata() {
  const start = performance.now()
  const data = await getData()
  console.log(`Data fetch took ${performance.now() - start}ms`)
  return { title: data.title }
}

Run this against your actual production data volume, not your local dev seed data. A lot of these problems only show up when payload sizes are realistic.

When This Gets Genuinely Hard

Once your app grows past a handful of routes, this stops being a quick audit and becomes an architecture problem: deciding which routes should be edge rendered, which need true server-side data fetching, and where your data layer needs restructuring entirely. That's usually the point where teams bring in dedicated engineering support with real production Next.js experience, since custom software development and performance optimization work at that scale needs more than a checklist, it needs someone who's debugged this exact caching and boundary mess before across different production environments.

The Real Lesson Here

Next.js isn't slow. Unaudited client boundaries and default caching assumptions are slow. The framework gives you the tools to be fast by default, but only if you're deliberate about where the server/client line sits in your tree.

Run the build output check from Step 1 right now on your own app. I'd bet you find at least one route rendering dynamic that has no reason to be.

What's your TTFB looking like after auditing this? Drop your build output in the comments, curious how common this actually is across different setups.

I Stopped Writing Code. I Started Orchestrating AI Agents. Here's My Exact Workflow.

Emma Schmidt — Mon, 29 Jun 2026 11:04:27 +0000

Last month I shipped a full authentication system with JWT, Google OAuth, rate limiting, and audit logging in 47 minutes. No, I did not have a template. No, I did not copy Stack Overflow. I orchestrated three AI agents in parallel and acted as their lead architect.

This is not a "AI is coming for your job" post. This is the exact step-by-step workflow that helped
me 10x my output in June 2026, and how you can copy it starting today.

Why Your Current AI Setup Is Holding You Back

If you are still using AI as a fancy autocomplete, you are leaving most of the value on the table.

The shift that happened quietly in early 2026 is this: AI moved from assistant to collaborator. Tools like Claude Code, GitHub Copilot Agent Mode, and Cursor no longer just
complete your line. They read your entire codebase, understand your architecture, plan multi-file changes, run tests, and iterate on failures, all without you touching the keyboard.

84% of developers now use AI tools daily. But the ones pulling ahead are not using them more. They are using them differently.

Here is the exact workflow that changed everything for me.

The Agentic Development Workflow (Step by Step)

Step 1: Define Your Architecture Intent, Not Your Code

Stop writing code first. Write intent first.

Before touching any file, I write a plain English spec that looks like this:
GOAL: Build a REST API for user authentication

STACK: Node.js, PostgreSQL, JWT

CONSTRAINTS:

Refresh token rotation
Rate limiting on /login (5 req/min)
All errors must follow RFC 7807
100% test coverage on auth routes

This becomes your agent's context. The more precise your intent, the better the output.

Why this matters: AI agents now use what Anthropic calls "repository intelligence," understanding
not just lines of code but the relationships and intent behind an entire codebase. Feed it intent,
not implementation.

Step 2: Run Parallel Agents on the Same Task

This is the move most developers are not doing yet.

Instead of one AI agent building your feature, you assign the same task to multiple agents with different constraints:

Agent A focuses on performance and minimal dependencies
Agent B focuses on security and edge case handling
Agent C focuses on readability and maintainability

Review all three outputs. Merge the best parts. You become the architect, not the typist.

Tools like GitHub's Agent HQ, launched in February 2026, now support running Claude and Copilot simultaneously on the same task. Each reasons differently about trade-offs. Your job is to pick the
winner.

Step 3: Set Up Your Context Window Like a Project Brief

AI agents have no memory between sessions. So every session needs a "project brief" file at the root of your repo. Here is mine:

# PROJECT.md

## Stack
Next.js 15, **[TypeScript](https://zignuts.com/hire-typescript-developers?utm_source=seo&utm_medium=backlinks&utm_campaign=seo_referral&utm_id=6)**, PostgreSQL, Prisma, Tailwind

## Conventions
- All API routes in /app/api
- Services in /lib/services
- Errors: throw AppError with code + message
- Tests: Vitest + Testing Library

## Current Sprint Goal
Build billing module with Stripe webhook handling

Load this at the start of every agent session. Your agents stay consistent across days and team
members.

Step 4: Use the "Review Loop" Instead of Accepting Output Blindly

The biggest mistake I see developers make: accepting AI output without a structured review.

Here is the review loop I run on every generated file:

Security scan - Does it expose any data it should not? Any SQL injection risks?
Type check - Does TypeScript compile clean with strict mode?
Edge case audit - What happens on empty input, null values, network timeouts?
Performance read - Any N+1 queries? Any missing indexes?

This takes 5 minutes per file but saves hours of debugging in production.

Pro tip: Prompt your agent to self-review first. Ask it: "What are the three most likely bugs
in this code?" You will be surprised how often it catches its own mistakes before you do.

Step 5: Automate Your Test Generation as a Separate Agent Task

Do not generate tests and implementation in the same prompt. They contaminate each other.

After implementation is complete, run a dedicated test agent with this prompt:
You are a QA engineer reviewing code you did not write.

Your job is to break this implementation.

Write tests for:

The happy path
Every edge case you can find
Failure scenarios (network errors, invalid input, race conditions)

Do not look at how the code is written. Only look at what it is supposed to do.

This separation produces dramatically better test coverage than asking for tests and code together.

Step 6: Version Your Prompts Like You Version Your Code

Your prompts are now part of your codebase. Treat them that way.

Create a /prompts directory in your repo:
/prompts

auth-module.md

api-route-template.md

code-review-checklist.md

test-generation.md

Commit them. Review them. Improve them over time. When a prompt produces bad output, fix the prompt.
This is the new debugging.

The Skill Shift Nobody Is Talking About

The developers winning in 2026 are not the fastest typists. They are the best system thinkers.

The skills that matter most right now:

Agent orchestration - Knowing which agent does what and when
Context engineering - Giving AI the exact information it needs, nothing more
Output evaluation - Critically reading generated code for security, correctness, and maintainability
Constraint design - Knowing how to restrict AI output so it stays within your architecture

These are not soft skills. These are the new hard skills of engineering.

Real Talk: When to Call in Specialists

Here is the honest part. Agentic workflows are powerful for features, refactoring, and boilerplate.But when you are building something genuinely complex, such as a cross-platform mobile product, a deeply integrated SaaS backend, or a system that needs to scale from day one, orchestrating agents
yourself has limits.

That is where working with an experienced product and engineering team makes the difference. Teams that offer mobile app development, web application development, custom software development, and dedicated developer hiring can pair your AI-assisted workflow with senior architectural oversight. This combination, AI speed plus human judgment on hard decisions, is where the real 10x happens.

The Workflow at a Glance

Step	What You Do	What the Agent Does
1	Write intent spec	Nothing yet
2	Assign parallel agents	Build 3 versions
3	Load PROJECT.md context	Stays consistent
4	Run review loop	Self-reviews on request
5	Run separate test agent	Tries to break the code
6	Commit your prompts	Reuses your best patterns

Start Today, Not Tomorrow

The gap between teams using agentic workflows and those using AI as autocomplete is growing every week. The tools are here. The workflow is proven. The only variable is whether you adapt now or
spend the next year catching up.

Pick one feature you are building this week. Apply this six-step workflow to it. See what 47 minutes feels like.

Then commit your prompts. Because the best prompt you write today is worth more than the best code you write today.

Have a workflow that is working for you right now? Drop it in the comments. The best stuff I have learned in 2026 came from other developers sharing exactly what is on their screen.

Your Next.js App is Slow Because You Are Still Using 2022 Patterns

Emma Schmidt — Fri, 26 Jun 2026 10:28:59 +0000

I reviewed 47 Next.js codebases this year. Every single one had the same three mistakes.

useEffect for data fetching. useState for server data. Props drilled four levels deep for something that belongs on the server.

These patterns worked in 2022. In 2026, with React 19 stable and the App Router production-hardened, they are the reason your Lighthouse score is a 58 and your users
are bouncing.

This post walks through building a full-stack Next.js 15 app the modern way, with every pattern explained and every anti-pattern called out. By the end you will have a working app and a mental model that actually matches how React works today.

The Mental Model Shift That Changes Everything

The old model: React is a client-side UI library. Fetch data in useEffect. Manage everything in state.

The new model: React is a full-stack framework. Render on the server by default. Send the minimum JavaScript to the client. Use the client only when you need interactivity.

That single shift explains every decision below.

What We Are Building

A full-stack Task Management App with:

Server-rendered list of tasks (fast, SEO-friendly, no loading spinners)
Optimistic UI updates when adding or completing tasks
Server Actions for mutations (no separate API routes needed)
Streaming with Suspense for slow data
TypeScript throughout with end-to-end type safety

Step 1: Project Setup

npx create-next-app@latest taskflow \
  --typescript \
  --tailwind \
  --eslint \
  --app \
  --src-dir

cd taskflow
npm install zod @tanstack/react-query

Your folder structure:
src/

app/

layout.tsx # Root layout

page.tsx # Home page (Server Component)

tasks/

page.tsx # Tasks list (Server Component)

loading.tsx # Suspense fallback

error.tsx # Error boundary

components/

task-list.tsx # Server Component

add-task-form.tsx # Client Component (needs interactivity)

task-item.tsx # Client Component (optimistic updates)

lib/

actions.ts # Server Actions

db.ts # Data layer

types/

index.ts # Shared types

Rule: Components are Server Components by default. Add "use client" only when
you need useState, useEffect, event handlers, or browser APIs.

Step 2: Define Your Types

// src/types/index.ts

export type Task = {
  id: string;
  title: string;
  completed: boolean;
  createdAt: Date;
  priority: "low" | "medium" | "high";
};

export type CreateTaskInput = {
  title: string;
  priority: Task["priority"];
};

One file. Shared between server and client. No duplication.

Step 3: The Data Layer

// src/lib/db.ts
// Replace this with Prisma, Drizzle, or any ORM in production

import { Task } from "@/types";

const tasks: Task[] = [
  {
    id: "1",
    title: "Review pull requests",
    completed: false,
    createdAt: new Date(),
    priority: "high",
  },
];

export async function getTasks(): Promise<Task[]> {
  // Simulate DB latency
  await new Promise((r) => setTimeout(r, 100));
  return tasks;
}

export async function createTask(input: {
  title: string;
  priority: Task["priority"];
}): Promise<Task> {
  const task: Task = {
    id: crypto.randomUUID(),
    title: input.title,
    completed: false,
    createdAt: new Date(),
    priority: input.priority,
  };
  tasks.unshift(task);
  return task;
}

export async function toggleTask(id: string): Promise<Task> {
  const task = tasks.find((t) => t.id === id);
  if (!task) throw new Error("Task not found");
  task.completed = !task.completed;
  return task;
}

Step 4: Server Actions (No API Routes Needed)

This is the biggest shift in 2026 Next.js development. Instead of building
/api/tasks POST endpoints and fetching them from the client, you write Server Actions:
functions that run on the server and can be called directly from your components.

// src/lib/actions.ts
"use server";

import { revalidatePath } from "next/cache";
import { z } from "zod";
import { createTask, toggleTask } from "./db";

const CreateTaskSchema = z.object({
  title: z.string().min(1, "Title is required").max(100),
  priority: z.enum(["low", "medium", "high"]),
});

export async function createTaskAction(formData: FormData) {
  const raw = {
    title: formData.get("title"),
    priority: formData.get("priority"),
  };

  const result = CreateTaskSchema.safeParse(raw);

  if (!result.success) {
    return {
      error: result.error.flatten().fieldErrors,
    };
  }

  await createTask(result.data);

  // Tell Next.js to revalidate the tasks page cache
  revalidatePath("/tasks");

  return { success: true };
}

export async function toggleTaskAction(id: string) {
  await toggleTask(id);
  revalidatePath("/tasks");
}

No fetch. No JSON.stringify. No API route file. The function runs on the server.
The client calls it like a regular async function.

Step 5: The Server Component (The Main Page)

// src/app/tasks/page.tsx

import { Suspense } from "react";
import { TaskList } from "@/components/task-list";
import { AddTaskForm } from "@/components/add-task-form";
import { TaskListSkeleton } from "@/components/task-list-skeleton";

export default function TasksPage() {
  return (
    <main className="max-w-2xl mx-auto p-6">
      <h1 className="text-2xl font-bold mb-6">My Tasks</h1>

      {/* Client Component: needs interactivity */}
      <AddTaskForm />

      {/* Suspense: stream the list while it loads */}
      <Suspense fallback={<TaskListSkeleton />}>
        <TaskList />
      </Suspense>
    </main>
  );
}

Notice there is no useEffect, no useState, no loading state in the page component
itself. Suspense handles the loading state. The Server Component fetches its own data.

Step 6: The Task List (Server Component)

// src/components/task-list.tsx

import { getTasks } from "@/lib/db";
import { TaskItem } from "./task-item";

export async function TaskList() {
  // Direct async call inside a Server Component. No hooks needed.
  const tasks = await getTasks();

  if (tasks.length === 0) {
    return (
      <p className="text-gray-500 text-center py-8">
        No tasks yet. Add one above.
      </p>
    );
  }

  return (
    <ul className="space-y-2 mt-4">
      {tasks.map((task) => (
        <TaskItem key={task.id} task={task} />
      ))}
    </ul>
  );
}

A Server Component is an async function. It fetches its own data. No prop drilling.
No global state. No context. The data lives exactly where it is used.

Step 7: The Task Item with Optimistic Updates (Client Component)

// src/components/task-item.tsx
"use client";

import { useOptimistic, useTransition } from "react";
import { toggleTaskAction } from "@/lib/actions";
import { Task } from "@/types";

export function TaskItem({ task }: { task: Task }) {
  const [optimisticTask, setOptimistic] = useOptimistic(task);
  const [isPending, startTransition] = useTransition();

  async function handleToggle() {
    startTransition(async () => {
      // Update the UI instantly, before the server responds
      setOptimistic((t) => ({ ...t, completed: !t.completed }));
      await toggleTaskAction(task.id);
    });
  }

  const priorityColors = {
    low: "bg-green-100 text-green-700",
    medium: "bg-yellow-100 text-yellow-700",
    high: "bg-red-100 text-red-700",
  };

  return (
    <li
      className={`flex items-center gap-3 p-3 rounded-lg border 
        ${optimisticTask.completed ? "opacity-50" : ""} 
        ${isPending ? "animate-pulse" : ""}`}
    >
      <input
        type="checkbox"
        checked={optimisticTask.completed}
        onChange={handleToggle}
        className="w-4 h-4 cursor-pointer"
      />
      <span
        className={`flex-1 ${
          optimisticTask.completed ? "line-through text-gray-400" : ""
        }`}
      >
        {optimisticTask.title}
      </span>
      <span
        className={`text-xs px-2 py-0.5 rounded-full font-medium 
          ${priorityColors[optimisticTask.priority]}`}
      >
        {optimisticTask.priority}
      </span>
    </li>
  );
}

useOptimistic is new in React 19. It updates the UI instantly while the server
action runs in the background. If the server fails, the UI reverts automatically.

Step 8: The Add Task Form (Client Component)

// src/components/add-task-form.tsx
"use client";

import { useActionState } from "react";
import { createTaskAction } from "@/lib/actions";

const initialState = { error: null, success: false };

export function AddTaskForm() {
  const [state, formAction, isPending] = useActionState(
    createTaskAction,
    initialState
  );

  return (
    <form action={formAction} className="flex gap-2 mb-6">
      <div className="flex-1">
        <input
          name="title"
          type="text"
          placeholder="Add a new task..."
          className="w-full px-3 py-2 border rounded-lg focus:outline-none 
            focus:ring-2 focus:ring-blue-500"
          disabled={isPending}
        />
        {state?.error?.title && (
          <p className="text-red-500 text-sm mt-1">{state.error.title[0]}</p>
        )}
      </div>

      <select
        name="priority"
        defaultValue="medium"
        className="px-3 py-2 border rounded-lg focus:outline-none"
        disabled={isPending}
      >
        <option value="low">Low</option>
        <option value="medium">Medium</option>
        <option value="high">High</option>
      </select>

      <button
        type="submit"
        disabled={isPending}
        className="px-4 py-2 bg-blue-600 text-white rounded-lg 
          hover:bg-blue-700 disabled:opacity-50 transition-colors"
      >
        {isPending ? "Adding..." : "Add"}
      </button>
    </form>
  );
}

useActionState is another React 19 hook. It handles form submission state, pending
state, and server errors in one call. No useState for loading. No try/catch in
the component.

Step 9: Add a Loading Skeleton

// src/components/task-list-skeleton.tsx

export function TaskListSkeleton() {
  return (
    <ul className="space-y-2 mt-4">
      {Array.from({ length: 3 }).map((_, i) => (
        <li
          key={i}
          className="h-12 rounded-lg bg-gray-100 animate-pulse"
        />
      ))}
    </ul>
  );
}

This renders inside <Suspense> while the task list is loading. The page does not
block. The shell renders instantly. The list streams in when it is ready.

Step 10: Error Boundary

// src/app/tasks/error.tsx
"use client";

export default function TasksError({
  error,
  reset,
}: {
  error: Error;
  reset: () => void;
}) {
  return (
    <div className="text-center py-8">
      <p className="text-red-500 mb-4">Something went wrong: {error.message}</p>
      <button
        onClick={reset}
        className="px-4 py-2 bg-blue-600 text-white rounded-lg"
      >
        Try again
      </button>
    </div>
  );
}

Next.js picks this up automatically. Any error thrown in the tasks route renders this
component instead of crashing the whole app.

The Patterns That Actually Matter in 2026

Server Component by default. If your component does not need onClick, useState,or browser APIs, it belongs on the server. This is still the most common mistake in
modern codebases.

Co-locate data fetching with the component that needs it. Stop passing data down through props. The Server Component fetches its own data. Siblings fetch their own data. No prop drilling.

Server Actions over API routes for mutations. For most CRUD operations you no longer need /api endpoints. Server Actions are type-safe, co-located, and require zero client-side fetch boilerplate.

Zod on every Server Action. Never trust form input. Parse and validate before touching the database.

useOptimistic for perceived performance. Users should never wait for a network round trip to see their action reflected in the UI.

What Bad Code Looks Like vs. What Good Code Looks Like

// Bad: fetching in a Client Component
"use client";
useEffect(() => {
  fetch("/api/tasks").then(r => r.json()).then(setTasks);
}, []);

// Good: fetching in a Server Component
async function TaskList() {
  const tasks = await getTasks(); // Direct DB call, no API, no useEffect
  return <ul>{tasks.map(t => <TaskItem key={t.id} task={t} />)}</ul>;
}

// Bad: manual API route + client fetch for a mutation
// POST /api/tasks -> client fetch -> useState update

// Good: Server Action
"use server";
export async function createTask(formData: FormData) {
  await db.insert(tasks).values({ title: formData.get("title") });
  revalidatePath("/tasks");
}

Deployment

npm run build
npm start

Or push to Vercel with zero config. The App Router is production-ready and your server components, server actions, and edge routes all deploy automatically.

If your team is building a production Next.js app and you need senior-level architecture guidance or development capacity, custom web application development services cover full-stack Next.js projects from architecture to launch.

Cheat Sheet

Old Pattern	Modern Replacement
`useEffect` for data fetching	`async` Server Component
`/api/route.ts` for mutations	Server Action (`"use server"`)
`useState` loading boolean	`useTransition` + `useActionState`
Prop drilling data down	Server Component fetches its own data
Manual optimistic update	`useOptimistic`
`try/catch` in every component	`error.tsx` error boundary
Skeleton in the component	`loading.tsx` or `<Suspense>`

Final Thought

React 19 and Next.js 15 are not just incremental updates. They represent a complete rethink of where your code runs and where your data lives. The developers who internalize the server-first model are building faster apps with less code right now.

The patterns in this tutorial are not experimental. They are what production teams at scale are shipping today.

Drop a comment with the pattern that surprised you most. And if you spot something I missed, call it out below.

I Built a Production AI Agent in a Weekend. Here is Exactly How I Did It (Step-by-Step, 2026 Edition)

Emma Schmidt — Thu, 25 Jun 2026 06:04:16 +0000

Everyone is talking about AI agents. Almost nobody is actually shipping them.

I got tired of reading theory. So I spent one weekend going from zero to a working, deployed AI agent that can browse the web, read files, send emails, and loop on its own until a task is done. No fluff. No toy examples. Just the actual steps, the actual code, and the real mistakes I made so you do not have to.

This tutorial is for developers who want to build something real, not just get through a hello-world demo.

Why AI Agents Are the Biggest Skill You Can Learn Right Now

The numbers are not subtle. The global agentic AI market surged past $9 billion in 2026. Gartner projects 40% of enterprise applications will embed task-specific AI agents by year-end, up from under 5% in 2025. Enterprise AI agent deployments are returning an average 171% ROI.

The mental model has shifted: the 10x engineer is no longer someone who writes more code. It is someone who effectively orchestrates agents that do.

If you can build agents, you are not just keeping up. You are the one teams depend on.

What Is an AI Agent, Actually?

A chatbot tells you the weather. An AI agent can check the weather, decide you need an umbrella, and add "buy umbrella" to your shopping list.

More technically: an AI agent uses a large language model as its reasoning engine. Unlike a chatbot that only generates text, an agent can observe its environment by reading inputs and context. It plans, acts, checks results, and loops until the job is done.

Every AI agent has exactly four components. The LLM is the brain. Memory, tools, and a runtime are what make it an agent instead of a chatbot.

Step 1: Pick One Problem (Not Ten)

The single biggest mistake beginners make is trying to build a general-purpose agent on day one.

Pick one workflow. Something with real, repetitive steps you do manually today. Good first agents:

Research a topic and summarize findings into a document
Monitor a folder for new files and process each one
Pull data from an API, transform it, and send a report by email

Start with one simple workflow. Give it 2 to 4 tools it can use, and define exactly when it must stop. Add rules for risky actions, like requiring approval for writes or payments. Once that works reliably, you can expand.

Step 2: Choose Your Framework

Three frameworks dominate agent development in 2026. They are not interchangeable. Each makes fundamental tradeoffs that matter depending on what you are building.

Vercel AI SDK is the best choice if your agent lives inside a web app (Next.js, SvelteKit, etc). It streams natively and integrates with React out of the box.

LangChain remains the most popular choice in 2026 because it has the largest community and works with virtually every AI model available.

Claude Agent SDK is the strongest pick for multi-agent systems where a coordinator routes tasks between specialist agents.

For this tutorial, I am using the Vercel AI SDK with the Anthropic model. Here is why: it gives you streaming for free, TypeScript types for everything, and a dead-simple tool-calling interface.

Step 3: Set Up Your Project

mkdir my-agent && cd my-agent
npm init -y
npm install ai @ai-sdk/anthropic zod

Create a .env file:
ANTHROPIC_API_KEY=your_key_here

Step 4: Define Your Tools

Tools are how your agent acts instead of just responds. Each tool needs a name, a description the model can understand, a typed input schema, and an execute function.

import { tool } from "ai";
import { z } from "zod";

const searchWeb = tool({
  description: "Search the web for current information on a topic",
  parameters: z.object({
    query: z.string().describe("The search query"),
  }),
  execute: async ({ query }) => {
    // Wire in your search API here (Tavily, Brave, etc.)
    const results = await fetchSearchResults(query);
    return results;
  },
});

const writeFile = tool({
  description: "Write content to a local file",
  parameters: z.object({
    filename: z.string(),
    content: z.string(),
  }),
  execute: async ({ filename, content }) => {
    await fs.writeFile(filename, content);
    return `Written to ${filename}`;
  },
});

Tools create checkable actions. Prompts guide decisions. If tools are vague, prompts cannot fix the outcome. Stable agents come from clear actions first, language second.

Step 5: Wire Up the Reasoning Loop

This is the engine. The agent observes, reasons, acts, and checks until done.

import { streamText } from "ai";
import { anthropic } from "@ai-sdk/anthropic";

const result = await streamText({
  model: anthropic("claude-sonnet-4-6"),
  system: `You are a research agent. Given a topic, search for information,
  synthesize the findings, and write a structured summary to a file.
  Be thorough. Check multiple angles. Stop only when the file is written.`,
  prompt: "Research the current state of agentic AI in enterprise software.",
  tools: { searchWeb, writeFile },
  maxSteps: 10, // Safety limit on the loop
});

for await (const chunk of result.textStream) {
  process.stdout.write(chunk);
}

The maxSteps parameter is your safety valve. Without limits, agents can go off rails. Token costs add up. A looping agent can cost hundreds in hours.

Step 6: Add Memory

Short-term memory handles the current session. Long-term memory, a vector database or SQL store, persists across runs so the agent gets smarter over time.

For a simple persistent memory, store a JSON log after each run and inject the last N entries at the start of the next session:

const memory = JSON.parse(await fs.readFile("memory.json", "utf-8") || "[]");

const systemPrompt = `
You are a research agent with memory of past tasks.

Previous context:
${memory.slice(-5).map(m => `- ${m}`).join("\n")}

Current task: ${userTask}
`;

For production, reach for a vector database like Pinecone or Weaviate so the agent can do semantic recall across thousands of past interactions.

Step 7: Add Guardrails Before You Ship

Moving from a cool demo to a production-ready application is not about better prompt engineering anymore. It is about rigorous agentic engineering, multi-agent architecture, state management, and deterministic guardrails.

The minimum guardrails you need before any agent touches real systems:

Require approval for destructive actions. Writes, deletes, emails, payments. Build a requiresApproval flag into those tools and pause for human confirmation.

Set cost controls. Track token usage per run and kill the loop if it exceeds your budget threshold.

Log everything. Every tool call, every result. You cannot debug what you cannot see.

Validate outputs. If the agent is supposed to return JSON, validate it before using it downstream.

// Simple output validation
const output = result.text;
try {
  const parsed = JSON.parse(output);
  if (!parsed.summary || !parsed.sources) throw new Error("Missing fields");
  return parsed;
} catch {
  // Retry with a more explicit prompt
  return retry(task, "Return valid JSON with summary and sources fields.");
}

Step 8: Deploy

The simplest production deployment is a serverless function behind a queue. Agents can run for minutes, not milliseconds, so you need a runtime that does not time out.

Good options in 2026:

Vercel Functions with extended max duration for lighter agents
AWS Lambda with SQS for queue-backed, long-running tasks
Modal or Fly.io for heavier workloads that need persistent containers

One pattern that works well for teams building multiple agents: offload the infrastructure layer to a dedicated custom software development team. Look for partners that offer end-to-end product engineering, covering mobile app development, backend systems, cloud-native architecture, AI integration, and full deployment pipelines. That kind of dedicated team model takes weeks off your timeline and lets your engineers stay focused on agent logic instead of plumbing.

The Mistakes I Made (So You Do Not Have To)

Mistake 1: Vague tool descriptions. The model reads your description to decide when to use the tool. "Searches stuff" is useless. "Searches the web for factual, up-to-date information on a specific topic" is what the model actually needs.

Mistake 2: No stop condition. Define in your system prompt what "done" means. An agent without a clear stopping condition will hallucinate tasks to keep going.

Mistake 3: Too many tools on day one. Start with two or three. Every extra tool is another decision point for the model. More tools means more chances to pick the wrong one.

Mistake 4: Skipping evals. Even autonomous agents need human check-ins for critical tasks. Run your agent on 10 test inputs before you trust it with production data. Log the results. Treat agent evaluation like unit testing.

What to Build Next

Once your first agent runs reliably, here are the five most valuable agents worth building right now based on what engineering teams actually need:

Research agent that monitors a topic and delivers a weekly digest
Code review agent that checks PRs against your team's style guide
Customer support triage agent that classifies and routes tickets before a human reads them
CRM enrichment agent that pulls public data and fills in contact records
Content pipeline agent that turns a brief into a drafted post, formatted for your channels

Businesses using AI agents report 55% higher operational efficiency and 35% cost reductions. The use cases above are where those numbers come from.

Conclusion

Building an AI agent is not complicated once you strip away the theory. Pick one problem. Define clear tools. Wire the loop. Add guardrails. Ship it.

The developers who understand how to build, evaluate, and operate agents are the ones engineering teams are racing to hire right now. You now have the full blueprint.

Start with one agent. Get it working. Then scale.

What workflow are you automating first? Drop it in the comments below.

I Pushed to Production on a Friday. Here Is Everything That Broke and Exactly How I Fixed It.

Emma Schmidt — Wed, 24 Jun 2026 05:55:50 +0000

Nobody warned me. I deployed at 4:57 PM on a Friday, closed my laptop, and woke up Saturday to 47 Slack messages, a database on fire, and users who could not log in.

This is not a theory post. This is the exact breakdown of what failed, why it failed, and the step-by-step fixes I now run on every project before it ever touches production again. If you ship Node.js or React apps, read this before your Friday deploy.

What Actually Broke (And Why)

Here is the damage report from that weekend:

Login endpoint returned 503 after 200 concurrent users
Dashboard loaded in 14 seconds instead of 1.2 seconds
One rogue API route had no rate limiting and got hammered by a bot within 6 hours of launch
App crashed on restart because sessions were stored in memory, not persisted
Zero visibility into what was happening because logging was just console.log

Every single one of these is fixable in an afternoon. I just did not know to fix them before launch.

Fix 1: Stop Your Login Endpoint From Dying Under Load

The login route was doing three database calls per request with zero caching. At 200 concurrent users, the database gave up.

First, find your slow routes before users find them for you:

// middleware/timing.js
export function timingMiddleware(req, res, next) {
  const start = process.hrtime.bigint();

  res.on('finish', () => {
    const ms = Number(process.hrtime.bigint() - start) / 1_000_000;
    if (ms > 300) {
      console.warn(`SLOW: [${req.method}] ${req.path} -- ${ms.toFixed(1)}ms`);
    }
  });

  next();
}

// app.js
import { timingMiddleware } from './middleware/timing.js';
app.use(timingMiddleware);

Any route consistently above 300ms is a problem waiting to go public. Fix it before launch, not during it.

Fix 2: Add a Cache Layer That Actually Makes Sense

Most developers throw everything into one Redis instance. That is wrong. There are four tiers and mixing them up costs you both performance and correctness.

CDN tier handles static files and public marketing pages. Your server should never touch these at all.

Application tier handles expensive computed data like user dashboards and analytics summaries.

Query tier handles repeated identical database lookups.

Browser tier handles files users already downloaded once.

Here is the application tier cache that saved us 80% of our database load:

// lib/cache.js
import { createClient } from 'redis';

const redis = createClient({ url: process.env.REDIS_URL });
await redis.connect();

export async function getOrSet(key, ttlSeconds, fetchFn) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);

  const fresh = await fetchFn();
  await redis.setEx(key, ttlSeconds, JSON.stringify(fresh));
  return fresh;
}

// routes/dashboard.js
app.get('/api/dashboard/:userId', async (req, res) => {
  const data = await getOrSet(
    `dashboard:${req.params.userId}`,
    60,
    () => buildDashboard(req.params.userId)
  );
  res.json(data);
});

Five database calls became one Redis call. The dashboard went from 14 seconds to 380ms.

Fix 3: Your Database Is Probably Doing Full Table Scans Right Now

Run this on your Postgres instance right now:

SELECT
  query,
  calls,
  mean_exec_time,
  total_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time DESC
LIMIT 10;

If any query averages above 100ms, look at it. Then check whether it is using indexes:

EXPLAIN ANALYZE
SELECT * FROM users WHERE email = 'someone@example.com';

If you see Seq Scan in the output, your database is reading the entire users table every single time someone tries to log in. Add the index:

CREATE INDEX CONCURRENTLY idx_users_email ON users(email);

CONCURRENTLY builds the index without locking your table. Always use it in production. We went from 340ms average login query time to 4ms with this one line.

Fix 4: Rate Limit Everything That Faces the Internet

A bot found our unsecured file upload endpoint within six hours of launch and sent 4,000 requests in 20 minutes. Here is the limiter that now goes on every single project I touch:

import rateLimit from 'express-rate-limit';

const apiLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,
  max: 100,
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: 'Too many requests. Try again in 15 minutes.' }
});

const authLimiter = rateLimit({
  windowMs: 60 * 60 * 1000,
  max: 10,
  message: { error: 'Too many login attempts.' }
});

app.use('/api/', apiLimiter);
app.use('/api/auth/', authLimiter);

Auth endpoints get the strict limiter. Everything else gets the generous one. No exceptions.

Fix 5: Move Sessions Out of Memory or You Cannot Scale

When I added a second server behind a load balancer, half my users got randomly logged out. The reason: sessions were stored in the server's memory, and the second server had no idea they existed.

The fix is one npm install away:

import session from 'express-session';
import RedisStore from 'connect-redis';

app.use(session({
  store: new RedisStore({ client: redis }),
  secret: process.env.SESSION_SECRET,
  resave: false,
  saveUninitialized: false,
  cookie: {
    secure: true,
    httpOnly: true,
    maxAge: 1000 * 60 * 60 * 24
  }
}));

Now every server shares the same session store. You can run ten instances and every user stays logged in across all of them.

Fix 6: Add a Health Check That Actually Tells the Truth

A health check that just returns 200 OK is lying to your infrastructure. Here is one that checks what actually matters:

app.get('/health', async (req, res) => {
  const result = {
    status: 'ok',
    timestamp: new Date().toISOString(),
    services: {}
  };

  try {
    await db.query('SELECT 1');
    result.services.database = 'ok';
  } catch {
    result.services.database = 'error';
    result.status = 'degraded';
  }

  try {
    await redis.ping();
    result.services.cache = 'ok';
  } catch {
    result.services.cache = 'error';
    result.status = 'degraded';
  }

  res.status(result.status === 'ok' ? 200 : 503).json(result);
});

Kubernetes, ECS, Railway, Render, all of them use this endpoint to decide whether to restart your app. Give them the real answer.

Fix 7: Handle Errors Like a Senior Dev, Not a Tutorial

The default behavior in most codebases is to either crash silently or send a raw stack trace to the browser. Both are terrible. Here is the global error handler that goes in every project:

app.use((err, req, res, next) => {
  const isDev = process.env.NODE_ENV === 'development';

  console.error({
    message: err.message,
    stack: err.stack,
    url: req.url,
    method: req.method,
    userId: req.user?.id ?? 'unauthenticated'
  });

  res.status(err.status || 500).json({
    error: isDev
      ? err.message
      : 'Something went wrong. Our team has been notified.',
    ...(isDev && { stack: err.stack })
  });
});

Structured logs internally. Safe message externally. Never both to the same place.

Fix 8: Graceful Shutdown So Deploys Do Not 502 Your Users

Every time you deploy without graceful shutdown, in-flight requests get cut off mid-response. Users see a sudden error for no reason. Here is the fix:

const server = app.listen(3000);

async function shutdown(signal) {
  console.log(`${signal} received. Shutting down...`);

  server.close(async () => {
    await db.end();
    await redis.quit();
    console.log('Clean shutdown complete.');
    process.exit(0);
  });

  setTimeout(() => {
    console.error('Shutdown timeout. Forcing exit.');
    process.exit(1);
  }, 10_000);
}

process.on('SIGTERM', () => shutdown('SIGTERM'));
process.on('SIGINT', () => shutdown('SIGINT'));

Add this once. Forget about mysterious 502s during deployments forever.

The Pre-Launch Checklist I Now Run on Every Project

Print this. Stick it somewhere. Do not deploy without it.

Slow route detection middleware added
Redis caching layer for expensive queries
Database indexes verified with EXPLAIN ANALYZE
Rate limiting on all public and auth endpoints
Sessions stored in Redis, not server memory
Health check that tests real dependencies
Global error handler with structured logging
Graceful shutdown wired to SIGTERM and SIGINT
No secrets in committed code
Environment variables in a proper secrets manager

When the Project Outgrows the Checklist

These eight fixes will carry most apps from zero to a few hundred thousand users without breaking a sweat. But when you are dealing with microservices architecture, advanced cloud and DevOps infrastructure, multi-region deployments, or a mobile app that needs to stay in sync with a complex backend, the decisions get harder and the cost of getting them wrong gets much higher.

That is the point where working with a team that offers dedicated full-stack web development, mobile app development, and cloud architecture services pays for itself fast. Getting the infrastructure decisions right at the start is dramatically cheaper than rebuilding them after a production fire.

The Real Lesson

I deployed on a Friday and paid for it all weekend.

You do not have to.

Every fix in this post is a few hours of work total. The checklist at the end is fifteen minutes before any deploy. The difference between a launch that becomes a growth story and one that becomes a postmortem is almost always not intelligence or talent. It is just knowing what to check before you push.

Now you know.

Which one of these are you missing in your current project? Drop it in the comments. I read all of them.

I Built a Full-Stack AI Agent App in 48 Hours Using React 19 + TypeScript. Here's Exactly How.

Emma Schmidt — Tue, 23 Jun 2026 06:03:27 +0000

No tutorials covered this end-to-end. So I documented every step.

Everyone is talking about AI agents in 2026. Very few are showing you how to actually ship one. I spent a weekend building a production-ready AI agent app using the hottest stack right now: React 19, TypeScript, Server Actions, and a multi-agent backend. No fluff. No theory. Just the steps that worked.

By the end of this post, you will have a working blueprint you can fork and ship today.

Why This Stack, Why Now

TypeScript became the most-used language on GitHub by contributor count in 2025, surpassing Python by roughly 42,000 contributors. Nearly every major framework now scaffolds in TypeScript by default, meaning developers adopting those frameworks are automatically working in TypeScript from day one.

And on the AI side? 84% of developers now use AI coding tools, and 51% of professionals reach for them every single day.

The shift is real. The developers winning right now are not writing more code. They are orchestrating smarter systems. Let's build one.

What We Are Building

A multi-agent task manager that:

Accepts a plain-English goal from the user
Breaks it into subtasks using an AI planner agent
Executes each subtask with a specialist agent
Streams results back to the UI in real time

This is not a chatbot. This is an agentic app with real architecture.

Step 1: Scaffold the Project

npx create-next-app@latest agent-app --typescript --app
cd agent-app
npm install ai @ai-sdk/anthropic zod

Use the App Router. Server Actions are a first-class citizen here and they will save you from writing a dozen API routes.

Project structure:
/app

/actions <- Server Actions (agent logic lives here)

/components <- React 19 UI components

/api <- Only for streaming endpoints

/lib

agents.ts <- Agent definitions and orchestration

schema.ts <- Zod schemas for structured outputs

Step 2: Define Your Agent Schema with Zod

Structured outputs are the backbone of reliable agents. If your agent returns raw prose, you cannot build UI on top of it.

// lib/schema.ts
import { z } from "zod";

export const TaskPlanSchema = z.object({
  goal: z.string(),
  subtasks: z.array(
    z.object({
      id: z.string(),
      title: z.string(),
      agent: z.enum(["researcher", "writer", "reviewer"]),
      instructions: z.string(),
    })
  ),
});

export type TaskPlan = z.infer<typeof TaskPlanSchema>;

This locks the AI output into a predictable shape. No more JSON.parse roulette.

Step 3: Build the Planner Agent (Server Action)

// app/actions/planner.ts
"use server";

import { generateObject } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { TaskPlanSchema } from "@/lib/schema";

export async function planGoal(goal: string) {
  const { object } = await generateObject({
    model: anthropic("claude-sonnet-4-6"),
    schema: TaskPlanSchema,
    prompt: `
      You are a project planner. Break this goal into 3-5 concrete subtasks.
      Assign each to the most suitable specialist agent.
      Goal: ${goal}
    `,
  });

  return object;
}

Server Actions in React 19 mean you call this directly from your component. No fetch, no API route, no boilerplate.

Step 4: Build the Specialist Agents

// lib/agents.ts
import { generateText } from "ai";
import { anthropic } from "@ai-sdk/anthropic";

const AGENT_PROMPTS = {
  researcher: "You are a research agent. Find facts, cite sources, summarize.",
  writer: "You are a writing agent. Produce clear, structured content.",
  reviewer: "You are a review agent. Check for accuracy, gaps, and quality.",
};

export async function runAgent(
  agentType: keyof typeof AGENT_PROMPTS,
  instructions: string
) {
  const { text } = await generateText({
    model: anthropic("claude-sonnet-4-6"),
    system: AGENT_PROMPTS[agentType],
    prompt: instructions,
  });

  return text;
}

Each agent has a focused role. The mental model has shifted: the 10x engineer is no longer someone who writes more code. It is someone who effectively orchestrates agents that do. Your architecture should reflect that.

Step 5: Orchestrate with a Server Action

// app/actions/orchestrate.ts
"use server";

import { planGoal } from "./planner";
import { runAgent } from "@/lib/agents";

export async function runGoal(goal: string) {
  const plan = await planGoal(goal);

  const results = await Promise.all(
    plan.subtasks.map(async (task) => {
      const output = await runAgent(task.agent, task.instructions);
      return { ...task, output };
    })
  );

  return { plan, results };
}

Notice Promise.all. Subtasks run in parallel. This is how you get fast agents instead of slow sequential chains.

Step 6: Build the React 19 UI

// app/components/AgentRunner.tsx
"use client";

import { useState, useTransition } from "react";
import { runGoal } from "@/app/actions/orchestrate";

export function AgentRunner() {
  const [goal, setGoal] = useState("");
  const [results, setResults] = useState<any>(null);
  const [isPending, startTransition] = useTransition();

  function handleRun() {
    startTransition(async () => {
      const data = await runGoal(goal);
      setResults(data);
    });
  }

  return (
    <div className="max-w-2xl mx-auto p-6">
      <h1 className="text-2xl font-bold mb-4">AI Agent Runner</h1>

      <input
        value={goal}
        onChange={(e) => setGoal(e.target.value)}
        placeholder="Enter your goal..."
        className="w-full border rounded p-2 mb-4"
      />

      <button
        onClick={handleRun}
        disabled={isPending}
        className="bg-blue-600 text-white px-4 py-2 rounded"
      >
        {isPending ? "Running agents..." : "Run"}
      </button>

      {results && (
        <div className="mt-6 space-y-4">
          {results.results.map((r: any) => (
            <div key={r.id} className="border rounded p-4">
              <p className="font-semibold">{r.title}</p>
              <p className="text-sm text-gray-500 mb-2">Agent: {r.agent}</p>
              <p className="text-sm">{r.output}</p>
            </div>
          ))}
        </div>
      )}
    </div>
  );
}

useTransition gives you pending state for free. No loading spinners wired by hand. The React Compiler reduces unnecessary re-renders by 25-40% with zero developer effort. The performance wins come for free here.

Step 7: Add Error Boundaries and Fallbacks

Agents fail. Models timeout. Networks drop. This is not optional.

// app/components/AgentErrorBoundary.tsx
"use client";

import { ErrorBoundary } from "react-error-boundary";

function Fallback({ error }: { error: Error }) {
  return (
    <div className="text-red-600 border border-red-300 p-4 rounded">
      <p className="font-semibold">Agent failed</p>
      <p className="text-sm">{error.message}</p>
    </div>
  );
}

export function SafeAgentRunner({ children }: { children: React.ReactNode }) {
  return (
    <ErrorBoundary FallbackComponent={Fallback}>{children}</ErrorBoundary>
  );
}

Wrap your AgentRunner in SafeAgentRunner. Done.

Step 8: Deploy to Vercel in 3 Minutes

npx vercel --prod

That is it. Vercel handles Edge Functions, Server Actions, and streaming natively. No config. No YAML files. No crying at 2am.

The Architecture at a Glance

User Input
|
v
Planner Agent (Server Action)
|
v
Task Plan (Zod-validated JSON)
|
v
Parallel Specialist Agents
[Researcher] [Writer] [Reviewer]
|
v
Streamed Results -> React 19 UI

Clean. Typed. Parallel. Production-ready.

What To Build Next

This blueprint scales. Swap in different agent types, add memory with a vector store, plug in tool use for web search or code execution. The architecture holds.

If you want to skip the setup entirely and work with a team of senior engineers who handle end-to-end product development, from architecture to deployment, covering React, React Native, Node.js, and AI-integrated builds for startups and scale-ups, that option exists and it moves faster than you think.

But if you are building it yourself, you now have the foundation.

Key Takeaways

React 19 Server Actions replace 90% of your API layer
TypeScript + Zod is the only sane way to build with LLMs
Parallel agent execution is not advanced, it is table stakes
useTransition gives you pending UI without any extra state
Deploy to Vercel, move on, iterate fast

What are you building with AI agents? Drop it in the comments. I read every one.

If this saved you time, drop a reaction. It helps more developers find it.

Your Code Is Being Replaced -And The Scary Part? You're Helping It Happen.

Emma Schmidt — Mon, 22 Jun 2026 12:09:36 +0000

Let me be blunt with you.

The week I watched an AI agent open a GitHub PR, write tests, respond to review comments, fix the failing CI pipeline, and ping the team on Slack, all without a human touching a keyboard, I did not feel excited.

I felt the floor move.

Because that was not a demo. That was a Tuesday.

We are no longer debating whether AI changes software development. That debate is closed, filed, and archived. The question now, the only question that matters, is: are you adapting fast enough, or are you just watching?

Let's talk about what's actually happening right now, what the data says, and how forward-thinking teams are building smarter systems in the middle of all this chaos.

The Numbers Are Not Subtle

The Stack Overflow Developer Survey (49,000+ developers across 177 countries) dropped a number that should be pinned to every engineering manager's wall:

84% of developers now use AI coding tools. 51% use them every single day.

That's not a trend. That's a new baseline.

But here's what makes it interesting. Widespread adoption hasn't produced widespread confidence. Most developers are using these tools while quietly unsure how deeply to trust them. There's a gap between reach and mastery, and that gap is where the real opportunity lives.

What "AI-Assisted Development" Actually Looks Like in 2026

Stop imagining autocomplete.

GitHub's Agent HQ now lets developers run Claude, Codex, and Copilot simultaneously on the same task, each reasoning differently about trade-offs and architecture decisions. Anthropic's 2026 Agentic Coding Trends Report describes this as "repository intelligence", AI that understands not just individual lines but the relationships and intent across an entire codebase.

The mental model has fundamentally shifted:

The 10x engineer is no longer someone who writes more code. It's someone who effectively orchestrates agents that do.

AI isn't writing functions anymore. It's handling:

Architecture design
Test generation
Code review responses
Deployment pipelines
Application monitoring
Documentation

The unit of AI assistance is no longer the line or function. It's the project.

TypeScript Just Pulled Off The Biggest Language Upset In A Decade

Here's a plot twist nobody predicted.

In August 2025, TypeScript surpassed Python to become the most-used language on GitHub by contributor count, by roughly 42,000 contributors. GitHub called it "the most significant language shift in more than a decade."

Over 1 million new TypeScript contributors joined in 2025 alone. A 66% year-over-year increase.

Why? It's structural, not stylistic.

Every major framework, Next.js, Angular, SvelteKit, Astro, Remix, now scaffolds in TypeScript by default. Developers adopting those frameworks are automatically TypeScript developers. End-to-end type safety is no longer a preference. In 2026, writing plain JavaScript for a professional project is considered a legacy approach.

// This is now the default starting point, not a preference
// npm create vite@latest my-app -- --template react-ts

import { useState, useTransition } from "react";

function SmartSearch({ items }: { items: string[] }) {
  const [query, setQuery] = useState("");
  const [filtered, setFiltered] = useState(items);
  const [isPending, startTransition] = useTransition();

  function handleSearch(e: React.ChangeEvent<HTMLInputElement>) {
    const value = e.target.value;
    setQuery(value);

    startTransition(() => {
      setFiltered(items.filter(i => i.toLowerCase().includes(value.toLowerCase())));
    });
  }

  return (
    <div>
      <input value={query} onChange={handleSearch} placeholder="Search..." />
      {isPending && <span>Updating...</span>}
      <ul>{filtered.map((item, i) => <li key={i}>{item}</li>)}</ul>
    </div>
  );
}

If your team is still debating TypeScript adoption in mid-2026, the ecosystem has already made the decision for you.

The Frameworks Have Won. The Debate Is Over.

In 2026, Next.js and Nuxt are the standard entry points for most professional web projects. They have evolved from opinionated frameworks into one-stop solutions, handling routing, rendering strategy, server functions, edge runtimes, and deployment in a single coherent system.

Tool	Cold Start	HMR Speed	Best For
Vite	Under 1s	Near-instant	New projects, SPAs
Turbopack	Very fast	Under 500ms	Next.js projects
Webpack 5	10-15s	1-3s	Legacy codebases

Create React App is officially dead. Real-world benchmarks show Vite loading pages in under 1 second vs 13+ seconds on legacy CRA setups. The migration is not optional anymore.

Agentic AI: From Assistant to Autonomous Operator

AI is no longer reactive. It does not wait for a prompt. Agentic systems plan, decide, execute, and course-correct, often within a single workflow, without step-by-step human input.

By 2028, a third of enterprise software is expected to include agentic AI components.

const agentWorkflow = {
  trigger: "PR merged to main",
  steps: [
    { action: "run_tests", onFail: "notify_slack_and_halt" },
    { action: "generate_changelog", model: "claude-sonnet-4-6" },
    { action: "deploy_to_staging" },
    { action: "run_e2e_smoke_tests", onFail: "rollback_staging" },
    { action: "await_human_approval", timeout: "24h" },
    { action: "deploy_to_production" },
    { action: "post_deployment_report_to_slack" },
  ]
};

The developers who thrive in this environment are not just coders. They are system designers and agent orchestrators.

Low-Code Is Not Your Enemy. Ignoring It Is.

Gartner projected the low-code market to hit $44.5 billion by 2026, growing to $264 billion by 2032.

Platform engineering teams are addressing governance with:

API standards enforcement
Automated security scanning at the build level
Git-linked deployments even for low-code outputs
Role-based access controls baked in from day one

The winning organizations in 2026 are not choosing between low-code and pro-code. They are layering them intelligently.

The Honest Summary

AI coding tools are baseline infrastructure, not optional add-ons
TypeScript has won. Plan your migration if you have not
Meta-frameworks like Next.js and Nuxt are the standard, not the shortcut
Agentic AI is moving from experiment to production
Low-code and pro-code are complementary layers, not competing philosophies
The 10x engineer in 2026 is an orchestrator, not just a coder

The floor is not stable. But that is not necessarily bad news. It means the gap between teams that adapt and teams that wait is widening faster than ever before.

Do not waste it watching from the sidelines.

What's the biggest shift your team has made in the last 6 months to adapt to the agentic development era? Drop it in the comments.