Forem: Emma Schmidt

Next.js in 2026: The Features Reshaping Full-Stack Web Development

Emma Schmidt — Fri, 22 May 2026 12:32:12 +0000

If you have been building with React for any length of time, you already know
that Next.js is not just a framework anymore. It is the foundation of modern
full-stack web development. Whether you are a solo developer shipping fast or
part of a team looking to Hire Next.js Developers to scale production-grade
applications, understanding what is trending in the Next.js ecosystem right now
will give you a serious competitive edge. In this post, we break down the
hottest Next.js features and patterns dominating 2026 so you can write better
code, ship faster, and build smarter.

1. Partial Prerendering (PPR) is Now Stable and It Changes Everything

This is the single biggest shift in how Next.js handles rendering. For years,
developers faced a painful choice: go fully static for speed or go fully dynamic
for freshness. PPR eliminates that tradeoff entirely.

With PPR, a single route can serve a static shell instantly from the CDN
while streaming dynamic "holes" into the page as they resolve. Think of a
product page where the layout, header, and hero section are pre-rendered, but
the live stock count and personalized cart are streamed in on demand.

// app/product/[id]/page.tsx
import { Suspense } from 'react'
import { ProductHero } from '@/components/ProductHero'
import { LiveStock } from '@/components/LiveStock'
import { PersonalizedCart } from '@/components/PersonalizedCart'

export default function ProductPage({ params }) {
  return (
    <main>
      {/* Served instantly from CDN */}
      <ProductHero id={params.id} />

      {/* Streamed in dynamically */}
      <Suspense fallback={<StockSkeleton />}>
        <LiveStock id={params.id} />
      </Suspense>

      <Suspense fallback={<CartSkeleton />}>
        <PersonalizedCart />
      </Suspense>
    </main>
  )
}

Enable it in your config:

// next.config.ts
const nextConfig = {
  experimental: {
    ppr: true,
  },
}

export default nextConfig

Why it matters: You get the SEO and load-speed benefits of static rendering
AND the freshness of dynamic data, on the same page, without compromise.

2. Turbopack is Fully Stable: Your Local Dev Will Never Feel the Same

Turbopack, the Rust-based successor to Webpack, is now fully stable in
development mode. The numbers are not a marketing gimmick. Real-world benchmarks
show cold starts up to 10x faster and Hot Module Replacement (HMR)
completing in milliseconds even in large monorepos.

No configuration needed. Just run:

next dev --turbo

For teams building large applications with 50+ pages and 200+ components, the
productivity difference is measurable. Less waiting, more shipping.

Practical tip: Enable Turbopack in your CI preview environments too. Your
feedback loops get noticeably tighter.

3. Server Actions: Backend Logic Without the Boilerplate

Server Actions have matured into one of the most powerful patterns in the
Next.js ecosystem. Instead of standing up a separate API route for every form
submission or mutation, you declare a function with "use server" and call it
directly from your component.

// app/actions/createPost.ts
"use server"

import { db } from '@/lib/db'
import { revalidatePath } from 'next/cache'

export async function createPost(formData: FormData) {
  const title = formData.get('title') as string
  const body = formData.get('body') as string

  await db.post.create({ data: { title, body } })
  revalidatePath('/blog')
}

// app/new-post/page.tsx
import { createPost } from '@/app/actions/createPost'

export default function NewPostPage() {
  return (
    <form action={createPost}>
      <input name="title" placeholder="Post title" required />
      <textarea name="body" placeholder="Write your content..." />
      <button type="submit">Publish</button>
    </form>
  )
}

Security improvements in Next.js 15/16 mean Server Actions now have
unguessable endpoints and unused actions are automatically tree-shaken from
your bundle. Clean, secure, and zero boilerplate.

4. React Server Components + React 19: The Rendering Model Has Grown Up

Next.js 15 brought full React 19 support, and the combination is a game-changer
for performance. React Server Components (RSC) let you fetch data at the
component level on the server, keeping sensitive logic and heavy dependencies
completely off the client bundle.

React 19 adds the use() hook and the new Actions API, which pairs perfectly
with Next.js Server Actions for async state management without useEffect
spaghetti.

// A Server Component that fetches its own data
// app/dashboard/analytics/page.tsx
import { fetchAnalytics } from '@/lib/data'

export default async function AnalyticsPage() {
  // This runs ONLY on the server, zero client bundle cost
  const data = await fetchAnalytics()

  return (
    <section>
      <h2>Analytics Overview</h2>
      <MetricsGrid data={data} />
    </section>
  )
}

The impact on bundle size is real. Heavy libraries like charting tools,
markdown parsers, or date utilities used only in RSC never ship to the browser.
Your Lighthouse scores will thank you.

5. The New Caching Model: Opt-In Instead of Opt-Out

One of the most controversial changes in Next.js 15 was flipping the caching
defaults. Previously, fetch() requests, GET Route Handlers, and client
navigations were cached by default, catching many developers off guard.

Now everything is uncached by default. You opt in explicitly, which makes
caching behavior predictable and transparent.

// Uncached by default in Next.js 15+
const res = await fetch('https://api.example.com/posts')

// Opt in to caching
const res = await fetch('https://api.example.com/posts', {
  next: { revalidate: 3600 } // Cache for 1 hour
})

// Force cache
const res = await fetch('https://api.example.com/config', {
  cache: 'force-cache'
})

This is a breaking change from Next.js 14 behavior, so if you are migrating,
audit your fetch calls and Route Handlers carefully. The new model is more
predictable and far easier to reason about in production.

6. TypeScript-First Development with `next.config.ts`

A small but beloved quality-of-life improvement: your Next.js config file can
now be written in TypeScript with full type checking and IDE autocompletion.

// next.config.ts
import type { NextConfig } from 'next'

const config: NextConfig = {
  experimental: {
    ppr: true,
  },
  images: {
    formats: ['image/avif', 'image/webp'],
    remotePatterns: [
      {
        protocol: 'https',
        hostname: 'cdn.yourdomain.com',
      },
    ],
  },
}

export default config

No more guessing at config option names. TypeScript surfaces errors at write
time, not at build time.

7. Edge Functions and the Rise of Global-First Architecture

Next.js middleware running at the edge is no longer experimental territory. It
is a production pattern adopted by teams that need authentication,
geolocation-based routing, and A/B testing to execute in under 10ms, globally.

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const country = request.geo?.country ?? 'US'

  // Route Indian users to localized pricing
  if (country === 'IN' && request.nextUrl.pathname === '/pricing') {
    return NextResponse.redirect(new URL('/pricing/in', request.url))
  }

  return NextResponse.next()
}

export const config = {
  matcher: ['/pricing'],
}

Edge middleware executes before the cache, giving you fine-grained control over
personalization without sacrificing static performance.

8. Developer Experience Upgrades Worth Knowing

Beyond the headline features, Next.js 15 and 16 ship several DX improvements
that quietly make your day better:

Static Route Indicator: A visual badge in the browser during development
shows whether a route is static or dynamic. No more guessing or checking build
output.

Better Hydration Error Messages: Hydration mismatches now include
source-level context pointing you directly to the component causing the issue,
not just a cryptic stack trace.

AVIF Image Support: The next/image component now supports AVIF by default,
delivering 50%+ smaller images versus JPEG with no extra work from you.

Async Request APIs: headers(), cookies(), params, and searchParams
are now async, aligned with the server rendering model and ready for future
optimizations.

Quick Reference: Next.js 14 vs 15 vs 16

Feature	Next.js 14	Next.js 15	Next.js 16
React Version	React 18	React 19 RC	React 19 Stable
Turbopack	Dev Beta	Dev Stable	Dev Stable + Build in progress
Build Speed	Baseline	2 to 3x faster	Further improved
Bundle Size	Baseline	10 to 15% smaller	Smaller still
Server Actions	Stable	Enhanced + Secure	Full error handling
Partial Prerendering	Experimental	Stable (opt-in)	Stable (production)
Caching Default	Aggressive	Opt-in	Opt-in
TypeScript Config	No	Yes	Yes
Image Formats	WebP	WebP + AVIF	WebP + AVIF

What You Should Be Building With Today

Here is an honest summary of what to actually use in production right now:

Use today:

Turbopack in development (zero config, real gains)
Server Actions for forms and mutations
React Server Components for data-heavy pages
The new opt-in caching model for fresh, predictable data
TypeScript config files for type-safe configuration

Adopt with care:

PPR on high-traffic content pages (stable, but test your streaming setup)
Edge Middleware for auth and geo-routing (excellent performance, narrow use case)

Keep watching:

Turbopack for production builds (coming later in 2026)
React Compiler integration (optional but promising for memoization)

Final Thoughts

Next.js in 2026 is a fundamentally different tool than it was two years ago. The
framework has grown from an opinionated React wrapper into a complete full-stack
platform with rendering strategies, server logic, edge compute, and bundling all
tightly integrated.

Whether you are a developer exploring these features for the first time or a
tech lead planning to scale your team, the investment in understanding Next.js
deeply pays real dividends. The gap between teams that understand RSC, PPR, and
Server Actions and those who do not is showing up directly in Core Web Vitals
scores, bundle sizes, and developer velocity.

Start with Turbopack today. Migrate your mutations to Server Actions. Experiment
with PPR on your most-visited dynamic pages. The tools are stable. The patterns
are proven. There has never been a better time to go deep on Next.js.

What Next.js feature has changed the way you build the most? Drop it in the
comments below.

If this post helped you, consider following for more practical deep-dives on
Next.js, React, and modern web architecture.

Stop Writing Slow Python: 5 Performance Mistakes That Are Killing Your App (With Fixes)

Emma Schmidt — Wed, 20 May 2026 05:06:01 +0000

Every Python developer has been there. Your app works fine locally, then hits production and suddenly it is crawling. You open the profiler and realize the bottleneck is not your database or your network.

It is your own Python code.

In this post, I will walk through 5 real-world Python performance mistakes I see constantly, even in senior developers code, and show you exactly how to fix them with benchmarks included.

If you are a solo developer, a team lead, or someone looking to Hire Python Developers for your next project, understanding these patterns will help you write better code and ask better interview questions.

Mistake 1: Using a List When You Should Use a Set

This is the most common performance killer I see in production codebases.

# BAD: O(n) lookup every time
user_ids = [1, 2, 3, 4, 5, ..., 1_000_000]

if target_id in user_ids:
    print("Found!")

# GOOD: O(1) lookup
user_ids = {1, 2, 3, 4, 5, ..., 1_000_000}

if target_id in user_ids:
    print("Found!")

Benchmark on 1 million items:

Method	Lookup Time
List	~52ms
Set	~0.00004ms

Sets use hash tables internally. For membership checks, they are over 1000x faster than lists. This is one of the simplest swaps you can make and it has an immediate impact.

Mistake 2: String Concatenation Inside a Loop

# BAD: Creates a new string object on every iteration
result = ""
for word in words:
    result += word + " "

Every += on a string allocates new memory. For 10,000 words, that is 10,000 memory allocations happening back to back.

# GOOD: Join at the end with a single allocation
result = " ".join(words)

Real difference on 100,000 words:
Concatenation: 3.87 seconds
join(): 0.012 seconds

This is a simple habit to build. Whenever you are building a string from a loop, reach for join() instead.

Mistake 3: Not Using Generators for Large Data

Most developers load everything into a list first without thinking about memory:

# BAD: Loads ALL records into RAM at once
def get_all_orders():
    return [process(order) for order in db.fetch_all()]

If each order is 1KB and you have 10 million orders, that is 10GB of RAM consumed instantly.

# GOOD: Generator processes one item at a time
def get_all_orders():
    for order in db.fetch_all():
        yield process(order)

# Usage stays exactly the same
for order in get_all_orders():
    send_email(order)

Memory usage comparison:
List comprehension: ~9.5 GB RAM
Generator: ~0.0001 GB RAM

Generators are one of the most underused features in Python. They let you work with infinite or very large datasets without blowing up your memory. If you are processing files, database rows, or API responses in batches, generators should be your default approach.

Mistake 4: Ignoring lru_cache for Repeated Computations

This one is extremely common in web applications where the same function gets called repeatedly with the same arguments:

# BAD: Called 10,000 times with the same args? Computed 10,000 times.
def get_user_permissions(user_id: int) -> list:
    return db.query(f"SELECT * FROM permissions WHERE user_id={user_id}")

# GOOD: Computed once, cached after that
from functools import lru_cache

@lru_cache(maxsize=512)
def get_user_permissions(user_id: int) -> list:
    return db.query(f"SELECT * FROM permissions WHERE user_id={user_id}")

For API endpoints hitting the same expensive function repeatedly, lru_cache can drop response time from 800ms to under 2ms.

Quick tips:

Use @cache in Python 3.9+ for unbounded caching
Use ttl_cache from the cachetools library when you need time-based expiry
Always think about cache invalidation. If the underlying data can change, you need a strategy to clear the cache

Mistake 5: Blocking the Event Loop in Async Code

This mistake catches async Python developers off guard. You adopt asyncio to handle concurrent requests, but then accidentally block the entire event loop:

# BAD: requests is synchronous and blocks the event loop
import asyncio
import requests

async def fetch_data(url: str):
    response = requests.get(url)  # This blocks everything
    return response.json()

When this runs, every other coroutine in your application freezes until that HTTP call completes. You have gained nothing from using async.

# GOOD: Use httpx or aiohttp which are async-native
import asyncio
import httpx

async def fetch_data(url: str):
    async with httpx.AsyncClient() as client:
        response = await client.get(url)
        return response.json()

Why this matters in real apps:

If your async server is handling 500 concurrent requests and one blocking call takes 2 seconds, all 500 requests are frozen for those 2 seconds. With proper async IO, they all make progress simultaneously.

Other common blocking calls to watch out for:

open() for file reading without aiofiles
time.sleep() instead of await asyncio.sleep()
Any CPU-heavy computation inside an async function without offloading to a thread pool

Putting It All Together

Here is a real-world function that combines several of these lessons:

import asyncio
import httpx
from functools import lru_cache

# Cache the allowed user IDs so we do not hit DB repeatedly
@lru_cache(maxsize=1)
def get_allowed_user_ids() -> frozenset:
    ids = db.query("SELECT id FROM allowed_users")
    return frozenset(row["id"] for row in ids)  # frozenset is hashable and fast

# Use a generator to stream results instead of loading all at once
def stream_user_events(user_id: int):
    for event in db.query(f"SELECT * FROM events WHERE user_id={user_id}"):
        yield event

# Use async HTTP calls instead of blocking ones
async def notify_users(user_ids: list[int]):
    allowed = get_allowed_user_ids()
    valid_ids = {uid for uid in user_ids if uid in allowed}  # set comprehension

    async with httpx.AsyncClient() as client:
        tasks = [client.post(f"/notify/{uid}") for uid in valid_ids]
        await asyncio.gather(*tasks)

In under 20 lines, this function uses sets for fast lookup, lru_cache to avoid repeated DB calls, a set comprehension for filtering, and async HTTP calls for non-blocking notifications.

Summary Table

Mistake	Fix	Impact
List for membership checks	Use a set	1000x faster lookups
String concatenation in loops	Use join()	Up to 300x faster
List comprehension on large data	Use a generator	Up to 95% less RAM
Repeated expensive function calls	Use lru_cache	Near-zero repeat cost
Blocking calls in async code	Use async libraries	True concurrency restored

Final Thoughts

Python is not slow by nature. Most performance problems come down to choosing the wrong data structure, loading too much into memory at once, or misunderstanding how async IO actually works.

These five patterns appear in almost every large Python codebase I have worked in. Fixing them does not require switching frameworks or rewriting your app. It requires understanding what your code is actually doing under the hood.

If you are scaling a Python application and your team is stretched thin, it might also be the right time to Hire Python Developers who already understand these patterns at a deeper level. The difference between a developer who knows that a list lookup is O(n) and one who does not can mean thousands of dollars in cloud costs saved every month.

Discussion

Which of these mistakes have you run into in production?
Have you found other patterns that caused unexpected slowdowns?
Are you using generators in your current project?

Drop your experience in the comments. I read and reply to all of them.

Why Your React App Lags After Integrating AI Chatbots (And How to Debug It)

Emma Schmidt — Tue, 19 May 2026 05:03:49 +0000

Integrating an AI chatbot into a React application can feel like a major win until users start complaining about slow responses, frozen UIs, and janky scroll behavior. If you are building a product that relies on conversational AI, you need to Hire React.js Developers who understand not just React fundamentals but also the performance pitfalls that come with streaming APIs,large state trees, and real-time rendering. These issues are not always obvious at first glance,but with the right debugging strategies, you can track down the root cause and fix it before it hurts your user experience.

This guide breaks down the most common reasons your React app slows down after adding an AI chatbot, walks through real-world examples, and shows you exactly how to diagnose and resolve each problem.

Understanding the Performance Problem

When you add an AI chatbot to a React app, you introduce a specific combination of challenges that most React apps never face at the same time:

Streaming data: Tokens arrive one by one, triggering state updates dozens of times per second.
Long message history: Conversations grow over time, and rendering hundreds of messages becomes expensive.
Rich content: Markdown, syntax-highlighted code, and tables require heavy parsing and rendering.
Real-time UX expectations: Users expect immediate feedback, low latency, and smooth scrolling.

Each of these factors alone can slow an app down. Combined, they can make your app nearly unusable. The good news is that every one of these problems has a clear solution once you know what to look for.

Cause 1: Uncontrolled Re-renders from Streaming State Updates

The Problem

When you stream AI responses token by token using the OpenAI API or a similar provider, you typically update a state variable on every token. If your component tree is not optimized, this causes the entire chat UI to re-render 10 to 30 times per second.

Example of the Problem

// Bad approach: updating state on every token causes cascading re-renders
function ChatWindow() {
  const [messages, setMessages] = useState([]);
  const [streamingText, setStreamingText] = useState('');

  const streamResponse = async (prompt) => {
    const response = await fetch('/api/chat', { method: 'POST', body: JSON.stringify({ prompt }) });
    const reader = response.body.getReader();
    const decoder = new TextDecoder();

    while (true) {
      const { done, value } = await reader.read();
      if (done) break;
      const chunk = decoder.decode(value);
      setStreamingText((prev) => prev + chunk); // fires re-render on every token
    }
  };

  return (

       {/* re-renders on every token */}


  );
}

Every call to setStreamingText re-renders ChatWindow, which re-renders MessageList, even though the existing messages have not changed.

The Fix

Split the streaming message out of the main message list and memoize the message list component.

import { memo, useState, useRef } from 'react';

const MessageList = memo(({ messages }) => {
  return (

      {messages.map((msg) => (

      ))}

  );
});

function StreamingBubble({ textRef }) {
  const [text, setText] = useState('');

  useEffect(() => {
    textRef.current = setText;
  }, [textRef]);

  return {text};
}

function ChatWindow() {
  const [messages, setMessages] = useState([]);
  const streamSetterRef = useRef(null);

  const streamResponse = async (prompt) => {
    const response = await fetch('/api/chat', { method: 'POST', body: JSON.stringify({ prompt }) });
    const reader = response.body.getReader();
    const decoder = new TextDecoder();
    let fullText = '';

    while (true) {
      const { done, value } = await reader.read();
      if (done) break;
      const chunk = decoder.decode(value);
      fullText += chunk;
      streamSetterRef.current?.(fullText); // only StreamingBubble re-renders
    }

    setMessages((prev) => [...prev, { id: Date.now(), role: 'assistant', content: fullText }]);
  };

  return (




  );
}

Now only StreamingBubble re-renders during streaming. MessageList stays frozen until the stream completes.

Cause 2: Blocking the Main Thread with Large Payloads

The Problem

AI responses can be several thousand tokens long. When the response finishes, parsing the full JSON payload, processing markdown, and updating the DOM all happen synchronously on the main thread, causing a visible freeze.

Example of the Problem

// This can freeze the UI for 200-500ms on large responses
const handleResponse = async () => {
  const data = await fetchLargeAIResponse(); // returns 4000 tokens
  const parsed = parseMarkdown(data.content); // synchronous, heavy
  setMessages((prev) => [...prev, { ...data, parsed }]);
};

The Fix

Use startTransition from React 18 to mark the heavy state update as non-urgent.

import { startTransition, useState } from 'react';

const handleResponse = async () => {
  const data = await fetchLargeAIResponse();

  startTransition(() => {
    setMessages((prev) => [...prev, data]);
  });
};

For CPU-intensive parsing, offload to a Web Worker:

// worker.js
self.onmessage = (e) => {
  const { markdown } = e.data;
  const result = parseMarkdown(markdown); // runs off the main thread
  self.postMessage(result);
};

// ChatWindow.jsx
const worker = new Worker(new URL('./worker.js', import.meta.url));

worker.onmessage = (e) => {
  startTransition(() => {
    setMessages((prev) => [...prev, { role: 'assistant', content: e.data }]);
  });
};

const handleResponse = async (rawText) => {
  worker.postMessage({ markdown: rawText });
};

Cause 3: Memory Leaks from Uncleaned Subscriptions and Streams

The Problem

If a user sends a message and then navigates away or closes the chat, the streaming fetch request continues running in the background. When it tries to update state on an unmounted component, you get memory leaks and potential errors.

Example of the Problem

// Memory leak: no cleanup when component unmounts
useEffect(() => {
  const streamResponse = async () => {
    const response = await fetch('/api/chat');
    const reader = response.body.getReader();

    while (true) {
      const { done, value } = await reader.read();
      if (done) break;
      setStreamingText((prev) => prev + decode(value)); // crashes if unmounted
    }
  };

  streamResponse();
}, []);

The Fix

Use an AbortController to cancel the fetch when the component unmounts.

useEffect(() => {
  const controller = new AbortController();

  const streamResponse = async () => {
    try {
      const response = await fetch('/api/chat', { signal: controller.signal });
      const reader = response.body.getReader();

      while (true) {
        const { done, value } = await reader.read();
        if (done) break;
        setStreamingText((prev) => prev + decode(value));
      }
    } catch (err) {
      if (err.name !== 'AbortError') {
        console.error('Stream error:', err);
      }
    }
  };

  streamResponse();

  return () => {
    controller.abort(); // clean up on unmount
  };
}, []);

Cause 4: Improper Message List Virtualization

The Problem

A long conversation with 200 or more messages renders all message DOM nodes at once. Even if most messages are off-screen, React still mounts and maintains them, consuming memory and slowing scroll performance.

The Fix

Use react-window to only render messages that are currently visible.

npm install react-window

import { VariableSizeList as List } from 'react-window';
import { useRef, useCallback } from 'react';

const ESTIMATED_ROW_HEIGHT = 80;

function VirtualMessageList({ messages }) {
  const listRef = useRef(null);
  const rowHeights = useRef({});

  const getItemSize = (index) => rowHeights.current[index] || ESTIMATED_ROW_HEIGHT;

  const setRowHeight = useCallback((index, height) => {
    if (rowHeights.current[index] !== height) {
      rowHeights.current[index] = height;
      listRef.current?.resetAfterIndex(index);
    }
  }, []);

  const Row = ({ index, style }) => {
    const rowRef = useRef(null);

    useEffect(() => {
      if (rowRef.current) {
        setRowHeight(index, rowRef.current.getBoundingClientRect().height);
      }
    }, [index, messages[index].content]);

    return (





    );
  };

  return (

      {Row}

  );
}

Cause 5: Inefficient Context API Usage

The Problem

Many developers store the entire chat state in a single React Context object. When any part of that state changes (for example, a streaming token update), every component that consumes the context re-renders even if it only needs the user's name or the input field value.

Example of the Problem

// Bad: single monolithic context
const ChatContext = createContext();

function ChatProvider({ children }) {
  const [messages, setMessages] = useState([]);
  const [isLoading, setIsLoading] = useState(false);
  const [userProfile, setUserProfile] = useState({});
  const [inputValue, setInputValue] = useState('');

  return (

      {children}

  );
}

// Re-renders on every token because it consumes ChatContext
function UserAvatar() {
  const { userProfile } = useContext(ChatContext);
  return ;
}

The Fix

Split context into separate, focused providers.

const MessagesContext = createContext();
const UIContext = createContext();
const UserContext = createContext();

function ChatProvider({ children }) {
  const [messages, setMessages] = useState([]);
  const [isLoading, setIsLoading] = useState(false);
  const [userProfile] = useState({ name: 'Alex', avatar: '/avatar.png' });
  const [inputValue, setInputValue] = useState('');

  return (



          {children}



  );
}

// Now only re-renders when userProfile changes
function UserAvatar() {
  const userProfile = useContext(UserContext);
  return ;
}

Cause 6: Markdown and Code Block Rendering Overhead

The Problem

AI responses frequently contain markdown with code blocks, tables, and lists. Parsing and rendering this on every re-render during streaming is expensive. Libraries like react-markdownwith rehype-highlight can take 50 to 150ms per render on large responses.

The Fix

Defer markdown rendering until streaming is complete, and memoize the rendered output.

import ReactMarkdown from 'react-markdown';
import { Prism as SyntaxHighlighter } from 'react-syntax-highlighter';
import { memo, useMemo } from 'react';

const RenderedMessage = memo(({ content, isStreaming }) => {
  const renderedContent = useMemo(() => {
    if (isStreaming) {
      return {content};
    }

    return (

                {String(children).replace(/\n$/, '')}

            ) : (

                {children}

            );
          },
        }}
      >
        {content}

    );
  }, [content, isStreaming]);

  return {renderedContent};
});

Cause 7: Network Latency Misattributed as UI Lag

The Problem

Sometimes what feels like UI lag is actually just slow API response time. Developers often spend hours optimizing React code when the real bottleneck is a cold API endpoint or a missing streaming setup on the server.

How to Distinguish Them

Open Chrome DevTools and check the Network tab:

If the request shows a long Waiting (TTFB) time → the server is slow.
If TTFB is fast but the page still feels sluggish → it is a rendering issue.

The Fix for Perceived Latency

Implement optimistic UI updates and loading skeletons to make the app feel immediate.

function ChatInput({ onSend }) {
  const [input, setInput] = useState('');

  const handleSubmit = () => {
    const userMessage = { id: Date.now(), role: 'user', content: input };

    setMessages((prev) => [
      ...prev,
      userMessage,
      { id: 'loading', role: 'assistant', content: null, isLoading: true },
    ]);

    setInput('');
    onSend(input);
  };

  return (

      <input value={input} onChange={(e) => setInput(e.target.value)} placeholder="Ask anything..." />
      Send

  );
}

function MessageBubble({ message }) {
  if (message.isLoading) {
    return (

    );
  }

  return {message.content};
}

How to Use React DevTools Profiler to Debug Lag

Step 1: Install React DevTools
Install the Chrome or Firefox extension from the browser's extension store.

Step 2: Open the Profiler Tab
Open DevTools, navigate to the "Profiler" tab, and click the record button.

Step 3: Trigger the Lag
Send a message to your chatbot and let it stream a response.

Step 4: Stop Recording and Inspect

Signal	Meaning
A component rendering hundreds of times	Uncontrolled re-renders from state updates
Long render durations (50ms+) on a single component	Heavy computation inside render — move to `useMemo`
The same component in every frame	Subscribed to a context or state that updates too often
Many components rendering when one thing changed	Missing `memo` or incorrect dependency arrays

Step 5: Use the "Why did this render?" Feature
In Profiler settings, enable "Record why each component rendered." This shows exactly which
prop or state change triggered each render.

Performance Checklist

[ ] Streaming text updates only re-render the active streaming bubble, not the full message list
[ ] memo is applied to MessageList and MessageBubble
[ ] useCallback is used for event handlers passed as props
[ ] startTransition wraps state updates triggered after the stream completes
[ ] An AbortController cleans up open streams on component unmount
[ ] Message history longer than 50 items uses a virtualized list
[ ] Chat state is split into multiple contexts or managed with Zustand / Jotai
[ ] Markdown parsing is skipped or deferred during active streaming
[ ] A loading skeleton or typing indicator appears immediately after the user sends a message
[ ] React DevTools Profiler has been used to confirm no unexpected re-renders exist

Conclusion

AI chatbot integration is one of the most performance-intensive features you can add to a React application. The combination of streaming updates, long message lists, rich content rendering,
and real-time UX expectations creates challenges that standard React best practices do not fully address on their own.

The fixes are not complicated once you understand the root cause:

Isolate streaming updates to dedicated components
Memoize stable parts of your UI
Virtualize long lists
Split your context
Defer expensive rendering
Always use the Profiler to verify your changes actually help

By applying the patterns in this guide, you will turn a laggy chatbot integration into a smooth,production-grade experience that users actually enjoy.

Build Autonomous AI Agents with Python in 2026 (The Complete Guide Developers Are Obsessed With)

Emma Schmidt — Fri, 15 May 2026 12:58:18 +0000

Introduction

The Python ecosystem just unlocked a new era and every developer is rushing to get ahead of it.AI Agents are no longer a research concept, they are production-ready, and Python is the undisputed language powering them. Whether you are an indie hacker building your first autonomousworkflow or a tech lead looking to Hire Python Developers who can architect multi-agent systems, this guide is exactly what you need right now. We will cover everything from the basics
to a full working example you can ship today.

What Exactly Is an AI Agent?

An AI agent is a system that uses a Large Language Model (LLM) as its reasoning engine to decide what actions to take, execute those actions using tools, observe the results, and loop until a goal is completed. Unlike a simple chatbot that just responds to messages, an agent thinks,acts, and adapts.

Think of it like this:

LLM alone = a brilliant brain with no hands
AI Agent = that same brain with access to tools, memory, and the ability to plan

Why Python Is the #1 Choice for AI Agents in 2026

Python dominates this space for very concrete reasons:

The best frameworks (LangChain, LangGraph, CrewAI, AutoGen) are Python-first
Seamless integration with OpenAI, Anthropic, Groq, and Ollama APIs
Rich ecosystem for data handling, APIs, and automation
Async support with asyncio makes concurrent agent tasks fast and efficient
Massive community producing tutorials, tools, and open-source agents daily

The Hottest Frameworks Right Now in 2026

1. LangGraph (The Most Powerful)

LangGraph lets you build agents as stateful graphs. Each node is a step, each edge is a decision. It gives you full control over agent logic and is perfect for complex, multi-step workflows.

from langgraph.graph import StateGraph, END
from typing import TypedDict

class AgentState(TypedDict):
    messages: list
    next_step: str

def researcher_node(state: AgentState):
    return {"messages": state["messages"], "next_step": "writer"}

def writer_node(state: AgentState):
    return {"messages": state["messages"], "next_step": END}

graph = StateGraph(AgentState)
graph.add_node("researcher", researcher_node)
graph.add_node("writer", writer_node)
graph.set_entry_point("researcher")
graph.add_edge("researcher", "writer")
graph.add_edge("writer", END)

agent = graph.compile()

2. CrewAI (Best for Multi-Agent Teams)

CrewAI lets you define a crew of specialized agents that collaborate on a shared goal. It is extremely readable and great for teams new to agents.

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Senior Research Analyst",
    goal="Find the latest trends in Python AI tooling",
    backstory="Expert in AI ecosystem research with 10 years experience",
    verbose=True
)

writer = Agent(
    role="Tech Content Writer",
    goal="Write engaging blog posts for developers",
    backstory="Passionate Python developer turned technical writer",
    verbose=True
)

research_task = Task(
    description="Research the top 5 trending Python AI agent frameworks in 2026",
    agent=researcher
)

write_task = Task(
    description="Write a 1000-word dev.to post based on the research",
    agent=writer
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    verbose=2
)

result = crew.kickoff()
print(result)

3. AutoGen (Best for Conversational Agents)

Microsoft's AutoGen is perfect when you want agents to talk to each other and solve problems through conversation. It is great for coding assistants and problem-solving pipelines.

Build a Full Working AI Agent from Scratch (Step by Step)

Step 1: Install Dependencies

pip install openai langchain langchain-openai duckduckgo-search python-dotenv

Step 2: Set Up Your Environment

# .env file
OPENAI_API_KEY=your_key_here

Step 3: Define Your Tools

from langchain.tools import DuckDuckGoSearchRun
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_openai_functions_agent
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
from dotenv import load_dotenv

load_dotenv()

search = DuckDuckGoSearchRun()
tools = [search]

Step 4: Create the Agent

llm = ChatOpenAI(model="gpt-4o", temperature=0)

prompt = ChatPromptTemplate.from_messages([
    ("system", """You are an expert research agent. Your job is to:
    1. Search for information on the given topic
    2. Synthesize findings into a clear, structured report
    3. Always cite the key points you found
    Be thorough but concise."""),
    MessagesPlaceholder(variable_name="chat_history", optional=True),
    ("human", "{input}"),
    MessagesPlaceholder(variable_name="agent_scratchpad"),
])

agent = create_openai_functions_agent(llm, tools, prompt)
agent_executor = AgentExecutor(agent=agent, tools=tools, verbose=True)

Step 5: Run It

result = agent_executor.invoke({
    "input": "What are the top trending Python libraries for AI agents in 2026?"
})

print(result["output"])

Adding Memory to Your Agent

from langchain.memory import ConversationBufferWindowMemory

memory = ConversationBufferWindowMemory(
    memory_key="chat_history",
    k=10,
    return_messages=True
)

agent_executor_with_memory = AgentExecutor(
    agent=agent,
    tools=tools,
    memory=memory,
    verbose=True
)

result1 = agent_executor_with_memory.invoke({"input": "What is LangGraph?"})
result2 = agent_executor_with_memory.invoke({"input": "How does it compare to CrewAI?"})

Async Agents: Handle Multiple Tasks Concurrently

import asyncio

async def run_agent_task(task_description: str, agent_executor) -> str:
    result = await agent_executor.ainvoke({"input": task_description})
    return result["output"]

async def run_parallel_agents():
    tasks = [
        "Research Python async frameworks in 2026",
        "Research top Python AI libraries in 2026",
        "Research Python packaging tools in 2026",
    ]

    results = await asyncio.gather(*[
        run_agent_task(task, agent_executor) for task in tasks
    ])

    for i, result in enumerate(results):
        print(f"\n--- Task {i+1} Result ---")
        print(result)

asyncio.run(run_parallel_agents())

Real-World Use Cases Shipping in Production Right Now

Use Case	Framework Used	Key Tools
Automated code review	LangGraph + GPT-4o	GitHub API, AST parser
Customer support automation	CrewAI	CRM API, vector search
Data analysis pipelines	AutoGen	Pandas, SQL, Matplotlib
Content generation workflows	LangGraph	Search, CMS API
Competitive research bots	CrewAI	Web scraping, summarization
DevOps incident response	LangGraph	Monitoring APIs, Slack

Common Mistakes Developers Make (And How to Avoid Them)

Mistake 1: No retry logic on tool failures

from tenacity import retry, stop_after_attempt, wait_exponential

@retry(stop=stop_after_attempt(3), wait=wait_exponential(multiplier=1, min=2, max=10))
def reliable_search(query: str) -> str:
    return search.run(query)

Mistake 2: Infinite loops with no exit condition

agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    max_iterations=10,
    early_stopping_method="generate"
)

Mistake 3: Storing full conversation history in memory

Use a sliding window or summarization memory instead of buffering everything.

Mistake 4: Not streaming responses

async for chunk in agent_executor.astream({"input": "Tell me about AI agents"}):
    if "output" in chunk:
        print(chunk["output"], end="", flush=True)

What Is Next: Trends to Watch in Python Agents for 2026

Model Context Protocol (MCP): A new standard for connecting agents to tools and data sources. Already supported by major frameworks.
Local LLMs + Agents: Running agents fully offline with Ollama + LangGraph is now production-viable for privacy-sensitive use cases.
Agent Observability: Tools like LangSmith and Arize Phoenix are becoming essential for debugging and monitoring agents in prod.
Voice-Powered Agents: Combining real-time speech-to-text with agent pipelines is the next frontier for user interfaces.

Final Thoughts

AI Agents with Python are not just hype. They are reshaping how software gets built and what is possible for a single developer or a small team to ship. The frameworks are mature, the ecosystem is rich, and the demand is only going up in 2026.

Start with one of the examples above, get something running locally today, and then push itfurther. The developers who understand how to build, orchestrate, and deploy AI agents are the ones who will define what software looks like for the rest of this decade.

Drop a comment below with what you are building. I read every single one.

Found this useful? Drop a like, share it with your team, and follow for more deep-dive Python content every week.

Next.js 16 + The React Compiler: The Combo That's Changing Everything in 2026

Emma Schmidt — Thu, 14 May 2026 12:45:58 +0000

If you haven't heard the noise around Next.js 16 and the React Compiler yet, you've been living under a very comfortable rock. In May 2026, this combo is the most talked-about topic across dev Twitter, Reddit threads, and every Discord server worth its salt.

Companies are rushing to Hire Next.js developers who understand this new architecture. And honestly? The gap between developers who get it and those who don't is growing fast. If you are a developer looking to stay relevant, or a team lead trying to future-proof your stack, this post is for you.

Let's break it all down. What changed, why it matters, and how to start using it today.

🚀 What's the Big Deal with the React Compiler?

For years, developers have manually sprinkled useMemo, useCallback, and React.memo across their codebase to prevent unnecessary re-renders. It worked, but it was tedious, error-prone, and cluttered the code.

The React Compiler (now stable and baked into Next.js 16) changes the game entirely. It analyzes your component tree at build time and automatically applies memoization where it's needed.

Before the Compiler (manual pain 😩)

import { useMemo, useCallback } from "react";

function ProductCard({ product, onAddToCart }) {
  const formattedPrice = useMemo(
    () => `$${product.price.toFixed(2)}`,
    [product.price]
  );

  const handleClick = useCallback(() => {
    onAddToCart(product.id);
  }, [onAddToCart, product.id]);

  return (

      {product.name}
      {formattedPrice}
      Add to Cart

  );
}

After the Compiler (clean code 😍)

function ProductCard({ product, onAddToCart }) {
  const formattedPrice = `$${product.price.toFixed(2)}`;

  return (

      {product.name}
      {formattedPrice}
      <button onClick={() => onAddToCart(product.id)}>Add to Cart

  );
}

The compiler handles the optimization automatically. Your code reads like plain JavaScript, and performance doesn't suffer. Instagram has been using this in production and the results speak for themselves.

⚡ Next.js 16: What's Actually New?

1. Turbopack is Now the Default

Next.js 16 ships with Turbopack (the Rust-based bundler) as the default. If you've been using Webpack, you'll notice the difference immediately:

	Webpack	Turbopack
Cold start	~8-12s	~1-2s
HMR update	~800ms	~50ms
Production build	minutes	seconds

To upgrade your existing project:

npx create-next-app@16 my-app
# or upgrade existing:
npm install next@16

2. `use cache` - Granular Caching Control

One of the most developer-requested features is finally here. The new use cache directive lets you control caching at the function, component, or page level, not just the route.

// Cache an entire page
async function ProductsPage() {
  "use cache";
  const products = await fetchProducts();
  return ;
}

// Cache a single expensive function
async function getAnalyticsSummary(userId: string) {
  "use cache";
  // This result is cached individually per userId
  return await db.analytics.summarize(userId);
}

No more wrestling with revalidate options scattered across 10 different files. Caching intent is declared right where the data lives.

3. Server Components Are Now the Default Mental Model

If you're still building everything as Client Components with "use client" at the top of every file, it's time to rethink your architecture.

The rule of thumb in 2026:
📦 Server Component (default)
└── Fetches data, has no interactivity
└── Zero JS sent to browser
└── Great for: layouts, data-heavy pages, SEO content
🖥️ Client Component ("use client")
└── Needs useState, useEffect, event handlers
└── Keep these small and at the leaves of your tree
└── Great for: buttons, forms, carousels, modals

A real-world example showing a blog post page:

// app/blog/[slug]/page.tsx - Server Component (default)
import { LikeButton } from "@/components/LikeButton"; // Client

async function BlogPost({ params }) {
  const post = await getPost(params.slug); // runs on server, no JS to client

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
      {/* Only this tiny island is interactive */}
      <LikeButton postId={post.id} initialLikes={post.likes} />
    </article>
  );
}

The result? Smaller JS bundles, faster Time to First Byte (TTFB), better SEO, without any extra config.

🛠️ Setting Up a Next.js 16 Project in 2026

Here's the stack most teams are shipping with right now:

npx create-next-app@16 my-app \
  --typescript \
  --tailwind \
  --app \
  --turbopack

Recommended additions:

# Database ORM
npm install prisma @prisma/client

# Auth
npm install better-auth

# UI Components
npm install @shadcn/ui

# Type-safe API layer
npm install @trpc/server @trpc/client

Your folder structure will look like this:
my-app/
├── app/
│ ├── layout.tsx <- Root layout (Server Component)
│ ├── page.tsx <- Home page (Server Component)
│ ├── api/
│ │ └── trpc/
│ │ └── route.ts <- tRPC API handler
│ └── dashboard/
│ ├── page.tsx
│ └── loading.tsx <- Streaming loading UI
├── components/
│ ├── ui/ <- Shadcn components
│ └── features/ <- Your feature components
└── lib/
├── db.ts <- Prisma client
└── trpc.ts <- tRPC setup

📊 Real-World Performance Wins

Teams migrating to Next.js 16 with the React Compiler are reporting:

25-40% fewer re-renders out of the box thanks to the React Compiler
Server Components reduce initial JS bundle by 30-60%
Turbopack cuts CI/CD build time by 60-80% on large monorepos
Core Web Vitals scores improved across the board, especially LCP and INP

These aren't synthetic benchmarks. These are numbers from real production migrations happening right now.

🤔 Should You Migrate Today?

If you're starting a new project: Yes, 100%. Use Next.js 16 from day one.

If you have an existing Next.js 14/15 app: Migration is mostly smooth. The Pages Router still works, but plan your App Router transition. The use cache directive and Turbopack are opt-in.

If you're on Create React App (CRA): CRA is effectively deprecated. Move to Next.js 16 or Vite + TanStack Start depending on your needs.

🔮 What's Next?

The direction is clear: less boilerplate, more intent. The React Compiler, Server Components, and smart caching are all moving toward a world where you declare what you want, and the framework figures out how to deliver it efficiently.

The developers who master this mental shift now will be the ones companies are actively looking to hire Next.js developers for in the second half of 2026. The demand is real and job boards are flooded with RSC + Turbopack requirements.

TL;DR

Feature	Why It Matters
React Compiler	Auto-memoization, delete your `useMemo` and `useCallback` clutter
Turbopack (default)	5-10x faster builds and HMR
`use cache` directive	Granular, declarative caching control
Server Components	Smaller bundles, faster pages, better SEO

Next.js 16 isn't just an update. It's a mindset shift. The boilerplate era is ending.

Are you already using Next.js 16 or the React Compiler in production? Drop your experience in the comments. I'd love to hear what's working (and what's not) for your team. 👇

Python Developers in 2026: The Ultimate Survival Guide

Emma Schmidt — Wed, 13 May 2026 06:11:20 +0000

If you are still writing Python the same way you did in 2022, you are leaving
a LOT of performance, clarity, and career growth on the table. Let us fix that today.

Why Python Is Still Dominating in 2026

Python turned 35 years old and it is not slowing down. According to the TIOBE
Index and Stack Overflow Developer Survey 2025, Python has held the 1 spot
for 4 consecutive years. Whether you are looking to Hire Python Developers
for your next big project or you are a developer leveling up your own skills,
understanding what the modern Python ecosystem looks like in 2026 is no longer
optional. It is a requirement.

Here is why Python keeps winning:

AI and ML pipelines run on Python
FastAPI and async frameworks changed backend development forever
Data engineering tools like Polars, DuckDB, and Ibis are Python-first
The new uv package manager made Python project setup blazing fast

If you are a Python developer in 2026, this post is your complete playbook.

1. Stop Using `pip` Alone. Start Using `uv`

uv is the new Rust-based Python package manager that is 10x to 100x faster
than pip. In 2026, most serious Python projects use it.

# Install uv
curl -Lsf https://astral.sh/uv/install.sh | sh

# Create a new project
uv init my-project
cd my-project

# Add a dependency
uv add fastapi

# Run your script
uv run main.py

Compare that to the old way:

# Old way (2022 style)
python -m venv venv
source venv/bin/activate
pip install fastapi
python main.py

uv handles virtual environments, dependencies, and Python versions all in one
tool. Switch now.

2. Type Hints Are Not Optional Anymore

In 2026, untyped Python in production code is a red flag during code reviews.
Here is what modern Python typing looks like:

# Old style (no types - please stop)
def get_user(user_id):
    return {"id": user_id, "name": "John"}


# Modern style with full type hints
from typing import TypedDict

class User(TypedDict):
    id: int
    name: str
    email: str


def get_user(user_id: int) -> User:
    return {"id": user_id, "name": "John", "email": "john@example.com"}

Using Pydantic v2 for Data Validation

from pydantic import BaseModel, EmailStr, Field

class UserCreate(BaseModel):
    name: str = Field(min_length=2, max_length=50)
    email: EmailStr
    age: int = Field(ge=18, le=120)

user = UserCreate(name="Rahul", email="rahul@dev.to", age=25)
print(user.model_dump())
# {'name': 'Rahul', 'email': 'rahul@dev.to', 'age': 25}

try:
    bad_user = UserCreate(name="X", email="not-an-email", age=10)
except Exception as e:
    print(e)

3. Async Python Is the Standard Now

from fastapi import FastAPI
import httpx
import asyncio

app = FastAPI()

@app.get("/github/{username}")
async def get_github_user(username: str):
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}"
        )
        return response.json()


# Parallel API calls
@app.get("/compare/{user1}/{user2}")
async def compare_users(user1: str, user2: str):
    async with httpx.AsyncClient() as client:
        result1, result2 = await asyncio.gather(
            client.get(f"https://api.github.com/users/{user1}"),
            client.get(f"https://api.github.com/users/{user2}")
        )
    return {"user1": result1.json(), "user2": result2.json()}

The asyncio.gather trick fetches both users at the same time, cutting
response time nearly in half.

4. Data Processing in 2026: Polars Over Pandas

Polars is written in Rust and is 5x to 50x faster than Pandas for most
operations.

import polars as pl

result = (
    pl.scan_csv("huge_dataset.csv")
    .filter(pl.col("age") > 25)
    .group_by("city")
    .agg([
        pl.col("salary").mean().alias("avg_salary"),
        pl.col("name").count().alias("total_employees")
    ])
    .sort("avg_salary", descending=True)
    .collect()
)

print(result)

5. Build AI-Powered Apps with Python + LLMs

from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain.chains import RetrievalQA
from langchain.text_splitter import RecursiveCharacterTextSplitter

docs = [
    "Python was created by Guido van Rossum in 1991.",
    "FastAPI is the most popular async web framework in 2026.",
    "Polars replaced Pandas as the go-to data library.",
]

splitter = RecursiveCharacterTextSplitter(chunk_size=200, chunk_overlap=20)
splits = splitter.create_documents(docs)

embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(splits, embeddings)

llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
    llm, retriever=vectorstore.as_retriever()
)

answer = qa_chain.invoke({"query": "Who created Python?"})
print(answer["result"])
# Output: Python was created by Guido van Rossum in 1991.

6. Pattern Matching You Should Know

# Old way: if/elif chains
def handle_command(command):
    if command["type"] == "move":
        return f"Moving to {command['direction']}"
    elif command["type"] == "attack":
        return f"Attacking {command['target']}"
    else:
        return "Unknown command"


# New way: match/case
def handle_command(command: dict) -> str:
    match command:
        case {"type": "move", "direction": direction}:
            return f"Moving to {direction}"
        case {"type": "attack", "target": target}:
            return f"Attacking {target}"
        case {"type": "heal", "amount": amount} if amount > 0:
            return f"Healing {amount} HP"
        case _:
            return "Unknown command"

print(handle_command({"type": "move", "direction": "north"}))
# Moving to north

7. Testing Like a Pro: pytest + Hypothesis

import pytest
from hypothesis import given, strategies as st

def add(a: int, b: int) -> int:
    return a + b

def test_add_positive_numbers():
    assert add(2, 3) == 5

# Property-based testing: runs 100s of cases automatically
@given(st.integers(), st.integers())
def test_add_is_commutative(a, b):
    assert add(a, b) == add(b, a)

@pytest.mark.parametrize("a, b, expected", [
    (1, 2, 3),
    (0, 0, 0),
    (-1, 1, 0),
    (100, 200, 300),
])
def test_add_parametrized(a, b, expected):
    assert add(a, b) == expected

8. Modern Python Project Structure

my-project/
│
├── src/
│   └── my_project/
│       ├── __init__.py
│       ├── main.py
│       ├── api/
│       │   ├── routes.py
│       │   └── middleware.py
│       ├── services/
│       │   └── user_service.py
│       └── models/
│           └── user.py
│
├── tests/
│   ├── unit/
│   └── integration/
│
├── pyproject.toml
├── .python-version
└── README.md

[project]
name = "my-project"
version = "0.1.0"
requires-python = ">=3.13"
dependencies = [
    "fastapi>=0.115.0",
    "pydantic>=2.0.0",
    "polars>=1.0.0",
    "httpx>=0.27.0",
]

[tool.ruff]
line-length = 88

9. Ruff Replaced Black + Flake8

uv add --dev ruff
ruff format .
ruff check --fix .

10. Python Developer Roadmap 2026

Level	Skills
Beginner	Python basics, OOP, type hints, pytest
Intermediate	FastAPI, async/await, Pydantic, Docker
Advanced	Polars, LLM integration, Rust extensions, uv
Expert	CPython contributions, building libs, distributed systems

Quick Cheat Sheet

# 1. Walrus operator
if (n := len(some_list)) > 10:
    print(f"List is too long ({n} elements)")

# 2. Dataclass with slots
from dataclasses import dataclass

@dataclass(slots=True, frozen=True)
class Point:
    x: float
    y: float

# 3. tomllib built-in
import tomllib
with open("pyproject.toml", "rb") as f:
    config = tomllib.load(f)

# 4. Self type hint
from typing import Self

class Builder:
    def set_name(self, name: str) -> Self:
        self.name = name
        return self

Conclusion

Python in 2026 is faster, safer, and more powerful than ever. The developers
who thrive are the ones who:

Embrace modern tooling (uv, ruff, pyproject.toml)
Write typed, async-first code
Use Polars for data and Pydantic for validation
Integrate AI tools into their workflow
Test with pytest and hypothesis

The Python ecosystem has never been this good. There has never been a better
time to be a Python developer.

What is your favorite Python tool or feature in 2026? Drop it in the comments!

Found this useful? Drop a like and follow for more Python content every week.

AI Agents in Next.js: How Developers Are Moving From Writing Code to Orchestrating Agents in 2026

Emma Schmidt — Tue, 12 May 2026 04:48:35 +0000

Introduction

The way developers build Next.js applications has fundamentally changed in 2026.
It is no longer just about writing components, setting up API routes, or
configuring the App Router. If you are a solo developer or a business looking
to Hire Next.js Developers, the skill set has expanded far beyond
traditional coding. Today, the most productive Next.js teams are not writing
every line of code. They are orchestrating AI agents that plan, build, test,
and ship features autonomously. This guide covers exactly how that works,
with real patterns and production-ready code you can use today.

What Is an AI Agent and Why Does It Matter for Next.js?

An AI agent is not a chatbot. It is a system that:

Reads your codebase and understands the context
Plans a sequence of steps to complete a task
Executes those steps autonomously across multiple files
Runs tests, catches failures, and self-corrects
Loops until the task is done or it needs your approval

In a Next.js project, this means an agent can scaffold an entire feature,
from the Server Component down to the Server Action and the database query,
without you writing a single line manually.

The New Developer Role: Orchestrator, Not Author

The shift happening right now across Next.js teams looks like this:

Before 2026
Developer writes code -> Reviews code -> Ships code

In 2026
Developer defines intent -> Agent writes code -> Developer reviews -> Agent fixes -> Ships

You are not removed from the process. You are elevated. You set the
constraints, review the output, and guide the agent when it goes off track.
The mechanical work is delegated. The architectural thinking stays with you.

Setting Up an AI Agent Pipeline in a Next.js Project

Project Structure for Agent-Friendly Next.js Apps

The first thing you need to do is make your codebase readable by agents.
Agents perform significantly better when your project follows clear,
predictable conventions.
app/
├── (auth)/
│ ├── login/page.tsx
│ └── register/page.tsx
├── (dashboard)/
│ ├── layout.tsx
│ ├── page.tsx
│ └── settings/page.tsx
├── api/
│ └── agents/
│ └── route.ts <- Agent communication endpoint
├── components/
│ ├── ui/ <- Dumb, reusable components
│ └── features/ <- Feature-specific components
├── lib/
│ ├── agents/
│ │ ├── task-planner.ts <- Agent task planning logic
│ │ ├── code-runner.ts <- Agent code execution logic
│ │ └── context-loader.ts <- Loads repo context for agent
│ ├── db.ts
│ └── auth.ts
├── actions/ <- All Server Actions live here
│ ├── user.actions.ts
│ └── task.actions.ts
└── AGENT_CONTEXT.md <- Instructions your agent reads first

The AGENT_CONTEXT.md File

This is one of the most important files in a modern Next.js project.
It tells the agent how your project works, what conventions to follow,
and what it should never do.

# Agent Context for This Project

## Stack
- Next.js 15 App Router
- TypeScript strict mode
- Prisma ORM with PostgreSQL
- **[Tailwind CSS](https://www.zignuts.com/blog/build-modern-ui-react-tailwind?utm_source=seo&utm_medium=backlinks&utm_campaign=seo_referral&utm_id=5)**
- Zod for validation
- Server Actions for all mutations

## Conventions
- All data fetching happens in Server Components
- All mutations happen via Server Actions in /actions
- Never use useEffect for data fetching
- Every Server Action must validate input with Zod
- Database access only in /lib/db.ts and /actions

## File Naming
- Components: PascalCase (UserCard.tsx)
- Actions: kebab-case.actions.ts
- Utilities: camelCase.ts

## What Never to Do
- Never add "use client" to page.tsx files
- Never fetch data inside a Client Component
- Never expose database models directly to the client

Building an AI Agent API Route in Next.js

This is the core of your agent system. The agent sends tasks to this
endpoint, and the endpoint executes them inside your application.

// app/api/agents/route.ts

import { NextRequest, NextResponse } from "next/server";
import { streamText } from "ai";
import { openai } from "@ai-sdk/openai";
import { loadProjectContext } from "@/lib/agents/context-loader";
import { z } from "zod";

const AgentTaskSchema = z.object({
  task: z.string().min(1),
  context: z.string().optional(),
  files: z.array(z.string()).optional(),
});

export async function POST(req: NextRequest) {
  const body = await req.json();
  const parsed = AgentTaskSchema.safeParse(body);

  if (!parsed.success) {
    return NextResponse.json(
      { error: "Invalid task payload", issues: parsed.error.issues },
      { status: 400 }
    );
  }

  const { task, context, files } = parsed.data;
  const projectContext = await loadProjectContext();

  const result = streamText({
    model: openai("gpt-4o"),
    system: `
      You are an expert Next.js developer working on this project.
      Follow all conventions in the AGENT_CONTEXT.md strictly.

      Project Context:
      ${projectContext}

      Rules:
      - Always use TypeScript with strict types
      - Always use Server Components unless interactivity is required
      - Always validate Server Action inputs with Zod
      - Output only the file content requested, nothing else
    `,
    messages: [
      {
        role: "user",
        content: `
          Task: ${task}
          ${context ? `Additional Context: ${context}` : ""}
          ${files ? `Files to consider: ${files.join(", ")}` : ""}
        `,
      },
    ],
    maxTokens: 4000,
  });

  return result.toDataStreamResponse();
}

Context Loader: Teaching the Agent Your Codebase

// lib/agents/context-loader.ts

import fs from "fs/promises";
import path from "path";

export async function loadProjectContext(): Promise<string> {
  const contextPath = path.join(process.cwd(), "AGENT_CONTEXT.md");
  const schemaPath = path.join(process.cwd(), "prisma", "schema.prisma");

  const [agentContext, prismaSchema] = await Promise.allSettled([
    fs.readFile(contextPath, "utf-8"),
    fs.readFile(schemaPath, "utf-8"),
  ]);

  const parts: string[] = [];

  if (agentContext.status === "fulfilled") {
    parts.push(`## Agent Instructions\n${agentContext.value}`);
  }

  if (prismaSchema.status === "fulfilled") {
    parts.push(`## Database Schema\n\`\`\`prisma\n${prismaSchema.value}\n\`\`\``);
  }

  return parts.join("\n\n");
}

export async function loadFileContext(filePaths: string[]): Promise<string> {
  const fileContents = await Promise.all(
    filePaths.map(async (filePath) => {
      try {
        const content = await fs.readFile(
          path.join(process.cwd(), filePath),
          "utf-8"
        );
        return `### ${filePath}\n\`\`\`typescript\n${content}\n\`\`\``;
      } catch {
        return `### ${filePath}\n(file not found)`;
      }
    })
  );

  return fileContents.join("\n\n");
}

Task Planner: Breaking Big Features Into Agent Steps

An agent that tries to do everything in one shot will fail on large features.
The task planner breaks a feature request into smaller, executable steps.

// lib/agents/task-planner.ts

import { generateObject } from "ai";
import { openai } from "@ai-sdk/openai";
import { z } from "zod";

const TaskPlanSchema = z.object({
  feature: z.string(),
  steps: z.array(
    z.object({
      id: z.string(),
      title: z.string(),
      description: z.string(),
      files: z.array(z.string()),
      dependsOn: z.array(z.string()),
      type: z.enum([
        "create_file",
        "modify_file",
        "create_action",
        "create_component",
        "create_api_route",
      ]),
    })
  ),
});

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

export async function planFeature(
  featureRequest: string,
  projectContext: string
): Promise<TaskPlan> {
  const result = await generateObject({
    model: openai("gpt-4o"),
    schema: TaskPlanSchema,
    system: `
      You are a senior Next.js architect.
      Given a feature request, break it into clear, ordered steps.
      Each step must be small enough for a single agent task.
      Follow the project context conventions strictly.

      ${projectContext}
    `,
    prompt: `Plan the implementation steps for this feature: ${featureRequest}`,
  });

  return result.object;
}

The Agent Dashboard: A Real UI to Manage Your Agent

This is a working Next.js page where you can submit tasks to your agent
and watch it build features in real time.

// app/(dashboard)/agent/page.tsx

import { Suspense } from "react";
import AgentTaskForm from "@/components/features/AgentTaskForm";
import AgentTaskHistory from "@/components/features/AgentTaskHistory";
import { getAgentTaskHistory } from "@/actions/agent.actions";

export default async function AgentPage() {
  const history = await getAgentTaskHistory();

  return (
    <div className="max-w-4xl mx-auto py-10 px-4">
      <h1 className="text-2xl font-bold mb-2">AI Agent Dashboard</h1>
      <p className="text-gray-500 mb-8">
        Describe a feature and let the agent build it for you.
      </p>

      <AgentTaskForm />

      <div className="mt-12">
        <h2 className="text-lg font-semibold mb-4">Task History</h2>
        <Suspense fallback={<p>Loading history...</p>}>
          <AgentTaskHistory tasks={history} />
        </Suspense>
      </div>
    </div>
  );
}

// components/features/AgentTaskForm.tsx

"use client";

import { useState } from "react";
import { useCompletion } from "ai/react";

export default function AgentTaskForm() {
  const [files, setFiles] = useState<string>("");

  const { completion, input, handleInputChange, handleSubmit, isLoading, error } =
    useCompletion({
      api: "/api/agents",
      body: {
        files: files.split(",").map((f) => f.trim()).filter(Boolean),
      },
    });

  return (
    <div className="border rounded-xl p-6 bg-white shadow-sm">
      <form onSubmit={handleSubmit} className="space-y-4">
        <div>
          <label className="block text-sm font-medium mb-1">
            Describe the feature or task
          </label>
          <textarea
            value={input}
            onChange={handleInputChange}
            placeholder="e.g. Create a user profile page that shows the user's name, avatar, and recent activity"
            rows={4}
            className="w-full border rounded-lg p-3 text-sm resize-none focus:outline-none focus:ring-2 focus:ring-black"
            required
          />
        </div>

        <div>
          <label className="block text-sm font-medium mb-1">
            Related files (comma-separated, optional)
          </label>
          <input
            type="text"
            value={files}
            onChange={(e) => setFiles(e.target.value)}
            placeholder="app/profile/page.tsx, actions/user.actions.ts"
            className="w-full border rounded-lg p-3 text-sm focus:outline-none focus:ring-2 focus:ring-black"
          />
        </div>

        <button
          type="submit"
          disabled={isLoading}
          className="w-full bg-black text-white py-3 rounded-lg text-sm font-medium disabled:opacity-50"
        >
          {isLoading ? "Agent is working..." : "Run Agent"}
        </button>
      </form>

      {error && (
        <div className="mt-4 p-3 bg-red-50 text-red-700 rounded-lg text-sm">
          {error.message}
        </div>
      )}

      {completion && (
        <div className="mt-6">
          <h3 className="text-sm font-medium mb-2">Agent Output</h3>
          <pre className="bg-gray-950 text-green-400 rounded-lg p-4 text-xs overflow-auto max-h-96 whitespace-pre-wrap">
            {completion}
          </pre>
        </div>
      )}
    </div>
  );
}

Server Actions with Agent-Generated Validation

One of the best patterns for agentic Next.js is having the agent generate
Server Actions that are fully validated. Here is what the agent should
always output when you ask it to create a Server Action.

// actions/user.actions.ts

"use server";

import { z } from "zod";
import { revalidatePath } from "next/cache";
import { db } from "@/lib/db";
import { auth } from "@/lib/auth";

// Agent always generates the schema first
const UpdateUserProfileSchema = z.object({
  name: z.string().min(2).max(100),
  bio: z.string().max(500).optional(),
  avatarUrl: z.string().url().optional(),
});

type UpdateUserProfileInput = z.infer<typeof UpdateUserProfileSchema>;

// Agent always generates typed return types
type ActionResult<T> =
  | { success: true; data: T }
  | { success: false; error: string };

export async function updateUserProfile(
  input: UpdateUserProfileInput
): Promise<ActionResult<{ id: string; name: string }>> {
  const session = await auth();

  if (!session?.user?.id) {
    return { success: false, error: "Unauthorized" };
  }

  const parsed = UpdateUserProfileSchema.safeParse(input);

  if (!parsed.success) {
    return {
      success: false,
      error: parsed.error.errors.map((e) => e.message).join(", "),
    };
  }

  try {
    const user = await db.user.update({
      where: { id: session.user.id },
      data: parsed.data,
      select: { id: true, name: true },
    });

    revalidatePath("/profile");
    return { success: true, data: user };
  } catch (err) {
    console.error("updateUserProfile error:", err);
    return { success: false, error: "Failed to update profile" };
  }
}

Multi-Agent Orchestration: Running Agents in Parallel

For larger features, you can run multiple specialized agents in parallel.
One agent handles the UI, another handles the data layer, and a third
handles testing.

// lib/agents/orchestrator.ts

import { planFeature } from "./task-planner";
import { loadProjectContext, loadFileContext } from "./context-loader";

type AgentRole = "ui" | "data" | "testing";

interface AgentTask {
  role: AgentRole;
  task: string;
  files: string[];
}

interface OrchestrationResult {
  role: AgentRole;
  output: string;
  status: "success" | "failed";
}

async function runAgent(agentTask: AgentTask): Promise<OrchestrationResult> {
  const projectContext = await loadProjectContext();
  const fileContext = await loadFileContext(agentTask.files);

  const systemPrompts: Record<AgentRole, string> = {
    ui: `
      You are a Next.js UI specialist.
      Focus only on Server Components, Client Components, and styling.
      Never touch database logic or Server Actions.
      ${projectContext}
    `,
    data: `
      You are a Next.js data layer specialist.
      Focus only on Server Actions, Prisma queries, and data validation.
      Never touch UI components or styling.
      ${projectContext}
    `,
    testing: `
      You are a Next.js testing specialist.
      Focus only on writing Vitest unit tests and Playwright e2e tests.
      Cover happy paths, error states, and edge cases.
      ${projectContext}
    `,
  };

  try {
    const response = await fetch("/api/agents", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        task: agentTask.task,
        context: fileContext,
        systemPromptOverride: systemPrompts[agentTask.role],
      }),
    });

    const text = await response.text();
    return { role: agentTask.role, output: text, status: "success" };
  } catch {
    return {
      role: agentTask.role,
      output: "Agent failed to complete the task",
      status: "failed",
    };
  }
}

export async function orchestrateFeature(
  featureRequest: string
): Promise<OrchestrationResult[]> {
  const projectContext = await loadProjectContext();
  const plan = await planFeature(featureRequest, projectContext);

  // Group steps by type and run in parallel where possible
  const uiTasks = plan.steps.filter(
    (s) => s.type === "create_component" || s.type === "modify_file"
  );
  const dataTasks = plan.steps.filter(
    (s) => s.type === "create_action" || s.type === "create_api_route"
  );

  const agentTasks: AgentTask[] = [
    {
      role: "ui",
      task: uiTasks.map((t) => t.description).join("\n"),
      files: uiTasks.flatMap((t) => t.files),
    },
    {
      role: "data",
      task: dataTasks.map((t) => t.description).join("\n"),
      files: dataTasks.flatMap((t) => t.files),
    },
    {
      role: "testing",
      task: `Write tests for this feature: ${featureRequest}`,
      files: [...uiTasks, ...dataTasks].flatMap((t) => t.files),
    },
  ].filter((t) => t.task.trim().length > 0);

  // Run all agents in parallel
  const results = await Promise.allSettled(agentTasks.map(runAgent));

  return results
    .filter((r) => r.status === "fulfilled")
    .map((r) => (r as PromiseFulfilledResult<OrchestrationResult>).value);
}

Agent-Generated Testing Pattern

Every feature an agent builds should come with tests. Here is the
pattern your testing agent should always follow for Next.js Server Actions.

// __tests__/actions/user.actions.test.ts

import { describe, it, expect, vi, beforeEach } from "vitest";
import { updateUserProfile } from "@/actions/user.actions";

// Mock dependencies
vi.mock("@/lib/db", () => ({
  db: {
    user: {
      update: vi.fn(),
    },
  },
}));

vi.mock("@/lib/auth", () => ({
  auth: vi.fn(),
}));

vi.mock("next/cache", () => ({
  revalidatePath: vi.fn(),
}));

import { db } from "@/lib/db";
import { auth } from "@/lib/auth";

describe("updateUserProfile", () => {
  beforeEach(() => {
    vi.clearAllMocks();
  });

  it("returns unauthorized when no session exists", async () => {
    vi.mocked(auth).mockResolvedValue(null);

    const result = await updateUserProfile({ name: "John" });

    expect(result.success).toBe(false);
    if (!result.success) {
      expect(result.error).toBe("Unauthorized");
    }
  });

  it("returns validation error for short name", async () => {
    vi.mocked(auth).mockResolvedValue({
      user: { id: "user-1" },
    } as never);

    const result = await updateUserProfile({ name: "A" });

    expect(result.success).toBe(false);
  });

  it("updates the user and returns data on success", async () => {
    vi.mocked(auth).mockResolvedValue({
      user: { id: "user-1" },
    } as never);

    vi.mocked(db.user.update).mockResolvedValue({
      id: "user-1",
      name: "John Doe",
    } as never);

    const result = await updateUserProfile({ name: "John Doe" });

    expect(result.success).toBe(true);
    if (result.success) {
      expect(result.data.name).toBe("John Doe");
    }
  });

  it("returns error when database throws", async () => {
    vi.mocked(auth).mockResolvedValue({
      user: { id: "user-1" },
    } as never);

    vi.mocked(db.user.update).mockRejectedValue(new Error("DB error"));

    const result = await updateUserProfile({ name: "John Doe" });

    expect(result.success).toBe(false);
  });
});

The Agent Guardrails Checklist

Running agents without guardrails is risky. Here is the checklist every
Next.js team should implement before shipping agent-generated code.

Check	What to Verify	Tool
Type Safety	All agent output compiles with strict TypeScript	tsc --noEmit
Lint	No lint errors in generated files	ESLint
Tests Pass	Agent-generated tests are green	Vitest
No Direct DB Access	No Prisma calls outside /actions or /lib	Custom ESLint rule
Zod Validation	Every Server Action validates with Zod	Code review
No Secrets Exposed	No API keys or env vars in client code	Secret scanner
Auth Checked	Every protected Action checks session	Code review

Automated Guardrail Script

// scripts/validate-agent-output.ts

import { execSync } from "child_process";

interface CheckResult {
  name: string;
  passed: boolean;
  output: string;
}

function runCheck(name: string, command: string): CheckResult {
  try {
    const output = execSync(command, { encoding: "utf-8" });
    return { name, passed: true, output };
  } catch (err: unknown) {
    const error = err as { stdout?: string; message?: string };
    return {
      name,
      passed: false,
      output: error.stdout ?? error.message ?? "Unknown error",
    };
  }
}

async function validateAgentOutput() {
  const checks: CheckResult[] = [
    runCheck("TypeScript", "npx tsc --noEmit"),
    runCheck("ESLint", "npx eslint . --ext .ts,.tsx --max-warnings 0"),
    runCheck("Tests", "npx vitest run --reporter=verbose"),
  ];

  const failed = checks.filter((c) => !c.passed);

  if (failed.length > 0) {
    console.error("Agent output validation FAILED:");
    failed.forEach((c) => {
      console.error(`\n${c.name}:\n${c.output}`);
    });
    process.exit(1);
  }

  console.log("All agent output checks passed.");
}

validateAgentOutput();

Key Takeaways

Agents need context — the AGENT_CONTEXT.md file is now as important as your README
Break tasks into steps — a task planner prevents agents from attempting too much at once and failing
Run agents in parallel — UI agents, data agents, and testing agents can work simultaneously on the same feature
Guardrails are not optional — TypeScript, ESLint, and Vitest are your safety net for all agent-generated code
You are the architect — agents handle the mechanical work, but decisions about structure, security, and trade-offs stay with you
Server Actions are agent-friendly — their co-location with components and their explicit validation requirements make them the ideal target for agent-generated code

What Are You Building?

Are you already using AI agents in your Next.js workflow? Have you built
a custom agent pipeline or are you using an off-the-shelf tool? Drop your
setup in the comments. The community would love to hear what is actually
working in production versus what is still just hype.

If this post helped you, drop a like and share it with your team.

React.js Hooks: The Complete Practical Guide for Developers in 2026

Emma Schmidt — Fri, 08 May 2026 12:04:54 +0000

If you want to write modern React applications and you want companies to
Hire React.js developers like you, then mastering Hooks is not optional
anymore. Hooks are the foundation of every React codebase written after
2019.They replaced class components, simplified state management, and
made code reuse actually practical. This guide covers every major Hook
with real working code, clear explanations, and common mistakes to avoid.

What Are React Hooks?

Hooks are functions that let you use React features like state and
lifecycle inside regular function components. Before Hooks existed,
you had to write class components to do any of that.

Here is the same Counter component, written both ways:

Old way using a Class Component:

class Counter extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }

  render() {
    return (
      <div>
        <p>Count: {this.state.count}</p>
        <button onClick={() =>
          this.setState({ count: this.state.count + 1 })
        }>
          Add
        </button>
      </div>
    );
  }
}

Modern way using a Hook:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Add</button>
    </div>
  );
}

Same result. Much less code. Far easier to read and test.

All the Hooks Covered in This Guide

Hook	What It Does
useState	Adds state to a component
useEffect	Runs side effects after render
useContext	Reads shared data without prop drilling
useRef	Accesses DOM elements or stores mutable values
useMemo	Caches expensive calculations
useCallback	Caches a function reference
useReducer	Manages complex state with actions
Custom Hooks	Reuses logic across multiple components

1. useState

useState gives your component memory. It stores a value and
triggers a re-render whenever that value changes.

Syntax:

const [value, setValue] = useState(initialValue);

Real example with a todo list:

import { useState } from "react";

function TodoApp() {
  const [task, setTask] = useState("");
  const [todos, setTodos] = useState([]);

  function addTodo() {
    if (!task.trim()) return;
    setTodos([...todos, task]);
    setTask("");
  }

  return (
    <div>
      <input
        value={task}
        onChange={(e) => setTask(e.target.value)}
        placeholder="Type a task"
      />
      <button onClick={addTodo}>Add</button>
      <ul>
        {todos.map((todo, index) => (
          <li key={index}>{todo}</li>
        ))}
      </ul>
    </div>
  );
}

Most common mistake: Mutating state directly instead of using the
setter function.

// Wrong
todos.push("new task");

// Right
setTodos([...todos, "new task"]);

2. useEffect

useEffect runs code after the component renders. You use it for API
calls, timers, subscriptions, and updating the document title.

Syntax:

useEffect(() => {
  // side effect code
  return () => {
    // cleanup code (optional)
  };
}, [dependencies]);

Real example fetching users from an API:

import { useState, useEffect } from "react";

function UserList() {
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("https://jsonplaceholder.typicode.com/users")
      .then((res) => res.json())
      .then((data) => {
        setUsers(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <p>Loading...</p>;

  return (
    <ul>
      {users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

How the dependency array controls when the effect runs:

useEffect(() => { ... });           // Runs after every render
useEffect(() => { ... }, []);       // Runs once on mount only
useEffect(() => { ... }, [userId]); // Runs when userId changes

Real example with cleanup to prevent memory leaks:

useEffect(() => {
  const timer = setInterval(() => {
    console.log("tick");
  }, 1000);

  return () => clearInterval(timer);
}, []);

Always return a cleanup function when you set up timers,
subscriptions, or event listeners.

3. useContext

Prop drilling means passing data through many layers of components
just to reach the one that actually needs it. useContext solves
this by letting any component read shared data directly.

Step 1: Create the context and a provider:

import { createContext, useContext, useState } from "react";

const ThemeContext = createContext();

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState("light");

  return (
    <ThemeContext.Provider value={{ theme, setTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

Step 2: Wrap your app:

// main.jsx
<ThemeProvider>
  <App />
</ThemeProvider>

Step 3: Read the context from any component:

function Navbar() {
  const { theme, setTheme } = useContext(ThemeContext);

  return (
    <nav style={{ background: theme === "dark" ? "#222" : "#fff" }}>
      <span>My App</span>
      <button onClick={() =>
        setTheme(theme === "dark" ? "light" : "dark")
      }>
        Toggle Theme
      </button>
    </nav>
  );
}

No props passed through intermediate components. The data is
available anywhere inside the provider.

4. useRef

useRef has two distinct uses that are worth understanding separately.

Use 1: Access a DOM element directly

import { useRef, useEffect } from "react";

function AutoFocusInput() {
  const inputRef = useRef(null);

  useEffect(() => {
    inputRef.current.focus();
  }, []);

  return <input ref={inputRef} placeholder="This auto-focuses" />;
}

Use 2: Store a value that does not trigger a re-render

function StopwatchApp() {
  const [seconds, setSeconds] = useState(0);
  const intervalRef = useRef(null);

  function start() {
    intervalRef.current = setInterval(() => {
      setSeconds((s) => s + 1);
    }, 1000);
  }

  function stop() {
    clearInterval(intervalRef.current);
  }

  return (
    <div>
      <p>{seconds}s</p>
      <button onClick={start}>Start</button>
      <button onClick={stop}>Stop</button>
    </div>
  );
}

The key difference: changing a useRef value does not cause the
component to re-render. That is what makes it the right tool for
storing timers and interval IDs.

5. useMemo

useMemo caches the result of an expensive calculation so it only
runs again when its dependencies change, not on every render.

import { useState, useMemo } from "react";

function ProductList({ products, filter }) {
  const filteredProducts = useMemo(() => {
    return products.filter((p) =>
      p.name.toLowerCase().includes(filter.toLowerCase())
    );
  }, [products, filter]);

  return (
    <ul>
      {filteredProducts.map((p) => (
        <li key={p.id}>{p.name} - {p.price}</li>
      ))}
    </ul>
  );
}

The filter calculation only runs when products or filter changes,
not when unrelated state changes cause a re-render.

Do not add useMemo everywhere. Only use it when you have measured
a real performance issue. Adding it unnecessarily makes code harder
to read for no actual benefit.

6. useCallback

useCallback caches a function so that its reference stays the same
between renders. This matters when you pass functions as props to
components wrapped in React.memo.

import { useState, useCallback, memo } from "react";

function Parent() {
  const [count, setCount] = useState(0);
  const [text, setText] = useState("");

  const handleClick = useCallback(() => {
    console.log("Button clicked");
  }, []);

  return (
    <div>
      <input
        value={text}
        onChange={(e) => setText(e.target.value)}
      />
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <ChildButton onClick={handleClick} />
    </div>
  );
}

const ChildButton = memo(({ onClick }) => {
  console.log("Child rendered");
  return <button onClick={onClick}>Click Me</button>;
});

Without useCallback, every re-render of Parent creates a new
function reference. ChildButton would re-render every time even
though nothing about it actually changed.

7. useReducer

When state logic becomes complex, especially when one action needs
to update multiple values at once, useReducer is cleaner than
multiple useState calls.

import { useReducer } from "react";

const initialState = { count: 0, step: 1 };

function reducer(state, action) {
  switch (action.type) {
    case "INCREMENT":
      return { ...state, count: state.count + state.step };
    case "DECREMENT":
      return { ...state, count: state.count - state.step };
    case "RESET":
      return initialState;
    case "SET_STEP":
      return { ...state, step: action.payload };
    default:
      return state;
  }
}

function AdvancedCounter() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div>
      <p>Count: {state.count} | Step: {state.step}</p>
      <button onClick={() => dispatch({ type: "DECREMENT" })}>-</button>
      <button onClick={() => dispatch({ type: "INCREMENT" })}>+</button>
      <button onClick={() => dispatch({ type: "RESET" })}>Reset</button>
      <input
        type="number"
        value={state.step}
        onChange={(e) =>
          dispatch({ type: "SET_STEP", payload: Number(e.target.value) })
        }
      />
    </div>
  );
}

The reducer function is a pure function that takes current state and
an action, and returns the next state. This pattern makes complex
state changes predictable and easy to test.

8. Custom Hooks

This is where Hooks become truly powerful. A custom hook is a regular
JavaScript function whose name starts with use and that calls other
hooks inside it. You use custom hooks to extract and reuse logic across
multiple components.

Custom Hook: useFetch

import { useState, useEffect } from "react";

function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    setLoading(true);
    setError(null);

    fetch(url)
      .then((res) => {
        if (!res.ok) throw new Error("Request failed");
        return res.json();
      })
      .then((json) => {
        setData(json);
        setLoading(false);
      })
      .catch((err) => {
        setError(err.message);
        setLoading(false);
      });
  }, [url]);

  return { data, loading, error };
}

Using the custom hook in multiple components:

function PostList() {
  const { data, loading, error } =
    useFetch("https://jsonplaceholder.typicode.com/posts");

  if (loading) return <p>Loading posts...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <ul>
      {data.slice(0, 5).map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

function UserCount() {
  const { data, loading } =
    useFetch("https://jsonplaceholder.typicode.com/users");

  if (loading) return <p>Loading...</p>;
  return <p>Total users: {data?.length}</p>;
}

Two different components. Same fetch logic. Zero code duplication.
This is what makes custom hooks one of the most valuable patterns
in React development.

Rules of Hooks

These two rules are enforced by React and breaking them will cause bugs
that are difficult to trace.
Rule 1: Only call Hooks at the top level of a component.
Never inside if statements, loops, or nested functions.
Rule 2: Only call Hooks inside React function components
or other custom hooks.

Wrong:

function Bad({ isLoggedIn }) {
  if (isLoggedIn) {
    const [data, setData] = useState(null); // breaks Rule 1
  }
}

Right:

function Good({ isLoggedIn }) {
  const [data, setData] = useState(null); // always at the top level

  if (!isLoggedIn) return null;

  return <div>{data}</div>;
}

Quick Reference

useState Store and update values, triggers re-render
useEffect Side effects: API calls, timers, subscriptions
useContext Read shared global data without prop drilling
useRef DOM access or persistent values without re-render
useMemo Cache expensive calculated values
useCallback Cache function references for child components
useReducer Complex state with multiple related values
Custom Hook Extract and reuse any logic across components

Projects to Build and Practice

The fastest way to learn Hooks is to use them in real projects. Here
are good starting points matched to the hooks they teach:

Todo App: useState, useReducer
Weather App: useEffect, custom useFetch hook
Dark Mode Toggle: useContext, useState
Search with Filter: useMemo, useState
Click-outside Detector: useRef, useEffect
Shopping Cart: useReducer, useContext combined

Pick one, build it from scratch, and you will understand Hooks
at a level that reading alone cannot give you.

Final Thoughts

Most developers learn Hooks by memorizing the API. That approach works
until something breaks and you cannot explain why. The better approach
is to understand what each Hook is solving. useState solves the problem
of memory inside a function. useEffect solves the problem of running
code in response to changes. useRef solves the problem of holding a
value without triggering a render.

When you understand the problem each Hook exists to solve, picking the
right one for any situation becomes straightforward.

Start with useState and useEffect. Build something real. Add the other
hooks only when you actually need them.

Found this useful? Drop a reaction and follow for weekly React posts,
project walkthroughs, and practical guides.

You Are Using useEffect Wrong - 5 Common Mistakes and How to Fix Them (2026)

Emma Schmidt — Thu, 07 May 2026 08:54:30 +0000

If you have ever had a bug you could not explain, infinite loops, stale data, or memory leaks, useEffect was probably involved.

Introduction

useEffect is one of the most used hooks in React. It is also one of the most misunderstood. Whether you are a solo developer leveling up your skills or a tech lead looking to Hire React.js Developers who truly understand the framework, knowing how useEffect works under the hood is non-negotiable in 2026. Even experienced developers ship bugs caused by subtle useEffect mistakes every single day. In this post, we will walk through the 5 most common useEffect mistakes, show you exactly why they break your app, and give you the correct pattern to fix each one. By the end, you will have a much clearer mental model of how useEffect actually works.

Mistake 1 - Missing the Cleanup Function

The Problem

You set up a subscription, a timer, or an event listener inside useEffect but never clean it up. This causes memory leaks and bugs that are incredibly hard to trace.

// WRONG
useEffect(() => {
  const interval = setInterval(() => {
    console.log("Tick");
  }, 1000);
}, []);

This interval keeps running even after the component unmounts. In large apps, these leaks stack up and slow everything down.

The Fix

Always return a cleanup function that tears down whatever you set up.

// CORRECT
useEffect(() => {
  const interval = setInterval(() => {
    console.log("Tick");
  }, 1000);

  return () => {
    clearInterval(interval); // Cleanup on unmount
  };
}, []);

The same pattern applies to event listeners, WebSocket connections, and API subscriptions.

// CORRECT - Event listener cleanup
useEffect(() => {
  const handleResize = () => console.log(window.innerWidth);
  window.addEventListener("resize", handleResize);

  return () => {
    window.removeEventListener("resize", handleResize);
  };
}, []);

Rule of thumb: If you set it up inside useEffect, clean it up in the return function.

Mistake 2 - Stale Closures in the Dependency Array

The Problem

You reference a variable inside useEffect but forget to add it to the dependency array. React captures the value at the time the effect runs, so you end up reading an old, stale value.

// WRONG
const [count, setCount] = useState(0);

useEffect(() => {
  const timer = setInterval(() => {
    console.log(count); // Always prints 0 - stale closure!
    setCount(count + 1); // Always sets to 1, never increments correctly
  }, 1000);

  return () => clearInterval(timer);
}, []); // count is missing from deps

count is frozen at 0 inside the closure because it is never listed as a dependency.

The Fix

Option A - Add the dependency properly:

// CORRECT - Option A
useEffect(() => {
  const timer = setInterval(() => {
    setCount(count + 1);
  }, 1000);

  return () => clearInterval(timer);
}, [count]);

Option B - Use the functional updater form of setState (best for counters and toggling):

// CORRECT - Option B (preferred for counters)
useEffect(() => {
  const timer = setInterval(() => {
    setCount(prev => prev + 1); // No dependency needed
  }, 1000);

  return () => clearInterval(timer);
}, []);

Option B is cleaner because the effect does not need to re-run every time count changes.

Mistake 3 - Using an Object or Array as a Dependency

The Problem

Objects and arrays are compared by reference in JavaScript, not by value. If you create an object or array inside the component and pass it as a dependency, React sees a new reference on every render and runs the effect endlessly.

// WRONG
const filters = { category: "electronics", inStock: true };

useEffect(() => {
  fetchProducts(filters);
}, [filters]); // New object reference every render = infinite loop

This triggers the effect on every single render, even when the values inside the object have not changed.

The Fix

Option A - Use primitive values as dependencies instead of objects:

// CORRECT - Option A
const category = "electronics";
const inStock = true;

useEffect(() => {
  fetchProducts({ category, inStock });
}, [category, inStock]); // Primitives compared by value

Option B - Memoize the object with useMemo:

// CORRECT - Option B
const filters = useMemo(() => ({
  category: "electronics",
  inStock: true
}), []); // Stable reference

useEffect(() => {
  fetchProducts(filters);
}, [filters]);

Mistake 4 - Fetching Data Without Handling Race Conditions

The Problem

You fetch data inside useEffect but the component re-renders (or unmounts) before the request completes. An older request finishes after a newer one and overwrites your state with stale data.

// WRONG
useEffect(() => {
  fetch(`/api/user/${userId}`)
    .then(res => res.json())
    .then(data => setUser(data)); // Could be stale data from an old request
}, [userId]);

If the user clicks quickly and userId changes twice, the first slow request might resolve after the second one, setting the wrong user in state.

The Fix

Use an isCancelled flag or the AbortController API to ignore outdated responses.

// CORRECT - Using AbortController
useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/user/${userId}`, { signal: controller.signal })
    .then(res => res.json())
    .then(data => setUser(data))
    .catch(err => {
      if (err.name === "AbortError") return; // Ignore cancelled requests
      console.error(err);
    });

  return () => {
    controller.abort(); // Cancel the request on cleanup
  };
}, [userId]);

// CORRECT - Using isCancelled flag
useEffect(() => {
  let isCancelled = false;

  fetch(`/api/user/${userId}`)
    .then(res => res.json())
    .then(data => {
      if (!isCancelled) setUser(data); // Only update if still relevant
    });

  return () => {
    isCancelled = true;
  };
}, [userId]);

The AbortController approach is preferred in 2026 because it also cancels the network request itself, saving bandwidth.

Mistake 5 - Putting Too Much Logic Inside useEffect

The Problem

Developers often dump complex logic directly into useEffect, making it hard to read, test, and reuse.

// WRONG - useEffect doing too much
useEffect(() => {
  if (user && user.isLoggedIn) {
    fetch(`/api/dashboard/${user.id}`)
      .then(res => res.json())
      .then(data => {
        setDashboard(data);
        localStorage.setItem("lastVisit", Date.now());
        analytics.track("dashboard_viewed", { userId: user.id });
      });
  }
}, [user]);

This is three separate concerns crammed into one effect. It is untestable and will cause confusing bugs when any one piece changes.

The Fix

Split each concern into its own useEffect or extract logic into a custom hook.

// CORRECT - Separate effects for separate concerns
useEffect(() => {
  if (!user?.isLoggedIn) return;
  fetchDashboard(user.id).then(setDashboard);
}, [user]);

useEffect(() => {
  if (!user?.isLoggedIn) return;
  localStorage.setItem("lastVisit", Date.now());
}, [user]);

useEffect(() => {
  if (!user?.isLoggedIn) return;
  analytics.track("dashboard_viewed", { userId: user.id });
}, [user]);

Even better, extract it into a custom hook:

// CORRECT - Custom hook
function useDashboard(user) {
  const [dashboard, setDashboard] = useState(null);

  useEffect(() => {
    if (!user?.isLoggedIn) return;

    const controller = new AbortController();

    fetch(`/api/dashboard/${user.id}`, { signal: controller.signal })
      .then(res => res.json())
      .then(setDashboard)
      .catch(err => {
        if (err.name !== "AbortError") console.error(err);
      });

    return () => controller.abort();
  }, [user]);

  return dashboard;
}

// Usage in component
const dashboard = useDashboard(user);

Custom hooks make your effects reusable, testable, and far easier to read.

Quick Reference - All 5 Fixes at a Glance

Mistake	Root Cause	Fix
Missing cleanup	Resource leak on unmount	Return a cleanup function
Stale closure	Missing dependency	Add to deps or use functional updater
Object as dependency	Reference comparison	Use primitives or useMemo
Race conditions	Async + re-render timing	Use AbortController
Too much in one effect	Poor separation of concerns	Split effects or use custom hooks

Bonus - The Two Questions to Ask Before Every useEffect

Before you write any useEffect, ask yourself:

1. Does this actually need to be an effect?

A lot of things developers put in useEffect do not belong there. Derived state, event handlers, and one-time initializations often do not need useEffect at all. If you are transforming data from props or state, just compute it inline or use useMemo.

2. What cleans this up?

If you cannot answer this question, you probably have a memory leak waiting to happen. Always think cleanup first.

Conclusion

useEffect is not complicated once you understand the mental model. Every mistake above comes down to the same root cause: not thinking carefully about when the effect runs, what it depends on, and what it leaves behind.

Fix these five patterns in your codebase and you will eliminate a whole category of React bugs overnight.

Which of these mistakes have you made before? Drop a comment below. I can guarantee everyone reading has hit at least three of them. And if this saved you some debugging time, a ❤️ helps other devs find this post.

Build Your Own AI Agent from Scratch Using Python + LangChain + OpenAI in 2026

Emma Schmidt — Thu, 07 May 2026 05:20:22 +0000

A step-by-step guide for developers who want to go beyond ChatGPT wrappers and build something real.

Introduction

AI agents are no longer a research concept. They are production tools being shipped by teams worldwide right now. Whether you are looking to Hire Python developers to build intelligent automation for your company, or you are a solo dev leveling up your own skills, understanding how to build an AI agent from scratch is one of the most valuable things you can learn in 2026. In this guide, we will build a fully functional AI agent using Python, LangChain, and the OpenAI API. One that can reason, use tools, and complete multi-step tasks autonomously. No fluff. Just working code and clear explanations.

What Exactly Is an AI Agent?

Before writing a single line of code, let us get the definition right.

A standard LLM call looks like this:
User Input > LLM > Output

An AI agent looks like this:
User Input > LLM > Decision > Tool Use > Observe Result > LLM > Decision > Final Output

The key difference is the loop. An agent can:

Decide which tool to use based on context
Call that tool (search the web, run code, query a database)
Observe the result
Decide what to do next
Repeat until it reaches a final answer

This is called the ReAct pattern (Reasoning + Acting), and it is the foundation of almost every modern AI agent framework.

What We Are Building

By the end of this tutorial, you will have an AI agent that can:

Answer questions using web search
Perform math calculations
Look up current weather
Chain multiple tools together to solve complex tasks

All orchestrated automatically by LangChain + OpenAI. You just give it a goal in plain English.

Prerequisites

Python 3.10+
An OpenAI API key
Basic familiarity with Python functions and pip

Step 1 - Project Setup

Create a clean project directory and set up a virtual environment.

mkdir ai-agent-tutorial
cd ai-agent-tutorial
python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate

Install the required packages:

pip install langchain langchain-openai langchain-community openai python-dotenv duckduckgo-search numexpr

Create a .env file in your project root:
OPENAI_API_KEY=your_openai_api_key_here

Step 2 - Load Environment Variables

Create a file called agent.py and start with:

from dotenv import load_dotenv
import os

load_dotenv()

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY")

Never hardcode your API key. Always use .env and add it to .gitignore.

Step 3 - Initialize the LLM

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    model="gpt-4o",
    temperature=0,
    api_key=OPENAI_API_KEY
)

We set temperature=0 because agents need deterministic, logical reasoning, not creative text generation. Lower temperature = more consistent tool selection.

Step 4 - Define the Tools

Tools are just Python functions wrapped with a LangChain decorator. The agent reads the docstring to understand what the tool does and when to use it, so write clear docstrings.

Tool 1 - Web Search

from langchain_community.tools import DuckDuckGoSearchRun
from langchain.tools import tool

search = DuckDuckGoSearchRun()

@tool
def web_search(query: str) -> str:
    """
    Search the web for current information.
    Use this when the user asks about recent events,
    news, or anything that requires up-to-date data.
    """
    return search.run(query)

Tool 2 - Math Calculator

@tool
def calculator(expression: str) -> str:
    """
    Evaluate a mathematical expression.
    Use this for any arithmetic, algebra, or numeric calculation.
    Input must be a valid Python math expression as a string.
    Example: '(100 * 1.08) ** 2'
    """
    try:
        result = eval(expression, {"__builtins__": {}}, {})
        return str(result)
    except Exception as e:
        return f"Error evaluating expression: {str(e)}"

⚠️ Security note: The eval() here is sandboxed with empty builtins. For production use, use the numexpr library or a dedicated math parser instead.

Tool 3 - Weather Lookup (Simulated)

@tool
def get_weather(city: str) -> str:
    """
    Get the current weather for a city.
    Use this when the user asks about weather conditions
    in a specific location.
    """
    mock_data = {
        "london": "Cloudy, 14°C, 80% humidity",
        "new york": "Sunny, 22°C, 55% humidity",
        "tokyo": "Rainy, 18°C, 90% humidity",
        "mumbai": "Hot and humid, 34°C, 75% humidity",
    }
    return mock_data.get(city.lower(), f"Weather data not available for {city}")

Step 5 - Bundle the Tools

tools = [web_search, calculator, get_weather]

LangChain will pass this list to the agent, which learns what each tool does from the docstrings automatically.

Step 6 - Create the Agent

from langchain import hub
from langchain.agents import create_react_agent, AgentExecutor

prompt = hub.pull("hwchase17/react")

agent = create_react_agent(
    llm=llm,
    tools=tools,
    prompt=prompt
)

agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    verbose=True,
    max_iterations=10,
    handle_parsing_errors=True
)

Step 7 - Run the Agent

if __name__ == "__main__":

    response = agent_executor.invoke({
        "input": "Who won the most recent FIFA World Cup and when was it held?"
    })
    print("\n✅ Answer:", response["output"])

    response = agent_executor.invoke({
        "input": "If I invest $5,000 at 8% annual compound interest for 10 years, how much will I have?"
    })
    print("\n✅ Answer:", response["output"])

    response = agent_executor.invoke({
        "input": "What is the current population of Japan? Now divide that by 1,000,000 and round it."
    })
    print("\n✅ Answer:", response["output"])

Step 8 - Sample Output

Entering new AgentExecutor chain...

Thought: I need to find the current population of Japan.
Action: web_search
Action Input: current population of Japan 2026
Observation: Japan's population is approximately 123.2 million as of 2026.
Thought: Now I need to divide 123,200,000 by 1,000,000.
Action: calculator
Action Input: 123200000 / 1000000
Observation: 123.2
Thought: I now know the final answer.
Final Answer: Japan's population is 123.2 million, which equals 123.2 when divided by 1,000,000.

Finished chain.

Full `agent.py` - Complete Code

from dotenv import load_dotenv
import os
from langchain_openai import ChatOpenAI
from langchain_community.tools import DuckDuckGoSearchRun
from langchain.tools import tool
from langchain import hub
from langchain.agents import create_react_agent, AgentExecutor

load_dotenv()

llm = ChatOpenAI(
    model="gpt-4o",
    temperature=0,
    api_key=os.getenv("OPENAI_API_KEY")
)

search = DuckDuckGoSearchRun()

@tool
def web_search(query: str) -> str:
    """Search the web for current information about recent events or news."""
    return search.run(query)

@tool
def calculator(expression: str) -> str:
    """Evaluate a mathematical expression. Input must be a valid Python math expression."""
    try:
        return str(eval(expression, {"__builtins__": {}}, {}))
    except Exception as e:
        return f"Error: {str(e)}"

@tool
def get_weather(city: str) -> str:
    """Get current weather for a city."""
    mock_data = {
        "london": "Cloudy, 14°C, 80% humidity",
        "new york": "Sunny, 22°C, 55% humidity",
        "tokyo": "Rainy, 18°C, 90% humidity",
        "mumbai": "Hot and humid, 34°C, 75% humidity",
    }
    return mock_data.get(city.lower(), f"Weather data not available for {city}")

tools = [web_search, calculator, get_weather]

prompt = hub.pull("hwchase17/react")
agent = create_react_agent(llm=llm, tools=tools, prompt=prompt)
agent_executor = AgentExecutor(
    agent=agent,
    tools=tools,
    verbose=True,
    max_iterations=10,
    handle_parsing_errors=True
)

if __name__ == "__main__":
    response = agent_executor.invoke({
        "input": "What is the weather in Tokyo and what is 34°C in Fahrenheit?"
    })
    print("\n✅ Answer:", response["output"])

How to Extend This Agent

Add memory:

from langchain.memory import ConversationBufferMemory

memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True)

agent_executor = AgentExecutor(agent=agent, tools=tools, memory=memory, verbose=True)

Add a custom database tool:

@tool
def query_user_database(user_id: str) -> str:
    """Look up user information from the internal database by user ID."""
    return f"User {user_id}: Name=John, Plan=Pro, Joined=2026-01"

Swap to an open-source model:

from langchain_community.llms import Ollama

llm = Ollama(model="llama3")

Common Mistakes to Avoid

Vague tool docstrings - the agent picks tools by reading them. Be specific or it hallucinates.
No max_iterations - a confused agent loops forever and drains your API credits.
temperature > 0 - makes tool selection unpredictable. Always use 0 for agents.
Skipping handle_parsing_errors=True - malformed output will crash silently without it.

What to Build Next

Research agent - searches, summarises, and writes a report on any topic
Code reviewer agent - reads a GitHub PR and suggests improvements
Customer support agent - handles tier-1 tickets using your product database
Data analyst agent - takes a CSV and answers plain-English questions about it

Conclusion

You have just built a working AI agent from scratch. One that reasons, selects tools, observes results, and loops until it finds the answer. This is not a toy demo. The same architecture powers production agents at companies shipping real products today.

The concepts here, ReAct loops, tool definitions, memory, and executor configuration, transfer directly to more advanced frameworks like LangGraph, AutoGen, and CrewAI.

What kind of agent are you going to build? Drop it in the comments. I read every single one. And if this helped you, a ❤️ goes a long way in helping other devs find this post.

Found this useful? Follow me for more Python, AI, and backend deep dives every week.

How to Hire Next.js Developers Who Actually Know App Router, Server Components and Edge Functions

Emma Schmidt — Wed, 06 May 2026 05:14:26 +0000

When you decide to Hire Next.js Developers for your product, you quickly realize that not all candidates are equal. The framework has evolved massively since the Pages Router days, and many developers still live in that old world. This guide cuts through the noise and gives you a precise, technical hiring framework to identify engineers who genuinely understand the App Router, React Server Components (RSC), and Edge Functions, so you stop paying for developers who Google everything on the job.

Why the Knowledge Gap Is Wider Than You Think

Next.js 13 and beyond introduced a mental model shift, not just a syntax change. The App Router is not simply a new file convention. It is a full rethinking of how data fetching, rendering, caching, and routing coexist in a React application.

Developers who learned Next.js before 2023 are often fluent in:

getServerSideProps / getStaticProps
Pages under /pages directory
API routes via /pages/api
Client-side data fetching with SWR or React Query

But modern Next.js (14 and 15) expects you to think in:

Server Components vs Client Components
Layouts, Templates, and nested routing via /app
Route Handlers instead of API routes
Streaming with Suspense
Edge and Node.js runtimes

Understanding this gap helps you write better job descriptions and ask the right interview questions.

Section 1: App Router Deep Dive

What to Look For

A strong candidate should be able to explain the /app directory structure without hesitation and articulate why nested layouts exist.

Interview Question to Ask

"Walk me through how you would set up a dashboard with a shared sidebar that does not re-render on route changes, while each dashboard page fetches its own data server-side."

Expected Answer Pattern

They should mention:

A root layout.tsx that wraps all pages
A nested dashboard/layout.tsx that holds the sidebar as a Server Component
Individual page.tsx files for each dashboard route that fetch their own data using async/await directly in the component

Code They Should Be Comfortable Writing

// app/dashboard/layout.tsx
import Sidebar from "@/components/Sidebar";

export default function DashboardLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <div className="flex h-screen">
      <Sidebar />
      <main className="flex-1 overflow-y-auto p-6">{children}</main>
    </div>
  );
}

// app/dashboard/analytics/page.tsx
async function getAnalyticsData() {
  const res = await fetch("https://api.example.com/analytics", {
    next: { revalidate: 60 },
  });
  return res.json();
}

export default async function AnalyticsPage() {
  const data = await getAnalyticsData();

  return (
    <section>
      <h1>Analytics</h1>
      <p>Total Users: {data.totalUsers}</p>
    </section>
  );
}

A weak candidate will suggest using useEffect for data fetching here or ask where to put getServerSideProps. That is your signal.

Section 2: React Server Components (RSC)

Why This Is a Frequent Lie on Resumes

Server Components are architecturally different from anything React developers were used to before. Many candidates claim to know them but cannot explain the boundary rules.

The Boundary Rule Test

Ask this directly: "What happens if you import a Client Component inside a Server Component and vice versa?"

The correct answer:

A Server Component can import and render a Client Component.
A Client Component cannot import a Server Component. However, a Server Component can be passed as a children prop to a Client Component.

Code to Illustrate During the Interview

// components/ProductCard.tsx  <-- Server Component (default)
import AddToCartButton from "./AddToCartButton"; // Client Component

export default async function ProductCard({ id }: { id: string }) {
  const product = await fetchProduct(id); // Direct DB or API call

  return (
    <div>
      <h2>{product.name}</h2>
      <p>{product.price}</p>
      <AddToCartButton productId={id} />
    </div>
  );
}

// components/AddToCartButton.tsx  <-- Client Component
"use client";

import { useState } from "react";

export default function AddToCartButton({ productId }: { productId: string }) {
  const [added, setAdded] = useState(false);

  return (
    <button onClick={() => setAdded(true)}>
      {added ? "Added" : "Add to Cart"}
    </button>
  );
}

Ask them: "Why does AddToCartButton need use client?" They should say: because it uses useState, which is a browser-side hook that has no meaning on the server.

Bonus Question for Senior Candidates

"How do Server Components affect bundle size?"

Expected answer: Server Components are never sent to the client as JavaScript. The component runs on the server, returns serialized UI, and only the HTML output reaches the browser. This can dramatically reduce client-side JavaScript.

Section 3: Edge Functions and the Runtime Model

What Edge Functions Actually Are

Edge Functions in Next.js run on a distributed runtime (like Cloudflare Workers or Vercel Edge Network) rather than a centralized Node.js server. They are closer to the user geographically and start up nearly instantly because they do not boot a full Node.js process.

The Tradeoff Most Developers Miss

Edge runtime does not support all Node.js APIs. Specifically, no fs, no native modules, no long-running processes. Ask candidates about this explicitly.

"Can you use the fs module inside a Next.js middleware running on the Edge runtime?"

Answer: No. The Edge runtime is a strict subset of the Web APIs. You need to use Web-standard APIs like Request, Response, fetch, crypto, and Headers.

Practical Edge Function Example: Auth Middleware

// middleware.ts
import { NextResponse } from "next/server";
import type { NextRequest } from "next/server";

export function middleware(request: NextRequest) {
  const token = request.cookies.get("auth_token")?.value;

  if (!token) {
    return NextResponse.redirect(new URL("/login", request.url));
  }

  // Optionally decode JWT on the edge without Node crypto
  return NextResponse.next();
}

export const config = {
  matcher: ["/dashboard/:path*", "/account/:path*"],
};

Strong candidates will note that JWT verification on the edge requires a Web Crypto-compatible library (like jose) rather than jsonwebtoken, which depends on Node.js internals.

Route Handler with Edge Runtime

// app/api/geo/route.ts
export const runtime = "edge";

export async function GET(request: Request) {
  const { geo } = request as any;

  return new Response(
    JSON.stringify({
      country: geo?.country ?? "Unknown",
      city: geo?.city ?? "Unknown",
    }),
    {
      headers: { "Content-Type": "application/json" },
    }
  );
}

Section 4: Caching and Revalidation

This is where even experienced developers get tripped up. Next.js 14+ introduced a layered caching system that behaves differently from anything in the Pages Router.

The Four Cache Layers

Request Memoization - Within a single render tree, identical fetch calls are deduped
Data Cache - Persisted across requests and deployments, controlled by next.revalidate
Full Route Cache - Statically rendered routes cached at the CDN level
Router Cache - Client-side cache of visited RSC payloads

Interview Scenario

"You have a product page that should update its price every 30 seconds but its description can stay cached for a week. How do you implement that?"

Expected answer:

// For price (revalidate every 30s)
const priceData = await fetch("https://api.example.com/price/123", {
  next: { revalidate: 30 },
});

// For description (revalidate weekly)
const descData = await fetch("https://api.example.com/description/123", {
  next: { revalidate: 604800 },
});

Or use tag-based revalidation:

// Fetching with a cache tag
const res = await fetch("https://api.example.com/products/123", {
  next: { tags: ["product-123"] },
});

// In a Server Action or Route Handler, revalidate by tag
import { revalidateTag } from "next/cache";
revalidateTag("product-123");

A weak candidate will suggest adding cache: 'no-store' everywhere "to be safe." That is a performance anti-pattern that removes all caching benefits.

Section 5: Server Actions

Server Actions are one of the most misunderstood modern features. They let you run server-side code directly from a form or event handler without writing a separate API route.

Code Example to Discuss

// app/contact/page.tsx
async function submitContactForm(formData: FormData) {
  "use server";

  const name = formData.get("name") as string;
  const email = formData.get("email") as string;

  await saveToDatabase({ name, email });
}

export default function ContactPage() {
  return (
    <form action={submitContactForm}>
      <input name="name" type="text" placeholder="Your name" required />
      <input name="email" type="email" placeholder="Your email" required />
      <button type="submit">Send</button>
    </form>
  );
}

Ask: "What is the security implication of using a Server Action exposed to a form?"

A senior candidate will bring up CSRF protection (Next.js handles this automatically for Server Actions), input validation on the server, and rate limiting.

Section 6: Practical Hiring Checklist

Use this table when evaluating candidates after a technical screen.

Skill Area	Junior	Mid-Level	Senior
App Router file conventions	Knows basics	Confident with parallel/intercepted routes	Can architect complex nested layouts
Server vs Client Components	Knows the `use client` directive	Understands composition patterns	Optimizes for minimal client bundle
Data fetching	Uses `useEffect` mostly	Uses async Server Components	Manages all four cache layers intentionally
Edge Functions	Has heard of them	Can write basic middleware	Knows runtime limitations and tradeoffs
Server Actions	Unfamiliar	Can implement basic forms	Handles optimistic updates and error states
Performance	No awareness	Uses Lighthouse	Analyzes bundle, streaming, and TTFB

Section 7: Red Flags During Interviews

Watch for these patterns. They are consistent signals of a developer who has not kept pace with the framework.

Red flag 1: They describe data fetching as "you have to use getServerSideProps or fetch on the client." This tells you they are not using the App Router at all.

Red flag 2: They cannot explain why you would choose Node.js runtime over Edge runtime for a specific route. They treat edge as simply "faster" without understanding the constraints.

Red flag 3: They add "use client" to every component "just in case." This completely defeats the purpose of Server Components and bloats the client bundle.

Red flag 4: They have no opinion on streaming. A developer working with modern Next.js should know about <Suspense> boundaries and how they affect time to first byte.

Red flag 5: They cannot explain the difference between a Route Handler and a Server Action and when to use each.

Section 8: What a Good Technical Assessment Looks Like

Rather than whiteboard problems, give candidates a small real-world task:

Task brief (take-home, 3 to 4 hours):

Build a product listing page using the Next.js App Router that:

Fetches products from a mock API at build time with ISR (revalidate every 60 seconds)
Has a client-side search filter that does not trigger a server round trip
Includes a "Add to Wishlist" Server Action that saves to a local JSON file or in-memory store
Has a middleware that logs each request to the console only in development mode
Has at least one route on the Edge runtime

This task reveals everything. You see their folder structure, their understanding of the client/server boundary, their cache strategy, and how they think about the Edge runtime.

Final Thoughts

The difference between a developer who knows Next.js and one who truly understands the modern stack is not about years of experience. It is about whether they have shipped real features using the App Router, wrestled with caching bugs, optimized Server Component boundaries, and deployed something to the edge.

Your hiring process should reflect that reality. Ask about tradeoffs, not just syntax. Ask about production problems, not just toy examples. Ask them to write code that reveals their mental model of the server/client boundary.

When you hire developers with this level of fluency, your Next.js application becomes faster, cheaper to run, and far easier to scale. When you do not, you end up with a codebase that looks like it uses the App Router but behaves like the Pages Router in disguise.

FastAPI vs Django vs Flask in 2026

Emma Schmidt — Tue, 05 May 2026 06:07:13 +0000

Emma Schmidt

May 5

FastAPI vs Django vs Flask in 2026: Choosing the Right Stack When You Hire Python Developers

#python #fastapi #django #flask

Comments

8 min read

Forem: Emma Schmidt

Next.js in 2026: The Features Reshaping Full-Stack Web Development

1. Partial Prerendering (PPR) is Now Stable and It Changes Everything

2. Turbopack is Fully Stable: Your Local Dev Will Never Feel the Same

3. Server Actions: Backend Logic Without the Boilerplate

4. React Server Components + React 19: The Rendering Model Has Grown Up

5. The New Caching Model: Opt-In Instead of Opt-Out

6. TypeScript-First Development with next.config.ts

7. Edge Functions and the Rise of Global-First Architecture

8. Developer Experience Upgrades Worth Knowing

Quick Reference: Next.js 14 vs 15 vs 16

What You Should Be Building With Today

Final Thoughts

Stop Writing Slow Python: 5 Performance Mistakes That Are Killing Your App (With Fixes)

Mistake 1: Using a List When You Should Use a Set

Mistake 2: String Concatenation Inside a Loop

Mistake 3: Not Using Generators for Large Data

Mistake 4: Ignoring lru_cache for Repeated Computations

Mistake 5: Blocking the Event Loop in Async Code

Putting It All Together

Summary Table

Final Thoughts

Discussion

Why Your React App Lags After Integrating AI Chatbots (And How to Debug It)

Understanding the Performance Problem

Cause 1: Uncontrolled Re-renders from Streaming State Updates

The Problem

Example of the Problem

The Fix

Cause 2: Blocking the Main Thread with Large Payloads

The Problem

Example of the Problem

The Fix

Cause 3: Memory Leaks from Uncleaned Subscriptions and Streams

The Problem

Example of the Problem

The Fix

Cause 4: Improper Message List Virtualization

The Problem

The Fix

Cause 5: Inefficient Context API Usage

The Problem

Example of the Problem

The Fix

Cause 6: Markdown and Code Block Rendering Overhead

The Problem

The Fix

Cause 7: Network Latency Misattributed as UI Lag

The Problem

How to Distinguish Them

The Fix for Perceived Latency

How to Use React DevTools Profiler to Debug Lag

Performance Checklist

Conclusion

Build Autonomous AI Agents with Python in 2026 (The Complete Guide Developers Are Obsessed With)

Introduction

What Exactly Is an AI Agent?

Why Python Is the #1 Choice for AI Agents in 2026

The Hottest Frameworks Right Now in 2026

1. LangGraph (The Most Powerful)

2. CrewAI (Best for Multi-Agent Teams)

3. AutoGen (Best for Conversational Agents)

Build a Full Working AI Agent from Scratch (Step by Step)

Step 1: Install Dependencies

Step 2: Set Up Your Environment

Step 3: Define Your Tools

Step 4: Create the Agent

Step 5: Run It

Adding Memory to Your Agent

Async Agents: Handle Multiple Tasks Concurrently

Real-World Use Cases Shipping in Production Right Now

Common Mistakes Developers Make (And How to Avoid Them)

What Is Next: Trends to Watch in Python Agents for 2026

Final Thoughts

Next.js 16 + The React Compiler: The Combo That's Changing Everything in 2026

🚀 What's the Big Deal with the React Compiler?

Before the Compiler (manual pain 😩)

After the Compiler (clean code 😍)

⚡ Next.js 16: What's Actually New?

1. Turbopack is Now the Default

6. TypeScript-First Development with `next.config.ts`

2. `use cache` - Granular Caching Control

1. Stop Using `pip` Alone. Start Using `uv`