Forem: Jubayer Hossain

The Resurgence of Hypermedia Systems: Building Modern UIs with HTMX 3.0

Jubayer Hossain — Tue, 14 Apr 2026 06:00:42 +0000

The Resurgence of Hypermedia Systems: Engineering Modern UIs with HTMX 3.0

For the past decade, the industry consensus on web architecture was settled: a "modern" application requires a thick Single Page Application (SPA) built in React, Vue, or Angular, communicating with a stateless JSON API. We accepted the complexity of state synchronization, the heavy bundle sizes, and the "JavaScript tax" as the necessary cost of progress.

But the tide is shifting. With the release of HTMX 3.0, a growing cohort of developers is rediscovering the power of the original architectural style of the web: Hypermedia.

By returning to "Hypermedia as the Engine of Application State" (HATEOAS), we can build rich, interactive user interfaces with a fraction of the complexity. In this post, we’ll explore the resurgence of hypermedia systems, type-safe patterns for HTMX, and why the Go + HTMX stack is becoming a favorite for performance-critical applications.

The "SPA Fatigue" and the Return to the Server

The shift toward SPAs was driven by the need for UX fluidity—the ability to update parts of a page without a full reload. However, this introduced a massive architectural split. Developers now had to manage two separate applications: the frontend state and the backend source of truth.

HTMX challenges the premise that "dynamic" requires "JSON." It allows you to access AJAX, CSS Transitions, WebSockets, and Server Sent Events directly in HTML, using attributes. Instead of exchange data (JSON) and turning it into DOM elements on the client, you exchange HTML fragments.

The Core Philosophy: Moving State back to the Server

In a hypermedia-driven architecture, the server remains the single source of truth for both data and the UI state. When a user clicks a "Delete" button, the server doesn't just return {"success": true}; it returns the new HTML state of the list.

Architecting with HTMX 3.0: High-Level Patterns

HTMX 3.0 brings refined event handling and better integration with modern browser APIs. When building production-scale systems, simple "swap" operations aren't enough. We need structured patterns.

1. The Fragment-Based Routing Pattern

Instead of full-page refreshes, use the hx-boost attribute to intercept standard anchor tags. HTMX will fetch the page via AJAX, swap the <body> content, and update the URL using the History API. This gives you SPA-like speed while maintaining the simplicity of a Multi-Page Application (MPA).

2. OOB (Out-of-Band) Swaps

One of the most powerful features of HTMX is the ability to update multiple parts of a page in a single request.

<!-- The primary response -->
<div id="cart-items">
  <li>New Item Added!</li>
</div>

<!-- An extra fragment to update the navbar counter -->
<div id="cart-count" hx-swap-oob="innerHTML">
  5
</div>

This eliminates the need for complex client-side state management (like Redux or Pinia) for cross-component communication.

Type-Safe HTMX: Bridging the Gap

A common criticism of hypermedia systems is the lack of "contract" safety. In an SPA, you can generate TypeScript interfaces from your OpenAPI/Swagger spec. In HTMX, you are sending HTML strings. How do we ensure the backend returns what the frontend expects?

The "Templates as Code" Approach

In the Go ecosystem, tools like Templ have revolutionized this. Templ allows you to write HTML components as type-safe Go code.

// cart_component.templ
package components

templ CartCount(count int) {
    <span id="cart-count" class="badge">
        { strconv.Itoa(count) }
    </span>
}

By using type-safe templates, if you change a data structure in your Go backend, the compiler will catch broken references in your HTML templates. This creates a "Type-Safe Hypermedia" loop that is arguably more robust than JSON-to-TS mapping because there is no serialization boundary to manage.

The "HyperGo" Stack: Why Go and HTMX?

The Go + HTMX stack (often called the "BETH" or "GOTH" stack) has gained viral traction. Why?

Concurrency: Go’s goroutines make it trivial to handle long-running hypermedia streams (SSE/WebSockets).
Binary Distribution: You can bundle your templates and static assets into a single executable. No more node_modules in production.
Low Latency: Since the server generates the HTML, the Time to First Byte (TTFB) is critical. Go’s efficiency ensures that fragment generation takes microseconds.

Example: A Zero-JS Search Filter

Here is how elegantly a Go + HTMX handler looks:

func SearchHandler(w http.ResponseWriter, r *http.Request) {
    query := r.URL.Query().Get("q")
    results := database.Search(query)

    // Check if it's an HTMX request
    if r.Header.Get("HX-Request") == "true" {
        // Return only the partial fragment for the table body
        components.SearchResultsTable(results).Render(r.Context(), w)
        return
    }

    // Otherwise, return the full page layout
    components.SearchPage(results).Render(r.Context(), w)
}

On the frontend:

<input type="text" name="q" 
       hx-get="/search" 
       hx-trigger="keyup changed delay:500ms" 
       hx-target="#search-results" 
       placeholder="Search users...">

<tbody id="search-results">
    <!-- Results load here -->
</tbody>

Zero-JS Frontend Strategies: Is it Really No JavaScript?

The goal of HTMX isn't necessarily "No JavaScript," but "No Custom JavaScript." By using a declarative attribute-based library, you reduce the surface area for bugs.

However, for complex client-side interactions (like a signature pad or a drag-and-drop file uploader), HTMX works best when paired with Alpine.js. Alpine follows the same philosophy: it keeps the logic in the HTML.

This combo—HTMX for server communication and Alpine for "sprinkles" of client logic—allows you to build 99% of modern web requirements without ever touching a build tool like Webpack or Vite.

The Future of the Hypermedia System

HTMX 3.0 isn't a step backward; it's a correction. We are moving away from the "distributed monolith" of JSON APIs and thick clients toward a more cohesive, resilient architecture.

When should you choose HTMX?

Internal tools and CRUD-heavy dashboards.
Content-centric platforms (Blogs, E-commerce, Social Media).
Teams that want to move fast without the overhead of two separate build pipelines.

When should you stay with an SPA?

Offline-first applications.
Highly iterative graphical editors (like Figma or Canva).
Applications with extremely complex client-side state (like a local-first DAW).

Conclusion

The resurgence of Hypermedia Systems represents a return to the fundamentals of the Web. By leveraging HTMX 3.0 and type-safe backend languages like Go, we can create applications that are faster to develop, easier to maintain, and significantly more performant for the end-user.

If you’re tired of the constant churn of JavaScript frameworks, it’s time to look back at HTML. You might be surprised at how much power was there all along.

Ready to try the HyperGo stack? Start by checking out the HTMX Documentation and the Templ project. The web is simpler than you think.

Sustainable GPU FinOps: Optimizing AI Compute for Cost and Carbon

Jubayer Hossain — Mon, 13 Apr 2026 14:00:36 +0000

Beyond the Hype: Mastering Sustainable GPU FinOps in the Generative AI Era

The rapid ascent of Generative AI has brought us to a paradoxical crossroads. On one hand, Large Language Models (LLMs) are driving unprecedented productivity gains; on the other, the computational cost of training and serving these models is exerting a massive strain on both corporate budgets and the planet.

As developers and architects, we are no longer just responsible for "uptime" and "latency." In the modern tech stack, a new discipline has emerged at the intersection of environmental stewardship and financial discipline: Sustainable GPU FinOps.

This post explores how to implement green cloud engineering principles to optimize GPU utilization, reduce carbon footprints, and regain control over spiraling cloud bills.

The Hidden Cost of the AI Gold Rush

A single training run for a frontier model can consume as much energy as hundreds of households use in a year. However, for most enterprises, the "silent killer" isn't the one-time training cost—it's the on-going inference.

According to recent benchmarks, running an H100 GPU at peak capacity creates a significant thermal and carbon footprint. When these resources are underutilized (idling at 10-15% while the bill runs at 100%), we witness the ultimate failure of modern infrastructure design. Sustainable Cloud Engineering is the antidote to this waste.

1. Right-Sizing: From H100s to Fractured GPUs

The first rule of GPU FinOps is that not every task requires a flagship accelerator. Using an NVIDIA H100 for simple sentiment analysis is like using a space shuttle to go to the grocery store.

Multi-Instance GPU (MIG)

Modern NVIDIA architectures (Ampere and Hopper) support Multi-Instance GPU (MIG). This allows you to partition a single physical GPU into multiple hardware-isolated instances.

# Example: Kubernetes manifest requesting a specific MIG partition
apiVersion: v1
kind: Pod
metadata:
  name: green-inference-worker
spec:
  containers:
  - name: model-server
    image: vllm-openai:latest
    resources:
      limits:
        nvidia.com/mig-2g.20gb: 1 # Requesting a 20GB slice instead of a full 80GB A100

By using MIG, you increase utilization density, meaning fewer physical chips are drawing "base power" (the electricity required just to keep the chip powered on).

2. Carbon-Aware Scheduling: Timing is Everything

The carbon intensity of the power grid fluctuates throughout the day based on the availability of wind, solar, and hydroelectric power. Carbon-aware scheduling involves shifting non-urgent workloads—like batch processing, model fine-tuning, or data augmentation—to times when the grid is "greenest."

Implementing a Carbon-Aware Cron

You can use APIs like Carbon SDK to programmatically check the carbon intensity of your cloud region.

import requests
from datetime import datetime

def get_carbon_intensity(region):
    # Mocking a call to a Carbon Intensity API
    response = requests.get(f"https://api.carbon-intensity.org/regional/{region}")
    return response.json()['intensity']

def schedule_finetuning_job():
    intensity = get_carbon_intensity("us-east-1")

    if intensity < 200: # Threshold in gCO2/kWh
        print("Grid is clean. Launching GPU Spot Instance...")
        launch_training_job()
    else:
        print("Grid is carbon-heavy. Deferring job by 4 hours.")
        reschedule(delay=4)

3. FinOps for Generative AI: The Spot Instance Strategy

GPU availability is tightening, but "Spot" or "Preemptible" instances remain the most potent tool in the FinOps arsenal. They offer up to 70-90% discounts compared to on-demand pricing.

The challenge with GPUs is the state. If a training job is interrupted, you lose progress. To solve this sustainably:

Automated Checkpointing: Use libraries like PyTorch Lightning to save weights to S3/GCS every n steps.
Serverless GPU Tiers: Platforms like RunPod or Modal allow you to scale to zero. If no requests are coming in, the GPU is deprovisioned instantly, stopping both the bill and the carbon emission.

4. Quantization: The Greenest Optimization

Optimization is often seen as a performance play, but in GPU FinOps, it’s a sustainability play.

By using Quantization (INT8 or FP4), you can fit larger models into smaller, less power-hungry GPUs. For example, a 70B parameter model that previously required two A100s might fit onto a single A6000 after 4-bit quantization via bitsandbytes or AutoGPTQ.

The Impact:

Memory reduction: ~50-70%
Throughput increase: 2x-4x
Energy per Request: Decreases proportionally with latency.

5. Metrics that Matter: Moving Beyond Dollars

Standard FinOps focuses on $. Sustainable FinOps focuses on Power Usage Effectiveness (PUE) and Carbon Intensity.

As a developer, you should aim to track:

GPU Utilization vs. Power Draw: Are you drawing 300W for a process only utilizing 20% of the CUDA cores?
Juries per Inference: How many Joules of energy does a single API response cost?
CO2e per Model: The total estimated carbon equivalents for a model's lifecycle.

Conclusion: The Responsible Architect

The future of cloud computing isn't just about who has the most compute—it’s about who uses it most efficiently. By implementing MIG partitioning, carbon-aware scheduling, and aggressive quantization, you aren't just saving your company money; you are reducing the digital industry's physical impact on the world.

FinOps and Green Engineering are two sides of the same coin: Zero Waste. When we optimize for the dollar, we almost always optimize for the planet.

Call to Action

Start small. Audit your current GPU clusters today. Are your dev environments running 24/7? Could your batch jobs wait for the sun to rise in their local region? The roadmap to sustainable AI starts with visibility.

Follow us for more deep dives into Green Cloud Engineering and the evolving world of AI Infrastructure.

Mastering Agentic Software Development Workflows

Jubayer Hossain — Mon, 13 Apr 2026 06:02:13 +0000

Beyond Copilot: Mastering Agentic Software Development Workflows

For the past two years, the industry has been obsessed with "Autocomplete on Steroids." We’ve integrated LLMs into our IDEs to suggest the next line of code or generate isolated functions. But as any senior engineer will tell you, writing code is only 20% of the job. The real complexity lies in debugging integration issues, maintaining legacy systems, and orchestrating complex deployments.

We are now entering the era of Agentic Software Development Workflows. This isn't just AI helping you write code; it’s an autonomous system that can navigate a codebase, reason about architecture, execute tests, and fix its own mistakes.

In this post, we’ll explore how to shift from passive AI assistance to active, autonomous developer agents.

What is an "Agentic" Workflow?

A standard AI workflow is linear and human-driven:

Human asks for a function.
AI provides code.
Human copies, pastes, and fixes errors.

An agentic workflow is iterative and goal-oriented:

Human provides a high-level goal (e.g., "Migrate the auth module to use OAuth2 instead of JWT").
The Agent explores the codebase to find relevant files (Context-aware code synthesis).
The Agent drafts a plan and executes changes.
The Agent runs a test suite; if it fails, it analyzes the logs and self-corrects (AI-driven refactoring loops).
The Agent submits a PR with a summarized changelog.

The core differentiator is the feedback loop.

1. Context-Aware Code Synthesis: Moving Beyond the File Buffer

The biggest limitation of current AI tools is "Context Blindness." An agentic system uses Retrieval-Augmented Generation (RAG) combined with AST (Abstract Syntax Tree) parsing to understand the entire repository, not just the open file.

The Architecture of an Agent's Context

To build an agentic workflow, you need a system that indexed your code into three layers:

The Structural Layer: A map of classes, methods, and their relationships.
The Semantic Layer: Vector embeddings of code blocks to find "similar logic" across the repo.
The Runtime Layer: Recent logs, traces, and test results.

When an agent is tasked with a refactor, it doesn't just guess. It queries the Structural Layer to see which downstream services will break if a method signature changes.

2. AI-Driven Refactoring Loops

The "hallucination" problem in LLMs is solved through verification loops. If an agent generates code that doesn't compile, an agentic workflow doesn't stop. It feeds the compiler error back into the LLM.

Example: The Self-Healing Test Loop

def agentic_refactor(module_path, goal):
    plan = planner.create_steps(module_path, goal)

    for step in plan:
        code_change = researcher.generate_fix(step)
        apply_patch(code_change)

        # The Feedback Loop
        success, logs = test_runner.execute_suite()

        while not success:
            print(f"Test failed: {logs}. Retrying...")
            # The agent analyzes the failure and refactors its own code
            correction = researcher.debug_failure(logs, code_change)
            apply_patch(correction)
            success, logs = test_runner.execute_suite()

    return "Refactoring Complete"

In this model, the developer acts as a Product Manager for the code, reviewing the final output rather than micromanaging every character typed.

3. Natural Language CI/CD Pipelines

Traditional CI/CD pipelines are rigid YAML files. If a deployment fails due to a transient environment issue or a missing secret, the pipeline simply turns red and sends a Slack notification.

Natural Language CI/CD introduces an agent between the failure and the developer.

Trigger: Deployment to Staging fails.
Agent Action: The agent reads the Kubernetes events, identifies a CrashLoopBackOff due to a missing environment variable, checks the README.md and docker-compose.yml for context, and submits a fix to the .env.example.

Instead of "Pipeline Failed," your notification becomes: "Staging deployment failed due to missing DB_PORT. I've initiated a PR to add the default value based on the dev config."

The Challenges: Security and Trust

Moving to an agentic workflow isn't without risk. Giving an LLM the ability to execute shell commands and modify codebases requires strict guardrails:

Deterministic Evaluation: Agents must run in isolated sandboxes (Docker/Wasm) where they cannot impact production data without manual approval.
Human-in-the-Loop (HITL): For critical architectural changes, the agent should pause and request a "Proceed?" confirmation after the planning phase but before the execution phase.
Prompt Injection: How do we ensure the agent doesn't follow malicious instructions hidden in a third-party library's documentation?

How to Get Started

You don't need to build a custom AGI to start using agentic workflows today. Several tools are already implementing these patterns:

Aider: A command-line tool that lets you pair program with an LLM that can edit files and commit changes directly to Git.
Devin/OpenDevin: Emerging platforms designed to behave as autonomous software engineers.
LangGraph: A framework for building stateful, multi-agent runtimes where different "specialists" (Writer, Tester, Searcher) collaborate.

Conclusion: The New Developer Persona

As agentic software development workflows mature, the role of the "Software Engineer" will shift. We are moving away from being "Typists" and becoming "Architects and Verifiers."

The value of an engineer will no longer be measured by how quickly they can search StackOverflow or memorize syntax, but by how effectively they can direct autonomous agents to solve complex business problems.

Are you ready to stop writing code and start managing agents? The first step is to automate your local testing feedback loop. Start small, verify everything, and embrace the autonomy.

Join the Conversation

What is the most tedious part of your sprint that you wish an autonomous agent could handle? Let me know in the comments or reach out on Twitter/X!

AI #SoftwareEngineering #DevOps #LLM #Automation

Browser-Native AI: Unleashing WebGPU and Wasm-GC

Jubayer Hossain — Mon, 13 Apr 2026 06:00:39 +0000

Beyond the Cloud: High-Performance Browser-Native AI with WebGPU and Wasm-GC

For years, the "AI revolution" has been synonymous with massive server farms and skyrocketing API costs. To run a Large Language Model (LLM) or a diffusion pipeline, you typically sent data to a headless GPU in a data center, waited for the inference to finish, and streamed the result back.

But the tide is turning. We are entering the era of Local-First AI.

Thanks to the stabilization of WebGPU and the arrival of Wasm-GC (WebAssembly Garbage Collection), the browser is no longer just a presentation layer. It is a powerful, sandboxed execution environment capable of running complex tensor operations and memory-intensive ML models at near-native speeds.

In this post, we’ll explore how these two technologies are fundamentally changing the Rust-to-Wasm workflow and why client-side ML inference is finally ready for production.

The Architectural Shift: Client-Side ML

Why move AI to the browser? The benefits are three-fold:

Privacy: User data never leaves the device.
Cost: You leverage the user’s hardware, reducing your cloud compute bill to zero.
Latency: Zero round-trip time for inference, enabling real-time interactions.

Historically, the bottleneck was hardware access and memory management. WebGL was a hack for compute, and WebAssembly’s linear memory model made interacting with managed languages (like those used in high-level ML frameworks) a chore.

Enter WebGPU and Wasm-GC.

1. WebGPU: Unlocking the Hardware

WebGPU is the successor to WebGL, but it isn't just a version update; it’s a total reimagining of how the web talks to graphics and compute hardware. It maps closely to modern APIs like Vulkan, Metal, and Direct3D 12.

For AI developers, the magic lies in WGSL (WebGPU Shading Language) and compute pipelines. Unlike WebGL, WebGPU allows for general-purpose GPU computing (GPGPU) without the overhead of pretending your tensors are pixels.

Example: A Simple Compute Shader in WGSL

To understand how WebGPU handles heavy lifting, look at how we might define a simple vector multiplication kernel:

@group(0) @binding(0) var<storage, read> input_a: array<f32>;
@group(0) @binding(1) var<storage, read> input_b: array<f32>;
@group(0) @binding(2) var<storage, read_write> output: array<f32>;

@compute @workgroup_size(64)
fn main(@builtin(global_invocation_id) global_id: vec3<u32>) {
    let index = global_id.x;
    output[index] = input_a[index] * input_b[index];
}

This shader runs in parallel across thousands of GPU cores. Frameworks like Burn (Rust) or ONNX Runtime Web use these primitives to execute entire neural networks directly on the user's silicon.

2. Wasm-GC: The Missing Piece for Managed Languages

While WebGPU handles the "math," WebAssembly handles the "logic."

Previously, if you compiled a garbage-collected language (like Java, Kotlin, or even parts of Python) to Wasm, you had to ship your own GC inside the Wasm binary. This led to massive "bloatware" binaries and poor performance.

Wasm-GC changes this by allowing Wasm to use the browser’s native garbage collector. This is a game changer for ML infrastructure because:

Reduced Binary Size: You no longer ship a GC; your Wasm module is lean.
Faster Interop: Objects can be shared between the JavaScript host and the Wasm module seamlessly.
Optimized Memory: The browser can see the whole memory landscape and optimize collections across the JS/Wasm boundary.

For developers using Rust-to-Wasm workflows, while Rust doesn't require a GC, Wasm-GC enables better integration with browser-native APIs and future-proofs the interop between the high-level application logic (often in JS/TS) and the low-level compute (Rust/Wasm).

3. The Modern Rust-to-Wasm Workflow for AI

If you are building a client-side AI application today, the stack usually looks like this:

The Compute Layer (Rust + Burn/Candle)

You write your model logic in Rust using libraries like Candle (Hugging Face) or Burn. These libraries are designed for high-performance inference and have backends specifically for WebGPU.

The Orchestration Layer (Wasm-bindgen)

You use wasm-bindgen to create the bridge between your Rust logic and the browser.

# Adding the WebGPU target in a Rust environment
cargo add wgpu

The Frontend (JavaScript/TypeScript)

The browser's JavaScript environment handles the WebGPU device initialization and feeds data into the Wasm module.

// Initializing WebGPU from JS
const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();

// Pass the device pointer to your Wasm module
wasm_module.init_gpu_inference(device);

Real-World Impact: LLMs in the Browser

The combination of WebGPU and Wasm-GC is what makes projects like WebLLM possible. You can now download a quantized Llama-3 or Mistral model and run it entirely in Chrome or Edge.

The memory management is handled by the browser, the compute is handled by the local GPU, and the result is a private, offline, and free-to-operate AI assistant.

Performance Benchmarks

In early testing, WebGPU-based inference is often 10x to 100x faster than the CPU-based WebAssembly fallbacks used just two years ago. This bridges the gap between "toy" demos and professional-grade tools.

Challenges and Considerations

While the future is bright, it is not without hurdles:

VRAM Constraints: Browsers often limit the amount of VRAM a single tab can use. Large models must be heavily quantized (e.g., 4-bit) to fit within the 2GB–4GB limits common in many environments.
Asset Delivery: Downloading a 2GB model weight file is a significant UX hurdle. Progressive loading and IndexedDB caching are essential.
Compatibility: While Chrome, Edge, and Firefox have made massive strides, WebGPU support is still rolling out across mobile browsers.

Conclusion: Start Building Locally

The era of shipping every single input string to an expensive cloud GPU is ending. By leveraging WebGPU for compute and Wasm-GC for efficient execution, we can build a more private, faster, and more sustainable web.

As a developer, the best way to get started is to explore the Burn framework for Rust or the Transformers.js library, both of which are aggressively optimizing for the WebGPU future.

The browser is no longer a document viewer—it’s an AI workstation. Are you ready to build for it?

Did you find this deep dive helpful? Follow us for more insights into Rust, WebAssembly, and the future of web performance.

Next.js 16: Stop Overusing 'use client' and Master These 5 Advanced RSC Patterns 🚀

Jubayer Hossain — Sun, 12 Apr 2026 22:14:35 +0000

The transition from the Pages Router to the App Router was the biggest shift in the React ecosystem since hooks. Now, with the arrival of Next.js 16, we are moving past the "how do I use these?" phase and into the "how do I architect for scale?" phase.

React Server Components (RSC) are no longer just a way to fetch data without useEffect. They are a structural primitive that, when used correctly, can eliminate 70% of your client-side bundle and solve the dreaded waterfall problem.

Think of it like a restaurant: The Server is the kitchen (heavy lifting, hidden ingredients), and the Client is the table (where the customer interacts). You don't want the chef cooking at the table; you want the food delivered hot and ready.

Today, we’re diving deep into advanced patterns: from hybrid composition to the cutting edge of Edge hydration.

1. The "Slot-Bridge" Pattern for Interactive Islands

Developers often panic when they need interactivity and mark a high-level component with 'use client', inadvertently turning their entire layout into a Client Component.

The Slot-Bridge Pattern uses React's children or named slots to "hole-punch" Server Components into Client Components.

The Advanced Solution:

// components/InteractiveSidebar.tsx
'use client';

import { useState } from 'react';

export default function InteractiveSidebar({
  navigation,
}: {
  navigation: React.ReactNode;
}) {
  const [isOpen, setIsOpen] = useState(true);

  return (
    <aside className={isOpen ? 'w-64' : 'w-10 transition-all'}>
      <button onClick={() => setIsOpen(!isOpen)}>Toggle</button>
      {/* This 'navigation' slot remains a Server Component! */}
      {navigation}
    </aside>
  );
}

// app/layout.tsx
import InteractiveSidebar from './components/InteractiveSidebar';
import ServerNavList from './components/ServerNavList';

export default async function Layout() {
  return (
    <InteractiveSidebar
      navigation={<ServerNavList />}
    />
  );
}

Why it works:
By passing the Server Component as a prop, Next.js renders it on the server and streams the result into the client component. This keeps your client bundle light and your sensitive logic secure on the server.

2. Server-Side State Persistence via Search Params

Global state management (Redux, Zustand) in an RSC-heavy world is difficult because Server Components cannot access React Context. The modern solution is URL-driven state using Search Params.

The Pattern:

// components/FilterBar.tsx (Client)
'use client';

import { useRouter, useSearchParams } from 'next/navigation';

export function FilterBar() {
  const router = useRouter();
  const searchParams = useSearchParams();

  const setFilter = (value: string) => {
    const params = new URLSearchParams(searchParams.toString());
    params.set('category', value);

    // Navigation triggers a re-run of the Server Component
    router.push(`?${params.toString()}`, { scroll: false });
  };

  return (
    <button onClick={() => setFilter('electronics')}>
      Electronics
    </button>
  );
}

// app/products/page.tsx (Server)
export default async function ProductsPage({
  searchParams,
}: {
  searchParams: Promise<{ category?: string }>;
}) {
  const { category } = await searchParams;

  // Data fetching happens on the server based on the URL
  const products = await db.products.findMany({
    where: { category },
  });

  return (
    <main>
      <FilterBar />
      <ProductGrid products={products} />
    </main>
  );
}

3. Edge Hydration & Partial Prerendering (PPR)

Next.js 16 tightens integration with the Edge Runtime. The goal is to reduce the delay between the initial HTML paint and full interactivity.

Pattern: Selective Suspense Strategy

Break your UI into hydration priorities. Don't let a slow footer block a fast header.

import { Suspense } from 'react';
import { CriticalHeader, LowPriorityFooter, ProductDetails } from './components';

export default function Page() {
  return (
    <>
      {/* 1. Static/Fastest */}
      <CriticalHeader />

      {/* 2. Dynamic - Streamed as it loads */}
      <Suspense fallback={<Skeleton />}>
        <ProductDetails />
      </Suspense>

      {/* 3. Non-critical - Lowest priority */}
      <Suspense fallback={null}>
        <LowPriorityFooter />
      </Suspense>
    </>
  );
}

4. Middleware-to-RSC Bridge (Data Interceptors)

Middleware cannot pass props directly, but you can pass data via request headers. This is perfect for geolocation, A/B testing, or auth-state passing.

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

export function middleware(request) {
  const country = request.geo?.country || 'US';
  const requestHeaders = new Headers(request.headers);
  requestHeaders.set('x-user-country', country);

  return NextResponse.next({
    request: { headers: requestHeaders },
  });
}

// app/page.tsx
import { headers } from 'next/headers';

export default async function Page() {
  const headerList = await headers();
  const country = headerList.get('x-user-country');
  const localizedContent = await fetchContent(country);

  return <div>Welcome from {country}!</div>;
}

5. The "Action Service" Pattern

To avoid "Dependency Hell," Server Actions should stay minimal. Treat them like Controllers in a modular backend—keep the business logic in a dedicated Service Layer.

Implementation:

// services/user-service.ts
export async function updateUserProfile(userId: string, data: FormData) {
  const name = data.get('name');
  // Validation and DB logic here
}

// app/profile/actions.ts
'use server';

import { updateUserProfile } from '@/services/user-service';
import { revalidatePath } from 'next/cache';

export async function updateAction(userId: string, formData: FormData) {
  await updateUserProfile(userId, formData);
  revalidatePath('/profile');
  return { success: true };
}

Conclusion: The Future is Composable

Next.js 16 reinforces that Server Components are the foundation. By mastering these patterns, you move from building pages to designing scalable systems.

What pattern are you finding most useful? Let's discuss in the comments! 👇

💡 Performance Tip:

Try using the pnpm package manager for leaner builds and next-bundle-analyzer to audit exactly what you're shipping to the client.

Did this help? Follow for more "deep-dives" into the modern web ecosystem! ✌️

React 20: The Death of useMemo? Mastering the New Compiler Era 🚀

Jubayer Hossain — Sun, 12 Apr 2026 02:26:40 +0000

For the better part of a decade, React developers have lived by a complex mental model: "When does this component re-render?" We’ve spent countless hours decorating our codebases with useMemo, useCallback, and React.memo like extra strings of holiday lights, trying to prevent unnecessary calculations. It felt like we were doing the framework's job for it.

But the era of manual performance optimization is ending. With the evolution towards React 20 and the introduction of the React Compiler, we are witnessing the most significant architectural shift since the introduction of Hooks.

1. The Problem: The "Manual Memoization" Tax

In current React development, updates are "coarse-grained." When state changes, React re-renders the component and its entire subtree unless we explicitly stop it.

To optimize, we often write code that looks like this:

const ExpensiveComponent = ({ data, onItemClick }) => {
  // Manual wrapping to prevent re-renders
  const processedData = useMemo(() => {
    return complexTransformation(data);
  }, [data]);

  const handleClick = useCallback((id) => {
    onItemClick(id);
  }, [onItemClick]);

  return (
    <List items={processedData} onClick={handleClick} />
  );
};

This approach has three fatal flaws:

Cognitive Overhead: You have to manually track dependency arrays.
Code Bloat: Business logic gets buried under boilerplate.
Fragility: Forget one variable in that [dependency] array, and you've got a stale closure or a memory leak that is a nightmare to debug.

2. Enter the React Compiler (React Forget)

The React Compiler (formerly React Forget) is a build-time tool that understands the "Rules of React" to automatically apply memoization.

Think of it as Auto-Memoization. In the React 20 era, that same expensive component simplifies to:

// Look! No useMemo or useCallback hooks.
const ExpensiveComponent = ({ data, onItemClick }) => {
  const processedData = complexTransformation(data);

  const handleClick = (id) => {
    onItemClick(id);
  };

  return (
    <List items={processedData} onClick={handleClick} />
  );
};

How it works:
The compiler transforms your standard JS code into a "reactive graph." It detects that processedData only needs recalculation if data changes. It handles the caching under the hood during the build step, so your production bundle is already optimized.

3. Why This Matters for React 20

1. Vanishing Memoization APIs

In the long term, useMemo and useCallback will become legacy tools. While React 20 maintains backward compatibility, the "happy path" will be writing plain JavaScript. This lowers the barrier for new devs and cleans up senior devs' codebases.

2. Fine-Grained Reactivity

The Compiler brings React closer to the surgical performance of "signal-based" frameworks (like SolidJS or Svelte) without actually forcing you to learn a new programming model.

3. Strict Safety

The compiler is a strict teacher. To optimize your code, it expects you to follow the core rules:

Don't mutate props.
Keep components pure.
Don't call hooks inside loops.

If it detects a violation, it safely skips optimization for that component. This effectively raises the code quality of the entire ecosystem.

4. Technical Deep Dive: The Pipeline

Under the hood, the compiler performs complex analysis on your code:

Data Flow Analysis: Tracking exactly where variables are initialized and consumed.
Alias Analysis: Checking if two variables point to the same memory location.
Inference: Identifying which values are "stable" (don't change) vs. "volatile."

The result? A "memoization slot" system that checks inputs before re-allocating memory for objects or arrays.

5. Preparing for the Compiler Era

You don't have to wait for the final React 20 release to start preparing. Here is how to stay ahead:

Enable Strict Mode: The compiler loves pure components. Strict Mode helps catch side effects early.
Lint Your Hooks: Use eslint-plugin-react-hooks. The compiler relies on the same logic these rules enforce.
Embrace Immutability: Stop mutating objects directly. Use spread operators or libraries like Immer.
Keep Components Small: Focused components are easier for the compiler (and humans) to analyze.

The Future: A "Zero-Config" Framework?

The trajectory of React 20 is clear: Complexity is moving from the developer's mind into the build tool. We are moving toward a future where "React performance" isn't a specialized skill set, but a default behavior. React is finally reclaiming its original promise: A declarative UI where you focus on what to render, not how to optimize it.

What’s your take? Are you ready to delete your useMemo hooks, or do you prefer having manual control over your re-renders? Let's discuss in the comments! 👇

If you found this deep dive helpful, follow for more insights into the React 20 ecosystem!

Beyond the Prompt: Why AI Agent Orchestration is the Next Big Skill for Developers 🤖

Jubayer Hossain — Sun, 12 Apr 2026 02:08:43 +0000

The first wave of GenAI was defined by the "Chat" interface. We marveled at LLMs that could write poems or summarize emails. But for developers, the novelty of a single prompt-response cycle wore off quickly.

We realized that for AI to solve complex, real-world problems—like managing a supply chain or debugging a full-stack app—a single inference call isn't enough. We are now entering the era of Agentic Workflows. Here, the LLM is no longer just a chatbot; it is the reasoning engine at the center of a sophisticated orchestration framework.

Think of it like a Construction Site: You don't just tell one person "Make me a house." You need a site manager, an architect, an electrician, and a plumber. They talk to each other, fix each other's mistakes, and work until the house is standing.

1. The Shift from Linear Chains to Cyclic Graphs

Early LLM development relied on "Chains" (made famous by LangChain). A chain is a linear sequence: Prompt -> LLM -> Tool -> Output.

While useful, chains are brittle. They can't loop back or self-correct. Agent Orchestration solves this by building Multi-Agent Systems (MAS) where specialized agents collaborate and iterate until a goal is met.

2. The Pillars of Modern Orchestration

To build production-grade agents, we need more than just a "black box." We need control:

State Management: This is the "Shared Memory" of the team. If the 'Researcher Agent' finds a bug, the 'Coder Agent' needs that specific log.
Control Loops & Feedback: Agents fail. They hallucinate. An orchestration framework allows for self-correction loops. If a 'Tester Agent' fails a unit test, the system loops back to the 'Coder' with the error logs.
Human-in-the-loop (HITL): Enterprise autonomy requires oversight. Frameworks now allow for "interrupts"—the agent pauses to ask for human approval before doing something sensitive (like pushing code to production).

3. LangGraph: The Precision Instrument

Developed by the LangChain team, LangGraph treats workflows as a directed graph. It’s built for developers who need granular control over "nodes" (agents) and "edges" (logic).

# A conceptual snippet of LangGraph orchestration
from langgraph.graph import StateGraph, END

# Define the workflow state (Shared Memory)
class AgentState(TypedDict):
    task: str
    plan: str
    draft: str
    critique: str
    iterations: int

workflow = StateGraph(AgentState)

# Add nodes (The "Specialists")
workflow.add_node("planner", planner_agent)
workflow.add_node("writer", writer_agent)
workflow.add_node("critic", critic_agent)

# Define the path
workflow.set_entry_point("planner")
workflow.add_edge("planner", "writer")
workflow.add_edge("writer", "critic")

# The Logic: Should we finish or try again?
workflow.add_conditional_edges(
    "critic",
    should_continue,
    {
        "continue": "writer",
        "end": END
    }
)

4. The Strategic Importance of Multi-Agent Systems (MAS)

Why use three agents when one will do?

Reduction of Hallucinations: When an agent is focused on a narrow task (e.g., "Just check syntax"), it's less likely to drift.
Specialized Tooling: You can give a 'Data Scientist Agent' access to a Python REPL, while giving the 'HR Agent' access to your internal database. No clutter, no tool-misuse.
Parallelism: Agents can execute tasks in parallel, cutting down the "Time to Result" significantly.

5. Challenges: It's Not All Magic

Orchestration comes with a cost:

Latency: Every "loop" or handoff requires a round-trip to the LLM.
Cost: More tokens = more money.
Observability: When an agent fails at step 14 of 20, you need tools like LangSmith to find out where the state got corrupted.

Conclusion: Building for the Future

The transition from "AI as a tool" to "AI as a workforce" is here. For developers, the skill of the future isn't just writing better prompts—it's designing better systems. Your Next Step: Start small. Instead of an autonomous "CEO Agent," build a 2-agent system: a Researcher and a Fact-Checker. Watch them argue, fix each other, and produce quality results.

Are you building with LangGraph, CrewAI, or AutoGPT? What's your biggest struggle in orchestration? Let's discuss in the comments! 👇

If you found this helpful, follow for more deep-dives into the AI engineering ecosystem!

Beyond Shifting Prompts: The Rise of AI Agent Orchestration Frameworks 🤖

Jubayer Hossain — Sun, 12 Apr 2026 02:04:09 +0000

The initial wave of Generative AI integration was dominated by the "Chatbot" paradigm—a linear, stateless exchange where a user asks, and an LLM answers. But as we move into 2026, the industry is pivoting toward Agentic Workflows. We are no longer satisfied with models that just talk; we want systems that do.

However, building a reliable AI agent is notoriously difficult. Loops become infinite, state management gets messy, and "hallucination" in a tool-calling sequence can lead to catastrophic system failures. This complexity has birthed a new layer of the tech stack: AI Agent Orchestration Frameworks.

1. The Shift: From Chains to Loops

Early implementations relied on "Chaining" (the early days of LangChain). A chain is a predefined, linear sequence: Step A feeds into Step B.

The problem? Real-world work is rarely linear. If a developer is debugging code, they don't just run one command. They run a test, see the error, and loop back to fix the code.

Agentic Workflows introduce "iterative reasoning." Instead of a straight line, the workflow is a Directed Acyclic Graph (DAG) or even a cyclic graph. This self-correction loop is what differentiates a simple script from a true AI Agent.

Key Pillars of Orchestration:

State Management: Keeping track of the "memory" across multiple iterations.
Planning: Breaking a high-level goal into sub-tasks.
Tool Use: Standardized interfaces for APIs, databases, and browsers.
Human-in-the-loop (HITL): Hooks for humans to approve or correct an agent's path.

2. LangGraph: Cycles as First-Class Citizens

LangGraph is the answer to the critique that standard chains are too rigid. It treats agentic workflows as a State Graph, allowing for cycles and persistence.

In LangGraph, you define Nodes (functions) and Edges (conditional logic). Because it’s built on a persistent state, you can "pause" an agent, save the state to a database, and resume it days later.

from langgraph.graph import StateGraph, END

# 1. Define the state shape (Shared Memory)
class AgentState(TypedDict):
    messages: Annotated[list[BaseMessage], operator.add]

# 2. Define the Graph
workflow = StateGraph(AgentState)

# 3. Add nodes (The "Workers")
workflow.add_node("agent", call_model)
workflow.add_node("action", call_tool)

# 4. Define edges (The "Logic")
workflow.set_entry_point("agent")
workflow.add_conditional_edges(
    "agent",
    should_continue,
    {
        "continue": "action",
        "end": END
    }
)
workflow.add_edge("action", "agent") # This creates the loop!

app = workflow.compile()

3. Multi-Agent Systems: Specialization Beats Generalization

One of the biggest shifts in AI engineering is realizing that one "God-mode" LLM is less effective than a squad of specialists.

Instead of asking one model to do everything, frameworks like CrewAI or AutoGen allow you to create a team:

The Coder Agent: Optimized for syntax and logic.
The QA Agent: Optimized for bug hunting.
The Architect: Maintains the vision and orchestrates the flow.

By assigning different System Prompts and Tools to different agents, you reduce the "cognitive load" on any single LLM call, drastically increasing reliability.

4. Architecting for Reliability (The 3 Patterns)

Orchestration isn't just about making things work; it's about making them work consistently.

The Guardrail Pattern: Never let an agent execute output directly. Validate the schema in the orchestration layer first.
The Reflection Pattern: Before finishing, have the agent (or a separate "Critic" agent) inspect the result. "Is this output grounded in the provided data?"
The Replay Pattern: Agentic runs are expensive. Your framework should support "checkpointing" so you can resume from the last successful step if a tool call fails.

Conclusion: Designing Systems, Not Just Prompts

We are shifting from a world of "AI as a tool" to "AI as a teammate." However, a teammate without a project manager is just a source of chaos. Orchestration frameworks are that project management layer.

For developers, the challenge is no longer just writing the best prompt. The challenge is designing the best system.

Are you ready to stop chaining and start orchestrating? Start by mapping your most complex manual process today. That map is the blueprint for your first stateful agent.

What's your go-to framework for agents right now? Let's discuss in the comments! 👇

Next.js 16: The End of Manual Optimization and the Rise of the React Compiler 🚀

Jubayer Hossain — Sun, 12 Apr 2026 02:02:25 +0000

The landscape of modern web development is shifting beneath our feet. For years, the "React Mental Model" required significant overhead: manual optimization. We’ve spent countless hours debating the placement of useMemo, useCallback, and debugging re-renders caused by referential instability in dependency arrays.

With Next.js 16 and the stabilization of the React Compiler, that era is officially over. This release represents the most significant shift in React's philosophy since Hooks. We are moving from a world of "manual optimization" to "auto-memoization."

1. The Stable React Compiler: Rethinking Reactivity

The star of the show is the React Compiler (originally code-named "React Forget"). It is now stable and ready for production workloads in Next.js 16.

What it solves

React traditionally re-renders a component and all its children whenever state changes. To prevent performance bottlenecks, we had to manually memoize components (React.memo) or values (useMemo).

The React Compiler shifts this responsibility to the build tool. It parses your code and automatically inserts memoization, ensuring components only re-render if their actual data changes, regardless of referential equality.

How to Opt-In

Next.js 16 makes enabling the compiler seamless. First, update your dependencies:

pnpm add next@latest react@latest react-dom@latest

Then, update your next.config.js:

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};

module.exports = nextConfig;

The "Rules of React" are Mandatory

The compiler isn't magic; it's an auditor. It relies on your code following the Rules of React (e.g., no mutations during render). If a component violates these rules, the compiler will gracefully skip it and fall back to standard behavior.

Pro Tip: Use eslint-plugin-react-compiler to catch violations in your IDE before hitting the build step.

2. Partial Prerendering (PPR): The Best of Both Worlds

In Next.js 16, Partial Prerendering (PPR) moves into a polished, stable state. It solves the "Static vs. Dynamic" tradeoff, allowing you to render a static shell immediately while leaving "holes" for dynamic content that gets streamed in.

Implementation

With PPR, you wrap dynamic components in a Suspense boundary. Next.js 16 will statically pre-render everything outside that boundary at build time.

import { Suspense } from 'react';
import { StaticHeader, SkeletonCart } from './components';
import DynamicCartDetails from './components/dynamic-cart';

export default function Page() {
  return (
    <main>
      <StaticHeader /> {/* Rendered statically at build time */}

      <Suspense fallback={<SkeletonCart />}>
        <DynamicCartDetails /> {/* Streamed dynamically on request */}
      </Suspense>
    </main>
  );
}

To enable PPR for specific routes, you can export a configuration constant:

export const experimental_ppr = true;

3. Strengthening Server Actions Security

Server Actions have transformed how we handle mutations, but as RPC-like functions, they require robust security. Next.js 16 introduces Secure Action Ref and the Taint API.

Automatic Tainting

The taint API prevents sensitive server-side objects (like raw database records) from accidentally being passed to the client.

import { experimental_taintObjectReference } from 'react';

export async function getUserData(id: string) {
  const user = await db.users.get(id);

  // This prevents the whole user object (including hashed password)
  // from ever leaking to a Client Component.
  experimental_taintObjectReference(
    'Do not pass the raw user object to the client!',
    user
  );

  return user;
}

4. Improved Hydration Error Reporting

We’ve all been there: Hydration failed because the initial UI does not match...

Next.js 16 introduces an overhauled error overlay for hydration mismatches with a Diff View. It highlights the exact element causing the mismatch and shows the difference between the Server-rendered HTML and the Client-rendered DOM. This turns hours of "inspect element" hunting into seconds.

5. Performance Metrics at Build Time

The new "Build Summary" view in Next.js 16 provides a granular breakdown of your bundle:

First Load JS per route.
Shared Bundles: Which dependencies are common across all pages.
Compiler Impact: A report showing how many components were successfully optimized versus those skipped.

Conclusion: A New Era of DX

Next.js 16 isn't just an incremental update; it's a structural shift. The React Compiler removes a layer of manual complexity that has defined React development for years. PPR provides the ultimate performance architecture by default, and the Security Layer ensures we build fast without being reckless.

The move to Next.js 16 is as much about deleting code (goodbye useMemo dependency arrays) as it is about adding features.

Ready to upgrade? Start by running the compiler on a small feature branch. The performance gains in your Lighthouse score—and the mental clarity of not writing manual memoization—are well worth the transition.

What’s your take? Is the React Compiler the end of manual optimization, or do you still prefer manual control? Let’s discuss below! 👇

Beyond Chatbots: The Rise of Autonomous AI Agent Orchestration 🚀

Jubayer Hossain — Sat, 11 Apr 2026 10:28:16 +0000

The first wave of Generative AI was defined by the "Chat" interface. We learned to prompt, we learned to iterate, and we marveled at an LLM's ability to summarize or synthesize text. But for developers building production-grade apps, a single prompt-response cycle is rarely enough.

We are now entering the era of Agentic Workflows. It is no longer about finding the perfect "golden prompt"; it is about designing systems where multiple AI agents—each with specific roles, tools, and constraints—collaborate to achieve a high-level goal.

In this post, we’ll dive deep into the architecture of Autonomous AI Agent Orchestration, why the industry is moving toward multi-agent systems, and the tools making this possible.

1. The Shift: From Linear to Agentic Workflows

Traditional software follows a linear path: Input -> Process -> Output. When we first integrated LLMs, we followed a similar pattern. However, complex tasks—like writing a software feature or managing a supply chain—require loops, corrections, and specialization.

The Problem with Single-Agent Systems

Early autonomous experiments (like the original AutoGPT) demonstrated the "wow" factor but often fell into infinite loops or "hallucination spirals." Why? Because a single LLM was trying to be the planner, the executor, and the critic all at once.

Agentic Workflows solve this by breaking tasks down. As Andrew Ng recently noted, agentic workflows can often help older models (like GPT-3.5) outperform a zero-shot prompt from a state-of-the-art model (like GPT-4).

2. Core Pillars of Multi-Agent Systems (MAS)

To build a coordinated agent team, you need four structural pillars:

Role Specialization: An agent is an LLM wrapped in a specific system prompt with specific tools.
- The Architect: Breaks objectives into sub-tasks.
- The Researcher: Gathers data via Search APIs.
- The Reviewer: Validates output against requirements.
State Management: This is the "shared memory." Agents need to know what their peers have already done to avoid redundant work.
Planning and Reasoning: Using patterns like Chain-of-Thought (CoT) or ReAct, where the agent "thinks" before calling a tool.
Human-in-the-Loop (HITL): Autonomy doesn't mean zero supervision. Good orchestration allows for "interrupts" where a human approves a plan before compute credits are spent.

3. Orchestration Patterns: From Chains to Graphs

The Problem with DAGs

Many early tools used Directed Acyclic Graphs (DAGs). These are great for pipelines but struggle with cycles. In the real world, if a "Reviewer" finds a bug, the "Coder" needs to go back and try again.

LangGraph: Cycles as a First-Class Citizen

LangGraph (by the LangChain team) allows you to define a state machine where nodes are actions and edges define the transition logic—including loops.

from langgraph.graph import StateGraph, END

# 1. Define the Shared State
class AgentState(TypedDict):
    task: str
    plan: list
    draft: str
    critique: str
    iterations: int

# 2. Build the graph logic
workflow = StateGraph(AgentState)
workflow.add_node("planner", planner_node)
workflow.add_node("worker", worker_node)
workflow.add_node("critic", critic_node)

# 3. Define transitions
workflow.set_entry_point("planner")
workflow.add_edge("planner", "worker")
workflow.add_edge("worker", "critic")

# Conditional logic: Loop back to worker or end
workflow.add_conditional_edges(
    "critic",
    should_continue,
    {"continue": "worker", "end": END}
)

app = workflow.compile()

4. The Evolution of AutoGPT-2

The shift from the original AutoGPT to AutoGPT-2 reflects a pivot toward "Agent-as-a-Service." The focus is no longer just a cool CLI tool, but a framework emphasizing:

Modular Architecture: Pluggable components for memory and toolsets.
Pathfinding: Improved navigation to prevent "infinite loop" traps.
Benchmarking: Using AgentBench to measure real task completion versus just "looking busy."

5. Challenges in Orchestration

Orchestration isn't a silver bullet. It introduces new hurdles:

Latency: Every agent turn is an LLM call. Multi-agent runs can take minutes.
Cost: Token consumption scales with the number of agents and their "chatter."
Observability: Debugging a failure at step 10 of a 20-step graph is a nightmare without tools like LangSmith or Arize Phoenix.

Conclusion: Designing the "AgOps" Future

We are moving toward a new discipline: AgOps (Agentic Operations). This involves version control for agents, observability, and prompt sandboxing.

The win is not in building one agent that can do everything, but in building a robust orchestration layer that knows which specialist to call, how to handle the feedback loop, and when to ask a human for help.

Your Next Step: Stop trying to write the "perfect prompt." Start mapping out a workflow as a graph. Identify the loops, the decision points, and the tools. The future of software is coordination.

Are you building with LangGraph or CrewAI? What's your biggest bottleneck? Let's talk in the comments!