What are the real differences between Vibe Coding and Agentic Engineering?

This is the part most explainers get wrong. They describe agentic engineering as “using better AI tools” or “more automation.” That’s not it.

Vibe coding means going with the vibes and not reviewing the code. That’s the defining characteristic. You prompt, you accept, you run it, you see if it works. If it doesn’t, you paste the error back in and try again.

The problem isn’t the AI. The problem is the human not reviewing what the AI built.

Agentic engineering means AI does the implementation, human owns the architecture, quality, and correctness. You might write only a fraction of the code by hand. The rest comes from agents working under your direction. That’s agentic. And you’re applying engineering discipline throughout.

Same tools. Completely different discipline.

The one-line distinction:

Vibe coding = YOLO. Agentic engineering = AI builds, human owns.

What is Harness Engineering?

To understand where harness engineering fits, here’s how it relates to the other disciplines you’ve probably heard about:

• Prompt Engineering → Single interaction to craft the best input to the model (single request-response interaction).

• Context Engineering → Control what the model sees during a whole session (multiple interactions until clearing).

• Harness Engineering → Designs the environment, tools, guardrails, and feedback loops (multiple sessions).

• Agent Engineering → Design the agent’s internal reasoning loop (define specialized agents).

• Platform Engineering → Infrastructure to manage deployment, scaling, and cloud operations (where agents can run).

Prompt engineering is about what you say to the model.

Context engineering is about what the model sees.

Harness engineering is about the entire world the model operates in. It includes the tools the agent can call, the constraints it cannot violate, the documentation structure it reads, and the automated feedback loops that catch its mistakes before they reach production

What is the llm.txt for?

llm.txt is a site-level instruction file for AI/LLM agents, like robots.txt but for models. It tells models what the site is about and which sources to prioritize. Example: a site could point models to its official docs and API reference; the spec and examples are described at https://llmstxt.org/ (which you can follow to publish your own).

What even is the difference? They all seem like "AI configuration stuff."

Yep, fair. Think of it this way:

• Instructions = Passive rules are always applied in the background

• Agents = Custom AI personas you manually switch into

• Skills = Step-by-step playbooks you explicitly invoke for a specific task

So instructions just... always run?

Yes — automatically. The applyTo frontmatter pattern controls when they're injected. For example, context-engineering.instructions.md has applyTo: '**' so it's always active. The nextjs.instructions.md has applyTo: '**/*.tsx, **/*.ts, ...' so it only kicks in when you're editing TypeScript/JSX files.

You don't call them. Copilot just silently reads them and adjusts its suggestions accordingly. They're like a standing memo on your desk — always there.

When would I actually switch to a custom agent mode?

When you want a fundamentally different persona and toolset for a session. Look at debug.agent.md — it locks in a specific tool list (terminal, tests, problems panel) and a structured debugging workflow. Or expert-nextjs-developer.agent.md — it declares expertise, forces certain behaviors, and even pins a model (GPT-4.1).

Basically: use an agent when "default Copilot" isn't the right mindset for the job. Debugging, writing a PRD, doing a technical spike — those all benefit from a mode switch.

What about skills — do those auto-load like instructions?

Nope. Skills are NOT automatically loaded. They're on-demand playbooks. You invoke them explicitly by referencing them in a prompt, or by having an agent that knows to use them.

For example, conventional-commit won't do anything unless you tell Copilot "use the conventional-commit skill" or you build it into an agent's workflow. Think of skills as reusable procedures stored in a drawer — they only run when someone pulls them out.

What's the loading order/hierarchy when Copilot runs?

Roughly:

1. copilot-instructions.md — loaded first, always, the main entry point

2. .github/instructions/*.instructions.md — auto-applied based on applyTo matching your open file

3. .github/agents/*.agent.md — only loaded when you explicitly switch to that agent mode in the Copilot chat panel

4. .github/skills/*/SKILL.md — only loaded when explicitly invoked

When do I use each?

• Instructions: Set-and-forget rules (tech constraints, code style, a11y rules, security guidelines)

• Custom Agent: When you need a different "mode" — debugging, planning, writing specs

• Skill: When you have a repeatable multi-step workflow you want to reuse without re-explaining every time

What is AGENTS.md, and who is it for?

AGENTS.md is a universal guide following the agents.md open spec. It targets any AI coding agent (Claude, Gemini, OpenAI Codex, etc.) and covers setup commands, project structure, testing patterns, and workflow — anything tool-agnostic.

What is copilot-instructions.md, and who is it for?

It's a GitHub Copilot-specific file loaded automatically by VS Code. It focuses on IDE-level code generation rules: version constraints, ❌ NEVER / ✅ ALWAYS generation constraints, and pointers to granular context files in the copilot with applyTo glob patterns.

What content belongs in each file?

Should they duplicate content?

No. copilot-instructions.md should delegate to AGENTS.md for shared content to avoid drift. Your current setup already does this correctly

What is the single most important design principle?

AGENTS.md is the single source of truth for project facts. copilot-instructions.md is a Copilot-specific lens on top of it — not a copy.

Why shouldn't we let AI write the AGENTS.md?

This is the big one. Research has shown (Gloaguen et al., ETH Zurich) that LLM-generated AGENTS.md files offer no benefit and can marginally reduce success rates (~3% on average) while increasing inference costs by over 20%. Developer-written context files, by contrast, provide a modest ~4% improvement. Never let an agent write to AGENTS.md directly. The lead must approve every line. Keep it shorter with clear sections:

https://addyosmani.com/blog/agents-md/

Why does AI-generated AGENTS.md increase the cost of AI?

Here’s the core problem with auto-generated context files. What does /init produce? Codebase overviews. Directory structure. Tech stack description. Module explanations. The ETH Zurich paper found that 100% of Sonnet 4.5’s auto-generated context files contained codebase overviews. 99% of GPT-5.2’s did the same.

These are precisely the things an agent can discover on its own by listing directories and reading your existing READMEs - which it does anyway, regardless of whether AGENTS.md exists. So you’ve added a file that the agent reads, then goes and confirms by reading your actual code, and now has to reconcile two sources of truth. More reasoning tokens. More steps. Same outcome, except slower and more expensive.

What information should we put in the AGENTS.md?

The practical filter is simple: can the agent discover this on its own by reading your code? If yes, delete it. Every line should represent information that isn’t already in the repo.

That means your AGENTS.md should look more like:

• Use uv for package management

• Always run tests with –no-cache or you’ll get false positives from the fixture setup

• The auth module uses a custom middleware pattern; do not refactor to standard Express middleware

• The legacy/ directory is deprecated but imported by three production modules - don’t delete anything in it

And almost nothing else.

What is the right mindset of AGENTS.md?

• Stop running /init. The auto-generated output is redundant with your existing documentation and adds overhead without benefit, unless your repo has genuinely zero documentation - in which case it’s marginally better than nothing.

• Before adding any line to AGENTS.md, ask: can the agent find this by reading the code? If yes, don’t write it.

• When an agent struggles with something repeatedly, treat it as a codebase problem before treating it as a context problem. Restructure the code. Add a linter rule. Improve the test coverage. Reach for AGENTS.md only after you’ve exhausted those options.

• If you’re running agents at scale in CI/CD or automated review pipelines, the 15-20% cost overhead from context files compounds across thousands of runs. Calculate it before assuming the tradeoff is worth it.

• Consider building a maintenance agent whose job is keeping the context file accurate rather than letting it rot.

• And hold your intuitions about what the agent needs loosely. What seems obviously useful to you might be noise to the model. The empirical evidence suggests the gap between what we think agents need and what actually helps them is substantial - and probably not in the direction we’d expect.

• The instinct to onboard your coding agent like a new hire - give it the office tour, explain the org chart, walk it through the architecture - comes from a reasonable place. But coding agents aren’t new hires. They can grep the entire codebase before you finish typing your prompt. What they need isn’t a map. They need to know where the landmines are.

• One technique worth trying: start your AGENTS.md nearly empty, and add a single instruction: “If you encounter something surprising or confusing in this project, flag it as a comment.” Most of the agent’s proposed additions aren’t things you want to keep permanently - they’re indicators of where the codebase is unclear. Fix those. Keep the file minimal.

Why do AI Agents fail on large files?

Large Language Models are probabilistic engines. They predict the next token based on patterns in their context window. When the context window is filled with thousands of lines of structured data, the model’s attention gets diluted. It correctly identifies the node you want to modify, but it loses track of sibling keys, nested brackets, and structural integrity. The result is a file that looks right at the point of change but is broken somewhere else.

What are the common issues that lead to AI failures?

The AI breaks in five specific ways:

1. Hallucination from missing context: The agent doesn’t have the information it needs, so it fills the gap with confident fiction. You asked for a login page and it invented an auth library that doesn’t exist.

2. State loss in long workflows: At 10K tokens, the agent is sharp. At 150K, it forgets you wanted dark mode and rebuilds the entire UI in blinding white. Three times.

3. Tool misuse: Wrong tool, bad parameters, or just ignoring the output entirely. The agent has access to 15 tools and picks the worst one for the job.

4. Unproductive loops: Same failed approach, over and over. Burning tokens with zero progress. The agent version of pulling a door that says “push.”

5. Silent failure at scale: Here’s the math nobody mentions: if your agent is 95% accurate per decision and makes 20 decisions per task, it fails more often than it succeeds. Small inaccuracies compound. At production scale, 95% isn’t good enough.

Why do our AI agents get worse over time due to the increase in context window?

LLM output quality degrades as context fills. This isn’t a bug. It’s a property of how transformer attention works. Sharp at 10K tokens. Noticeably worse at 150K on the same tasks.

Think of context management like packing for a backpacking trip. You could bring your entire wardrobe. You’d move slowly and nothing would be easy to find. Pack light instead. Know where to resupply.

In context (what you carry): system prompt, instruction files, skill headers, the current task.

On disk (available when needed): full file contents, web search results, codebase, git history. The agent loads these on demand through tools.

In practice, you’ll find that system prompts, MCP tool definitions, and memory files can eat 8-9K tokens before you’ve typed a word. That’s context space not available for reasoning. Audit regularly. Trim what you can.

Compaction happens when the context hits its limit. The platform summarizes your conversation to free space. It works, but details get lost. Early decisions compress. Tool outputs disappear. Don’t let it surprise you — manage context proactively so the agent doesn’t lose important state at the worst moment.

How many levels of applying AI Agents in coding work?

Steve Yegge recently described eight stages of how developers grow with AI tools. It's a helpful way to see where you are and where you're going.

Most developers are at Level 3-4. Level 6 begins the orchestration stage, needing different skills than Level 5.

What is the shift from conductor to orchestrator?

In the conductor setup, you work with one AI agent in real-time, kind of like pair programming. It's all about guiding that single agent, and everything happens one step at a time within a fixed context. Tools like Claude Code CLI and Cursor's in-editor mode fit this style.

Switching to the orchestrator model is like managing a whole team. You've got multiple agents, each doing their thing with their own context, and they're working independently. You plan everything out, assign tasks, and check in now and then. Tools like Agent Teams, Conductor, Codex, and Copilot Coding Agent are perfect for this approach.

What are the single-agent limits?

Every developer eventually runs into three main issues with a single agent: context overload, lack of specialization, and zero coordination. Subagents tackle the first two, while Agent Teams handle all three.

Why can't one agent handle everything? There are three main reasons.

First, context overload. A single agent can only process so much info. Large codebases can overwhelm it, causing you to lose important details as the conversation drags on.

Second, lack of specialization. When one agent tries to do it all—data layer, API, UI, tests—it becomes a jack of all trades, master of none. An agent focused solely on the data layer, for instance, will write much better database code than a generalist trying to juggle everything.

Lastly, no coordination. Even if you bring in helpers, they can't communicate, share tasks, or manage dependencies. Adding more agents without coordination just makes things messier.

Why do we need multi-agents?

Parallelism, specialization, isolation, and compound learning don't just add up—they multiply. Three focused agents consistently do better than one generalist working three times as long.

Four reasons to use multiple agents:

Parallelism (3x speed) - Three agents work on frontend, backend, and tests at the same time.

Specialization (focused work) - Each agent handles only its own files. An agent focused on db.js writes better database code than one managing everything.

Isolation (safe work) - Git worktrees give each agent its own space. No merge conflicts while they work.

Compound learning - An AGENTS.md file collects patterns and tips, improving each session.

What is the Subagents pattern?

Subagents are the simplest multi-agent pattern and the one you should try first.

Subagents use the Task tool to spawn specialized child agents from a parent orchestrator. The parent decomposes a task into pieces, spawns subagents for each piece, and manages the dependency graph manually.

What subagents solve: context isolation per agent, specialization, parallel execution for independent tasks, and it's cost-neutral at roughly 220k tokens total.

What is still missing: the parent must manually manage the dependency graph. There's no peer messaging between agents. There's no shared task list. And if you're sloppy about file scoping, two agents could write to the same file.

Bottom line: subagents give you parallel execution with manual coordination. That is great for simple decomposition. But when coordination becomes the bottleneck, you need Agent Teams.

The pro tip of working with hierarchical subagents?

Don't just delegate once. Create feature leads that have their own specialists. This allows for deeper task breakdown without overwhelming anyone.

Instead of the orchestrator creating six subagents, it should create two feature leads. Each lead then creates two or three specialists.

The main orchestrator only communicates with two agents, keeping things simple. Feature Lead A, for example, gets the task "Build the search feature" and breaks it down into Data, Logic, and API subagents. The main orchestrator doesn't need to know these details.

This approach is similar to real engineering teams, where tasks are assigned through layers of tech leads, not directly from the VP of Engineering to individual engineers.

What is the Agent Team pattern?

Agent Teams add the coordination primitives that subagents lack: a shared task list with dependency tracking, peer-to-peer messaging between teammates, and file locking to prevent conflicts.

Agent Teams are Claude Code's experimental feature for true parallel execution. Enable it with:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

The architecture has three layers:

1. Team Lead at the top - decomposes work, creates the task list, synthesizes results

2. Shared Task List in the middle - tasks with statuses (pending, in_progress, completed, blocked), dependency tracking, and file locking

3. Teammates at the bottom - each an independent Claude Code instance with its own context window, running in tmux split panes

Teammates self-claim tasks from the shared list. They message each other directly - peer-to-peer, not through the lead. When a teammate finishes and marks a task complete, any blocked tasks that depended on it automatically unblock. Press Ctrl+T at any time to toggle a visual overlay of the task list.

How does the Agent Teams work?

Two mechanisms make Agent Teams work: a shared task list with automatic dependency resolution, and peer-to-peer messaging that prevents the lead from becoming a bottleneck.

The shared task list gives each task a status: pending, in_progress, completed, or blocked. Blocked tasks have explicit dependencies. When the backend teammate marks the search API as completed, the blocked test-writing task automatically flips to pending and a teammate picks it up. File locking prevents two teammates from editing the same file simultaneously.

Peer messaging is the other critical piece. The backend agent tells the frontend agent the API contract directly: "GET /search?q= returns [{id,title,url}]." This doesn't go through the lead. When a teammate goes idle, the lead is automatically notified. This peer-to-peer approach prevents the lead from becoming a coordination bottleneck.

How can you manage with 5, 10, or 20+ agents across multiple repos and features?

When you need to manage 5, 10, or 20+ agents across multiple repos and features, you need purpose-built orchestration tools. Every tool in 2026 fits one of three tiers - pick the right tier for the job.

The 2026 tool landscape breaks into three tiers:

Tier 1: In-process subagents and teams

Claude Code subagents and Agent Teams. Single terminal session, no extra tooling needed. Start here.

Tier 2: Local orchestrators

Your machine spawns multiple agents in isolated worktrees. You stay in the loop with dashboards, diff review, and merge control. Best for 3-10 agents on known codebases. Tools include Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, and Cursor Background Agents.

Tier 3: Cloud async agents

Assign a task, close your laptop, return to a pull request. Agents run in cloud VMs. No terminal, no local setup. Tools include Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, and Codex Web by OpenAI.

Most developers in 2026 will use all three tiers - Tier 1 for interactive work, Tier 2 for parallel sprints, Tier 3 to drain the backlog overnight.

How do we keep shipping the high-quality code when working with multiple agents?

Three quality gates make agent output trustworthy: plan approval catches bad architecture before code exists, hooks enforce automated checks on every lifecycle event, and AGENTS.md compounds learning across sessions.

Plan approval. Require teammates to write a plan before they start coding. The lead reviews the approach and approves or rejects. It's far cheaper to fix a bad plan than to fix bad code. The flow looks like:

teammate >>> writes plan >>> lead review >>> approve/reject >>> implement

Hooks. Automated checks on lifecycle events. A TeammateIdle hook verifies all tests pass before allowing an agent to stop working. A TaskCompleted hook runs lint and tests before marking a task as done. If the hook fails, the agent keeps working until it passes:

task done >>> hook runs npm test >>> pass? allow  |  fail? keep working

AGENTS.md for compound learning. This file captures discovered patterns, gotchas, and style preferences. Every agent reads it at the start of a session, and every session adds to it. Session one learns about a testing pattern, AGENTS.md is updated, session two avoids the same mistake.

What is the Ralph Loop?

The Ralph Loop pattern breaks development into small atomic tasks and runs an agent in a stateless-but-iterative loop. Each iteration: pick task, implement, validate, commit if pass, reset context and repeat. This avoids context overflow while maintaining continuity through external memory.

The five-step cycle:

1. Pick - select the next task from tasks.json

2. Implement - make the change

3. Validate - run tests, types, lint

4. Commit - if checks pass, commit and update task status

5. Reset - clear the agent context and start fresh with the next task

The key insight is stateless-but-iterative. By resetting each iteration, the agent avoids accumulating confusion. Small bounded tasks produce cleaner code with fewer hallucinations than one enormous prompt.

AI Tips

Establish AI guidelines for the project

=> Review the guidelines on instructions, agents, and skills from the Awesome Copilot GitHub repository, identify the useful ones, and download them to our source code. To simplify the download process, install the awesome Copilot extension from the VS Code marketplace. After downloading the guidelines, carefully review them to ensure they fit our codebase.

There are some useful GitHub repos that we can refer to for useful AI Agent guidelines: https://github.com/anthropics/skills/tree/main, https://github.com/obra/superpowers, https://github.com/addyosmani/agent-skills, https://github.com/codejunkie99/agentic-stack

Below are some AI guidelines from the GitHub Copilot repository that I use the most:

Copilot Instructions

• code-review-generic.instructions.md: Instructions for creating effective and portable Agent Skills that enhance GitHub Copilot with specialized capabilities, workflows, and bundled resources.

• context-engineering.instructions.md: Principles for helping GitHub Copilot understand your codebase and provide better suggestions.

• context7.instructions.md: Use Context7 proactively whenever the task depends on authoritative, current, version-specific external documentation that is not present in the workspace context.

• markdown-accessibility.instructions.md: Markdown accessibility guidelines based on GitHub's 5 best practices for inclusive documentation

• markdown.instructions.md: Markdown formatting aligned to the CommonMark specification (0.31.2).

• memory-bank.instructions.md: Coding standards, domain knowledge, and preferences that AI should follow.

• nextjs-tailwind.instructions.md: Instructions for high-quality Next.js applications with Tailwind CSS styling and TypeScript.

• nextjs.instructions.md: Best practices for building Next.js (App Router) apps with modern caching, tooling, and server/client boundaries (aligned with Next.js 16.1.1).

• performance-optimization.instructions.md: The most comprehensive, practical, and engineer-authored performance optimization instructions for all languages, frameworks, and stacks.

• security-and-owasp.instructions.md: Comprehensive secure coding instructions for all languages and frameworks, based on OWASP Top 10 and industry best practices.

Custom Agents

• 4.1-Beast.agent.md: It is a custom “agent profile” that tells Copilot how to behave: keep working until the task is fully solved, use lots of research (including web fetches), plan with to-do lists, test rigorously, and follow specific workflow rules. In short, it is a strict, autonomous mode configuration for long, research-heavy tasks.

• Thinking-Beast-Mode.agent.md: A transcendent coding agent with quantum cognitive architecture, adversarial intelligence, and unrestricted creative freedom.

• aem-frontend-specialist.agent.md: IExpert assistant for developing AEM components using HTL, Tailwind CSS, and Figma-to-code workflows with design system integration

• blueprint-mode.agent.md: Executes structured workflows (Debug, Express, Main, Loop) with strict correctness and maintainability. Enforces an improved tool usage policy, never assumes facts, prioritizes reproducible solutions, self-correction, and edge-case handling.

• critical-thinking.agent.md: Challenge assumptions and encourage critical thinking to ensure the best possible solution and outcomes.

• debug.agent.md: Debug your application to find and fix a bug.

• demonstrate-understanding.agent.md: Validate user understanding of code, design patterns, and implementation details through guided questioning.

• devils-advocate.agent.md: I play the devil's advocate to challenge and stress-test your ideas by finding flaws, risks, and edge cases

• expert-nextjs-developer.agent.md: Expert Next.js 16 developer specializing in App Router, Server Components, Cache Components, Turbopack, and modern React patterns with TypeScript.

• expert-react-frontend-engineer.agent.md: Expert React 19.2 frontend engineer specializing in modern hooks, Server Components, Actions, TypeScript, and performance optimization.

• principal-software-engineer.agent.md: Provide principal-level software engineering guidance with focus on engineering excellence, technical leadership, and pragmatic implementation.

• refine-issue.agent.md: Refine the requirement or issue with Acceptance Criteria, Technical Considerations, Edge Cases, and NFRs

Agent Skills

• PatternsDev/skills: Patterns.dev JavaScript Skills: 58 Agent Skills bringing JS, React, and Vue design patterns into your agentic coding workflow!

• agentic-eval: Patterns and techniques for evaluating and improving AI agent outputs.

• architecture-blueprint-generator: Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation

• autoresearch: Autonomous iterative experimentation loop for any programming task.

• breakdown-epic-arch: Prompt for creating the high-level technical architecture for an Epic, based on a Product Requirements Document.

• chrome-devtools: Expert-level browser automation, debugging, and performance analysis using Chrome DevTools MCP. Use for interacting with web pages, capturing screenshots, analyzing network traffic, and profiling performance.

• context-map: Generate a map for all relevant files to a task before making changes

• conventional-commit: Prompt and workflow for generating conventional commit messages using a structured XML format

• copilot-intructions-blueprint-generator: Technology-agnostic blueprint generator for creating comprehensive copilot-intructions.md files that guide GitHub Copilot to produce code consistent with project standards, architecture patterns, and exact technology versions by analyzing existing codebase patterns and avoiding assumptions.

• create-agentsmd: Prompt for generating an AGENTS.md file for a repository

• create-implementation-plan: Create a new implementation plan file for new features, refactoring existing code or upgrading packages, design, architecture or infrastructure.

• create-specification: Create a new specification file for the solution, optimized for Generative AI consumption.

• create-technical-spike: Create time-boxed technical spike documents for researching and resolving critical development decisions before implementation

• documentation-writer: Diátaxis Documentation Expert. An expert technical writer specializing in creating high-quality software documentation, guided by the principles and structure of the Diátaxis technical documentation authoring framework

• doublecheck: Three-layer verification pipeline for AI output. Extracts verifiable claims, finds supporting or contradicting sources via web search, runs adversarial review for hallucination patterns, and produces a structured verification report with source links for human review

• skill-creator: Create new skills, modify, and improve existing skills, and measure skill performance. Use when the user wants to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

• model-recommendation: Analyze chatmode or prompt files and recommend optimal AI models based on task complexity, required capabilities, and cost-efficiency

• prd: Generate high-quality Product Requirements Documents (PRDs) for software systems and AI-powered features. Includes executive summaries, user stories, technical specifications, and risk analysis.

• project-workflow-analysis-blueprint-generator: Comprehensive technology-agnostic prompt generator for documenting end-to-end application workflows.

• refactor: Surgical code refactoring to improve maintainability without changing behavior.

• remember: Transforms lessons learned into domain-organized memory instructions (global or workspace)

• dispatching-parallel-agents: Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

• executing-plans: Use when you have a written implementation plan to execute in a separate session with review checkpoints

• systematic-debugging: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

• using-agent-skills: Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked

• code-review-and-quality: Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

• context-engineering: Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.

MCP

• Chrome DevTools MCP: chrome-devtools-mcp lets your coding agents (such as Gemini, Claude, Cursor, Copilot) control and inspect a live Chrome browser. It acts as a Model Context Protocol (MCP) server, giving your AI coding assistance access to the full power of Chrome DevTools for reliable automation, in-depth debugging, and performance analysis.

• Context7 MCP: Without Context7, LLMs rely on the generic and outdated information about the libraries we use. To resolve that, Context7 pulls up-to-date, version-specific documentations and code examples straight from the source and places them directly into your prompt.

• Playwright MCP: This MCP provides browser automation capabilities using Playwright. This server enables LLMs to interact with webpages through structured accessibility snapshots, bypassing the need for screenshots and visually turned models.

• Atlassian MCP Server: The Atlassian Rovo MCP server is a cloud-based bridge between your Atlassian cloud site and compatible tools. Once configured, it enables those tools to interact with Jira, Confluence, and Compass data in real time. This functionality is powered by secure authentication using OAuth 2.1 or API tokens, which ensures all actions respect the user's existing access controls.

• Figma MCP Server: The Figma MCP Server brings Figma directly into your workflow by providing important design information and context to AI Agents. generating code from Figma design files.

• shadcn/ui MCP: The Shadcn Server allows the AI Assistant to interact with items from registries. We can browse available components, search for specific ones, and install them directly into our project with natural language.

• Github MCP Server: The Github MCP Server connects AI tools directly into Github's platform. This gives AI agents, assistants, and chatbots the ability to read repositories and code files, manage issues and PRs, analyze code, and automate workflows all through natural language interactions.

• Permit's MCP-gateway: Permit MCP Gateway is a drop-in zero-trust proxy that adds authentication, fine-grained authorization, consent, and audit logging to any MCP server. Swap one URL. No code changes. Works with Salesforce, GitHub, Slack, Jira, and any MCP server you already use.

Hooks

• secret-scanner: Scans files modified during a Copilot coding agent session for leaked secrets, credentials, and sensitive data

• session-auto-commit: Automatically commits and pushes changes when a Copilot coding agent session ends

• session-logger: Logs all Copilot coding agent session activity for audit and analysis

• tool-guardian: Blocks dangerous tool operations (destructive file ops, force pushes, DB drops) before the Copilot coding agent executes them

=> Let's set up a rule for the AI so that whenever project guideline files are updated or there's a big change in our source code, like updating package versions, the AI automatically checks other documents to ensure everything stays consistent.

=> When searching for specific agents, instructions, or skills, simply run the suggest-awesome-copilot-agents, instructions, or skills tools. This will help you find exactly what you need from the awesome Copilot repository.

Agentic Harness Patterns

https://generativeprogrammer.com/p/12-agentic-harness-patterns-from

1. Persistent Instruction File Pattern

   Without a persistent instruction file, every agent session starts blank. The user repeats the same conventions, commands, and boundaries each time. The agent makes the same mistakes in session five that it made in session one.

   This pattern introduces a durable project-level configuration file loaded automatically at the start of every session. It defines build commands, test commands, architecture rules, naming conventions, and coding standards. It ships with the repo, not with the user’s clipboard.

   

   Use this when your agent works on a codebase across multiple sessions. The main trade-off is the maintenance burden: the file must stay current as the project evolves, and a stale instruction file can be worse than none if it teaches the agent outdated rules.

2. Scoped Context Assembly Pattern
   A single instruction file works for small projects. As a codebase grows, one file either becomes a giant blob that gets ignored, or stays too generic to be useful for any specific directory.

   This pattern loads instructions dynamically from multiple files at different scopes: organization, user, project root, parent directories, and child directories. The agent sees different rules depending on where in the codebase it is working. Import syntax allows splitting large instruction sets across files without duplication.

   

   Use this in monorepos, multi-language projects, or any codebase where different directories follow different conventions. The main trade-off is discoverability: when instructions live in many files, it becomes harder to understand what the agent actually sees. Conflicting rules across scopes can produce surprising behavior.

3. Tiered Memory Pattern

   An agent that remembers everything the same way ends up remembering nothing well. Loading all memory into the context window every session wastes tokens, hits size limits, and buries useful information under noise.

   This pattern organizes agent memory into distinct layers with different loading strategies. A compact index (capped at 200 lines in Claude Code) stays in context at all times. Topic-specific files load on demand when the current task matches them. Full session transcripts stay on disk and are only searched when needed. One of the most detailed breakdowns of the leaked code confirmed this three-layer design.

   

   Use this when your agent runs across multiple sessions and needs to retain preferences, decisions, or workflow state. The main trade-off is the added complexity in deciding what goes where, when to promote or demote information between layers, and how to keep the index in sync with the underlying files.

4. Dream Consolidation Pattern

   Even with tiered memory, agent memory degrades over time. Duplicate entries accumulate, outdated facts contradict new ones, and the index grows until it is no longer compact.

   This pattern runs a background process that periodically reviews, deduplicates, prunes, and reorganizes agent memory during idle time. Think of it as garbage collection for agent state. The leaked code revealed an “autoDream” mode that merges duplicates, prunes contradictions, and keeps the index tight. A separate analysis found 8 phases of memory management and 5 types of context compaction.

   

   Use this when your agent accumulates memory across many sessions and you cannot rely on users to curate it manually. The main trade-off is that the consolidation process itself uses tokens and can make mistakes. An overly aggressive prune might delete something the user still needs.

5. Progressive Context Compaction Pattern

   Long agent sessions eventually hit the context window limit. The agent either loses its earliest context entirely or stops working. Neither is acceptable for tasks that require sustained reasoning across many turns.

   This pattern applies multiple stages of compression tuned for different ages of the conversation. Recent turns stay at full detail. Older turns get lightly summarized. Very old turns get aggressively collapsed. The leaked code used four layers: HISTORY_SNIP, Microcompact, CONTEXT_COLLAPSE, and Autocompact, each progressively more aggressive.

   

   Use this when sessions regularly exceed 20-30 turns. The main trade-off is lossy compression: every summarization step discards detail, and if the agent later needs something from a collapsed segment, it may hallucinate rather than admit it forgot.

6. Explore-Plan-Act Loop Pattern
   When an agent jumps straight to editing files, it makes changes based on incomplete understanding. The result is edits to the wrong files, missed dependencies, and approaches that ignore existing patterns.

   This pattern separates the workflow into three phases with increasing write permissions. In the explore phase, the agent can only read, search, and map the codebase. In the plan phase, it discusses the approach with the user. Only in the act phase does it get full tool access. The leaked code showed distinct plan and act phases with system prompts that steer the agent away from editing before it understands the codebase.

   

   Use this for any task that touches an unfamiliar codebase or involves non-trivial changes across multiple files. The main trade-off is speed: enforcing exploration and planning adds turns before the agent produces output, which feels slow for simple tasks.

7. Context-Isolated Subagents Pattern

   In a long agentic session, the context window accumulates everything: research findings, planning discussions, code edits, test output, error logs. By the time the agent is deep into editing, its context is polluted with irrelevant material from earlier phases.

   This pattern runs separate agents with their own context windows, system prompts, and restricted tool access. Research agents cannot edit code. Planning agents cannot execute commands. Each subagent sees only what it needs for its specific task.

   

   Use this when sessions are long, multi-phase, or involve tasks with very different context needs. The main trade-off is coordination overhead: the main agent must decide what to pass to each subagent, and important nuance from an earlier phase can get lost in the handoff.

8. Fork-Join Parallelism Pattern

   Large tasks that could be split into independent units still run sequentially if the agent can only work on one thing at a time. A migration across 20 files takes 20 sequential steps even though most of those files have no dependencies on each other.

   This pattern spawns multiple subagents in parallel, each working in an isolated git worktree on an independent copy of the repo. The parent’s cached context is reused by each fork, making parallel branching essentially free in token cost. Results merge when all branches complete.

   

   Use this when a task decomposes into independent units that do not depend on each other’s output. The main trade-off is merge complexity: when parallel branches touch overlapping files, the merge can produce conflicts harder to resolve than sequential work would have been.

9. Progressive Tools Expansion Pattern

   Giving an agent access to every available tool at once creates a selection problem. With 60 tools visible, the model spends more time deciding which to use and is more likely to pick the wrong one.

   This pattern starts with a small default set (fewer than 20 tools in Claude Code) and activates additional tools on demand. Justin Schroeder noted the deliberately small default set. The agent starts with Read, Edit, Write, Bash, Grep, Glob, and a handful of others. MCP tools, remote tools, and custom skills activate only when needed.

   

   Use this when your agent has access to many tools but most tasks only need a few. The main trade-off is that the expansion logic adds complexity: the harness must decide when to activate tools, and activating too late means the agent wastes turns without the right capability.

10. **Command Risk Classification Pattern
    **
    Letting an agent run arbitrary shell commands without inspection is dangerous. But asking the user to approve every command creates fatigue, and users end up clicking “yes” to everything.

    This pattern applies deterministic pre-parsing and per-tool permission gating before execution. Each tool has individual allow, ask, and deny rules with pattern matching. Shell commands pass through a classification layer that parses the verb, flags, and target to assess risk. The auto-mode classifier found in the code auto-approves low-risk actions while keeping a safety classifier for anything dangerous.

    

    Use this when your agent can execute shell commands or interact with external systems. The main trade-off is rigidity: a deterministic classifier cannot anticipate every safe or dangerous command, so the rules need ongoing tuning.

11. **Single-Purpose Tool Design Pattern
    **
    When an agent routes every file operation through a general shell (cat, sed, grep, find), the commands are harder to review, harder to permission, and harder for the model to use correctly. A sed command that edits a file looks identical in structure to one that corrupts it.

    This pattern replaces the general shell with purpose-built tools for each common operation: FileReadTool, FileEditTool, GrepTool, GlobTool. Each tool has typed inputs, a constrained scope, and its own permission rules. Raschka calls this out explicitly: the harness provides “predefined tools with validated inputs and clear boundaries” rather than allowing improvised commands.

    

    Use this when your agent performs common file and search operations frequently. The main trade-off is flexibility: purpose-built tools cannot cover every edge case, so you still need a general shell as a fallback.

12. Deterministic Lifecycle Hooks Pattern

    Some actions must happen every time without exception: run the formatter after every edit, validate commands before execution, reload configuration when the working directory changes. Relying on the model to remember these through prompt instructions is unreliable. The model will forget, skip, or reinterpret the instruction depending on context pressure.

    This pattern runs shell commands or other actions automatically at specific points in the agent lifecycle, outside the prompt entirely. The leaked code includes 25+ hook points such as PreToolUse, PostToolUse, SessionStart, and CwdChanged. Anything that must happen every time belongs in a hook, not in an instruction.

    

    Use this when you have invariant behaviors that should never be skipped. The main trade-off is debugging difficulty: when something goes wrong in a hook, it can be harder to diagnose than a prompt-level instruction because hooks run outside the conversation.

Experience of Working with AI

Spec-driven development

Plan your work before you write code. But rather than writing plans for humans, we're writing plans and tasks for agents.

What is spec-driven development?

Instead of prompting first and figuring it out as you go, you start with a spec. It's a short document that defines what you're building, the constraints, and the key decisions—a contract for how your code should behave. The spec becomes the source of truth the agent uses to generate code. Less guesswork. Fewer surprises.

I see people conflating PRDs, design docs, and specs all the time. They serve completely different purposes, and mixing them up — especially when working with AI agents — causes a lot of confusion down the line.

Here's how I separate them:

Product Requirements Document (PRD) — For humans. Product managers, stakeholders. Covers what we're building and why — user stories, success metrics, business value. This is your debate document.

Technical Design Document — For engineers. Covers how we're building it — architecture decisions, scalability trade-offs, security implications. Also reviewed and debated with the team.

AI Spec — For agents. This is a pure execution document. No debates, no open questions. It translates the finalized decisions from the PRD and design doc into something an agent can act on directly.

Traditional software development has always followed this pattern:

The process is the same. The audience is different.

My Workflow:

1. Generate the PRD
   I use spec-driven-instructions-workflow.md combined with skills like prd/skill.md, prd.agent.md, or breakdown-epic-pm to generate the initial PRD. For large epics, I first use breakdown-feature-prd to break them down into feature-level PRDs before any implementation starts.

   Important: always use your most capable (most expensive) model for these root documents. And never trust the first generated version. My verification pipeline:

   Run doublecheck skill — surfaces inconsistencies and gaps => Run agentic-eval — makes updates based on the doublecheck report => Manual review using critical-thinking — go through every single point and make sure you genuinely understand it => Use agents like principle-software-engineer, devils-advocate, demonstrate-understanding, and refine-issue to stress-test assumptions further.

2. Generate the Technical Architecture
   With a solid prd.md, use the breakdown-epic-arch skill to produce the high-level technical architecture for the epic. This becomes your design.md.

3. Generate the Spec
   With both prd.md and design.md ready, generate a detailed spec using the create-specification skill combined with the spec-driven-workflow instructions. This spec.md is what agents will actually work from.

4. Generate the Implementation Plan
   From spec.md, use create-implementation-plan/SKILL.md to produce a task-by-task plan.md.

At this point you have all four core documents:

Review all four before touching any code.

During Implementation

Even with a solid plan, I don't just hand tasks over and walk away. My rules:

• Run doublecheck before every task — pull in external resources to verify the approach and understand the full impact of each change before it's made.

• Understand everything the AI produces — not "looks fine." Actually understand each decision and each line. If something's unclear, ask the agent to explain it with demonstrate-understanding.

• One task = one commit — every task on the plan gets its own commit. Keeps history clean and makes it easy to trace what changed and why.

• One big task = a new chat session -- every big task on the plan should be implemented in the new chat session. It keeps the context window fresh; the context window won't be poisoned by the irrelevant information from those previous responses.

• Mark tasks as Done — always tell the agent to update the Complete column in plan.md after finishing each task. Small habit, makes tracking much easier.

• For tasks that are too big or too complex, it's better to split them into multiple tasks. If a big task can't be split, we should ask the AI to apply rules or instructions like those in (copilot-thought-logging.instructions.md) for noting AI thoughts to a dedicated memory file to avoid losing context.

=> We can build a skill named executing-plans => this skill will contain 2 modes (mode 1 : phase review mode, mode 2: task implementation mode) => mode 1 process (load phase => using agentic-eval skill to review => use double-check skill to review => update relevant docs for consistency => Report) => mode 2 process (load task => implement => verify: using verification-before-completion skill => review: using code-review skill => Mark complete on plan.md)

=> For example, skills like verification-before-completion, code-review, we can look at an example on this powerful Github repo (remember to customize those skills to be suitable with our project, tools, and AI Agent)

=> So every time we need to review each phase before implementation or implement each task in the phase => we just need to attach executing-plans skill to AI Agent

After we completed all tasks in the plan

When we are in this step, there are several things I constantly follow up:

• Requesting AI to review and ensure the current AI documents, such as AGENTS.md, copilot-instructions.md, and other guidelines, are consistent with the updates made in plan.md.

• We completed all tasks in plan.md, which doesn't mean we have completely finished the feature. We need to carefully verify the AI's work for any issues we find and ask AI to fix them. Remember to ask AI to note these in the spec folder, keeping those documents up to date with our code changes.

• To fix any issues we find, let's develop a debugging skill (contain verification health check skill, code-review skill, commit-convention skill, ...) for verifying and resolving them. We can use the debugging skill template available at https://github.com/obra/superpowers.By doing this, we simply attach a debugging skill, include the spec folder with all the necessary context for the AI Agent, and provide an issue description. This allows the AI to quickly assist in resolving issues.

Keeping Docs in Sync

Docs live in multiple places — the specs/ folder in the repo, Jira tickets, Confluence pages — and they drift apart fast.

My rule: whenever a doc changes in one place, all related docs must be updated too. I explicitly tell the AI agent: if you modify a file in the specs/ folder, identify and update all related documents across Jira, Confluence, and any other linked sources. It's not a perfect system, but it cuts down on the drift problem significantly.

=> More upfront work than just prompting and hoping for the best — but once all four documents are locked in and the verification habit is in place, implementation gets surprisingly smooth. And more importantly, you actually understand what was built when it's done.

Spec-Driven Workflow with Linear

Use Linear MCP to give Claude Code direct access to your project management. The agent reads tickets, updates status, creates sub-issues, and follows your workflow — without you copy-pasting descriptions.

For larger features, combine specs with Linear tickets:

1. Write the spec
   Read my spec template and generate a spec for: user authentication with JWT tokens. Save it to specs/auth.md

2. Create tickets from the spec
   Read specs/auth.md and create a parent Linear issue titled "JWT Authentication" in the Auth project, team Engineering.

   Then create one sub-issue per task from the spec, linked to the parent. Each sub-issue should reference the spec: "Spec: specs/auth.md"

3. Works on tickets
   /implement PROJ-43 The agent reads the ticket, finds the spec reference, reads the spec, and implements with full context.

4. Track Progress
   Your Linear board now shows:

   • Parent issue with progress bar (auto-calculated from sub-issues)

   • Each sub-issue moving through: Todo → In Progress → In Review → Done

   • Comments with PR links on each ticket

   You get visibility without doing any project management manually.

Review AI Code

https://newsletter.owainlewis.com/p/how-i-use-ai-to-review-ai-code

Here’s the four-layer setup I use. Each layer filters out a category of problems so the next layer sees less noise.

1. Automated checks run your linter, tests, and security scanner before the agent can finish.

2. Local AI review gets a second agent to review the code before you push.

3. CI review runs AI code review automatically on every PR. The safety net for when you skip step two (it happens)

4. Human review handles what’s left: architecture, business logic, and “should we even build this?”

By the time a human looks at the code, the only things remaining are the things only a human can judge.

Layer 1: Automate The Obvious

Claude Code has a feature called hooks. A hook is a shell script that runs automatically at certain points in the agent lifecycle (like when the agent finishes a task). If the script fails, the agent is blocked from completing and has to fix the issues first.

I use a Stop hook that runs my linter and scanner every time Claude finishes work.

The config goes in your Claude Code settings:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/stop-checks.sh"
          }
        ]
      }
    ]
  }
}

The script itself is just whatever checks you already run:

#!/bin/bash
set -e
rubocop .
brakeman -q
bundle exec rspec --fail-fast

Swap those for whatever your project uses. Ruff and pytest for Python. ESLint for JavaScript. The point is the same: the agent can’t say “done” until these pass.

This alone catches a surprising amount. Formatting issues, unused imports, type errors, broken tests. None of that makes it into a review.

Layer 2: Agent Review

After automated checks pass, review the code yourself and get an AI second opinion before you push.

Two things matter here. First, actually run the code. This sounds obvious but it catches the most embarrassing bugs in two minutes. Second, read the diff. You don’t need to understand every line; understand the shape of the change. What files were touched? Does the scope match what you asked for? Did the agent silently change something you didn’t ask it to?

For the AI review, the key is a fresh context window. Don’t ask the same agent that wrote the code to review it. It has sunk-cost bias and is less likely to challenge its own decisions.

There are a few ways to do this:

• Custom Claude Code command. A review prompt in .claude/commands/review.md, paired with a REVIEW file at the project root that encodes your project-specific rules. Portable across tools, fully customisable. Claude Code also ships with some built in plugins.

• Codex /review**.** Four presets covering every scenario (base branch, uncommitted changes, specific commit, custom instructions). Priority-ranked findings. The best local review UX I’ve seen. Bonus: writing with Claude and reviewing with Codex means cross-model review built into your workflow. Different models have different blind spots.

• CodeRabbit. /coderabbit:review locally. 40+ linters and scanners running behind the scenes, purpose-built for code review. There are many other great code review tools like Greptile to explore also.

I use a custom review command that reads a REVIEW file at the project root. This file has project-specific rules, things I always want checked.

# REVIEW.md

## Project Patterns
- Repository pattern for data access. Direct DB queries in handlers are a flag.
- New API routes need an integration test. Flag if missing.

The general review catches general problems. The project-specific rules catch the things that are unique to your codebase.

Layer 3: External Review

Sometimes I forget to run the local review. Sometimes I’m in a rush. So I have an automated check on GitHub that reviews every PR before a human sees it.

There are a few options for this. Codex has a GitHub integration that reviews PRs automatically. CodeRabbit has a GitHub App that does the same thing. Anthropic has an open source GitHub Action for security-focused review.

I like having this as a separate layer because it catches things even when I skip the local step. Set it up once, runs on every PR for free.

Layer 4: Human Review

By the time a teammate opens the PR, the linter has passed, tests are green, and an AI has already flagged obvious issues. The human reviewer doesn’t need to catch formatting problems or unused variables.

What’s left is the stuff only a human can judge. Is this the right approach? Does it solve the actual business problem? Will this cause issues in three months? Five minutes of focused review on those questions is more valuable than thirty minutes of line-by-line reading.

TL;DR

I spent a long time trying to find the perfect code review setup. The experience was frustrating. There are hundreds of tools, plugins, and approaches, many of them doing the same thing in slightly different ways.

Don’t get lost looking for the perfect solution or perfect prompt. Start with Layer 1. Set up your linter and your hooks; that alone eliminates an entire category of review noise. Then find one way to get an AI review locally that you trust. Add CI when you’re ready.

Start simple and never accept the first output from an agent.

References

https://github.com/owainlewis/youtube-tutorials/tree/main

https://github.com/obra/superpowers

https://ainative.to/p/ai-agents-full-course-2026

https://addyosmani.com/blog/code-agent-orchestra/

https://awesome-copilot.github.com/learning-hub/

https://ai.plainenglish.io/vibe-coding-is-dead-heres-what-replaced-it-aa7d2889b05a

Tech hiring in the AI era: Why everyone’s at zero

How AI amplifies developers instead of replacing them, and why this is the React moment all over again.

Headlines scream about tech layoffs at Netflix, Amazon, and Microsoft, but what’s happening beneath the surface tells a different story. In this episode, Taylor Desseyn, VP of Global Community at Torc, joins the We Love Open Source podcast to share why tech hiring isn’t actually dead, how AI changes team composition without replacing developers, and why everyone’s on the same playing field when it comes to learning these new tools.

https://www.youtube.com/watch?v=KvflH9NMaiU

Taylor reframes the tech hiring narrative by looking beyond big tech. While FAANG companies (or MANGO, as he’s heard it called now) make layoff headlines, the startup ecosystem is thriving. AI-specific tech startup funding is through the roof. Torc and Randstad are both growing, driven largely by the AI boom. The reality beneath the headlines shows tech hiring evolving, not dying.

AI won’t replace developers, but it will change headcount dynamics. Taylor frames it simply: Think of an engineer as 1.0. With AI tools like Claude or Cursor, that engineer becomes 1.25, 1.5, or even 1.75. A team that previously needed 50 engineers might now need 25 or 20 really good engineers who know how to use AI effectively. It’s not about replacement, it’s about amplification.

For developers worried about AI taking their jobs, Taylor draws a parallel to earlier shifts. He’s been recruiting since 2011, through .NET MVC replacing VB.NET and React’s emergence. AI is the same kind of inflection point. The key insight: Everyone’s at zero right now. Senior, staff, and principal engineers are just getting started with Claude alongside junior developers. It’s a level playing field, but only if you engage.

Key takeaways

• Tech hiring is evolving, not dying: Startup ecosystem and AI-specific funding are thriving while big tech layoffs make headlines. Look beneath the surface to see where growth is actually happening.

• AI amplifies engineers rather than replacing them: Teams will hire fewer developers but those developers become 1.5x or 1.75x more productive with AI tools. The focus shifts to hiring engineers who know how to use Claude and Cursor effectively.

• Everyone’s at zero with AI right now: Senior and junior developers alike are just getting started. Find a mentor, document your learning publicly, and be known for how you’re using AI.

Taylor’s message is clear: This is the React moment for AI. You can ignore it or you can learn it, but everyone who’s learning is starting from the same place. The opportunity is there for developers who take it seriously.

https://allthingsopen.org/articles/tech-hiring-ai-era-everyone-at-zero?ref=dailydev

https://medium.com/@tsecretdeveloper/be-thankful-that-you-were-there-at-the-beginning-of-ai-b47142053d0b

https://leadershipinchange.com/p/stop-learning-ai-tools

https://substack.com/home/post/p-188178090?source=queue

Most Important AI Concepts

LLMs

https://medium.com/mr-plan-publication/not-everything-is-an-llm-8-ai-model-types-you-need-to-know-in-2025-6fb026bcdc82

https://substack.com/home/post/p-188649002

What is Generative AI?

While today’s generative models are built upon a decade of progress, 2022 was the year when they triggered an “Aha!” moment for most. Generative AI is a subfield of machine learning. It involves training artificial intelligence models on large volumes of real-world data to generate new content (text, images, code, etc.) that resembles human creation.

This may have been a mouthful. Let’s clarify these terms first before we jump into LLMs. Here’s a plain-English map of those first words you’ll see.

• AI is the big umbrella: getting computers to do things that look intelligent.

• Machine learning (ML) lives inside AI: systems learn from data instead of hard-coded rules.

• Deep learning (DL) is a way for computers to learn patterns by practicing on a huge number of examples.

• NLP (natural language processing) is the part of AI that works with human language. As simple as that.

• Generative AI is the branch that creates new content (text, images, audio, code). Whatever it is, it just means it generates things rather than predicts things, as done with more classical AI systems.

• LLMs (Large Language Models) are deep learning models within the generative AI family that specialize in text generation.

That’s all you need for now: AI → ML → DL → (NLP) → LLMs. With the labels straight, we can understand what an LLM actually does.

What is an LLM?

An LLM is a powerful autocomplete system. It’s a machine built to answer one simple question over and over again: “Given this sequence of text, what is the most probable next token?” That “piece of text” is called a token—it can be a word, a part of a word (like runn and ing), or punctuation.

For example, if a user asks ChatGPT, “What is fine-tuning?”, it doesn’t “know” the answer. It just predicts the next token, one at a time:

1. The most probable first token is “Fine-tuning”.

2. Given that, the next most probable token is “is”.

3. Next is “the”, and so on...

Until it generates a full sentence: “Fine-tuning is the process of training a pre-trained model further on a smaller, specific dataset.”

It’s called a Large Language Model for three simple reasons:

• Large: It has billions of internal variables (called parameters) and was trained on a massive amount of text.

• Language: It’s specialized for understanding and generating human language.

• Model: It’s a mathematical representation of the patterns it learned.

So, at its heart, an LLM is just a very advanced guessing machine: predicting the next token again and again until a full answer appears. So, how does it get good at making those guesses in the first place?

To get there, the model undergoes a long study session of its own—a process called pre-training. For example, if a student is asked to read every book in a giant library (a huge slice of the internet, in the case of LLMs). They’re not trying to memorize pages word-for-word. Instead, they learn patterns—how words, sentences, and ideas fit together—well enough to predict the next piece of text in any sentence. This is how a base model like GPT-5 is built during pre-training.

https://newsletter.systemdesign.one/p/llm-concepts?utm_source=publication-search

AI Agents

AI Workflows

AI workflows can be either non-agentic or agentic.

1. Non-Agentic Workflow: An LLM is given an instruction and produces a response. For example, in a question answering workflow, the input is a question, the LLM generates an answer, and the workflow returns that answer.

   

   Even if you give the LLM an extra tool, the workflow is still non-agentic if it follows a fixed path and the LLM has no control over decisions or actions.

   

2. Agentic Workflow: An agentic workflow is a set of connected steps carried out by an agent or multiple agents to complete a task or goal. These workflows use key features of AI agents, such as reasoning, planning, tool use, and memory.

   

Now let’s take a closer look at AI agents.

AI Agents

AI agents are systems that use LLMs for reasoning and decision-making, along with tools to interact with the real world. This allows them to handle complex tasks with minimal human input. Each agent is given a specific role and a certain level of autonomy to achieve its goal. They also have memory, which helps them learn from past actions and improve over time.

https://newsletter.systemdesign.one/p/ai-agents-explained

https://substack.com/home/post/p-181466313

Components of an AI Agent

1. Reasoning: AI agents work well because they can reason step by step. This ability comes from the LLM (with a defined role and task) and supports two main functions: Planning and reflecting.

2. Memory: Stores context and relevant information. Short-Term memory tracks the current interaction, while Long-Term memory holds past knowledge and experiences.

3. Tools (vector search, web search, APIs, etc.): Extends the agent’s abilities beyond text generation, giving it access to external data, real-time information, or APIs.

Agentic Patterns

These patterns enable agents to dynamically adapt, plan, and collaborate, ensuring that the system can handle complex, real-world tasks with precision and scalability.

1. Reflection

The reflection pattern is a self-feedback mechanism, enabling agents to iteratively evaluate and refine their outputs.

Reflection is especially useful for tasks like coding, where the agent may not succeed right away. For example, it can write code, test it, analyze any errors, and use that feedback to fix and improve the code until it works.

By critiquing its own work and learning from each step, the agent can improve without human help. These reflections can be saved in memory so the agent solves future problems faster and adapts to user needs over time.

1. Tool Use

Agents interact with external tools like vector search, APIs, or web search to expand their capabilities.

This pattern allows agents to gather information, perform computations, and manipulate data beyond their pre-trained knowledge. By dynamically integrating tools into workflows, agents can adapt to complex tasks and provide more accurate and contextually relevant outputs.

1. ReAct

Reflection’s good. Tools are good. But when you let your agent think and act in loops, it gets even better.

That’s what the ReAct pattern is all about: Reasoning + Acting.

Instead of answering everything in one go, the model reasons step-by-step and adjusts its actions as it learns more.

Example:

• Goal: “Find the user’s recent invoices.”

• Step 1: “Query payments database.”

• Step 2: “Hmm, results are outdated. Better ask the user to confirm.”

• Step 3: Adjust query, repeat.

It’s not just responding — it’s navigating.

To make ReAct work, you’ll need three things:

• Tools (for taking action)

• Memory (for keeping context)

• A reasoning loop (to track progress)

ReAct makes your agents flexible. Instead of sticking to a rigid script, they think through each step, adapt in real-time, and course-correct as new information comes in.

If you want to build anything beyond a quick one-off answer, this is the pattern you need.

1. Planning

Planning is a key agentic pattern that enables agents to autonomously decompose complex tasks into smaller, manageable subtasks.

Planning works best when the path to the goal is unclear and flexibility is important. For example, to fix a software bug, an agent might first read the bug report, find the relevant code, list possible causes, and then choose a debugging method. If the first fix fails, it can adjust based on the new error.

This is useful for solving complex problems that require flexibility and multiple steps.

1. Multi-Agent

Multi-agent collaboration allows agents to specialize in different tasks and work in parallel. Agents share progress and results to keep the overall workflow efficient and consistent.

By breaking complex tasks into smaller parts and assigning them to different agents, this approach makes workflows more scalable and flexible. Each agent can use its own memory, tools, reflection, or planning, which supports dynamic and collaborative problem-solving.

Benefits of Agentic Workflows

• Flexible and adaptable: Agentic workflows adjust to changing tasks and challenges. Unlike rule-based systems, they evolve based on task complexity and can be customized using different patterns.

• Efficiency Gains: Agentic workflows can automate repetitive tasks with high accuracy.

• Self-correcting and learning: Using feedback and memory, agents refine their actions over time. This leads to better performance with each use.

• Better at complex tasks: By breaking complex problems into smaller steps, agents handle complex tasks more effectively.

Challenges of Agentic Workflows

• Overkill for simple tasks: AI agents can create extra overhead when used for simple tasks, leading to unnecessary complexity and higher costs.

• Less predictable: More autonomy means more unpredictability. Without proper guardrails, agent outputs can become unreliable or hard to control.

• Ethical concerns: Not all decisions should be left to AI. Sensitive tasks need human oversight to avoid mistakes or harm.

Agentic workflows are powerful, but they come with extra complexity and computation. Use them only when needed.

Context Engineering vs Prompt Engineering

Prompt Engineering

The “Static Script”.

If you’ve been working with LLMs, you already know Prompt Engineering. It’s the craft of writing effective instructions for a model, and for the past two years, it’s been the primary way developers have tried to improve AI output.

Think of an LLM as a talented improv actor:

Prompt Engineering is the script you hand them before the curtain rises. It defines their character, the scene's tone, and the rules of engagement. A good script can make a significant difference in performance.

The standard developer toolkit for prompt engineering includes:

• Role Assignment – Setting the persona with instructions like “You are an expert travel agent.” This primes the model to use vocabulary and behaviors associated with that role.

• Few-Shot Examples – Providing input/output pairs demonstrating the exact format you want. For example, showing the model three examples of properly formatted JSON responses before asking it to generate one.

• Chain of Thought (CoT) – Instructions like “Let’s think step by step” that encourage the model to show its reasoning. This dramatically reduces errors in logic and math problems by forcing the model to “work through” the problem rather than jumping to an answer.

• Constraint Setting – Hard limits on output, like “Limit your response to 50 words,” or “Respond only with valid JSON.”

These techniques are valuable and worth mastering.

But they share a fundamental limitation that becomes apparent when you move from demos to production.

The “Paris, Kentucky” Failure

The limitation of Prompt Engineering is that it is static.

Let’s return to our travel agent. The user says: “Book me a hotel in Paris for the DevOps conference.”

An agent relying only on prompt engineering sees the words “Paris” and “DevOps.” It has no access to external data, so it does what LLMs do when they lack information: it makes a probabilistic guess. There’s a Paris in France, sure, but there’s also a Paris in Kentucky, Texas, Tennessee, and several other states. Without additional context, the model has no way of knowing which one you mean.

The result?

Your user gets booked into the Best Western in Paris, Kentucky.

No amount of clever prompt phrasing can fix this. You could write “Always book hotels in major international cities”—but what about the user who actually wants Paris, Texas? The problem isn’t the prompt. The problem is that the model lacks three critical pieces of information:

1. User lives in London (suggesting international travel is more likely)

2. DevOps conference this year is actually in Paris, France

3. The user’s company policy requires booking Marriott properties under €200/night

This is where the paradigm shifts.

We need to move from optimizing static scripts to dynamically assembling the right information at runtime. We need Context Engineering.

https://andrewships.substack.com/p/prompt-driven-development

https://newsletter.systemdesign.one/p/context-engineering-vs-prompt-engineering

https://addyo.substack.com/p/the-prompt-engineering-playbook-for

https://blog.bytebytego.com/p/a-guide-to-effective-prompt-engineering

What is Context?

https://newsletter.systemdesign.one/p/what-is-context-engineering

Before getting into techniques or frameworks, it helps to be clear about what “context” actually means.

When you send a message to an AI assistant, it doesn’t just see your latest question. It sees the information included with your message, such as system instructions that guide its behavior, relevant parts of the conversation so far, any examples you provide, and sometimes documents or tool outputs.

All of that together is the context.

This matters because the model lacks long-term memory as humans do. It cannot recall past conversations unless that information is included again. Each response is generated solely from the current context.

The model can pay attention to only a limited amount of text at once. This limit is often called the context window. Dumping more into that space often makes answers worse, not better.

Context engineering is about managing that working space.

The goal is not to give the model as much information as possible, but to give it the right information at the moment it needs to respond.

Why does this matter for agents?

This becomes more important when the AI is doing more than answering a single question.

A simple chatbot takes your question, replies, and stops. But more advanced AI systems, often called agents, work on tasks that unfold over many steps. They might search for information, read results, summarize what matters, and then decide what to do next.

Each step generates new information that is added to what the model sees next, such as search results, summaries, and intermediate notes. Over time, the context grows, and much of it becomes no longer relevant to the current step. This is called context rot, where useful information gets buried under outdated details.

Agents often work well on focused tasks.

But when a task is broad and requires many steps, the quality can vary. As the context gets heavier, important details from earlier can get lost.

The Anatomy of Context

Understanding what causes context rot is the first step.

The next is knowing exactly what goes into the context window so you can control it.

When an AI generates a response, it is not just reacting to your last message. It is responding to a structured bundle of inputs. Each part plays a different role, but they all compete for the same limited space.

1. System Prompt and User Prompt

The system prompt determines the model's overall behavior.

It describes how the assistant should act, the rules it should follow, and the kinds of responses expected.

Most of the time, you do not see the system prompt directly. It’s defined by the product or application you are using. This is why two assistants built on the same underlying model can behave very differently.

For example, ChatGPT tends to answer politely, refuse certain requests, and format responses in predictable ways, even if you never explicitly asked it to do so.

The user prompt is your message.

This includes your current question and, in a chat setting, earlier messages that are still included.

Both are sent to the model together. The system prompt guides behavior, and the user prompt describes what to do right now.

If you are building an AI feature and you control the system prompt, the hard part is balance. If the instructions are too strict, the assistant can become brittle when something unexpected occurs. If they are too vague, responses become inconsistent.

A practical approach is to start minimal, test with real use cases, and add rules only when you see specific failures.

1. Examples

Sometimes the clearest way to guide an AI is to show it what you want.

Instead of writing a long list of rules, you can include one or two example inputs and the exact outputs you expect. This is often called few-shot prompting.

You have probably done this in ChatGPT without realizing it. If you say, “Format it like this,” and paste a sample answer, the model will usually follow the pattern.

Examples work because they remove ambiguity. They show tone, structure, and level of detail in a way that instructions often cannot.

The tradeoff is space. Examples take up room in the context window, so they need to earn their spot. A few well-chosen examples are usually better than a long list.

1. Message History

In a chat, the model can respond to follow-up questions because earlier messages remain in context.

For example, if you ask ChatGPT, “What is the capital of France?” and then ask, “What is the population?”, it can usually infer you still mean the capital you just discussed.

This works because the conversation so far acts like shared scratch paper. The model does not truly remember the earlier exchange. It is simply reading it again as part of the input.

The problem is that the message history grows over time. As more turns accumulate, older messages take up space even when they are no longer relevant. That can make the model less focused. It may repeat itself, follow outdated assumptions, or miss a detail that matters now.

Managing message history usually means keeping what is still relevant, summarizing what is settled, and letting the rest drop out of the active context.

1. Tools

On its own, an LLM can only generate text. Tools let it do more than that.

Tools allow an agent to search the web, read documents, run code, query databases, or interact with external systems. When a tool is used, the result is usually fed back into the context so the model can use it in the next step.

You have seen this in ChatGPT when it searches the web or analyzes a file you uploaded. The output becomes part of what the model sees before it responds.

Tools are powerful, but every tool call adds more text that competes for attention. If a tool returns too much information or in an unclear format, it can overwhelm the model rather than help it.

Good tool design keeps results focused and predictable. Clear names, narrow responsibilities, and concise outputs make it easier for the model to use tools effectively.

1. Data

Beyond messages and tools, agents often work with external data.

This can be a document you upload, an article you paste into the chat, or files the system can access. When that information is included, it becomes part of the context.

Large documents do not always behave the way you expect. The model may focus on the wrong section or miss details. This is often a context management problem, not carelessness.

Managing documents usually means breaking them into smaller pieces, pulling in what is relevant to the current step, and leaving the rest out of the active context until needed.

Context Retrieval Strategies

System instructions, examples, tools, and message history are the context in which you can write directly.

But often the most important information is not known in advance. It has to be retrieved during the task.

For example, if you ask ChatGPT a question about a PDF you uploaded, it needs to find the relevant section. If you ask it to search the web, it has to decide what to search for and which results matter.

How an agent retrieves and injects information is a major part of context engineering. There are two main approaches: loading everything upfront, or retrieving as you go.

1. Loading Upfront

The simplest approach is to retrieve relevant information before the model starts responding, then include it in the context all at once.

This is what happens when ChatGPT searches the web and then writes an answer using the results it just found. The model is not answering from memory. It is answering based on the information that was retrieved and added to its context.

This pattern is commonly called retrieval augmented generation (RAG).

https://newsletter.systemdesign.one/p/how-rag-works

Loading upfront works well when the question is clear, and the agent can predict what information will be useful. The downside is that the agent makes an early retrieval decision and may stick with it.

If something important is missing or the task changes direction, it can be harder to correct course.

1. Just-in-Time Retrieval

Another approach is to retrieve information as the task unfolds.

Instead of loading everything at the start, the agent takes a step, looks at what it has learned so far, and retrieves more information only when needed. You can sometimes see this in ChatGPT when it searches, reads, refines the query, and searches again during longer tasks.

This keeps the context cleaner because only the information actually needed gets pulled in. The tradeoff is that it takes more steps and requires the agent to decide when to retrieve and when to stop.

A useful pattern within just-in-time retrieval is to start broad and then drill down. This specification is called Progressive Disclosure.

Rather than loading full documents immediately, the agent may start with short snippets or summaries, identify what looks relevant, and pull in more detail only then.

This is how humans tackle research, too.

You do not read every article in a database. You scan titles, read abstracts of promising ones, and dive deep only into the sources that matter.

1. Hybrid Strategy

Fortunately, you don’t have to pick one or the other.

Many agents combine both approaches. They load a small amount of baseline information upfront, then retrieve more as needed.

You can see this in tools like ChatGPT. Some instructions and conversation history are already present, and additional information, such as search results or document excerpts, is pulled in based on what you ask.

For simpler use cases, loading upfront is often enough. As tasks get more complex and span multiple steps, retrieving as you go becomes more important.

The right choice depends on how predictable your agent’s information needs are.

Techniques for Long-Horizon Tasks

Retrieval helps an agent pull in the right information.

But some tasks create a different problem. They run long enough that the agent produces more text than can fit in the context window.

You may have seen this in ChatGPT during long conversations or research tasks. Early responses are clear, but after many steps, the answers can drift or repeat themselves, especially when you send very long instructions, like asking for help with entire code bases. Over a long task, the agent can encounter far more information than it can keep in working memory at once.

Larger context windows are not a complete solution. They can be slower and more expensive, and they still accumulate irrelevant information over time. A better approach is to actively manage what stays in context and preserve the important parts as the task grows.

Three techniques help with this:

• compressing the context when it gets full,

• keeping external notes,

• splitting work across multiple agents.

1. Compaction

When the context approaches its limit, one option is to compress what’s there.

The agent summarizes the conversation so far, keeping the essential information and discarding the rest. This compressed summary becomes the new starting point, and the conversation continues from there.

You may have noticed something like this in long ChatGPT conversations. After many messages, earlier details can fade. This often happens because older parts of the conversation are shortened or dropped to make room for new input.

The hard part is deciding what to keep.

The goal, key constraints, open questions, and decisions that affect future steps should stay. Raw tool outputs that have already been used can usually go. Repeated back and forth that does not change the plan can go too.

There is always a risk of losing something that matters later. A common safeguard is to store important details outside the context before discarding them, so the agent can retrieve them if needed.

1. Structured Note Taking

Compaction occurs when you’re running out of space. Structured note-taking happens continuously.

As the agent works, it keeps a small set of notes outside the context window. These notes capture stable information, such as the goal, constraints, decisions made so far, and a short list of what remains.

You can see a user-level version of this idea in features like ChatGPT’s memory. If you tell it to remember something, that information can persist beyond a single conversation and be brought back when relevant.

This works well for tasks with checkpoints or tasks that span multiple sessions.

A coding agent might keep a checklist of completed steps. A support assistant might store user preferences so that it does not have to ask the same questions again.

1. Sub-Agent Architectures

Sometimes the best approach is to break a large task into pieces and assign each piece to a separate agent with its own context window.

In many research-style agent designs, a main agent coordinates the overall task, while sub-agents handle focused subtasks. A sub-agent explores one area in depth, then returns a short summary. The main agent keeps the summary and moves on without carrying all the raw details forward.

You can think of research features in tools like ChatGPT as an example of the kind of workflow where this pattern is useful.

This works well when subtasks can run independently or require deep exploration.

The tradeoff is complexity. Coordinating multiple agents is harder than managing a single one, so it is usually best to start with simpler techniques and add sub-agents when a single agent becomes overwhelmed.

Choosing the Right Technique

There’s no one-size-fits-all solution. The right approach depends on your “agent and your use case”. These rules of thumb can help:

• Compaction works best for long, continuous conversations where context gradually accumulates.

• Structured notes work best for tasks with natural checkpoints or when information needs to persist across sessions.

• Sub-agents work best when subtasks can run in parallel or require deep, independent exploration.

These techniques can be combined. Start with the simplest approach and add complexity as needed.

Putting It All Together

Context engineering is not a single technique.

It’s an approach to designing AI systems. At each step, you decide what goes into the model’s context, what stays out, and what gets compressed.

The components we covered work together.

System prompts and examples shape behavior. Message history maintains continuity. Tools let the agent take actions. Data gives it information to work with. Retrieval strategies determine how and when that information gets loaded. For long-running tasks, compaction, external notes, and sub-agents help manage context that would otherwise overflow.

When something goes wrong, context is often the place to look. If the agent hallucinates, it might need better retrieval to ground its answers. If it picks the wrong tool, the tool descriptions might be unclear. If it loses track after many turns, the message history might need summarization.

A practical approach is to start simple.

Test with small tasks first. If it works, scale up. If it fails, identify what went wrong and address the specific issue.

How Does Memory For AI Agents Work?

https://www.decodingai.com/p/how-does-memory-for-ai-agents-work

AI Agent's Memory

One year ago at ZTRON, we faced a challenge that many AI builders encounter: how do we give our agent access to the right information at the right time? Like most teams, we jumped straight into building a complex multimodal Retrieval-Augmented Generation (RAG) system. We built the whole suite: embeddings for text, embeddings for images, OCR, summarization, chunking, and multiple indexes.

Our ingestion pipeline became incredibly heavy. It introduced unnecessary complexity around scaling, monitoring, and maintenance. At query time, instead of a straight line from question to answer, our agent would zigzag through 10 to 20 retrieval steps, trying to gather the right context. The latency was terrible, costs were high, and debugging was a nightmare.

Then we realized something essential. Because we were building a vertical AI agent for a specific use case, our data wasn’t actually that big. Through virtual multi-tenancy and smart data siloing, we could retrieve relevant data with simple SQL queries and fit everything comfortably within modern context windows—around 65,000 tokens maximum, well within Gemini’s 1 million token input capacity.

We dropped the entire RAG layer in favor of Context-Augmented Generation (CAG) with smart context window engineering. Everything became faster, cheaper, and more reliable. This experience taught me that the fundamental challenge in building AI agents isn’t just about retrieval. It is about understanding how to architect memory systems that match your actual use case.

The core problem we are solving is the fundamental limitation of LLMs: their knowledge is vast but frozen in time. They are unable to learn by updating their weights after training, a problem known as “continual learning”. An LLM without memory is like an intern with amnesia. They might be brilliant, but they cannot recall previous conversations or learn from experience.

To overcome this, we use the context window as a form of “working memory.” However, keeping an entire conversation thread plus additional information in the context window is often unrealistic. Rising costs per turn and the “lost in the middle” problem—where models struggle to use information buried in the center of a long prompt limit this approach. While context windows are increasing, relying solely on them introduces noise and overhead.

Memory tools act as the solution. They provide agents with continuity, adaptability, and the ability to “learn” without retraining. When we first started building agents, working with 8k or 16k token limits forced us to engineer complex compression systems. Today, we have more breathing room, but the principles of organizing memory remain essential for performance.

In this article, we will explore:

1. The four fundamental types of memory for AI agents.

2. A detailed look at long-term memory: Semantic, Episodic, and Procedural.

3. The trade-offs between storing memories as strings, entities, or knowledge graphs.

4. The complete memory cycle, from ingestion to inference.

The 4 Memory Types for AI Agents

To build effective agents, we must distinguish between the different places information lives. We can borrow terms from biology and cognitive science to categorize these layers useful for engineering.

There are four distinct memory types based on their persistence and proximity to the model’s reasoning core.

1. Internal Knowledge: This is the static, pre-trained knowledge baked into the LLM’s weights. It is the best place to store general world knowledge—models know about whole books without needing them in the context window. However, this memory is frozen at the time of training.

2. Context Window: This is the slice of information we pass to the LLM during a specific call. It acts as the RAM of the LLM. It is the only “reality” the model sees during inference.

3. Short-Term Memory: This is the RAM of the entire agentic system. It contains the active context window plus recent interactions, conversation history, and details retrieved from long-term memory. We slice this short-term memory to create the context window for a single inference step. It is volatile and fast, simulating the feeling of “learning” during a session

4. Long-Term Memory: This is the external, persistent storage system (disk) where an agent saves and retrieves information. This layer provides the personalization and context that internal knowledge lacks and short-term memory cannot retain [4].

The dynamic between these layers creates the agent’s intelligence. First, part of the long-term memory is “retrieved” and brought into short-term memory. This retrieval pipeline queries different memory types in parallel. Next, we slice the short-term memory into an active context window through context engineering. Finally, during inference, the LLM uses its internal weights plus the active context window to generate output.

Another useful way to visualize this is by proximity to the LLM. Internal memory is intrinsic, while long-term memory is the furthest away, requiring specific retrieval mechanisms to become useful.

Categorizing memory this way is critical for engineering. Internal knowledge handles general reasoning. Short-term memory manages the immediate task. Long-term memory handles personalization and continuity. No single layer can perform all three functions effectively. To better understand long-term memory, we can further apply cognitive science definitions to specific data types.

MCP - A Deep Dive

https://portkey.ai/blog/understanding-mcp-authorization/?ref=dailydev

In November 2024, Anthropic launched the Model Context Protocol (MCP) to fix this problem. This wasn’t just another developer tool. It aimed to tackle a key infrastructure issue in AI engineering.

The challenge?

Every AI application needs to connect to data sources. Until now, they had to build custom integrations from scratch. This approach creates a fragmented ecosystem that does not scale.

For example, the world isn’t frozen in time, but LLMs are…

If you want an AI to “monitor server logs,” you can’t feed it a file. You would have to build a data pipeline that polls an API every few seconds. Filter out noise, then push only the relevant anomalies into the AI’s context window. If the API changes its rate limits or response format, your entire agent breaks.

A better way to think of MCP is like a USB-C port.

The Old Way (Before USB):

If you bought a mouse, it had a PS/2 plug. A printer had a massive parallel port. A camera had a proprietary cable. If you wanted to connect these to a computer, the computer needed a specific physical port for each one.

This is the “N×M” problem:

Each device maker had to figure out how to connect to each computer. So, computer makers had to create ports for every device.

The MCP Way (With USB-C):

Now, everything uses a standard port.

• Computer (AI Model) needs one USB-C port. It doesn’t need to know if you are plugging in a hard drive or a microphone; it just speaks “USB.”

• Device (Data Source) requires a USB-C port. It doesn’t need to know if it’s plugged into a Mac, a PC, or an iPad.

The result: you can plug anything into anything instantly.

The analogy makes sense in theory. But to understand why MCP matters, you need to see how painful the current reality actually is…

The Integration Complexity Problem

Every AI assistant needs context to be useful:

Claude needs access to your codebase. ChatGPT may require your Google Drive files. Custom agents need database connections. But how do these AI systems actually get that context?

Traditionally, each connection requires a custom integration.

If you’re building an AI coding assistant, you need to:

1. Write code to connect to the GitHub API.

2. Add authentication and security.

3. Create a way to change GitHub’s data format into a version that your AI can understand.

4. Handle rate limiting, errors, and edge cases.

5. Repeat this entire process for GitLab, Bitbucket, and every other source control system.

This creates the N×M problem:

‘N’ AI assistants multiplied by ‘M’ data sources equals N×M unique integrations that need to be built and maintained.

When Cursor wants to add Notion support, they build it from scratch. When GitHub Copilot wants the same thing, they build it again. The engineering effort gets duplicated across every AI platform.

The traditional approaches have fundamental limitations:

Static, build-time integration:

Integrations are hard-coded into applications. You can’t add a new data source without updating the application itself. This makes rapid experimentation impossible and forces users to wait for official support.

Application-specific security implementations:

Every integration reinvents authentication, authorization, and data protection. This leads to inconsistent security models and increases the attack surface.

No standard way to discover:

AI systems can’t find out what capabilities a data source has. Everything needs clear programming. This makes it hard to create agents that adapt. They can’t use the new tools on their own.

The result is a ‘broken’ ecosystem!

Innovation is stuck because of integration work. Users can access only the connections that application developers create. So that’s a mess.

Now let’s look at how MCP cleans it up…

How MCP Solves It

MCP’s solution is straightforward: define a single protocol that functions across all systems.

Instead of building N×M integrations, you build N clients (one per AI application) and M servers (one per data source). The total integration work drops from N×M to N+M.

When a new AI assistant wants to support all existing data sources, it just needs to implement the MCP client protocol once.

When a new data source wants to be available to all AI assistants, it just needs to implement the MCP server protocol once.

Two critical architectural features power this efficiency:

1. Dynamic Capability Discovery

In traditional integrations, the AI application must know the data source details in advance.

If the API changes, the application breaks…

MCP flips this. It uses a “handshake” model. When an AI connects to an MCP server, it asks, “What can you do?”.

The server returns a list of available resources and tools in real time.

RESULT:

You can add a new tool to your database server, like a “Refund User” function. The AI agent finds it right away the next time it connects. You won’t need to change any code in the AI application.

2. Decoupling Intelligence from Data

MCP separates the thinking system (AI model) from the knowing system (the data source).

• For Data Teams: They can build robust, secure MCP servers for their internal APIs without worrying about which AI model will use them.

• For AI Teams: They can swap models without having to rebuild their data integrations.

This decoupling means your infrastructure doesn’t become obsolete whenever a new AI model gets released.

You build your data layer once, and it works with whatever intelligence layer you choose to plug into it.

An AI agent using MCP doesn’t need to know in advance what tools are available. It simply connects, negotiates capabilities, and uses them as needed. This enables a level of flexibility and scale that is impossible with traditional static integrations.

The high-level concept is straightforward.

But the real elegance is in how the architecture actually works under the hood…

MCP Architecture Deep Dive

MCP’s architecture has three main layers.

These layers separate concerns and allow for easy scalability:

1. The Three-Layer Model

Hosts are user-facing apps.

This includes the Claude Desktop app, IDEs like VSCode, or custom AI agents you create. Hosts are where users connect with the AI. They are also where requests begin. They do more than display the UI; they orchestrate the entire user experience.

The host application interprets the user’s prompt.

It decides whether external data or tools are needed to fulfill the request. If access is necessary, the host creates and manages several internal clients. It keeps one client for each MCP server it connects to.

The protocol layer handles the mechanics of data access.

Clients are protocol-speaking connection managers that run on hosts.

Each client maintains a dedicated 1:1 connection with a single MCP server. They serve as the translation layer.

They convert abstract AI requests from the host into clear MCP messages. These messages, like tools/call or resources/read, can be understood by the server. Clients do more than send messages. They manage the entire session lifecycle. This includes handling connection drops, reconnections, and state.

When a connection starts, the client takes charge of capability negotiation. It asks the server which tools, resources, and prompts it supports.

Servers provide context.

They act as the layer that connects real-world systems, such as PostgreSQL databases, GitHub repositories, or Slack workspaces.

A server connects the MCP protocol to the data source. It translates MCP requests into the system’s native operations. For example, it turns an MCP read request into a SQL SELECT query. They are very flexible. They can run on a user’s machine for private access or remotely as a cloud service.

Servers share their available capabilities when connected. They inform the client about the Resources, Prompts, and Tools they offer.

https://newsletter.systemdesign.one/p/how-mcp-works

AGENTS.MD

An AGENTS.md file is a markdown file you check into Git that customizes how AI coding agents behave in your repository. It sits at the top of the conversation history, right below the system prompt.

Think of it as a configuration layer between the agent's base instructions and your actual codebase. The file can contain two types of guidance:

• Personal scope: Your commit style preferences, coding patterns you prefer

• Project scope: What the project does, which package manager you use, your architecture decisions

The AGENTS.md file is an open standard supported by many - though not all - tools.

Why Massive AGENTS.MD Files Are a Problem

There's a natural feedback loop that causes AGENTS.md files to grow dangerously large:

1. The agent does something you don't like

2. You add a rule to prevent it

3. Repeat hundreds of times over months

4. File becomes a "ball of mud"

Different developers add conflicting opinions. Nobody does a full style pass. The result? An unmaintainable mess that actually hurts agent performance.

Another culprit: auto-generated AGENTS.md files. Never use initialization scripts to auto-generate your AGENTS.md. They flood the file with things that are "useful for most scenarios" but would be better progressively disclosed. Generated files prioritize comprehensiveness over restraint.

The Instruction Budget

Kyle from Humanlayer's article mentions the concept of an "instruction budget":

Frontier thinking LLMs can follow ~ 150-200 instructions with reasonable consistency. Smaller models can attend to fewer instructions than larger models, and non-thinking models can attend to fewer instructions than thinking models.

Every token in your AGENTS.md file gets loaded on every single request, regardless of whether it's relevant. This creates a hard budget problem:

Taken together, this means that the ideal AGENTS.md file should be as small as possible.

Stale Documentation Poisons Context

Another issue for large AGENTS.md files is staleness.

Documentation goes out of date quickly. For human developers, stale docs are annoying, but the human usually has enough built-in memory to be skeptical about bad docs. For AI agents that read documentation on every request, stale information actively poisons the context.

This is especially dangerous when you document file system structure. File paths change constantly. If your AGENTS.md says "authentication logic lives in src/auth/handlers.ts" and that file gets renamed or moved, the agent will confidently look in the wrong place.

Instead of documenting structure, describe capabilities. Give hints about where things might be and the overall shape of the project. Let the agent generate its own just-in-time documentation during planning.

Domain concepts (like "organization" vs "group" vs "workspace") are more stable than file paths, so they're safer to document. But even these can drift in fast-moving AI-assisted codebases. Keep a light touch.

Cutting Down Large AGENTS.md File

Be ruthless about what goes here. Consider this the absolute minimum:

• One-sentence project description (acts like a role-based prompt)

• Package manager (if not npm; or use corepack for warnings)

• Build/typecheck commands (if non-standard)

That's honestly it. Everything else should go elsewhere.

The One-Liner Project Description

This single sentence gives the agent context about why they're working in this repository. It anchors every decision they make.

Example: This is a React component library for accessible data visualization.

That's the foundation. The agent now understands its scope.

Package Manager Specification

If you're In a JavaScript project and using anything other than npm, tell the agent explicitly:

This project uses pnpm workspaces.

Without this, the agent might default to npm and generate incorrect commands.

Use Progressive Disclosure

Instead of cramming everything into AGENTS.md, use progressive disclosure: give the agent only what it needs right now, and point it to other resources when needed.

Agents are fast at navigating documentation hierarchies. They understand context well enough to find what they need.

Move Language-Specific Rules to Separate Files

If your AGENTS.md currently says:

Always use const instead of let.
Never use var.
Use interface instead of type when possible.
Use strict null checks.
...

Move that to a separate file instead. In your root AGENTS.md:

For TypeScript conventions, see docs/TYPESCRIPT.md

Notice the light touch, no "always," no all-caps forcing. Just a conversational reference.

The benefits:

• TypeScript rules only load when the agent writes TypeScript

• Other tasks (CSS debugging, dependency management) don't waste tokens

• File stays focused and portable across model changes

Nest Progressive Disclosure

You can go even deeper. Your docs/TYPESCRIPT.md can reference docs/TESTING.md. Create a discoverable resource tree:

docs/
├── TYPESCRIPT.md
│   └── references TESTING.md
├── TESTING.md
│   └── references specific test runners
└── BUILD.md
    └── references esbuild configuration

You can even link to external resources, Prisma docs, Next.js docs, etc. The agent will navigate these hierarchies efficiently.

Use Agent Skills

Many tools support "agent skills" - commands or workflows the agent can invoke to learn how to do something specific. These are another form of progressive disclosure: the agent pulls in knowledge only when needed.

AGENTS.MD in Monorepos

You're not limited to a single AGENTS.md at the root. You can place AGENTS.md files in subdirectories, and they merge with the root level.

This is powerful for monorepos:

What Goes Where:

Root AGENTS.md:

This is a monorepo containing web services and CLI tools.
Use pnpm workspaces to manage dependencies.
See each package's AGENTS.md for specific guidelines.

Package-level AGENTS.md (in packages/api/AGENTS.md):

This package is a Node.js GraphQL API using Prisma.
Follow docs/API_CONVENTIONS.md for API design patterns.

Don't overload any level. The agent sees all merged AGENTS.md files in its context. Keep each level focused on what's relevant at that scope.

Fix A Broken Agents.md with this prompt

If you're starting to get nervous about the AGENTS.md file in your repo, and you want to refactor it to use progressive disclosure, try copy-pasting this prompt into your coding agent:

I want you to refactor my AGENTS.md file to follow progressive disclosure principles.

Follow these steps:

1. **Find contradictions**: Identify any instructions that conflict with each other. For each contradiction, ask me which version I want to keep.

2. **Identify the essentials**: Extract only what belongs in the root AGENTS.md:
   - One-sentence project description
   - Package manager (if not npm)
   - Non-standard build/typecheck commands
   - Anything truly relevant to every single task

3. **Group the rest**: Organize remaining instructions into logical categories (e.g., TypeScript conventions, testing patterns, API design, Git workflow). For each group, create a separate markdown file.

4. **Create the file structure**: Output:
   - A minimal root AGENTS.md with markdown links to the separate files
   - Each separate file with its relevant instructions
   - A suggested docs/ folder structure

5. **Flag for deletion**: Identify any instructions that are:
   - Redundant (the agent already knows this)
   - Too vague to be actionable
   - Overly obvious (like "write clean code")

Don’t Build a Ball of Mud

When you're about to add something to your AGENTS.md, ask yourself where it belongs:

The ideal AGENTS.md is small, focused, and points elsewhere. It gives the agent just enough context to start working, with breadcrumbs to more detailed guidance.

Everything else lives in progressive disclosure: separate files, nested AGENTS.md files, or skills.

This keeps your instruction budget efficient, your agent focused, and your setup future-proof as tools and best practices evolve.

Agent Skills

What are the Claude Skills?

Claude Skills, officially launched as "Agent Skills" in October 2024 and significantly expanded in December 2024, are modular capabilities that teach Claude how to perform specific tasks in a repeatable, specialized way.

Think of Skills as custom training modules. Instead of explaining the same process to Claude every single time ("Here's how our company formats PRDs" or "Here's how we analyze user data"), you package those instructions once into a Skill. From then on, Claude automatically recognizes when that Skill is relevant and applies it.

The technical definition: Skills are folders containing instructions, scripts, and resources that Claude loads dynamically when needed to perform specialized tasks. They can include:

• Markdown files with instructions and procedures

• Executable code for complex operations

• Templates and examples

• Domain-specific knowledge

The practical reality: Skills turn Claude from a general-purpose AI into a specialist that knows your workflows, your brand guidelines, your data analysis methods, and your organizational processes.

https://resources.anthropic.com/hubfs/The-Complete-Guide-to-Building-Skill-for-Claude.pdf?hsLang=en

A Brief History: How Skills Evolved

Understanding when and why Anthropic introduced Skills helps explain why this matters now:

October 2024: Anthropic quietly launched Agent Skills as a beta feature. Initially, it was developer-focused—available through the API and Claude Code. The idea was simple: let developers package specialized capabilities that Claude could invoke when relevant.

December 18, 2024: The major expansion. Anthropic made Skills available across claude.ai, introduced organization-wide management for Team and Enterprise plans, launched a Skills Directory with partner-built skills from companies like Notion, Figma, Canva, and Atlassian, and most importantly, published Agent Skills as an open standard at agentskills.io.

January 2025: Skills became integrated with other Claude features like Memory, Extended Thinking, and the new Cowork agent. The Skills Directory expanded significantly, and custom skill creation became more accessible to non-technical users.

Current State (January 2026): Skills are now available to Pro, Max, Team, and Enterprise users. You can use pre-built Anthropic Skills (for Excel, PowerPoint, Word, PDFs), install partner Skills from the directory, or create custom Skills tailored to your exact workflows.

The evolution shows Anthropic's strategy: start with developers, prove the concept, then democratize it for everyone. And it's working.

What Claude Skills do?

1. Teach Claude ONCE, Benefit FOREVER (Zero Re-Explaining): Skills are instruction folders Claude loads automatically when relevant. Stop re-explaining your preferences, processes, and domain expertise in every single conversation. One folder = permanent memory of your workflow. Build in 15-30 minutes using the built-in skill-creator tool. Works for frontend design, research methodology, document creation, sprint planning, customer onboarding, and compliance workflows. Saves hours weekly across teams and individual users.

2. Progressive Disclosure = Minimal Token Usage (3-Level System): The 3-level system is genius: Level 1 (YAML frontmatter) always stays in Claude's system prompt — just enough for Claude to know WHEN to activate. Level 2 (SKILL.md body) loads only when relevant. Level 3 (linked files) loads only as needed. Result: specialized expertise without bloating every conversation. Same AI power, fraction of the token cost. An estimated 50%+ reduction in tokens per workflow session versus re-prompting every chat. Keep SKILL.md under 5,000 words, move detailed docs to references/ folder

3. One Skill = All Surfaces (100% Portability): Build a skill ONCE, and it works identically on Claude.ai, Claude Code, and API — no modifications needed. This is unprecedented in AI tooling. Competitors lock you into one interface. Skills follow you everywhere. Deploy to individuals, teams, or your entire organization from one central folder. Organization-wide deployment launched December 18, 2025, with automatic updates and centralized admin management for enterprise teams.

4. MCP + Skills = Your AI Employee (Kitchen Analogy): MCP provides the professional kitchen: real-time access to Notion, Asana, Linear, Slack, GitHub, and Figma. Skills provide the recipes: step-by-step instructions optimized for YOUR workflow. Without Skills, MCP users get tool access but no workflow guidance — resulting in support tickets and inconsistent results. With Skills, pre-built workflows activate automatically. Anthropic data shows users blame the MCP connector when the real issue is missing workflow knowledge.

5. 5 Battle-Tested Patterns (Real-World Workflows): Anthropic released 5 proven workflow patterns from early adopters: Pattern 1 (Sequential Workflow) for multi-step processes in exact order. Pattern 2 (Multi-MCP Coordination) for workflows spanning Figma, Drive, Linear, and Slack simultaneously. Pattern 3 (Iterative Refinement) for self-validating output loops. Pattern 4 (Context-Aware Tool Selection) for smart routing to the right tool. Pattern 5 (Domain-Specific Intelligence) for compliance, finance, and legal workflows with embedded rules.

6. OPEN Standard = Platform-Independent (Like MCP): Anthropic published Agent Skills as an OPEN standard. Like MCP, skills work across AI platforms — not locked to Claude. Early ecosystem adoption already underway. Partners from Asana, Atlassian, Canva, Figma, Sentry, and Zapier have published skills. The GitHub repo anthropics/skills contains production-ready skills you can customize TODAY instead of building from scratch. Community-built skills are multiplying fast — early publishers gain maximum visibility and downloads.

7. Skill File Structure (15-Minute Setup): A skill is JUST a folder with 4 possible items: SKILL.md (required — Markdown with YAML frontmatter), scripts/ (optional Python or Bash), references/ (optional docs loaded on demand), assets/ (optional templates and icons). Folder name MUST be kebab-case (sprint-planner, NOT Sprint Planner or sprint_planner). SKILL.md must be EXACTLY that spelling — case-sensitive. No README.md inside the skill folder. Start with just SKILL.md — that is the entire minimum viable skill.

8. API Integration = Production-Scale Deployment (/v1/skills): For production applications, the /v1/skills endpoint lets you manage skills programmatically. Add skills to Messages API requests via the container.skills parameter. Version control through Claude Console. Works with Claude Agent SDK for custom AI agents. Requires Code Execution Tool beta access. Use the API for production deployments, automated pipelines, and agent systems. Individual users should use Claude.ai. API skills unlock enterprise-grade AI workflow automation at unlimited scale.

9. Trigger Optimization = 90%+ Auto-Activation Rate: The description field is EVERYTHING. Target: skill triggers on 90%+ of relevant queries automatically. Good descriptions include WHAT the skill does AND WHEN to use it with specific trigger phrases. Bad: "Helps with projects." Good: "Manages Linear sprint planning. Use when user mentions 'sprint', 'Linear tasks', or asks to 'create tickets'." Run 10-20 test queries. Ask Claude directly: "When would you use the [skill name] skill?" — Claude quotes your description back and reveals exactly what is missing.

10. Organization-Wide Skills Deployment (December 2025): Admins can now deploy skills workspace-wide — launched December 18, 2025. Automatic updates push to all users simultaneously. Centralized management from admin panel. One skill update standardizes EVERY team member's workflow instantly. No more inconsistent AI results between teammates who prompt differently. Companies building skills libraries NOW gain compounding efficiency advantages against competitors still re-explaining context every single chat session. This is the AI operations layer enterprises have been waiting for.

Why This Changes Everything

1. The End of Prompt Engineering (Finally): Prompt engineering required constant re-explanation, relied on individual memory, produced inconsistent results, and could not be shared easily. Skills are shareable, versioned, auto-activating, and organization-deployable. The shift is from art (crafting the perfect prompt) to engineering (building a reliable system). Early adopters building skills libraries NOW will have a 6-12 month workflow advantage over teams still copying prompts from Notion docs and Slack messages.

2. Solves the "New Chat = New Explanation" Problem: Every new Claude conversation resets context completely. Skills eliminate this permanently. Claude loads your workflow automatically based on what you say — no explicit trigger needed. Power users currently spend 10-20% of their AI time re-establishing context every session. Skills compress that to near-zero. The compounding time savings across 1,000+ sessions per year is enormous — estimated 200+ hours annually per person recovered from pure context-setting overhead.

3. Democratizes Expert AI Workflows: Previously, getting Claude to follow expert workflows required prompt engineering knowledge, time, and extensive trial-and-error. Skills democratize this: download a community-built skill from GitHub, upload to Claude.ai in 60 seconds, and instantly access workflows built by domain experts. A junior marketer can now operate with the same AI workflow sophistication as a senior AI engineer. The public skills marketplace is still early — first movers can publish skills that thousands of users download and benefit from.

4. MCP Adoption Accelerator (Critical for Developers): Without skills, MCP integrations face user abandonment: users connect the tool but don't know how to use it effectively. With skills, MCP becomes turnkey. Anthropic's research shows users blame the MCP connector when the real issue is missing workflow guidance. Skills fix this permanently. If you've built an MCP server, adding a companion skill dramatically increases user retention, reduces support tickets, and differentiates your product from the growing field of MCP-only competitors.

5. Compounding Efficiency = Compounding Advantage: Every skill you build is a one-time investment that pays dividends indefinitely. Build a 30-minute skill today, save 5 minutes per workflow session. At 10 sessions per day = 50 minutes saved daily = 250 minutes per week = 200+ hours per year per person. Teams of 10 = 2,000+ hours annually recovered from a single well-built skill. Organizations building skills libraries systematically gain structural productivity advantages that compound over time against competitors still working session-by-session.

When something deserves to become a Skill

The Skill doesn’t come first. What comes first is a pattern.

Every time I faced messy strategic notes, I was unconsciously applying the same mental structure:

Clarify the context → Extract key signals → Surface risks → Compare trade-offs → Present structured options → Define next steps

That repetition is what changed everything.

Because repetition is the signal that something deserves structure.

Here are the problems I had before using skills (and what they led to):

• No defined role → Inconsistent responses

• No rules → Shifts in tone

• No boundaries → Unnecessary creative drift

• No environment → Constant repetition

That shift didn’t happen because I created a Skill. It happened because I stopped improvising.

Structure came first. Automation came second.

The hidden step most people skip can be summarized like this:

The difference is massive. In the first case (left side), you automate an idea. In the second case (right side), you automate a proven framework.

A Skill is not a clever idea. It is a structure that has already proven it works multiple times.

Skills vs. Other Claude Features: What's the Difference?

Claude has several features that sound similar. Here's how they differ:

Skills vs. Projects:

• Projects provide static background context that's always loaded when you're in that project

• Skills provide dynamic procedures that only load when relevant

• Use Projects for persistent knowledge, Skills for repeatable processes

Skills vs. Custom Instructions:

• Custom Instructions apply broadly to all your conversations

• Skills are task-specific and only activate when needed

• Custom Instructions set general preferences; Skills provide specialized procedures

Skills vs. MCP Connectors:

• MCP Connectors give Claude access to external tools and data (like Notion, Slack)

• Skills teach Claude how to use those tools effectively

• They work together: MCP provides access, Skills provide process

Example: An MCP connector gives Claude access to your Notion workspace. A Skill teaches Claude how to format meeting notes according to your team's specific template within Notion.

Potential Drawbacks and Limitations

Let's be honest about where Skills fall short:

1. Requires Code Execution to be Enabled
Skills use Claude's code execution capability. If you've disabled this for security reasons, Skills won't work. This is a consideration for enterprises with strict security policies.

2. Initial Setup Time
Creating good Skills takes time. You need to document processes clearly, provide examples, and iterate based on results. The ROI is there, but it's not instant.

3. Not Ideal for Highly Dynamic Processes
If your workflow changes constantly, maintaining Skills becomes overhead. They're best for processes that are reasonably stable.

4. Potential for Over-Reliance
There's a risk that teams become dependent on Skills without understanding the underlying processes. Junior PMs might use a "Feature Spec" Skill without learning what makes a good spec.

5. Quality Depends on Quality of Instructions
Garbage in, garbage out. Poorly written Skill instructions produce inconsistent results. This requires thoughtful documentation.

6. Limited to Available Plans
Skills are only available on Pro, Max, Team, and Enterprise plans. Free-tier users can't access them.

Finding & Installing Third-Party Skills

1. Official Anthropic Repositories

github.com/anthropics/skills → Official skill examples + production document skills (docx, pdf, pptx, xlsx). Apache 2.0 for examples; source-available for doc skills. Functions as a Claude Code Plugin marketplace.

github.com/anthropics/claude-plugins-official → Official plugin marketplace directory. Third-party partners can submit.

github.com/anthropics/knowledge-work-plugins → 11 role-based plugins (Sales, Support, Product Management, Finance, Data, etc.) with skills, commands, and MCP connectors. Open source.

github.com/anthropics/life-sciences → Life sciences MCP servers and skills (PubMed, BioRender, etc.)

1. Community Skill Directories & Marketplaces

skills.sh → Primary distribution hub. npx skills add . Leaderboard, multi-platform.

skillsmp.com → Independent directory, aggregates from GitHub. Min 2-star filter.

skillhub.club → 20K+ skills with AI-evaluated quality ratings. Has a playground.

hub.skild.sh → Another community registry

agentskill.sh → 25K+ skills directory, browseable by category/platform

1. Key Community Projects

obra/superpowers → Complete software dev workflow: brainstorm → plan → TDD → implement → review. 20+ battle-tested skills. The gold standard for skill composition. Install: /plugin marketplace add obra/superpowers-marketplace then /plugin install superpowers@superpowers-marketplace

obra/superpowers-skills → Community-editable extension to Superpowers

obra/superpowers-lab → Experimental skills (tmux for interactive commands, etc.)

travisvn/awesome-claude-skills → Curated awesome-list of skills, resources, and tools

numman-ali/openskills → Universal skills loader. npx openskills install anthropics/skills. Works across Claude Code, Cursor, Windsurf, Aider, Codex, etc.

vercel-labs/agent-skills → Vercel’s official skills: React, Next.js, React Native patterns + Vercel deploy skill

qufei1993/skills-hub → Desktop app: “Install once, sync everywhere” — manages skills across multiple AI tools

inference.sh skills → 150+ cloud AI app skills (image gen, video, TTS, search) via infsh CLI

Building Your Own Skills — Best Practices

Design Principles

1. Single-purpose: “SEO optimization for blog posts” is good. “Content marketing helper” is too broad. “Add meta descriptions” is too narrow.

2. Description is king: Claude routes based on the description field. Vague = missed triggers. Overly generic = false triggers. Be specific about when and what.

3. Progressive disclosure: Keep SKILL.md lean. Reference files for deep details. Scripts for deterministic steps.

4. Imperative instructions: Write as if onboarding a smart junior engineer. Be explicit about steps, inputs, outputs.

5. Include examples: Show expected inputs and outputs. Show what “good” looks like.

6. Token budget: Metadata ~50-100 tokens. Full SKILL.md < 5000 tokens. Reference files on-demand.

The Description Field — Most Important 200 Characters You’ll Write

Bad:

yaml

description: Helps with code

Good:

yaml

description: >-
  Generate FastAPI backend with React+Vite frontend, Tailwind, shadcn/ui,
  and OpenAI integration. Use when asked to scaffold a full-stack AI app.

Claude uses semantic matching, not keyword matching — but vague descriptions still reduce accuracy.

Skill Structure Patterns

Pattern 1: Instructions-only (simplest)

my-skill/
└── SKILL.md     # All instructions in one file

Pattern 2: Instructions + References

brand-guidelines/
├── SKILL.md           # Overview + when to apply
└── references/
    ├── colors.md      # Detailed color specs
    ├── typography.md   # Font rules
    └── voice.md       # Tone of voice guide

Pattern 3: Instructions + Scripts (executable)

data-pipeline/
├── SKILL.md
├── scripts/
│   ├── validate.py
│   └── transform.sh
└── templates/
    └── output-schema.json

Pattern 4: Full production skill (like the built-in docx skill)

docx/
├── SKILL.md
├── LICENSE.txt
├── scripts/
│   ├── office/
│   │   ├── soffice.py
│   │   ├── unpack.py
│   │   └── validate.py
│   └── accept_changes.py
├── references/
│   └── REFERENCE.md
└── examples/
    └── sample-doc.docx

Creating Skills with the Skill-Creator

Claude has a built-in skill-creator skill (available in claude.ai and as a plugin). The workflow:

1. Tell Claude “I want to create a skill for X”

2. It interviews you about the workflow

3. Generates the SKILL.md and folder structure

4. Creates test prompts

5. Runs Claude-with-skill on them

6. You evaluate results

7. Iterate until satisfied

You can also use the eval/benchmark system for more rigorous testing:

• Eval mode: Test individual prompts, compare with/without skill

• Improve mode: Iterative optimization with blind A/B comparisons

• Benchmark mode: Standardized measurement with variance analysis (3x runs per config)

Claude Code-Specific Features

In Claude Code, skills gain extra powers via frontmatter:

yaml

---
name: deep-research
description: Research a topic thoroughly
context: fork          # Runs in a forked subagent
agent: Explore         # Uses the Explore agent (read-only tools)
---

Options for context:

• Default (omitted): Claude loads it when relevant

• fork: Runs as a separate subagent task

Options for agent:

• Explore: Read-only codebase exploration

• Plan: Planning-focused

• Custom: Any subagent from .claude/agents/

Skills can also be invoked as slash commands:

• .claude/skills/review/SKILL.md creates /review

• (This replaced the older .claude/commands/ system)

Getting-Up-To-Speed - Practical Plan

Here I outline a practical approach on how to multiply your productivity by integrating agentic skills into your day-to-day workflow with Claude, Codex, or any other AI agent tool of your choice (using Claude as an example).

1. Foundation (2-3 hours)

Understand the landscape

• Read the Agent Skills specification (15 min)

• Read Anthropic’s blog post introducing skills (10 min)

• Read the how to create skills guide (15 min)

• Read the Claude Code skills docs (15 min)

• Read Lee Han Chung’s deep dive on skill architecture (20 min)

Explore existing skills

• Browse github.com/anthropics/skills — read 3-4 example SKILL.md files to see patterns

• Browse skills.sh and skillsmp.com to see what the community has built

• Install Superpowers in Claude Code: /plugin marketplace add obra/superpowers-marketplace + /plugin install superpowers@superpowers-marketplace

• Read Jesse Vincent’s blog post on Superpowers — this is the best practical write-up on skill composition

• Browse travisvn/awesome-claude-skills for curated resources

Try it hands-on

• Ask Claude (in claude.ai or Claude Code) to “create a skill for [something you do repeatedly]” — use the skill-creator

• Test the generated skill on a real task

• Iterate once or twice based on results

1. Build Your System (3-4 hours)

Set up your skills infrastructure

• Create a GitHub repo for your personal skills (your-username/claude-skills)

• Add a marketplace.json to make it a Claude Code marketplace

• Set up Obsidian vault with the Skills/ and Workflows/ structure described above

• Install the Obsidian Git plugin and connect to your skills repo

• Create a SKILL.md template in Obsidian Templater

Build your first 3 skills Start with workflows you repeat across projects:

1. Your project scaffolding workflow — how you set up a new project (tech stack, folder structure, CI, etc.)

2. Your code review checklist — your standards for reviewing code

3. Your product spec process — how you go from idea to spec

For each:

1. Document the workflow in Obsidian Workflows/

2. Draft the SKILL.md

3. Push to Git

4. Register your marketplace in Claude Code

5. Test on a real task

6. Iterate

Day 5: Explore the API surface

• Read the Skills API docs

• Try uploading a custom skill via the API

• Understand the /v1/skills endpoints for programmatic management

1. Scale & Parallelize (3-4 hours)

Build product-specific skills For each of your product ideas, create:

• Domain knowledge skill (what this product does, its entities, its terminology)

• Architecture skill (your preferred stack, patterns, conventions for this product)

• Testing skill (how you want tests structured for this product)

Explore advanced patterns

• Read the MCP builder skill — skills + MCP is a powerful combination

• Try context: fork and subagent delegation in Claude Code

• Explore anthropics/knowledge-work-plugins for the plugin architecture pattern

• Install openskills (npx openskills install anthropics/skills) for cross-tool skill management

Automate and refine

• Set up GitHub Actions to validate your skills on push (use skills-ref Python library)

• Create a “meta-skill” that helps you create new skills faster (or use the built-in skill-creator as a base)

• Document your skills system in your Obsidian vault so future-you (and future-Claude) can maintain it

https://codeagentsalpha.substack.com/p/claude-agent-skills-complete-getting

https://sifuyik.substack.com/p/anthropic-dropped-the-32-page-internal

https://artificialcorner.com/p/claude-code-skills

https://medium.com/product-powerhouse/claude-skills-the-ai-feature-thats-quietly-changing-how-product-managers-work-aad5d8d0640a

https://www.youngleaders.tech/p/claude-skills-commands-subagents-plugins

https://aiblewmymind.substack.com/p/claude-skills-36-examples

https://medium.com/@mohit15856/i-tested-anthropics-skill-creator-plugin-on-my-own-skills-here-s-what-i-found-23ad406b0825

Spec-Driven Development

Like with many emerging terms in this fast-paced space, the definition of “spec-driven development” (SDD) is still in flux. Here’s what I can gather from how I have seen it used so far: Spec-driven development means writing a “spec” before writing code with AI (“documentation first”). The spec becomes the source of truth for the human and the AI.

GitHub: “In this new world, maintaining software means evolving specifications. […] The lingua franca of development moves to a higher level, and code is the last-mile approach.”

Tessl: “A development approach where specs — not code — are the primary artifact. Specs describe intent in structured, testable language, and agents generate code to match them.”

After looking over the usages of the term, and some of the tools that claim to be implementing SDD, it seems to me that in reality, there are multiple implementation levels to it:

1. Spec-first: A well thought-out spec is written first, and then used in the AI-assisted development workflow for the task at hand.

2. Spec-anchored: The spec is kept even after the task is complete, to continue using it for evolution and maintenance of the respective feature.

3. Spec-as-source: The spec is the main source file over time, and only the spec is edited by the human, the human never touches the code.

All SDD approaches and definitions I’ve found are spec-first, but not all strive to be spec-anchored or spec-as-source. And often it’s left vague or totally open what the spec maintenance strategy over time is meant to be.

What Is Spec-Driven Development?

The key question in terms of definitions of course is: What is a spec? There doesn’t seem to be a general definition, the closest I’ve seen to a consistent definition is the comparison of a spec to a “Product Requirements Document”.

The term is quite overloaded at the moment, here is my attempt at defining what a spec is:

A spec is a structured, behavior-oriented artifact - or a set of related artifacts - written in natural language that expresses software functionality and serves as guidance to AI coding agents. Each variant of spec-driven development defines their approach to a spec’s structure, level of detail, and how these artifacts are organized within a project.

There is a useful difference to be made I think between specs and the more general context documents for a codebase. That general context are things like rules files, or high level descriptions of the product and the codebase. Some tools call this context a memory bank, so that’s what I will use here. These files are relevant across all AI coding sessions in the codebase, whereas specs only relevant to the tasks that actually create or change that particular functionality.

The challenge with evaluating SDD tools

It turns out to be quite time-consuming to evaluate SDD tools and approaches in a way that gets close to real usage. You would have to try them out with different sizes of problems, greenfield, brownfield, and really take the time to review and revise the intermediate artifacts with more than just a cursory glance. Because as GitHub’s blog post about spec-kit says: “Crucially, your role isn’t just to steer. It’s to verify. At each phase, you reflect and refine.”

For two of the three tools I tried it also seems to be even more work to introduce them into an existing codebase, therefore making it even harder to evaluate their usefulness for brownfield codebases. Until I hear usage reports from people using them for a period of time on a “real” codebase, I still have a lot of open questions about how this works in real life.

That being said - let’s get into three of these tools. I will share a description of how they work first (or rather how I think they work), and will keep my observations and questions for the end. Note that these tools are very fast evolving, so they might have already changed since I used them in September.

The Three Documents (and Why They’re Different)

I see people conflating PRDs, design docs, and specs constantly. They serve different purposes.

Product Requirements Document (PRD): For humans; product managers, stakeholders. Covers what we’re building and why. Business value, user stories, success metrics. This is a debate document.

Technical Design Document: For engineers. Covers how we’re building it. Architecture decisions, scalability considerations, security implications. Also debated and reviewed.

AI Spec: For agents. This is an execution document - not a debate, a plan. It translates decisions from the PRD and design doc into something an agent can act on.

In practice, you don’t always write all three. For a small feature, you might skip straight to a spec. For a large initiative, you’d have a PRD that spawns multiple design docs, each spawning multiple specs. The spec is always the final translation layer before code.

Anatomy of a Good Spec

A spec has four parts:

1. Why (Brief Context)

Keep this short. One or two sentences about the problem you’re solving. This helps the agent make intelligent decisions if it encounters ambiguity.

2. What (Scope)

Define the boundaries. What features are you building? Be specific about implementation details the agent would otherwise guess about.

Example: “JWT-based auth with one-hour access tokens and seven-day refresh tokens. Users can register, login, and refresh tokens.”

3. Constraints (Boundaries)

This is where you prevent the agent from being too eager. What libraries to use. What patterns to follow. What’s explicitly out of scope.

Example: “Use bcrypt for password hashing. Store user data in Postgres via Prisma. Must not add new dependencies. Must not store tokens in the database. Out of scope: password reset, OAuth, email verification.”

4. Tasks (Discrete Work Units)

Break the work into small, verifiable chunks. Each task should specify what to build, which files to touch, and how to verify completion.

Example:

• Task 1: Add user model to Prisma schema. Verify: npx prisma generate succeeds.

• Task 2: Create registration endpoint. Verify: Test with curl, user appears in database.

• Task 3: Create login endpoint. Verify: Returns valid JWT on correct credentials.

When Specs Go Wrong

Specs fail in two directions.

Over-specified: You’ve constrained the agent so tightly it can’t solve the problem. Signs: the agent keeps asking for permission, or produces convoluted code to satisfy contradictory constraints. Fix: loosen constraints, focus on outcomes rather than implementation details.

Under-specified: The agent still has to guess. Signs: you review the code and find unexpected decisions - new files, different patterns, surprise dependencies. Fix: add the missing constraints. Each surprise is a constraint you forgot to write down.

The goal is a spec tight enough that the agent can’t make decisions you’d disagree with, but loose enough that it can solve problems you didn’t anticipate.

My Workflow

It’s important to point out that this level of planning isn’t always needed. If you’re fixing a simple bug, you likely don’t need extensive planning. Just do it. If you’re working on something large that might split into many tasks or run over multiple sessions - write a spec.

Here’s how I actually use specs day to day:

Step 1: Generate. I describe what I want to build to the agent and ask it to write a spec—not implement the feature. I use a /spec command for this.

Step 2: Iterate. I review the spec carefully. The agent will make assumptions. I correct them, add constraints I forgot, remove scope creep. This is where I catch problems before they become code.

Step 3: Execute. I open a fresh session. I ask the agent to read the spec and implement Task 1. Review the code. Commit. Move to Task 2.

“Read and implement T1”

Step 4: Adapt. Review the code. Could it be improved? Maybe Task 3 reveals a flaw in the spec. I go back and update it. This isn’t waterfall, it’s iterative. The spec is a living document.

The key insight: don’t ask the same agent to plan the work and do the work. Planning and execution are different modes. An agent that’s planning will think through edge cases. An agent that’s executing will rush to ship.

Skip the Frameworks?

There are a lot of spec-driven development frameworks out there. OpenSpec. Kiro. GitHub Spec Kit. I’ve tried them.

To me, they felt like overkill.

They generate tons of files. They want you to define user stories in markdown. They add ceremony that slows you down without adding value.

Here’s what you actually need: one slash command that acts as a meta-prompt to generate a spec.

> “/spec implement rate limiting in the API.

The power of spec-driven development isn’t in the tooling. It’s in the practice of thinking before prompting. A fancy framework won’t fix sloppy thinking. A simple markdown file that forces you to articulate constraints is probably enough.

If you want a comparison of these tools, I recommend the excellent article Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl by Birgitta Böckeler.

Why This Creates Leverage

Spec-driven development isn’t new. Software teams have always worked this way. PRD > Design doc > Task breakdown > Implementation. The only difference is we’re handing tasks to agents instead of other developers.

But here’s what changes: an agent that executes well-defined specs can move faster than any human. The bottleneck shifts from implementation to specification. Your job becomes defining work clearly enough that an agent can execute it autonomously.

https://newsletter.owainlewis.com/p/how-i-code-with-ai-agents-spec-driven

https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

https://heeki.medium.com/using-spec-driven-development-with-claude-code-4a1ebe5d9f29

https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html?ref=dailydev

https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

Claude Code Ralph Loop

Every Claude Code session has the same hidden flaw; Claude stops when it thinks the job is done.

• Tests broken

• API half-implemented,

• Edge cases untouched

But it declares complete and exits. And the longer and more complex the task, the worse it gets.

There is a technique designed to fix this problem. You have probably heard the word “Ralph” thrown around.

It’s a simple idea that forces Claude to keep iterating until the work is genuinely completed.

Surprisingly, this technique has been used to ship entire projects overnight at a fraction of the actual cost.

In this newsletter, I’ll take you from understanding why Claude fails on complex tasks to building the full Ralph Loop system and running it on real projects.

We’ll cover the Ralph core mechanism, the PRD and memory architecture, and everything you need to put Ralph Loop to work.

Let’s start with the basics.

What is Ralph Loop?

Let me start with something that might surprise you.

Ralph Loop isn’t a framework, and it is not a sophisticated AI orchestration system. At the core, it’s a Bash while loop.

while true; do
  cat prompt.md | claude
done

The technique was created by Jeffrey Huntley

The name comes from Ralph Wiggum, arguably the dumbest character in The Simpsons. Ralph fails constantly, making silly mistakes. But stubbornly continues in an endless loop until he eventually succeeds.

This childlike persistence is the philosophy behind the technique.

With Ralph Loop, Claude is no longer allowed to exit when it thinks it’s done. It’s forced to keep working until the task is truly finished.

The key insight is that Ralph Loop treats failure as expected, not exceptional.

Each iteration builds on the last. The AI sees what it did before, recognizes what’s still broken, and improves.

Why Claude Code Needs Ralph

Claude Code has a limitation that most developers don’t recognize until they’ve hit it repeatedly.

It operates in single-pass mode.

Even though Claude reasons extremely well, it stops as soon as it believes the output is “good enough.”

The model has what you might call an implicit execution budget. Once it feels like it’s done reasonable work, it wraps up and exits.

The problem is that “ good enough”, according to Claude, often isn’t good enough.

I’ve seen this pattern dozens of times:

• Claude builds a feature, declares it complete, but the edge cases are broken

• Claude writes tests, says they pass, but they don’t actually run

• Claude implements an API, marks it done, but forgot error handling

It believes it’s finished, but it’s making that judgment based on what the code looks like, not whether it works.

Another problem that makes this worse is the context rot.

As the conversation with Claude gets longer, the context window fills up. The model’s reasoning quality degrades as it has to juggle more information.

Jeffrey Huntley calls this “compaction” — when the context gets summarized and loses important details. The model starts forgetting things it knew earlier in the conversation. It makes mistakes it wouldn’t have made with a fresh context.

This is why the single-pass approach fails for complex tasks.

By the time Claude reaches the end of a big feature, its context is bloated with attempts, errors, and fixes. The quality of its reasoning has degraded.

Ralph Loop solves both problems:

1. Forces verification — Claude can’t exit until it proves the work is done

2. Fresh context — Each iteration starts clean, avoiding context rot

https://newsletter.claudecodemasterclass.com/p/claude-code-ralph-loop-from-basic

Conductors to Orchestrators: The Future of Agentic Coding

AI coding assistants have quickly moved from novelty to necessity where up to 90% of software engineers use some kind of AI for coding. But a new paradigm is emerging in software development - one where engineers leverage fleets of autonomous coding agents. In this agentic future, the role of the software engineer is evolving from implementer to manager, or in other words, from coder to conductor and ultimately orchestrator.

Over time, developers will increasingly guide AI agents to build the right code and coordinate multiple agents working in concert. This write-up explores the distinction between Conductors and Orchestrators in AI-assisted coding, defines these roles, and examines how today’s cutting-edge tools embody each approach. Senior engineers may start to see the writing on the wall: our jobs are shifting from “How do I code this?” to “How do I get the right code built?” - a subtle but profound change.

What’s the tl;dr of an orchestrator tool? It supports multi-agent workflows where you can run many agents in parallel without them interfering with each another. But let’s talk terminology more first.

https://addyo.substack.com/p/conductors-to-orchestrators-the-future

Critical Thinking during the age of AI

In a time where AI can generate code, design ideas, and occasionally plausible answers on demand, the need for human critical thinking is greater than ever. Even the smartest automation can’t replace the ability to ask the right questions, challenge assumptions, and think independently at this time.

This essay explores the importance of critical thinking skills for software engineers and technical teams using the classic “Who, what, where, when, why, how” framework to structure pragmatic guidance.

Critical thinking checklist for AI-augmented teams

• Who: Don’t rely on AI as an oracle. Verify its output.

• What: Define the real problem before rushing to a solution.

• Where: Context is king. A fix that works in a sandbox might break in production.

• When: Know when to use a quick heuristic (triage) vs. deep analysis (root cause).

• Why: Use the “5 Whys” technique to uncover underlying causes.

• How: Communicate with evidence and data, not just opinions.

We’ll dive into how each of these question categories applies to decision-making in an AI-augmented world, with concrete examples and common pitfalls. The goal is to show how humble curiosity and evidence-based reasoning can keep projects on track and avoid downstream issues.

https://addyo.substack.com/p/critical-thinking-during-the-age

Harness Engineering

Why AI Agents Fail on Large Files

Most engineers today interact with AI coding tools the same way: open Cursor, Claude Code, or Codex, type a prompt, review the output, repeat. For small files and isolated tasks, this works beautifully. But the moment the problem involves a large amount of files, the whole approach falls apart.

Large Language Models are probabilistic engines. They predict the next token based on patterns in their context window. When the context window is filled with thousands of lines of structured data, the model’s attention gets diluted. It correctly identifies the node you want to modify, but it loses track of sibling keys, nested brackets, and structural integrity. The result is a file that looks right at the point of change but is broken somewhere else.

We have to understand that Context Window isn’t the same as Context Attention. As a human, I can store hundreds of items in a storage unit, but I will remember about a fraction of the items I have there.

Same with LLMs. Performance degrades as the context window gets filled (and costs).

Did you know that every message you send is sending all the previous conversation in an API call? Yes, you’re billed also for those past messages. The servers in the cloud don’t keep any state, they only have a cache.

When the model fails to make an update, the instinct is to write a better prompt.

Add more constraints.

Tell the model to “preserve the surrounding structure.”

“Make no mistakes.”

But that is like asking someone to juggle while blindfolded and then giving them more detailed instructions about hand positioning. The problem is not the instructions. The problem is the blindfold.

The context window itself becomes a liability when it’s packed with thousands of lines of repetitive structure. No prompt can fix that.

I covered in this post how to scale AI, setting up guardrails

What Is Harness Engineering?

Harness engineering is the discipline of designing the systems, architectural constraints, execution environments, and automated feedback loops that wrap around AI agents to make them reliable in production.

The term was first coined by Mitchell Hashimoto, the founder of HashiCorp. The metaphor comes from horse riding. Think of the LLM as a powerful horse. It has raw energy, speed, and strength. But without reins, a saddle, and a bridle, that energy is undirected and potentially destructive (the horse kicks you, the LLM runs a rm -rf, and I don’t know which is worse). The harness allows the rider to direct the horse’s power productively.

To understand where harness engineering fits, here’s how it relates to the other disciplines you’ve probably heard about:

• Prompt Engineering → Single interaction to craft the best input to the model (single request-response interaction).

• Context Engineering → Control what the model sees during a whole session (multiple interactions until clearing).

• Harness Engineering → Designs the environment, tools, guardrails, and feedback loops (multiple sessions).

• Agent Engineering → Design the agent’s internal reasoning loop (define specialized agents).

• Platform Engineering → Infrastructure to manage deployment, scaling, and cloud operations (where agents can run).

Prompt engineering is about what you say to the model.

Context engineering is about what the model sees.

Harness engineering is about the entire world the model operates in. It includes the tools the agent can call, the constraints it cannot violate, the documentation structure it reads, and the automated feedback loops that catch its mistakes before they reach production.

https://strategizeyourcareer.com/p/harness-engineering-ai-agents

AI Best Practices

LLM Coding Workflow

https://addyo.substack.com/p/my-llm-coding-workflow-going-into

https://newsletter.systemdesign.one/p/ai-coding-workflow?ref=dailydev

https://escobyte.substack.com/p/writing-high-quality-production-code

AI coding assistants became game-changers this year, but harnessing them effectively takes skill and structure. These tools dramatically increased what LLMs can do for real-world coding, and many developers (myself included) embraced them.

At Anthropic, for example, engineers adopted Claude Code so heavily that today ~90% of the code for Claude Code is written by Claude Code itself. Yet, using LLMs for programming is not a push-button magic experience - it’s “difficult and unintuitive” and getting great results requires learning new patterns. Critical thinking remains key. Over a year of projects, I’ve converged on a workflow similar to what many experienced devs are discovering: treat the LLM as a powerful pair programmer that requires clear direction, context and oversight rather than autonomous judgment.

Start with a clear plan (specs before code)

https://addyo.substack.com/p/how-to-write-a-good-spec-for-ai-agents

Don’t just throw wishes at the LLM - begin by defining the problem and planning a solution.

One common mistake is diving straight into code generation with a vague prompt. In my workflow, and in many others’, the first step is brainstorming a detailed specification with the AI, then outlining a step-by-step plan, before writing any actual code. For a new project, I’ll describe the idea and ask the LLM to iteratively ask me questions until we’ve fleshed out requirements and edge cases. By the end, we compile this into a comprehensive spec.md - containing requirements, architecture decisions, data models, and even a testing strategy. This spec forms the foundation for development.

Next, I feed the spec into a reasoning-capable model and prompt it to generate a project plan: break the implementation into logical, bite-sized tasks or milestones. The AI essentially helps me do a mini “design doc” or project plan. I often iterate on this plan - editing and asking the AI to critique or refine it - until it’s coherent and complete. Only then do I proceed to coding. This upfront investment might feel slow, but it pays off enormously. As Les Orchard put it, it’s like doing a “waterfall in 15 minutes” - a rapid structured planning phase that makes the subsequent coding much smoother.v

Having a clear spec and plan means when we unleash the codegen, both the human and the LLM know exactly what we’re building and why. In short, planning first forces you and the AI onto the same page and prevents wasted cycles. It’s a step many people are tempted to skip, but experienced LLM developers now treat a robust spec/plan as the cornerstone of the workflow.

Scope management is everything - feed the LLM manageable tasks, not the whole codebase at once.

A crucial lesson I’ve learned is to avoid asking the AI for large, monolithic outputs. Instead, we break the project into iterative steps or tickets and tackle them one by one. LLMs do best when given focused prompts: implement one function, fix one bug, add one feature at a time. For example, after planning, I will prompt the codegen model: “Okay, let’s implement Step 1 from the plan”. We code that, test it, then move to Step 2, and so on. Each chunk is small enough that the AI can handle it within context and you can understand the code it produces.

This approach guards against the model going off the rails. If you ask for too much in one go, it’s likely to get confused or produce a “jumbled mess” that’s hard to untangle. Developers report that when they tried to have an LLM generate huge swaths of an app, they ended up with inconsistency and duplication - “like 10 devs worked on it without talking to each other,” one said. I’ve felt that pain; the fix is to stop, back up, and split the problem into smaller pieces. Each iteration, we carry forward the context of what’s been built and incrementally add to it. This also fits nicely with a test-driven development (TDD) approach - we can write or generate tests for each piece as we go (more on testing soon).

Several coding-agent tools now explicitly support this chunked workflow. For instance, I often generate a structured “prompt plan” file that contains a sequence of prompts for each task, so that tools like Cursor can execute them one by one. The key point is to avoid huge leaps. By iterating in small loops, we greatly reduce the chance of catastrophic errors and we can course-correct quickly. LLMs excel at quick, contained tasks - use that to your advantage.

Provide extensive context and guidance

LLMs are only as good as the context you provide - show them the relevant code, docs, and constraints.

When working on a codebase, I make sure to feed the AI all the information it needs to perform well. That includes the code it should modify or refer to, the project’s technical constraints, and any known pitfalls or preferred approaches. Modern tools help with this: for example, Anthropic’s Claude can import an entire GitHub repo into its context in “Projects” mode, and IDE assistants like Cursor or Copilot auto-include open files in the prompt. But I often go further - I will either use an MCP like Context7 or manually copy important pieces of the codebase or API docs into the conversation if I suspect the model doesn’t have them.

Expert LLM users emphasize this “context packing” step. For example, doing a “brain dump” of everything the model should know before coding, including: high-level goals and invariants, examples of good solutions, and warnings about approaches to avoid. If I’m asking an AI to implement a tricky solution, I might tell it which naive solutions are too slow, or provide a reference implementation from elsewhere. If I’m using a niche library or a brand-new API, I’ll paste in the official docs or README so the AI isn’t flying blind. All of this upfront context dramatically improves the quality of its output, because the model isn’t guessing - it has the facts and constraints in front of it.

There are now utilities to automate context packaging. I’ve experimented with tools like gitingest or repo2txt, which essentially “dump” the relevant parts of your codebase into a text file for the LLM to read. These can be a lifesaver when dealing with a large project - you generate an output.txt bundle of key source files and let the model ingest that. The principle is: don’t make the AI operate on partial information. If a bug fix requires understanding four different modules, show it those four modules. Yes, we must watch token limits, but current frontier models have pretty huge context windows (tens of thousands of tokens). Use them wisely. I often selectively include just the portions of code relevant to the task at hand, and explicitly tell the AI what not to focus on if something is out of scope (to save tokens).

I think Claude Skills have potential because they turn what used to be fragile repeated prompting into something durable and reusable by packaging instructions, scripts, and domain-specific expertise into modular capabilities that tools can automatically apply when a request matches the Skill. This means you get more reliable and context aware results than a generic prompt ever could and you move away from one off interactions toward workflows that encode repeatable procedures and team knowledge for tasks in a consistent way. A number of community-curated Skill Collections exist, but one of my favorite examples is the but one of my favorite examples is the frontend-design skill which can “end” the purple design aesthetic prevalent in LLM generated UIs. Until more tools support Skills officially, workarounds exist.

Finally, guide the AI with comments and rules inside the prompt. I might precede a code snippet with: “Here is the current implementation of X. We need to extend it to do Y, but be careful not to break Z.” These little hints go a long way. LLMs are literalists - they’ll follow instructions, so give them detailed, contextual instructions. By proactively providing context and guidance, we minimize hallucinations and off-base suggestions and get code that fits our project’s needs.

Choose the right model (and use multiple when needed)

Not all coding LLMs are equal - pick your tool with intention, and don’t be afraid to swap models mid-stream.

In 2025 we’ve been spoiled with a variety of capable code-focused LLMs. Part of my workflow is choosing the model or service best suited to each task. Sometimes it can be valuable to even try two or more LLMs in parallel to cross-check how they might approach the same problem differently.

Each model has its own “personality”. The key is: if one model gets stuck or gives mediocre outputs, try another. I’ve literally copied the same prompt from one chat into another service to see if it can handle it better. This “model musical chairs” can rescue you when you hit a model’s blind spot.

Also, make sure you’re using the best version available. If you can, use the newest “pro” tier models - because quality matters. And yes, it often means paying for access, but the productivity gains can justify it. Ultimately, pick the AI pair programmer whose “vibe” meshes with you. I know folks who prefer one model simply because they like how its responses feel. That’s valid - when you’re essentially in a constant dialogue with an AI, the UX and tone make a difference.

Personally I gravitate towards Gemini for a lot of coding work these days because the interaction feels more natural and it often understands my requests on the first try. But I will not hesitate to switch to another model if needed; sometimes a second opinion helps the solution emerge. In summary: use the best tool for the job, and remember you have an arsenal of AIs at your disposal.

Leverage AI coding across the lifecycle

Supercharge your workflow with coding-specific AI help across the SDLC.

On the command-line, new AI agents emerged. Claude Code, OpenAI’s Codex CLI and Google’s Gemini CLI are CLI tools where you can chat with them directly in your project directory - they can read files, run tests, and even multi-step fix issues. I’ve used Google’s Jules and GitHub’s Copilot Agent as well - these are asynchronous coding agents that actually clone your repo into a cloud VM and work on tasks in the background (writing tests, fixing bugs, then opening a PR for you). It’s a bit eerie to witness: you issue a command like “refactor the payment module for X” and a little while later you get a pull request with code changes and passing tests. We are truly living in the future. You can read more about this in conductors to orchestrators.

That said, these tools are not infallible, and you must understand their limits. They accelerate the mechanical parts of coding - generating boilerplate, applying repetitive changes, running tests automatically - but they still benefit greatly from your guidance. For instance, when I use an agent like Claude or Copilot to implement something, I often supply it with the plan or to-do list from earlier steps so it knows the exact sequence of tasks. If the agent supports it, I’ll load up my spec.md or plan.md in the context before telling it to execute. This keeps it on track.

We’re not at the stage of letting an AI agent code an entire feature unattended and expecting perfect results. Instead, I use these tools in a supervised way: I’ll let them generate and even run code, but I keep an eye on each step, ready to step in when something looks off. There are also orchestration tools like Conductor that let you run multiple agents in parallel on different tasks (essentially a way to scale up AI help) - some engineers are experimenting with running 3-4 agents at once on separate features. I’ve dabbled in this “massively parallel” approach; it’s surprisingly effective at getting a lot done quickly, but it’s also mentally taxing to monitor multiple AI threads! For most cases, I stick to one main agent at a time and maybe a secondary one for reviews (discussed below).

Just remember these are power tools - you still control the trigger and guide the outcome.

Keep a human in the loop - verify, test, and review everything

AI will happily produce plausible-looking code, but you are responsible for quality - always review and test thoroughly. One of my cardinal rules is never to blindly trust an LLM’s output. As Simon Willison aptly says, think of an LLM pair programmer as “over-confident and prone to mistakes”. It writes code with complete conviction - including bugs or nonsense - and won’t tell you something is wrong unless you catch it. So I treat every AI-generated snippet as if it came from a junior developer: I read through the code, run it, and test it as needed. You absolutely have to test what it writes - run those unit tests, or manually exercise the feature, to ensure it does what it claims. Read more about this in vibe coding is not an excuse for low-quality work.

In fact, I weave testing into the workflow itself. My earlier planning stage often includes generating a list of tests or a testing plan for each step. If I’m using a tool like Claude Code, I’ll instruct it to run the test suite after implementing a task, and have it debug failures if any occur. This kind of tight feedback loop (write code → run tests → fix) is something AI excels at as long as the tests exist. It’s no surprise that those who get the most out of coding agents tend to be those with strong testing practices. An agent like Claude can “fly” through a project with a good test suite as safety net. Without tests, the agent might blithely assume everything is fine (“sure, all good!”) when in reality it’s broken several things. So, invest in tests - it amplifies the AI’s usefulness and confidence in the result.

Even beyond automated tests, do code reviews - both manual and AI-assisted. I routinely pause and review the code that’s been generated so far, line by line. Sometimes I’ll spawn a second AI session (or a different model) and ask it to critique or review code produced by the first. For example, I might have Claude write the code and then ask Gemini, “Can you review this function for any errors or improvements?” This can catch subtle issues. The key is to not skip the review just because an AI wrote the code. If anything, AI-written code needs extra scrutiny, because it can sometimes be superficially convincing while hiding flaws that a human might not immediately notice.

I also use Chrome DevTools MCP, built with my last team, for my debugging and quality loop to bridge the gap between static code analysis and live browser execution. It “gives your agent eyes”. It lets me grant my AI tools direct access to see what the browser can, inspect the DOM, get rich performance traces, console logs or network traces. This integration eliminates the friction of manual context switching, allowing for automated UI testing directly through the LLM. It means bugs can be diagnosed and fixed with high precision based on actual runtime data.

The dire consequences of skipping human oversight have been documented. One developer who leaned heavily on AI generation for a rush project described the result as an inconsistent mess - duplicate logic, mismatched method names, no coherent architecture. He realized he’d been “building, building, building” without stepping back to really see what the AI had woven together. The fix was a painful refactor and a vow to never let things get that far out of hand again. I’ve taken that to heart. No matter how much AI I use, I remain the accountable engineer.

In practical terms, that means I only merge or ship code after I’ve understood it. If the AI generates something convoluted, I’ll ask it to add comments explaining it, or I’ll rewrite it in simpler terms. If something doesn’t feel right, I dig in - just as I would if a human colleague contributed code that raised red flags.

It’s all about mindset: the LLM is an assistant, not an autonomously reliable coder. I am the senior dev; the LLM is there to accelerate me, not replace my judgment. Maintaining this stance not only results in better code, it also protects your own growth as a developer. (I’ve heard some express concern that relying too much on AI might dull their skills - I think as long as you stay in the loop, actively reviewing and understanding everything, you’re still sharpening your instincts, just at a higher velocity.) In short: stay alert, test often, review always. It’s still your codebase at the end of the day.

Commit often and use version control as a safety net. Never commit code you can’t explain.

Frequent commits are your save points - they let you undo AI missteps and understand changes.

When working with an AI that can generate a lot of code quickly, it’s easy for things to veer off course. I mitigate this by adopting ultra-granular version control habits. I commit early and often, even more than I would in normal hand-coding. After each small task or each successful automated edit, I’ll make a git commit with a clear message. This way, if the AI’s next suggestion introduces a bug or a messy change, I have a recent checkpoint to revert to (or cherry-pick from) without losing hours of work. One practitioner likened it to treating commits as “save points in a game” - if an LLM session goes sideways, you can always roll back to the last stable commit. I’ve found that advice incredibly useful. It’s much less stressful to experiment with a bold AI refactor when you know you can undo it with a git reset if needed.

Proper version control also helps when collaborating with the AI. Since I can’t rely on the AI to remember everything it’s done (context window limitations, etc.), the git history becomes a valuable log. I often scan my recent commits to brief the AI (or myself) on what changed. In fact, LLMs themselves can leverage your commit history if you provide it - I’ve pasted git diffs or commit logs into the prompt so the AI knows what code is new or what the previous state was. Amusingly, LLMs are really good at parsing diffs and using tools like git bisect to find where a bug was introduced. They have infinite patience to traverse commit histories, which can augment your debugging. But this only works if you have a tidy commit history to begin with.

Another benefit: small commits with good messages essentially document the development process, which helps when doing code review (AI or human). If an AI agent made five changes in one go and something broke, having those changes in separate commits makes it easier to pinpoint which commit caused the issue. If everything is in one giant commit titled “AI changes”, good luck! So I discipline myself: finish task, run tests, commit. This also meshes well with the earlier tip about breaking work into small chunks - each chunk ends up as its own commit or PR.

Finally, don’t be afraid to use branches or worktrees to isolate AI experiments. One advanced workflow I’ve adopted (inspired by folks like Jesse Vincent) is to spin up a fresh git worktree for a new feature or sub-project. This lets me run multiple AI coding sessions in parallel on the same repo without them interfering, and I can later merge the changes. It’s a bit like having each AI task in its own sandbox branch. If one experiment fails, I throw away that worktree and nothing is lost in main. If it succeeds, I merge it in. This approach has been crucial when I’m, say, letting an AI implement Feature A while I (or another AI) work on Feature B simultaneously. Version control is what makes this coordination possible. In short: commit often, organize your work with branches, and embrace git as the control mechanism to keep AI-generated changes manageable and reversible.

Customize the AI’s behavior with rules and examples

Steer your AI assistant by providing style guides, examples, and even “rules files” - a little upfront tuning yields much better outputs.

One thing I learned is that you don’t have to accept the AI’s default style or approach - you can influence it heavily by giving it guidelines. For instance, I have a CLAUDE.md file that I update periodically, which contains process rules and preferences for Claude (Anthropic’s model) to follow (and similarly a GEMINI.md when using Gemini CLI). This includes things like “write code in our project’s style, follow our lint rules, don’t use certain functions, prefer functional style over OOP,” etc. When I start a session, I feed this file to Claude to align it with our conventions. It’s surprising how well this works to keep the model “on track” as Jesse Vincent noted - it reduces the tendency of the AI to go off-script or introduce patterns we don’t want.

Even without a fancy rules file, you can set the tone with custom instructions or system prompts. GitHub Copilot and Cursor both introduced features to let you configure the AI’s behavior globally for your project. I’ve taken advantage of that by writing a short paragraph about our coding style, e.g. “Use 4 spaces indent, avoid arrow functions in React, prefer descriptive variable names, code should pass ESLint.” With those instructions in place, the AI’s suggestions adhere much more closely to what a human teammate might write. Ben Congdon mentioned how shocked he was that few people use Copilot’s custom instructions, given how effective they are - he could guide the AI to output code matching his team’s idioms by providing some examples and preferences upfront. I echo that: take the time to teach the AI your expectations.

Another powerful technique is providing in-line examples of the output format or approach you want. If I want the AI to write a function in a very specific way, I might first show it a similar function already in the codebase: “Here’s how we implemented X, use a similar approach for Y.” If I want a certain commenting style, I might write a comment myself and ask the AI to continue in that style. Essentially, prime the model with the pattern to follow. LLMs are great at mimicry - show them one or two examples and they’ll continue in that vein.

The community has also come up with creative “rulesets” to tame LLM behavior. You might have heard of the “Big Daddy” rule or adding a “no hallucination/no deception” clause to prompts. These are basically tricks to remind the AI to be truthful and not overly fabricate code that doesn’t exist. For example, I sometimes prepend a prompt with: “If you are unsure about something or the codebase context is missing, ask for clarification rather than making up an answer.” This reduces hallucinations. Another rule I use is: “Always explain your reasoning briefly in comments when fixing a bug.” This way, when the AI generates a fix, it will also leave a comment like “// Fixed: Changed X to Y to prevent Z (as per spec).” That’s super useful for later review.

In summary, don’t treat the AI as a black box - tune it. By configuring system instructions, sharing project docs, or writing down explicit rules, you turn the AI into a more specialized developer on your team. It’s akin to onboarding a new hire: you’d give them the style guide and some starter tips, right? Do the same for your AI pair programmer. The return on investment is huge: you get outputs that need less tweaking and integrate more smoothly with your codebase.

Embrace testing and automation as force multipliers

Use your CI/CD, linters, and code review bots - AI will work best in an environment that catches mistakes automatically.

This is a corollary to staying in the loop and providing context: a well-oiled development pipeline enhances AI productivity. I ensure that any repository where I use heavy AI coding has a robust continuous integration setup. That means automated tests run on every commit or PR, code style checks (like ESLint, Prettier, etc.) are enforced, and ideally a staging deployment is available for any new branch. Why? Because I can let the AI trigger these and evaluate the results. For instance, if the AI opens a pull request via a tool like Jules or GitHub Copilot Agent, our CI will run tests and report failures. I can feed those failure logs back to the AI: “The integration tests failed with XYZ, let’s debug this.” It turns bug-fixing into a collaborative loop with quick feedback, which AIs handle quite well (they’ll suggest a fix, we run CI again, and iterate).

Automated code quality checks (linters, type checkers) also guide the AI. I actually include linter output in the prompt sometimes. If the AI writes code that doesn’t pass our linter, I’ll copy the linter errors into the chat and say “please address these issues.” The model then knows exactly what to do. It’s like having a strict teacher looking over the AI’s shoulder. In my experience, once the AI is aware of a tool’s output (like a failing test or a lint warning), it will try very hard to correct it - after all, it “wants” to produce the right answer. This ties back to providing context: give the AI the results of its actions in the environment (test failures, etc.) and it will learn from them.

AI coding agents themselves are increasingly incorporating automation hooks. Some agents will refuse to say a code task is “done” until all tests pass, which is exactly the diligence you want. Code review bots (AI or otherwise) act as another filter - I treat their feedback as additional prompts for improvement. For example, if CodeRabbit or another reviewer comments “This function is doing X which is not ideal” I will ask the AI, “Can you refactor based on this feedback?”

By combining AI with automation, you start to get a virtuous cycle. The AI writes code, the automated tools catch issues, the AI fixes them, and so forth, with you overseeing the high-level direction. It feels like having an extremely fast junior dev whose work is instantly checked by a tireless QA engineer. But remember, you set up that environment. If your project lacks tests or any automated checks, the AI’s work may slip through with subtle bugs or poor quality until much later.

So as we head into 2026, one of my goals is to bolster the quality gates around AI code contribution: more tests, more monitoring, perhaps even AI-on-AI code reviews. It might sound paradoxical (AIs reviewing AIs), but I’ve seen it catch things one model missed. Bottom line: an AI-friendly workflow is one with strong automation - use those tools to keep the AI honest.

Continuously learn and adapt (AI amplifies your skills)

Treat every AI coding session as a learning opportunity - the more you know, the more the AI can help you, creating a virtuous cycle.

One of the most exciting aspects of using LLMs in development is how much I have learned in the process. Rather than replacing my need to know things, AIs have actually exposed me to new languages, frameworks, and techniques I might not have tried on my own.

This pattern holds generally: if you come to the table with solid software engineering fundamentals, the AI will amplify your productivity multifold. If you lack that foundation, the AI might just amplify confusion. Seasoned devs have observed that LLMs “reward existing best practices” - things like writing clear specs, having good tests, doing code reviews, etc., all become even more powerful when an AI is involved. In my experience, the AI lets me operate at a higher level of abstraction (focusing on design, interface, architecture) while it churns out the boilerplate, but I need to have those high-level skills first. As Simon Willison notes, almost everything that makes someone a senior engineer (designing systems, managing complexity, knowing what to automate vs hand-code) is what now yields the best outcomes with AI. So using AIs has actually pushed me to up my engineering game - I’m more rigorous about planning and more conscious of architecture, because I’m effectively “managing” a very fast but somewhat naïve coder (the AI).

For those worried that using AI might degrade their abilities: I’d argue the opposite, if done right. By reviewing AI code, I’ve been exposed to new idioms and solutions. By debugging AI mistakes, I’ve deepened my understanding of the language and problem domain. I often ask the AI to explain its code or the rationale behind a fix - kind of like constantly interviewing a candidate about their code - and I pick up insights from its answers. I also use AI as a research assistant: if I’m not sure about a library or approach, I’ll ask it to enumerate options or compare trade-offs. It’s like having an encyclopedic mentor on call. All of this has made me a more knowledgeable programmer.

The big picture is that AI tools amplify your expertise. Going into 2026, I’m not afraid of them “taking my job” - I’m excited that they free me from drudgery and allow me to spend more time on creative and complex aspects of software engineering. But I’m also aware that for those without a solid base, AI can lead to Dunning-Kruger on steroids (it may seem like you built something great, until it falls apart). So my advice: continue honing your craft, and use the AI to accelerate that process. Be intentional about periodically coding without AI too, to keep your raw skills sharp. In the end, the developer + AI duo is far more powerful than either alone, and the developer half of that duo has to hold up their end.

Real-Case Workflows

https://blog.algomaster.io/p/using-ai-effectively-in-large-codebases

https://boristane.com/blog/how-i-use-claude-code/?utm_source=substack&utm_medium=email

Noted Things

Some Key Notes

• Use llms.txt pages: https://llmstxt.org/

• MCPs: https://mcpmarket.com/server, https://github.com/upstash/context7#installation, https://github.com/vercel/next-devtools-mcp, https://github.com/ChromeDevTools/chrome-devtools-mcp, https://docs.sentry.io/ai/mcp/, https://github.com/GLips/Figma-Context-MCP

• Claude prompting best practices: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices

• Open AI prompting best practices: https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api

• Vercel Skills: https://skills.sh/anthropics/skills/pptx, https://github.com/vercel-labs/agent-skills/blob/main/skills/react-best-practices/SKILL.md

• AI agent real UI component knowledge — best practices, layout patterns, and design-system conventions for 60+ interface components: https://github.com/carmahhawwari/ui-design-brain/tree/main

• If GitHub Copilot can't fix a bug after 3 tries, stop. You're making it worse.
  Here's what most devs do - they paste the error message back into the chat. Agent tries something. Doesn't work. Paste the new error. Agent tries again. Doesn't work. You're now 10 messages deep and your code is more broken than when you started.
  This happens because the context window is poisoned. The agent is so fixated on its previous failed attempts that it's basically guessing at this point.
  Here's what you do instead. When the agent gets stuck, don't give it another error message. Give it a job
  Say exactly this: "Add whatever logging we need to reproduce this bug."
  The agent knows your codebase. It'll drop console statements in exactly the right places - the ones it actually needs to understand what's happening.
  Not random logging. Strategic logging.
  The agent can't fix what it can't see. Give it visibility first, then ask for the fix. Works every single time.

References

https://craftbettersoftware.com/p/the-vibe-coding-stack-for-2026

https://blog.bytebytego.com/p/how-cursor-shipped-its-coding-agent

https://medium.com/vibe-coding/the-concept-every-ai-coder-learns-too-late-c63dd872f923

https://addyo.substack.com/p/how-to-write-a-good-spec-for-ai-agents

https://www.aihero.dev/a-complete-guide-to-agents-md#what-goes-where

https://substack.com/home/post/p-188588325?source=queue

https://awesomeneuron.substack.com/p/a-visual-guide-to-ai-agents

https://medium.com/data-science-collective/stop-prompting-start-designing-5-agentic-ai-patterns-that-actually-work-a59c4a409ebb

Programming Languages (JavaScript/TypeScript)

What is a closure in JavaScript, and how does it work?

As you know, JavaScript functions can be nested within each other, which creates a hierarchy of scope. Each function has its own local variables and is able to access the variables from the outer function. Closure is a powerful JavaScript feature that allows a function to access the outer scope even if the outer function is already finished executing. For example, you define a new createCounter() function. This function contains a variable called counter and returns a new function called calculateFunction that returns counter++. Even after the createCounter() function is finished executing, the calculateFunction is still able to access the counter variable. That’s how the JavaScript closure works.

function createCounter() {
  let count = 0;
  return function() {
    count++;
    return count;
  };
}
const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2

What is hoisting in JavaScript, and how does it work with const and let?

Hoisting is a feature that JavaScript will hoist the variables to the top of the global scope. For example, when you try to log a variable above the line where it was defined, then JavaScript will log undefined without throwing any errors. Most programmers only think that the hoisting feature only works with the var variable and doesn’t work with the const and let variables because they see JavaScript throw an error when they do that. But the truth is, you should notice the error JavaScript throws. When you try to log let, const variables before initialization, then the error message will be “Can not access before initialization, “ but when you try to log a variable that is not defined, then the error will be “Variable is not defined“. That means JavaScript knows the variable but doesn’t automatically initialize a value for that variable as it does with a var variable.

Modern Front-end Frameworks (React.js/Next.js)

Can you explain how the React Rendering Process works under the hood?

I already published a detailed explanation about this topic on my blog. In short, when a React Component is rendered, it goes through two main phases: the render phase and the commit phase. On the render phase, React will create a new virtual DOM by converting the React component to JSX and then to a React Element, and the final result is a new Virtual DOM. When we have a new Virtual DOM, React will start to compare the new one with the previous one by using React’s Reconciliation mechanism to figure out the list of changes that need to be updated to the actual DOM. Now React knows exactly the changes that need to be made, which is why we don’t need to update the full DOM when a state update happens. Next to the commit phase, React will start to commit to the DOM based on the list of changes we have in the render phase by calling the DOM API like (createElement, setAttribute, appendChild,…), and the useEffectLayout will run after that. When the commit to the DOM process is done, it is time for the browser to work by executing the calculate layout, paint, and composite, so I will not talk about it. When the browser’s work is done, it’s time for the micro queue of useEffect to run. That is how React works under the hood.

What is the difference between a controlled and an uncontrolled component?

A controlled component is a component that React will be in charge of managing the behavior of the component by using state.

On the other side, an uncontrolled component is a component that just lets the DOM manage its own states by using refs.

A controlled component is mostly used in the project because it allows more controls and predictable behaviours.

In opposite, if your component is just a file upload input, no need for validations, no need for dependencies, then an uncontrolled component is preferred.

Can you explain the difference between useEffect and useLayoutEffect?

The main difference between useEffect and useLayoutEffect is when those functions are called and their purpose. Those are all running in the commit phase, but the useLayoutEffect is run before the browser paints process, while the useEffect runs after the browser paints. Also, the useLayoutEffect runs the code in a synchronous way, while the useEffect runs the code in an asynchronous way. That’s why React recommends you should be careful when using useLayoutEffect because the code run inside the useLayoutEffect will block the rendering process. React recommends we should use useLayoutEffect when we need to handle an immediate task relevant to DOM measurement, calculating the element’s position to prevent flicker, and use useEffect when we need to handle side effect tasks.

Can you list down all the factors that make the component re-render?

Well, that is the interesting question, but it takes quite take time to answer. Firstly, I think we should understand that React’s re-render happens when React needs to update the UI with some new data. Necessary re-renders themself are not the problem, but too much unnecessary re-renders are the big problem for the performance. There are four reasons why a component would re-render itself: state changes, parents re-render, props change, context changes, and hook changes.

• When the state changes, the component would re-render itself

• When a parent component re-renders, then all of its children will also re-render. It always goes down the tree; the re-render of a child component doesn’t trigger the parent component's re-renders.

• When props change, they are mostly updated by the parent component. That means the parent component would have to re-render and trigger all of its component re-renders regardless of its props.

• When a value of the Context Provider changes, then all the components that use this context will re-render, even if that component doesn’t use the changed portion of the data directly.

• Everything that happens inside a hook belongs to the component that uses it. That means the same rules regarding State and Context apply here. And, we should notice that the hook can be chained; the same rules apply to all of them.

How many approaches do you know that we can use to prevent unnecessary re-rendering?

Wow, that is a big question. There are many ways we could use to prevent unnecessary re-rendering. Firstly, we should understand that unnecessary re-renders themself are not actually a big problem. React is fast and able to deal with them without users noticing anything. However, if it happens too often and on a heavy component, then that could cause the performance issue to end users.

• We should avoid creating a new component inside other components. On every re-render, React will re-mount the component (destroy it and recreate it from scratch), which is going to be much slower than the normal render.

• We should move the state down as close to the component that consumes it. For example, instead of putting open/close dialog state on the parent component, we should move it down to the dialog component, then every time the state changes, only the dialog component will be re-rendered, not affecting the parent component

• We should encapsulate the state changes into a smaller component by passing slow components as props. Because the props are not affected by the state changes, heavy components won’t re-render.

• We can prevent unnecessary re-renders by using React.memo, useMemo, useCallback

• We also need to implement the React key in the correct way if we don’t want our elements to be re-rendered every time.

• We can prevent re-renders caused by Context with those techniques, like memoizing context value, splitting data into chunks, and context selectors

Those are all the techniques that I can remember right now for preventing unnecessary re-renders in React.

Can you explain exactly the usage of useMemo and useCallback, and when we should avoid them?

Most of the Front-end engineers know about the usage of those memoized React hooks like useMemo and useCallback. The useMemo hook is used to memoize a value when that value requires a heavy calculation. The useCallback hook is used to memoize a function. But they don’t actually understand how these functions work under the hood and how to implement them correctly to prevent heavy components from re-rendering. I used to like them and blindly used those hooks without understanding. React only uses value to compare if the prop is a primitive value; if the prop is an object or a function, React will use reference to compare. That is why we need to memoize the function and the object prop type. For example, if I already memoized the heavy value and pass it as a prop to a child component, the child component still re-renders if we don’t wrap the child inside React.memo function. Also, if we want to put an object or a function into the dependency array of useEffect, we have to memoize them first if we don’t want useEffect to always re-run. And, we shouldn’t overuse these React memoized functions because the memoization is not free, it adds a few extra works like storing previous value, comparing the dependency array,… in every re-render. We should only use it when it is actually needed.

What are React keys used for, and what happens if we don’t use them correctly?

React’s key is the mechanism that allows React to control the rendering process by identifying which element of a list has changed and needs to be re-rendered. The React key needs to be both unique and static. The best practice is to use the id property in each item as a key, or we could use the index of the array as a key if that array can’t be modified (but we don’t recommend that way). If you don’t use the React key in the correct way, like using Math.random(), it will be a disaster for the performance of the website. You will destroy the most important DOM reconciliation mechanism of React and will make the whole array element re-render, causing some mysterious UI bugs that are really hard to trace.

How does React’s reconciliation process work?

Well, that is an interesting question that requires a deep understanding of how React works under the hood. React’s reconciliation process is a really important mechanism in React that allows React to compare the Virtual DOM to figure out specific changes that need to be made to the actual DOM. That technique made React re-render elements efficiently, only re-rendering the changed parts instead of re-rendering the whole DOM. React’s reconciliation algorithm is based on two simple assumptions:

• Two elements of different types will produce two different trees. For example, if an element changes from the span into the div, then React will assume that everything inside has changed and rebuild the entire subtree. And, if the element tag is not changed, then React will start comparing props and states. React does a shallow comparison so you have to use those memo techniques if you don’t want that element will be re-rendered

• The React key provides stability hints: React requires us to provide a key for each item element when we want to build a listing. By doing that, React will know exactly which item on that list has changed, been added, deleted, or no changes need to be made.

Tell me what you know about CSR?

Client-side rendering is the strategy where the server only sends the minimum HTML to the client, and the data fetching, templating, and routing required to display content for the page are handled by JavaScript that executes on the browser. Almost all of the UI is generated on the browser. The entire application is loaded on the first request. CSR enables the creation of a Single-Page application that supports navigation without page refreshes and provides a great user experience. As the user navigates to another page by clicking a link, there is no request to the server to generate a new page; the code runs on the client to change the view/data. While CSR provides a rich interactive experience after the initial load, it has the well-known drawback of negatively impacting first-page load performance and SEO, which means users must see a blank page before the large JavaScript bundle is fully downloaded and executed.

Tell me what you know about SSR?

SSR is one of the oldest methods of rendering web content, where the HTML is rendered on the server and sent to the client browser as a response. With SSR, every request is treated individually and will be processed as a new request to the server. It helps to reduce the JavaScript bundle size sent to the browser and improve the user experience by reducing the time for the page content to be visible. We still have to wait for the data to be fetched and pre-rendered on the server before sending it to the client, and also wait for the hydration process to be finished before the user can interact with the UI.

Tell me what you know about SSG?

SSG comes to resolve the weakness of SSR by moving the rendering HTML process from the runtime to the build time and serving the page as a static site. For example, when users request a page, that page is already generated at build time and is served as a static file by CDN or served from cache. That static file is immediately sent to the browser without waiting for data to be fetched, waiting for HTML to be prepared, and users can see the page instantly. SSG is ideal for the static content.

Tell me what you know about ISG?

As you know, SSG is only suitable for static content. It has limitations for applying to dynamic content or content that changes frequently. The Incremental Static Generation was introduced as an upgrade to SSG. It allows for refetching new content in the background at a period of time and automatically applies it to the old one without the need for a full rebuild. Once generated, the new version of the static file becomes available and will be served for any new requests in subsequent minutes.

What are Suspense and Streaming in React?

In the normal SSR implementation, the server will wait to generate all the HTML it is going to as a string and send it to the client as a big chunk. That made you have to wait for all the data for the entire page to prepare before you can see, hydrate, and interact with anything.

With streaming SSR implementation, the server will first create a Node.js stream. Then, it will use renderToPipeableStream to render the React app chunk by chunk into that Node stream. It lets React “flush whatever parts of HTML are ready and postpone slow parts for later“

The chunk boundaries for this process are those components that are wrapped by . Whenever you wrap a component with , that means you tell React not to wait for the data of this component, and start streaming HTML for the rest of the page, and show the fallback UI for that component instead.

What are Server Components?

The biggest issue with SSR is “no interactivity gap“. While SSR helps reduce the load time for the initial load but users need to wait and can’t interact with it until the hydration process is finished. RSCs were introduced at React 18 to allow you to render part of the UI on the server ahead of time without sending any JavaScript to the browser, dramatically shrinking client bundles. RSCs are rendered on the server and send a special data format called the React Server Component Payload to the browser. The client-side React runtime then uses the payload to hydrate HTML. The Container/Presentation pattern is a great candidate for RSCs, while the container component could be an RSC that fetches data and passes it as props to the presentational client component, meaning the fetching logics never ship to the browser.

Will React Server Components replace the SSR?

No. RSCs do not replace SSR. They complement it. In practice, we can still do SSR for the initial render, but many components can be RSC then significantly reduces the JavaScript needed to ship to the browser.

There are a few differences between SSR and RSCs:

• Code of the RSC is never sent to the browser, while on some implementations of SSR, their code is still included in the JavaScript bundle and sent to the browser.

• SRCs enable access to the back end everywhere on the tree. But on the SSR implementation, for example, in Next.js. We have to fetch all of the data via getServerSideProps, which has limitations of only working on the top of the page.

• SRCs may be refetched in the background while maintaining the client-side state of the tree. This is because the main transport mechanism is richer than just pain HTML that allows re-fetch on the server parts without blowing up the client state, such as search input text, focus.

How does React insert real data into a streaming component?

For the first render, React will send the fallback UI, like the loading skeleton, immediately to the user and attach an ID to that element while waiting for the actual data to be loaded and streamed. Once it’s ready, React includes it in the ongoing HTML stream, along with the lightweight JavaScript that handles the magic: replace the new actual data with the old placeholder based on the ID we attached before. This makes this transition feel smooth and effortless to the user due to no full rerenders, no flicker, just progressive enhancements. It’s a part of the internal React streaming process, not something that we can handle manually. But understanding it helps connect the dots between the fallback we see on the screen and seamlessly be replaced by the real content.

What are the hydration, Progressive hydration, and Selective Hydration? How does the selective hydarion solve the pain points of traditional hydaration?

In the traditional SSR rendering before React 18, when the user first sees the page, the user can’t interact with the page, such as clicking on a button, or see any animations. The user needs to wait for the JS bundle of the whole page to be loaded and executed before they can become responsive to interaction. The hydration is the process that the browser attaches event handlers and everything to the DOM, which makes the page become interactive. This process takes a while, so users have to wait.

Progressive hydration is a new approach that was released in React 18 for resolving the pain point of traditional hydration. Instead of hydrating the entire page at once, we can also progressively hydrate the DOM nodes. Progressive hydration makes it possible to individually hydrate nodes over time, which makes it possible to only request the minimum necessary JavaScript. It delays hydration of the less important parts of the page, like those parts that aren’t visible in the first viewport. On the downside, progressive hydration may not be suitable for a dynamic app where every element on the screen is available to the user and needs to be made interactive on load.

The selective hydration is a new hydration mechanism that was introduced in React 18, along with a progressive hydration approach. Besides trying to hydrate as soon as possible based on the DOM tree, it prioritizes what matters most to the user — the parts they touch. This creates an illusion of instant hydration because interactive components are hydrated first, even if they are deeper in the component tree. For example, both the blog component and header component could stream on the server independently. By default, React starts with the first Suspense boundary it encounters in the tree — it’s header component in this case. But, imagine users click on the blog section before it is hydrated. Instead of waiting for the header component to finish, React intercepts the event during the capture phase and synchronously hydrates the blog section first, so the interaction works immediately.

How do you structure a large-scale React application for scalability and maintainability?

That is a big question that takes a lot of time to fully answer. There are a few important points that I constantly follow up on when I am setting up a large-scale React application:

• Firstly, I organize files not just by technical roles, but also by domain responsibilities. Organizing files based on technical roles might be fast at the start. But when the application grows, updating things like cart features, we need to go through multiple folders, such as components/, stores/, and utils/. This separation slows you down and creates mental overhead. On the other hand, when grouping components by domain responsibilities, everything related to the feature lives in one folder. Features become self-contained, refactoring becomes safer, and your team grows; each squad might handle different domains without tight coupling and conflicts with each other. This clear boundary makes parallel development much easier. Teams can refactor their own features without worrying about breaking others.

• I always prefer to create a dedicated common module for all generic components and utilities used across different pages and modules. This helps avoid redundancy and promotes reusability across the application.

• For each module, I apply the Locality of Behaviour principle by keeping things as close to where they are used. For example, I locate child components, hooks, and utils near where they are used within the application. This strategy improves readability and maintainability as when a developer works on a feature, they have all the related files in proximity, which makes it easier to understand and maintain.

• I also apply Layered Architecture with the Separation of Concerns Principle (refer to the next questions for better explanation)

• Furthermore, I also apply the Atomic Design Pattern for managing the growing complexity of component structures (refer to the next question)

Can you tell me more about the Layered Architecture with Separation of Concerns?

When we design a Front-end application, it is better to split the application into multiple layers for easier management and to avoid causing bugs in unrelated parts. Most scalable Front-end systems can be thought of as layers, each with a purpose. Each layer has its own responsibilities and knows only as much as it needs. This separation creates clarity, reduces bugs, and increases developer speed. Commonly, we could split an application into 5 layers: UI Layer, Behavior Layer, State Management Layer, Services Layer, and Utilities/Core Logic Layer.

• The UI Layer should be predictable and reusable. No useEffect, no useState, just props in and UI out. It knows nothing about where data comes from, just receives props and renders markup.

• The Behavior Layer is where the logic lives. It lives in a custom hook and is responsible for local states, effects, and interaction logics. We can plug the same behavior for different UIs without duplicating a line of logic.

• The State Management Layer is where we centralize shared states. When our app grows, we need a place to manage our shared state to be shared across components. We can use React Context for small apps and other popular libraries, such as Redux and Zustand, for large apps

• The Service Layer is where we are talking with the outside world. This layer is our interface with APIs, storage, and anything that lives outside of the app.

• The Utilities/Core Logic Layer is where shared helpers, validation functions, formatters, and pure logic reside.

What is the Atomic Design Pattern?

When we build scalable applications in React, we often encounter challenges in managing the growing complexity of component structures. The Atomic Design Pattern has emerged as a powerful methodology for organizing and structuring applications. This pattern suggests breaking down the interface into multiple fundamental building blocks, promoting a more modular and scalable approach to application design.

The Atomic Design Methodology breaks down design into 5 distinct levels:

• Atoms: These are basic building blocks of an application, such as inputs, buttons, etc.

• Molecules: Molecules are groups of atoms that are combined together to form a functional unit, such as a search feature that includes a label, an input, and a submit button.

• Organisms: Organisms are relatively complex UI components composed of groups of molecules and atoms, such as a header of a page.

• Templates: Templates are page-level objects that place components into a layout. They usually consist of groups of organisms, representing a complete layout.

• Pages: Pages are specific instances of templates that show what a UI looks like with real data.

The Atomic Design Pattern aligns perfectly with React’s component-based architecture and brings a lot of benefits, such as promoting reusability, ensuring consistency, etc. While it provides many benefits, we should be cautious not to over-engineer and introduce unnecessary complexity.

How many React patterns do you know?

Well. There are several popular React patterns that we can apply in our React code to make it more optimized, readable, and maintainable, such as the Higher Order Pattern, Render Props Pattern, Container/Presentation Pattern, Hooks Pattern, and Compound Pattern.

• A HOC is a component that receives another component. The HOC contains a certain logic that we want to apply to the other component by passing that component as a parameter. This pattern allows us to share the same logic throughout multiple components. For example, when we want to apply a custom loading logic called useLoading to multiple components, we can apply HOC.

• Another way of making components more reusable is by applying the Render Props Pattern. A Render Prop is a prop on a component whose value is a function that returns JSX. The component itself does not render anything, but calls the render prop.

• In React, one way to enforce separation of concerns is by using the Container/Presentation Pattern. With this pattern, we can separate the view from the logic. For example, when we want to create a component to display a list of products, container components are responsible for fetching the data, formatting it, and passing the data as props to the presentational components to show.

• Hooks were the new feature that was released on React 16.8. Although Hooks are not necessarily a design pattern but they play a very vital role in React applications. The traditional ways to share code across multiple components are by using HOC and the Render Props Pattern. Although both patterns are still valid and good practice but Hooks mostly replaced them.

• The Compound pattern is really useful when we have to deal with multiple components that belong to each other through a shared state. The Compound Component Pattern allows you to create a component that all work together to perform a task. For example, when we want to create a custom complex select component that contains multiple select items and other sub-components.

How can you structure state management architecture for a large-scale application?

Not all states are the same, so instead of treating it as one thing, we should clarify it into layers, with its own natural place in the application.

• The local state should stay local, and we should keep it as close as possible to where it is used. For example, a simple open/close state of a modal should be local and not belong to Redux or Context. Components died, local states died

• Server States are anything that originates from the external sources, like API responses, data from the backend. It usually comes with its own complexities (state data, retries, invalidation), so it should be treated as a dedicated layer. That is exactly why tools like React Query, Apollo, or SWR exist. They handle caching, refetching, and synchronization for us, allowing client state to remain cleanly separate from server data.

• Everything that is happening in the website’s URL is a state in a way, then we can treat it as a separate layer. For example, we can pass some queries or parameters to reflect the UI. When the URL changes, then the UI changes. These days, some of the routers also provide built-in methods like useSearchParams for you to easily manage the URL states, or you can use a popular library like nuts instead

• Not all states can stay isolated. Sometimes, data has to move beyond a single component. That’s where the shared state layer comes in. But the shared client state needs boundaries. And we should follow the simple principle that “The State should rise only as high as its consumers require“. If it is just shared between siblings, prop drilling, then a small Context is perfectly fine. If it cuts across multiple features or pages, then it earns its place in a dedicated store like Redux, Zustand.

By drawing these lines, the decision of how to manage a state becomes clearer.

Can you explain what React Context is and how it works?

As we know, when a React app grows then the amount of state grows. Additionally, React uses one-way data flow, which means data can only go down the component tree, making passing state between components at the same level a really hard task. If we don’t manage it properly in time, it could lead to uncontrolled data flow, causing props drilling issues, and making it harder to debug. React Context is a built-in mechanism that creates a kind of “global store“ for specific parts of the application. React Context allows us to pass data through the component tree without manually passing props through immediate components. However, while Context is a great choice for providing access to data, it has some limitations, such as Context does not provide a standardized way to modify states, and it becomes harder to track where state changes occur because we have multiple contexts that wrap different parts of the project.

Can you list a few ways to optimize React Context?

We all know React Context allows us to pass the props from a component to other deep components in the React tree without passing props through multiple components. Passing data in this way can improve the performance of our React app by avoiding the re-rendering of components in between. However, it could be dangerous if we don’t manage it properly because all components that consume state from the Context Provider will be re-rendered if a state in the Provider gets updated. Even if components do not consume the changed parts, there are no standard memorization techniques that can prevent it. Below are some techniques that we can use to optimize the usage of React Context:

• To minimize the React Context re-renders, we should always memoize the value we pass to the Context Provider.

• We can split from one provider to multiple providers to further minimize re-renders. Switching from useState to useReducer can help with this.

• Even though we don’t have the proper selectors for Context like Redux, we can use the trick by combining the Higher-Order Function and React.memo.

What is Redux, and how does it work?

Redux is a state management library that implements ideas inspired by the Flux architecture. It ensures a one-way data flow that makes the application state flow more predictable and easier to track.

Redux introduces a more structured approach with clearly defined elements:

A Store element holds the entire application state in a single object and manages dispatching actions. The logic for how state changes is defined in reducers, not in the store itself.

Action elements are plain JavaScript objects that describe what happened in the application.

Dispatch is a function that sends actions to the store and starts the update process.

Reducer elements are pure functions that take the previous state and an action and return the next state.

Selector elements are functions that read or derive specific pieces of data from the Redux state.

And the standard Redux flow is:

The user interacts with the view, then creates an action by clicking on a button → The action is dispatched to send the action to the store → The store receives the action and passes it to the reducers → The reducer receives the action and previous state and returns a new state → The store replaces the old state with the new state returned by the reducers → Components use selectors to read the updated state and re-render.

What are the differences between React Context and Redux?

Well. React Context is a built-in feature of React, while Redux is an external library inspired by the Flux architecture. They are both developed by the React team and provide abilities for managing global state across the application. React Context is more suitable for a small app, or when we just need to share the state across multiple components in the hierarchy. On the other hand, Redux is a preferred choice for managing state in a large application where we need to share the state across multiple features or pages. Additionally, React Context is only good for providing access to data and does not provide a standardized way to modify states. Also, it becomes harder to track where state changes occur since we have multiple Contexts that wrap different parts of the project. In contrast, Redux introduces a more structured approach with defined elements such as (Store, Reducer, Dispatchers, Actions,….) and ensures one-way data flow that makes the state flow of the application more predictable and easier to track.

Can you explain the approach for managing complex global state?

For managing a complex global state, where using React Context is not enough, I will look into state management libraries, such as Redux, Zustand, Jotai, and MobX. Honestly, I haven’t joined any business projects that applied those libraries before. I used to apply Redux and MobX to my pet project for learning a few years ago. I worked with the React Context mostly because it is enough. I do know the Flux architecture and the core data flow of Redux. There is a pattern that I have read somewhere that: “A State should rise only as high as its consumers require“. We should keep the boundaries clear and avoid both over-engineering and unnecessary sprawl.

What is useEffect? How do you use it in the project?

As its core, useEffect is a powerful hook that runs after the browser’s paint process. This hook allows us to perform side-effect tasks that go beyond the pure render logic, such as API calls and DOM mutations. Because it’s about keeping React components in sync with something outside of React, so if we are using useEffect to synchronize one piece of React state to another piece, we are doing it wrong. We should treat useEffect as the last option instead of the first option.

What do you care about data fetching on the client?

Nowadays, instead of writing a lot of code for fetching data over the network, to cover various aspects such as error handling, caching, and canceling requests. We have several libraries that will handle almost everything for us, like axios, swr, and tanstack query. But I do believe that the choice of technology doesn’t matter much here, and no library can improve the performance of the app by itself. I do focus on the fundamentals of data fetching and data orchestration patterns and techniques. I am aware of the browser limitations of parallel requests, prefetching critical resources even before React is initialized, and techniques for handling waterfalls and race conditions issues.

What is the React Server Action?

React Server Action is a way to write server-side code, the stuff usually handled by API Routes, that can now be written inside the React Component. In Next.js, we just need to add the directive “use server“at the top of the file to tell Next.js that this function should only be called on the server. The React Server doesn’t mean to replace the API Routes entirely; it’s a game-changer for tasks deeply tied to the UIs.

How does Next.js Server Actions work under the hood?

Firstly, to mark a function as a Next.js Server Action, we only need to put a “use server“ directly at the top of the file. By doing so, it will tell Next.js that every exported function in that file is a Next Server Action. When we call Server Actions on Client-side components, it is not just a regular function call. Next.js does some magic behind the scenes; it’s like an RPC(Remote Procedure Call) process. The flow will be: the client code calls the Server Action function => Next.js serializes arguments, converting them into a format that can be sent over the network => the POST request is fired off to the special Next.js endpoint => The server receives the request, deserializes arguments, and executes the code => When the process on the server is finished, the server then serializes the returned value and send it back to the client => The client receives the responses, deserializes it and automatically re-renders the relevant parts of the UI. The best part is no more manually refetching the data or updating the state after mutation. Next.js will automatically re-render the parts that need to be changed because of it.

Can you list all the benefits of the Server Action?

As we know, managing the communication between the client and the server is the real pain. Server Action comes to resolve that real pain by letting us put the server-side code right into the components. That makes things simpler, no more APi routes, no more re-fetching after mutation. React Server also boosts the performance by reducing those back-and-forth trips between the client and the server. Security is also another win when we put sensitive information like database queries and keys on the server.

Can you list all the downsides of using the Server Action?

While Server Actions bring a lot of benefits, it also has some downsides like any other technology. Below are some of them:

• One of the biggest issues is the potential for tight-coupling. By allowing the server logic to live right inside the component, it is easy to end up less modular and harder to maintain codebase. Changing the server logic might force the front-end to be updated.

• The second one is a learning curve. While understanding the basic Server Action is simple, learning advanced things like serialization, caching, and error handling takes time.

• The third issue is debugging. When something goes wrong with Server Action, we cannot just rely on the network tab of the Chrome Dev Tool. We need to get comfortable with debugging techniques on the server-side.

• The last issue is about performance if we overuse React Actions. Each Server Action is a network request; if there are too many network requests, that could make things worse.

Server Action is a powerful tool, but like other tools, it can be misused. It is best for data mutations and operations where the server logic tight couple with the UI and needs to be lived on the server.

When should we use Server Actions?

The Server Actions align perfectly with tasks like Performing Data Mutations. It allows performing server operations and database mutations without exposing the credentials and sensitive information to the client. It also dramatically reduces and simplifies the code by removing the need to write API routes for your operations.

What are the potential pitfalls with Server Actions?

While Server Actions bring us a lot of benefits, if we use them everywhere without understanding how it works, it could hurt our application’s performance. I could list some of the mistakes when we use Server Actions in the wrong way:

• For client-side fetching, Server Actions might not be the best option. They automatically use the POST requests, so the data can’t be cached like with the GET requests. Furthermore, Server Actions shouldn’t be used with the Server Components. Because using Server Actions here would delay the data availability, as it causes extra network requests.

• Even though Server Actions handle server-side logic, under the hood, they are just another API route, and Next.js handles the POST requests automatically. Because of that, Server Actions do not hide the requests, and anyone can replicate them by using the Rest Client. That is why we should use proper authentication and authorization checks when working with sensitive data.

• Using Server Action might be convenient, but every action comes at a cost. We should avoid using them everywhere and consider before using them. For tasks that could be easily handled on the client side, keep them on the client side.

• When we need our API to be accessible to multiple clients, classic API routes might be a more appropriate solution. Imagine if we need the same logic for both web app and mobile app, duplicating the same Server Action logic will duplicate the work and make it complicated for maintenance.

Can you list some common mistakes when applying Server Actions?

Server Actions help to simplify our code, reduce the code boilerplate, and look like the future of data mutations in Next.js. But if we don’t use it in the right way, it would cause a serious problem with our application’s performance.

• The most common mistake is not using the useTransition hook for the pending state. The user clicks on a submit button again and again, the Server Action is running, but the UI provides zero feedback. We need to wrap our action inside the useTransition to make the interface interactive and avoid users spamming the Submit button

• The second mistake is that we are skipping validation on the client side. For example, it it so waste of resources if we trigger a Server Action and make the full network round trip to tell the user that they are missing a required field. It’s better to validate the input before passing it to Server Action.

• The third mistake is that we are missing adding validateTag or validatePath after calling the Server Action. This mistake is not slowing the performance, but it will make the user still see the stale data after executing the data mutations. By adding those functions, it will tell Next.js to refetch the data that was changed, and the user can see the new data.

• The fourth mistake is that we are importing the large client-side library into a server actions file. Server Actions are server-side code; they run in a Node.js environment. If we import a massive client-side library, we will get errors. And the solution is that we should choose the server-side compatible library.

What is a Route Group in Next.js, and what is it used for?

A Route Group is a folder wrapped in parentheses (e.g., (marketing)) in the App Router. The parentheses signal to Next.js to exclude that segment from the URL path, so the folder exists purely in the file system. This lets you organize routes and share layouts without polluting the URL structure — for example, (marketing)/about/page.tsx still resolves to /about, not /marketing/about.

What are the main use cases?

1. Shared layouts without URL pollution — wrap related routes in a group with a common layout.tsx. For example, (auth) routes share a minimal layout with no nav, while (app) routes share a full shell with sidebar and header — all without those group names appearing in the URL.

2. Code organization — group routes by feature, team, or domain (e.g., (shop), (blog), (admin)) purely for developer clarity. This is especially valuable in large codebases where a flat app directory becomes hard to navigate.

3. Multiple root layouts — each group can define its own root layout.tsx, giving entirely different page shells to different sections of the app. This avoids messy conditional rendering inside a single root layout.

What is unstable_cache in Next.js?

unstable_cache is a Next.js utility that lets you cache the result of any async function — not just fetch calls. It wraps a function and stores its return value in the Next.js Data Cache, with support for cache tags, revalidation intervals, and on-demand invalidation via revalidateTag. The unstable_ prefix signals it's a stable-enough API but still subject to change before a finalized name is given.

import { unstable_cache } from 'next/cache';

const getCachedUser = unstable_cache(
  async (id: string) => db.user.findUnique({ where: { id } }),
  ['user'],          // cache key parts
  { revalidate: 60, tags: ['users'] }
);

Why is it necessary for non-fetch data sources?

Next.js automatically caches and deduplicates fetch requests in Server Components. However, database queries, ORM calls, third-party SDKs, filesystem reads, or any non-HTTP data access bypass that cache entirely — they re-execute on every request by default. unstable_cache fills that gap by bringing those data sources under the same caching model as fetch, giving you equivalent control over revalidation without changing your data-fetching layer.

Where should context providers be placed in the App Router, and why can't they go directly in a Server Component?

Context providers rely on createContext and React's runtime context API, which are client-only features. Server Components cannot render providers directly because they don't participate in the React component tree at runtime on the client. Placing a provider in a Server Component will throw an error. Instead, you must extract the provider into a dedicated 'use client' wrapper component, then use that wrapper inside your layout.

// app/providers.tsx
'use client';
import { ThemeProvider } from './ThemeContext';

export function Providers({ children }: { children: React.ReactNode }) {
  return <ThemeProvider>{children}</ThemeProvider>;
}

Where exactly in the App Router tree should the Providers wrapper be placed?

It belongs in the root layout.tsx (or the closest layout that covers all routes needing that context), wrapping {children}. This keeps the provider as high as needed but no higher — following the principle of placing context at the lowest common ancestor.

// app/layout.tsx  (Server Component)
import { Providers } from './providers';

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <Providers>{children}</Providers>
      </body>
    </html>
  );
}

What is revalidatePath and how does it differ from revalidateTag?

revalidatePath purges the cache for a specific URL path, causing that page to be re-rendered on the next request. revalidateTag purges all cached data entries carrying a specific tag, regardless of which pages consume them. The core difference is: revalidatePath thinks in terms of pages, revalidateTag thinks in terms of data.

revalidatePath('/blog/my-post');   // purges the /blog/my-post page cache
revalidateTag('contentful-post-123'); // purges the data tagged across any page that uses it

When should you use revalidateTag over revalidatePath?

Prefer revalidateTag when the same data appears on multiple pages — a product price shown on a listing page, a detail page, and a related items widget all need to update together. Using revalidatePath would require knowing and calling every affected URL manually, which is brittle and doesn't scale. revalidateTag lets you invalidate the data once and every page consuming it gets fresh content on next request.

Use revalidatePath when the invalidation is inherently page-scoped — e.g., a user submits a form that only affects one specific page's output, or you want to force a layout re-render that isn't tied to a tagged fetch. It's simpler and more explicit when the data-to-page relationship is 1:1.

What is revalidateTag and what problem does it solve?

revalidateTag is a Next.js server-side function that purges all cached data associated with a specific tag on demand. Without it, cached data only refreshes on a time-based interval (revalidate: 60). That model is too blunt for real-world apps — if a user updates their profile, you want that data fresh immediately, not after 60 seconds. revalidateTag lets you invalidate precisely the right cache entries the moment the underlying data changes.

// app/actions/updateUser.ts
'use server';
import { revalidateTag } from 'next/cache';

export async function updateUser(id: string, data: UserData) {
  await db.user.update({ where: { id }, data });
  revalidateTag('users'); // purges all cache entries tagged 'users'
}

How does it work end-to-end with fetch and unstable_cache?

Tags are assigned at the data-fetching layer and consumed by revalidateTag at the mutation layer:

• With fetch: pass { next: { tags: ['users'] } } in the options.

• With unstable_cache: pass { tags: ['users'] } in the config object.

When revalidateTag('users') is called — inside a Server Action, Route Handler, or middleware — Next.js marks every cached entry carrying that tag as stale. The next request for that data triggers a fresh fetch and re-populates the cache.

Why did the Page Router cause 30-minute rebuilds for small Contentful changes?

In the Page Router with static rendering (getStaticProps), pages are pre-built at deploy time into static HTML. Any content change in Contentful required a full next build to regenerate every static page — even if only one blog post title changed. While Page Router did offer ISR (revalidate: N), it was time-based and page-scoped, meaning you still had to wait for the interval to expire or trigger a manual redeploy. There was no efficient way to say "only rebuild the pages affected by this specific content change."

How does the App Router with revalidateTag solve this?

With the App Router, pages are Server Components that fetch and cache data at runtime — not at build time. You tag your Contentful fetches with meaningful identifiers, then configure Contentful webhooks to call a Route Handler that fires revalidateTag the moment a content entry is published:

// app/api/revalidate/route.ts
import { revalidateTag } from 'next/cache';
import { NextRequest } from 'next/server';

export async function POST(req: NextRequest) {
  const { contentType, entryId } = await req.json();
  revalidateTag(`contentful-\({contentType}-\){entryId}`);
  return Response.json({ revalidated: true });
}

// Contentful fetch tagged at the data layer
const post = await fetch(https://cdn.contentful.com/..., { next: { tags: [contentful-blogPost-${entryId}] } });

Now when a Contentful editor publishes a change, the webhook fires instantly, revalidateTag purges only that entry's cache, and the next visitor gets fresh content within milliseconds — no rebuild, no waiting, no CI pipeline involved.

What happens internally the moment revalidateTag is called?

When revalidateTag('users') is called, Next.js does not immediately delete or refetch the cached data. Instead, it writes a staleness marker against all cache entries carrying that tag in the Next.js Data Cache (an in-memory + persistent cache layer managed by the Next.js server runtime). The cached data is still physically there — it's just flagged as stale. No network requests are made, no pages are re-rendered at this point. It's a near-instant, low-cost operation.

What happens on the next incoming request after the tag is invalidated?

When a request comes in for a page that depends on the invalidated tag, Next.js detects the stale marker during rendering and re-executes the original data-fetching function (the fetch or unstable_cache wrapped function) to get fresh data. The result is stored back into the Data Cache with a new freshness timestamp, replacing the stale entry. The page is then re-rendered with the fresh data and the new HTML is served — and optionally written to the Full Route Cache if the route is statically cacheable. Subsequent requests hit the warm cache again until the next invalidation.

How did static pages work in the Page Router, and what changes in the App Router?

In the Page Router, static pages were explicitly opted into with getStaticProps — Next.js pre-rendered them to HTML at build time and served them as flat files. In the App Router, every Server Component is statically rendered by default — there is no getStaticProps. If a route has no dynamic behavior (no cookies, headers, search params, or uncached data fetches), Next.js automatically pre-renders it to static HTML at build time without any configuration. The mental model shifts from "opt in to static" to "static unless you introduce something dynamic."

What determines whether an App Router page stays static or becomes dynamic after migration?

Next.js inspects the route at build time and checks for dynamic signals:

If none of these are present and all fetches are cached, the route is statically rendered and written to the Full Route Cache as HTML. After migrating from Page Router, pages that previously used getStaticProps with no user-specific data will automatically become static in the App Router — often with zero extra configuration needed.

What is the key behavioral difference to watch for post-migration?

In the Page Router, getStaticProps pages were rebuilt only on redeploy or ISR interval. In the App Router, static pages cached in the Full Route Cache can be invalidated at runtime via revalidateTag or revalidatePath — without a redeploy. This means post-migration your static pages are no longer tied to the build pipeline, which is a significant operational improvement but also means you need to be intentional about cache invalidation strategy. A page that was "always fresh on deploy" now needs explicit revalidation logic if its data changes between deploys.

Does the App Router with Server Components replace SSG?

Functionally, yes — but the underlying mechanism is different. In the Page Router, SSG was an explicit pattern you opted into with getStaticProps + getStaticPaths. In the App Router, static generation is the default behavior: if a Server Component route has no dynamic signals, Next.js automatically pre-renders it to static HTML at build time and caches it in the Full Route Cache. You get the same end result — pre-built HTML served at the edge — without writing any SSG-specific APIs. The concept of SSG didn't disappear; it was absorbed into the default rendering model.

What does the App Router give you that SSG couldn't?

SSG was an all-or-nothing commitment at the page level — the entire page was either static or dynamic. The App Router introduces per-component granularity. A single page can have a statically rendered Server Component shell (cached) wrapping a dynamically rendered section using <Suspense>, with client-interactive islands via 'use client'. This means you can statically cache the expensive parts (navigation, product listings) while keeping user-specific parts (cart count, personalized recommendations) dynamic — something SSG fundamentally couldn't express without client-side hydration workarounds.

When would you still think in "SSG terms" in the App Router?

When dealing with dynamic route segments at scale — e.g., /blog/[slug] with thousands of posts. App Router still supports generateStaticParams (the successor to getStaticPaths) to pre-render known paths at build time. Without it, those pages render on first request and get cached afterward, meaning the very first visitor to a new URL pays the render cost. For high-traffic or SEO-critical pages, pre-generating them at build time via generateStaticParams is still the right call — so SSG as a strategy remains relevant even if SSG as an API is gone.

Do Client Components appear in the initial HTML on first load in the App Router?

Yes — and this is a common misconception. Despite being called "Client Components," they are still server-rendered to HTML on the first request. Next.js renders the entire component tree (both Server and Client Components) to HTML on the server for the initial page load, so the user sees meaningful content immediately without waiting for JavaScript. The 'use client' directive doesn't mean "skip server rendering" — it means "this component needs to be hydrated and made interactive on the client after the HTML arrives."

What is the difference then between Server and Client Components in terms of the initial HTML?

Both appear in the initial HTML, but what happens after that HTML lands in the browser is different:

• Server Components — rendered to HTML on the server, never hydrated. No JavaScript is sent to the client for them. They are inert HTML.

• Client Components — rendered to HTML on the server (for the initial load), then their JavaScript bundle is sent to the browser and React hydrates them — attaching event listeners and restoring interactive state.

The practical implication is that both contribute to First Contentful Paint, but only Client Components add to the JavaScript bundle size and hydration cost.

What is the senior-level insight about hydration and the "use client" boundary?

The 'use client' boundary defines where the React component tree splits — everything below that boundary in the import tree is bundled and sent to the client for hydration. This is why keeping the boundary as deep and narrow as possible matters: a 'use client' on a large layout component pulls its entire subtree into the client bundle, increasing JS payload and hydration time. The optimal pattern is to push interactivity to small leaf components (a button, a dropdown) while keeping data-heavy parent components as Server Components — maximizing static HTML and minimizing what React needs to hydrate.

Web Performance

What is “Critical Rendering Path“?

As we know, the browser needs to know exactly the minimum resources required to download before rendering to avoid presenting an obviously broken experience. On the other hand, the browser can’t let the user wait for too long to download unnecessary resources for presenting some of the content to the user. The sequence of processes that the browser takes before rendering content on the first render is called the “critical rendering path“. Since the browser can’t complete the initial rendering without those critical resources, it is known as “rendering blocking resources“. The browser absolutely needs at least three types of resources:

• The initial HTML that is received from the server to construct the actual DOM

• The important CSS files are used to style the initial HTML. Otherwise, if the browser keeps proceeding without waiting for them, the user will see the weird “flash“ of unstyled elements.

• The critical JavaScript files are used to construct the layout synchronously.

Can you tell me the overall process of rendering the“Critical Rendering Paths“?

The Critical Rendering Path includes the Document Object Model (DOM), the CSS Object Model (CSSOM), the render tree, and layout.

A request for a web page or application starts with an HTTP request, and the server sends back an HTML response. The browser then begins parsing the HTML and converts the received bytes into the DOM tree. While parsing the HTML, the browser discovers external resources such as stylesheets, scripts, and images, and starts downloading them in parallel.

The browser continues parsing the HTML and building the DOM until it reaches the end of the document. At the same time, CSS files are parsed to build the CSSOM. Once both the DOM and CSSOM are ready, the browser combines them to build the render tree, which contains only the visible elements and their computed styles.

After the render tree is created, the browser performs layout to calculate the size and position of each element. Finally, the browser paints the pixels on the screen, rendering the page that the user sees.

What are “Google Web Vitals“ and “Core Web Vitals“?

Google Web Vitals is a set of standardized performance metrics defined by Google to measure the real user experience of the website. They focus on how fast it loads, how responsive it feels, and how stable it is visually while loading.

Core Web Vitals are a subset of Web Vitals that Google considers the most critical for user experience and uses as ranking signals in search results. There are three metrics that can be seen as Core Web Vitals: Largest Contentful Paint, Interaction To Next Paint, and Cumulative Layout Shift.

• Largest Contentful Paint (LCP): It is used to measure how long it takes for the largest visible content element to appear

• Interaction to Next Paint (INP): It is a relatively new metric that was introduced in 2023, which measures how fast the app responds to user interaction with it. Basically, how “snappy“ the interaction feels

• Cumulative Layout Shift (CLS): It is used to measure unexpected layout shifts while the page is loading

Can you explain the “Time To First Byte (TTFB)“ Metric?

When we open the browser and navigate to a website, the browser first sends a GET request to the server and receives an initial HTML in return. The time it takes to do that is known as the “Time To First Byte“ metric

Can you explain the "Time To Interactive (TTI)" Metric?

Time to Interactive is a lab metric for measuring load responsiveness. It helps identify the case when the page looks interactive but actually isn't. A fast TTI helps to ensure the page is usable with fully interactive elements. This metric was removed from Lighthouse and Core Web Vitals, but it is still useful to measure the performance of the SSR app. For example, an SSR app can lead to a scenario where a page looks interactive (links and buttons are visible on the screen), but it is not interactive because the main thread is blocked or the JavaScript controlling those elements hasn't loaded. To measure, just look at the end time of the longest task before the quiet window.

When do the DOMContentLoaded and Load Event occur?

DOMContentLoaded and Load are two key browser events that mark the different stages of page loading.

The DOMContentLoaded is fired when the HTML document has been completely parsed, and the DOM tree is built. That indicates the page structure is ready for user interaction, but it may not be fully complete yet

The Load Event is fired when the entire page and all its dependent resources have finished loading. That indicates the page is fully loaded and visually complete.

What are the “First Contentful Paint (FCP)“ and “Largest Contentful Paint (LCP)“?

First Contentful Paint is one of the most important performance metrics since it measures the perceived initial load. Basically, it is the user’s first impression of how fast your website is. Until this moment, the user has to stare at the blank screen. According to Google, FCP is ideally below 1.8 seconds before users lose interest in the website.

Somewhere in the FCP process is where the Largest Contentful Paint (LCP) happens. Instead of the very first element, like FCP, it represents the main content of the page, the largest text, image, or video visible in the viewport. According to Google, this number should ideally be below 2.5 seconds. More than that, users will think our website is slow.

Tell me about the “Lighthouse“ tool?

Lighthouse is the Google performance tool integrated in the Chrome Dev Tools and can also be run as a shell script, web interface, and a Node module. We can use a Node module to run it inside our build and detect regressions before they hit production. Those Google metrics can be measured by this tool.

Lighthouse only gives surface-level information and doesn’t allow for simulating different scenarios, like a slow network or low CPU. It’s just a great entry point and an awesome tool to track the performance changes over time. To dig deeper into what is happening, we need the “Performance“ panel.

How important is CDN in improving the website’s load time?

The primary purpose of any CDN (Content Delivery Network) is to reduce the latency and deliver content to users as soon as possible. They implement multiple strategies for this, but the two most important ones are “caching“ and “distributed servers“.

A CDN server will have several servers in various geographical locations. These servers are closer to the end user and are able to store those copies of static files on your website and send them to users when they request.

How would you know the resource is getting from the browser’s cache instead of getting a new version?

When a server receives a request for a file, it could check when the file was last modified. The browser knows because the browser sends cache validation headers like If-Modified-Since and If-None-Match allowing the server to compare versions. If the date is the same as the cached file on the browser’s side, it returns with a 304 status code with an empty body(that’s why the size is too small). This indicates to the browser that it’s safe to reuse it and there's no need to re-download it.

Can you explain the behaviour of the Cache-Control header that servers set in the response?

The Cache-Control header can contain multiple directives in different combinations, but the most important:

• max-age with a number controls how long the particular response is going to be stored

• must-revalidate directs the browser always send the request for a refreshed version if the response is stale. The response will be stale if it lives in the cache for longer than the max-age setting.

If we set the max-age=0 and must-revalidate, the browser will always check with the server and never use the cache right away. And if we set to max-age=31536000(1 year), it will tell the browser to get the content right away from the browser’s cache.

Do modern bundlers like Vite, Rollup, and Webpack always create “immutable“ JS and CSS files?

Well, they are not truly "immutable", of course. But those tools generate file names with a hash string that depends on the file's content. If the file's content changes, then the hash changes, and the name of the file changes. As a result, when the website is deployed, the browser will re-fetch a completely fresh copy of the file regardless of the cache settings. The cache is "busted", exactly like in the exercise before when we manually renamed the CSS file.

How does the component of those libraries, such as Next.js, Remix, Tanstack, work under the hood?

All of those modern frameworks give us a component that prevents the default link behaviour and some ways to render different pages for different routes without reloading the page itself. From regex pattern matching to folder-based routing. There is no more “traditional” page navigation, which includes asking the server for the new HTML, parsing it, and so on. Instead, the already initialized JavaScript just destroys the entire page or a part of it and then generates a new page and injects it into the old page. This part is usually invisible to us and is handled entirely by React.

For example:

Somewhere in the code, there is a Link component, inside of which there is this code:

<a
 onClick={(e) => { 
  e.preventDefault();
  navigate(href); 
}}>
{children}
</a>

A normal tag, where the default behavior on click is prevented - i.e., the "normal" link redirect won't happen. Instead, the navigation to the next page is triggered by JavaScript via navigate(href). Which is not a "navigation to the next page" per se, actually. Inside this navigate function, there will be something like this:

window.history.pushState({}, '', newPath); 
dispatchEvent(new PopStateEvent('popstate', { state: {} }));

Where window.history.pushState will simply update the URL part of the browser, and that's it, no redirects. The dispatchEvent part then dispatches a JavaScript event that can be listened to via addEventListener .

Somewhere else entirely, there will be a part that listens to that event and sets the state with the pathname value:

window.addEventListener('popstate', () => { 
  setPath(window.location.pathname);
});

And then somewhere in the third place, there will be code that renders different pages based on that state value:

switch (path) {
  case "/login":
    return <LoginPage />;
  default:
    return <DashboardPage />;
}

Why are no JavaScript environments so important?

The fact that real people are not the ones who can access the website. There are two other major things:

• Search engine bots (crawlers), especially Google crawlers

• Various social media and messages’ preview functionality

All of them work in a similar manner. First, they somehow get the URL of the website. This usually happens when users share the website through social media or when search bots mindlessly crawl through miliions websites out there.

Second, the bots send the request to the server and receive the response, like the browser usually does

Third, from the received HTML, they extract useful information like text, links, and meta tags. Based on that, they form the search index, and the page becomes “Googleable “. Social media previews grab the meta tags and build the nice preview we all have seen with the large picture, title, and sometimes a short description.

Many old web crawler bots have no JavaScript involved, but some of the popular search engines wait for JavaScript. However, this process means that the indexing of a website relies heavily on JavaScript and might be slow and budget-intensive. Then, it’s really important for the server to return the “proper“ HTML with all critical information on the very first request.

Can you tell me "the cost of server pre-rendering"?

When the server receives any requests, it reads the index.html file that the build step generated in advance, converts it to a string, and sends it back to whoever requests it. It is basically what all hoisting platforms that support SPA will do for us. To fix the "no JavaScript" problem, where the browser only receives the empty div without JavaScript enabled, we need to modify the HTML on the server now because nothing stops us from modifying that string before sending it back.

Adding a simple pre-rendering script, it introduces two problems in complexity:

• The first problem is where we should deploy the app now. From now on, we need a server and no longer keep the hosting cost at zero for hosting static resources.

• The second problem is the performance impact of having a server. Having a server introduces several problems with latency, including an unavoidable round-trip to the server for every initial load request.

Can you tell me what the "Server React DOM API" is and list all its methods?

The react-dom/server APIs let you server-side render React components to HTML. These API are only used on the top level of the React app to generate initial HTML. The framework calls them for us, and we mostly don't need to import them manually. There are three types of React server APIs:

• Server APIs for Web Streams(renderToReadableStream, resume): These methods are only available in environments with Web Streams, which includes browser, Deno, and some modern edge runtimes.

• Server APIs for Node.js Streams(renderToPipeableStream, resumeToPipeableStream, preRenderToNodeStream): These methods are only available in environments with Node.js Streams.

• Legacy Server API for non-streaming environments(renderToString, renderToStaticMarkup): These methods can be used in environments that don't support streams

Explain to me the renderToString API method?

React calls the renderToString method to render our app to an HTML string, which can be sent with our server response. This will produce the initial non-interactive HTML output of our React components. On the client, we need to call hydrateRoot method to hydrate the server-generated response to make it interactive. renderToString method returns the string immediately; it does not support streaming content as its load. We could use other modern streaming methods as alternative solutions. For server-side rendering, they can stream content in chunks as it resolves on the server, so users can see the page being progressively filled in before the client loads. For static generation, they can wait for all content to be resolved before generating the static HTML.

What are the differences between createRoot and hydrateRoot?

createRoot lets us create a root to display React components inside the browser DOM node.

hydrateRoot lets us display React components inside the browser DOM node whose HTML content was previously generated by react-dom/server.

The main difference is createRoot will clear the existing HTML before generating the new HTML using JavaScript and inject it into the browser DOM node. On the other hand, hydration will reuse the generated HTML that is received on the Server and only attaches the event handlers. If our app is SPA, then we use createRoot. In contrast, if our app is server-rendered, createRoot is not supported, and we need to use the hydrateRoot method.

Can SSR make LCP worse?

Unstable, there are no silver bullets in performance. If someome tell us that SRR is a 100% increase in initial load for out SPA app, they are mistaken. In the scenario when the CPU is really fast, the networking is really slow and the browser's cache is turned on, the FCP/LCP metric in SPA seems better than SSR. That is because the browser took a long time to download the initial HTML due to the slowest network in SSR. In contrast, the size of the initial HTML in SPA is really small, while the CPU is really fast for JavaScript execution. So if your app is targeting that specific niche primarily, and our app is already SPA, trying to introduce SSR to it might make it worse.

Why does implemting conditional SSR Rendering is a big mistake?

We all know that some browsers' APIs, such as window, document, .. can't be used in the server's environment. A typical way to fix it would be to use a conditional check to determine whether the window is undefined or not, and then decide which parts of the code should be executed on server or browser environment. Another way that we can put the client code inside the useEffect or useLayoutEffect is because those hooks are called after hydration happens and won't be run on the server side.

const Component = () => {
// don't render anything while in SSR mode
if (typeof window === "undefined") return null;
  // render stuff when the Client mode kicks in
return ...
}

The natural temptation of implementing conditional SSR rendering is not going to work in the correct way. React expects that the same HTML produced by the server code is exactly the same as the HTML produced by the client code. Implementing this way makes the content on the server is different with the content on the client, that confuse it so much and React will replace the entire content of the "root" div and repalces with the freshly generated elements. The hydration mechanism is totally destroyed, with all the downsides that come with that. Sometimes, it can just introduce really weird layout bugs due to the rehydration issue.

The correct way to do this is to rely on React's life cycle to "hide" the non-SSR compatible blocks.

const Component = () => {
// initially, it's not mounted
const [isMounted, setIsMounted] = useState(false);
};

const Component = () => {
// initially, it's not mounted
const [isMounted, setIsMounted] = useState(false);
useEffect(() => { 
    setIsMounted(true);
}, []); 
};

On first render, both client and server receive the same null content, so the server thinks that I can trust this DOM and the hydration mechanism won't be broken.

Why does compressing JavaScript help to improve the web performance?

We all know that the more large in size in JavaScript bundle, the more time users need to wait for the browser complete downloading. Having a few megabytes of JavaScript on the page just feels wrong, so the issue of the bundle size and how to reduce it dominates performance-related discussions. In real life, when sending those files to users, we often would first compress them with something like gzip and brotli to reduce the size. Most of the hoisting providers have compression enabled by default, especually we are using CDN.

What is the JavaScript Evaluation?

If we are profiling a web application that ships a lot of JavaScript code, we might see a long task that is labeled with Evaluate Script. Script evaluation is a necessary part of executing JavaScript code in the browser, as JavaScript is compiled just-in-time before execution. When the JavaScript is evaluated, it is first parsed for errors. If the parser doesn't find any errors, then the script is compiled into bytecode, and the continue onto the execution part. The network cost of downloading JavaScript is the only thing users need to pay for once on the first visit. After that, resources can be gotten from cache, but the cost ofthe JavaScript Evaluation process is what users need to pay for every visit.

Which tools do you use to improve the performance of the website?

Well, there are a few tools that I use to measure the performance of the website. In the development phase, I use the React Profiler of the React Dev Tool to check if any components render unnecessarily. It helps me to identify which components are slow and why. I use the Performance tab on Chrome Dev Tools to analyze the main thread and identify what is blocking the UI during interactions. For example, when users report janky scrolling, you might find the long-running JS tasks causing frames drop. I use the Network tab when investigating slow load times. The waterfall chart reveals API delays, building issues, and caching problems. I also use the webpack-bundler-analyzer to identify dependencies that are inflating my bundle size. And Lighthouse is my go-to for auditing the overall performance, accessibility, and SEO before pushing to production.

Can you explain those terms, like minification and tree-shaking in the bundler?

Minification is the simplest optimization step, but surprisingly powerful. It will help you to remove all the redundant things from your final code without affecting the execution. Things such as whitespaces, comments, long variable names, and formatting, those are don’t need on your final bundle. Your final code works exactly the same, but becomes smarter, faster to download, and faster to parse.

Tree-shaking is a way to let the bundler remove the dead code, unused code from your final bundle. For example, you define 5 functions, but you only use one; the 4 left are never used in your codebase. Tree-shaking will remove those 4 dead code from your final bundle, which makes the final bundle to be more smaller. Tree-shaking relies heavily on ES modules (import/export). Because ES modules are static. The bundler can analyze them at build time and see which exports are actually used.

How do we need to use the Code Splitting technique to reduce bundle size?

The idea behind the Code Splitting technique is that when we have to send a large 5MB file to the users, if those 5Mb are packed into a single file, downloading that file will take more than a minute. So the question is: Why don't we just split that large file into multiple chunks, then let the browser download them in parallel? It will help me reduce the download time. The hard part is that we can't just cut that file into 10 random files; that is not how JavaScript works. We need to split it into isolated, independent modules and ensure that those modules can call functions in other modules. Doing this manually would be a huge headache, but luckily, most modern bundlers can do it for us.

https://vite.dev/guide/build.html#chunking-strategy

https://webpack.js.org/guides/code-splitting/

How do you decide when to split a large JavaScript bundle into multiple chunks?

Answer: I focus on Cache Stability and Resource Criticality. First, I separate vendor code from app code. Since node_modules change rarely, splitting them allows for long-term browser caching. For the dependency tree, if a library or feature is over 100KB, I'll extract it into its own chunk. I aim for chunks between 50KB–100KB to balance parallel download speed with compression efficiency.

Can you explain the risk of having TOO MANY small chunks in a web application?

Answer: There are two main risks. First is the Protocol Bottleneck: On HTTP/1.1, browsers are limited to ~6 concurrent connections. Too many chunks can create a "waterfall" that delays critical CSS. Second is Compression Overhead: Algorithms like Brotli work better on larger text blocks. Breaking code into tiny chunks reduces the compression ratio, potentially increasing the total transfer size.

What is the difference between how local development and production environments handle chunking?

Answer: The primary difference is the protocol. Local dev servers often use HTTP/1.1, while production CDNs use HTTP/2 or HTTP/3. In local testing, you might see performance regressions from many chunks due to connection limits. In production, those same chunks are requested in parallel. It is vital to verify performance in a production-like environment before final decisions.

If you move a specific UI component into a 'components' chunk, why might it still appear in the 'index' chunk?

Answer: This happens due to how the bundler traces the dependency tree. If the index entry point imports that component directly (or via a shared utility not included in the chunk rule), the bundler may prioritize including it in the main bundle to avoid extra round-trips. You must ensure the manualChunks configuration (like in Rollup/Vite) explicitly targets the file path and that imports are structured to allow isolation.

How does code splitting improve performance beyond just the initial download speed?

Answer: It significantly reduces JavaScript Execution and Compilation time. By splitting code, the browser can parse and compile individual chunks as they arrive, rather than waiting for a single massive file to finish downloading. This frees up the Main Thread much sooner, which improves responsiveness metrics like First Input Delay (FID) or Interaction to Next Paint (INP).

How would you approach a task where the production JavaScript bundle has suddenly grown by 2MB?

Answer: I would start by running a Bundle Analyzer (like webpack-bundle-analyzer or rollup-plugin-visualizer) to generate a treemap of the production build. I’d look for large "blobs" in the node_modules section. Once a culprit is identified, I’d trace its usage in the codebase. Often, it’s a case of someone importing an entire library (like lodash or MUI) instead of specific named exports, or a new dependency being pulled in by a sub-dependency.

What are the performance implications of using import * as UI from 'library-name' ?

Answer: This pattern generally prevents the bundler from performing effective Tree-Shaking. By using the namespace import (*), you are explicitly telling the bundler that you might need any part of that library at runtime. Even if you only use UI.Button, many bundlers will include the entire library in the final chunk, leading to massive "Bundle Bloat" and increased parse/compile times for the user.

Why might a "Unified Icon Library" file (one file that exports all project icons) be a bad architectural choice?

Answer: While it provides a clean developer experience (DX) and better autocomplete, it creates a bottleneck. If that central file imports 2,000 icons from a library to re-export them, every page that needs even a single "Close" icon will end up loading all 2,000 icons. This is because the bundler sees the central file as a single dependency that requires all those icons to be present.

If a bundle analyzer shows that a library is taking up 40% of your bundle, but you only use one function from it, what are your options?

Answer: First, I would check if the library supports Named Exports (e.g., import { functionName } from 'lib') which allows for tree-shaking. If it doesn't, I’d check for "sub-path imports" (e.g., import functionName from 'lib/functionName'). If the library is simply not tree-shakeable, I’d evaluate if there is a lighter alternative (like date-fns instead of moment.js) or if I can implement that specific logic manually to save those several hundred KB.

What is the "Comment-Out" strategy in bundle optimization?

Answer: It’s a quick sanity check used during the investigation process. Before committing to a complex refactor, you comment out the suspected heavy imports and rebuild the project. Even though the app won't run, the build will complete, allowing you to see exactly how much the bundle size drops. This confirms that your "investigation" is targeting the right package before you spend hours on the actual fix.

What is Tree-Shaking, and how does it differ from traditional Dead Code Elimination?

Answer: Tree-shaking is a form of dead code elimination that relies on the static structure of ES Modules (import and export). Unlike traditional DCE, which looks at segments of code that can't be reached, tree-shaking tracks the "live" exports across the entire module graph. If a module exports a function but nothing in the dependency tree imports it, the bundler "shakes" it off the tree to keep the final bundle lean.

Why does import * as Material from '@mui/material' often cause performance issues in production?

Answer: In theory, modern bundlers can tree-shake namespace imports. However, in practice, if that Material object is ever used as a dynamic reference (like Material[componentName]) or wrapped in another exported object (like export const Theme = { Material }), the bundler loses the ability to statically analyze which specific parts of the library are needed. To be safe, it includes the entire library, which for MUI includes hundreds of components and thousands of icons.

Can you explain a scenario where a component is imported but still excluded from the final bundle?

Answer: Yes. If I import MyDialog in App.tsx but don't actually reference it in the JSX/return statement, or if it's inside a conditional block that the bundler determines is "dead" (like if (false) { ... }), the bundler will see that the component is never actually "reached." Since the branch is dead, the component and all of its unique dependencies will be omitted from the production chunk.

How would you refactor a "Global UI Wrapper" that is causing a 5MB bundle size due to Material UI imports?

Answer: I would replace the import * as Material with Direct/Named Imports. Instead of mapping the entire library to a key, I would import only the specific components we use—like Button or Snackbar—and explicitly add them to the wrapper object. This restores the bundler's ability to perform static analysis, ensuring that only those two components (and their specific dependencies) are included in the vendor chunk.

Is it possible to use the "Namespace Pattern" (e.g., <UI.Button />) without breaking tree-shaking?

Answer: It depends on the bundler, but generally, the safest way to maintain that DX is to build the UI object manually using named imports. For example: import { Button } from './Button'; export const UI = { Button };. As long as you aren't using import * to grab the whole directory, the bundler can see that UI.Button only requires the Button file, and it will continue to tree-shake other unused components in that directory.

Why can a bundler tree-shake your own code easily, but often fails to tree-shake older libraries like Lodash?

Answer: Tree-shaking requires the ESM (ES Modules) format. Our own code uses import and export, which allows the bundler to map the dependency tree statically. Older libraries often distribute code in CommonJS or UMD formats. Because these formats allow dynamic requires and exports, the bundler cannot be 100% sure that a piece of code is unused, so it includes the entire library to avoid breaking the app.

What is "Cherry-picking" in the context of bundle optimization?

Answer: Cherry-picking is the practice of importing a specific function directly from its file path rather than the library's main entry point—for example, import trim from 'lodash/trim' instead of import { trim } from 'lodash'. This bypasses the potentially non-tree-shakeable main index file and ensures only the code for that specific utility is included in the bundle.

If npx is-esm returns "No" for a package, what does that tell you about its impact on your bundle?

Answer: It tells me that the package does not provide a standard ES Module entry point. Consequently, standard named imports (import { x } from 'pkg') will likely fail to tree-shake, and the entire library will be bundled. In this case, I would either look for an ESM-native alternative, search the documentation for sub-path "cherry-picking" imports, or evaluate if I can replace the functionality with native JavaScript.

How do you decide between using a utility library (like Lodash) and writing native JavaScript code?

Answer: I look at Browser Support and Bundle Cost. If I only need simple functions like trim() or toLowerCase(), I use native JavaScript because it costs 0 bytes and is highly optimized by the browser engine. I only reach for a library if I need complex, battle-tested logic (like deepClone or debounce) that would be error-prone to write manually, and even then, I ensure I'm importing only the specific functions needed.

What is the difference between import { Star } from '@mui/icons-material' and import Star from '@mui/icons-material/Star'?

Answer: The first is a Named Import from the main index. If the library is properly configured for ESM, this should tree-shake. The second is a Default Import from a specific file path. The second approach is "safer"—it guarantees that only the Star icon is pulled in, regardless of how complex the library's internal tree-shaking configuration is. Many developers prefer the second one for icons because it prevents "accidental" bloat from configuration errors.

What would you do if you found three different date-manipulation libraries in a single project’s bundle?

Answer: I would perform a Unification Audit. First, I’d use a search tool to see how many times each library is used. If a heavy library like moment is only used in a few places, I’d refactor those instances to use a more modern, tree-shakeable alternative like date-fns or native Intl APIs. The goal is to standardize on the single most efficient library and then uninstall the others to shrink the vendor chunk significantly.

How do you identify why a specific package is being included in your bundle if you haven't explicitly imported it?

Answer: I would use a dependency tracing tool like npm-why or yarn why. These tools show the dependency chain. For example, if I see @emotion in my bundle but I only use Tailwind, npm-why might reveal that it’s being pulled in as a sub-dependency of @mui/material. To get rid of it, I’d have to either replace the parent library (MUI) or find a version that doesn't rely on that transitive dependency.

Why did replacing one @emotion component with a Tailwind class not immediately remove Emotion from the bundle?

Answer: This is a classic case of Transitive Dependencies. Even if you stop using a library directly in your code, it will remain in the bundle if another library you are still using (like Material UI) depends on it. Removing a library from a bundle often requires a "recursive" cleanup of all packages that reference it.

What is the trade-off between using a UI library like Material UI vs. a headless primitive library like Radix UI?

Answer: Bundle size vs. Development speed. Material UI comes with pre-defined styles and heavy internal dependencies (like Emotion), which can bloat the bundle to several megabytes. Radix UI provides "headless" primitives (accessible logic without styles), which are much smaller and allow you to use your own lightweight CSS-in-JS or Tailwind. In performance-critical apps, switching from MUI to Radix can often save hundreds of kilobytes.

In a "Bundle Size Initiative," how do you prioritize which libraries to refactor first?

Answer: I use the "Impact vs. Effort" matrix. I start by looking at the Bundle Analyzer. Large, non-tree-shakeable blocks that are only used in a few places are "Low Effort, High Impact" wins. Redundant libraries (like having two different icon sets) are also top priorities. I save large-scale migrations—like moving an entire themed app away from MUI—for last, as they require significant regression testing.

Others

How do you debug issues?

There are a few effective strategies I used to resolve the most complex issues and help me save time and energy:

• Firstly, I try to reproduce the error consistently. We can’t fix the error when we can’t see it. Once I know how to reproduce the bug, then I will try to make it fast for able to jump straight into the problem area. After that, before digging into the problem, I will try to collect as much context as possible (confirming with the QC, checking records, logs) to make sure it’s a bug and avoid missing information.

• The next part is isolating the problem. Finding bugs in a large codebase is really hard. I apply the binary search approach that divides the code into working and non-working parts by commenting out the suspicious code. Repeat that process until I find exactly the problematic area. Additionally, I usually use console.log to find issues in most cases. Besides, I also use some debugger tools like VSCode Debugger, Chrome Dev Tools, and React Developer Tools if needed.

• After I found the part of the code that causes the issue, I adopted a more scientific, methodological approach instead of making random changes. I start with forming a hypothesis about the root cause, add logging and breakpoints to verify it, observe the results, fix the code based on what I learn, verify the fix, and repeat the cycle again with a new hypothesis. Finding issues and fixing them depends on how much you understand the system, the flow, and how things work under the hood. Once you have a clearly knowledege how things work, you can find the issues quickly.

• When I am stuck because the bug is particularly hard, I write down what I have tried. This way helps me to prevent doing the same thing twice and expecting different results. It also makes it easier for others to help me. When I feel like my brain is being shut down after hours trying to fix a bug, but couldn’t, I will step away from my laptop to take a 15 minutes walk to refresh my mind. Sometimes, I feel like it is the fastest way to solve a bug.

• AI coding tools are really powerful these days, especially if we give them the right information. The right context is the key. I mostly let AI fix bugs after I found the issue and provided the solution to AI. For some simple issues, I just let the AI do all things and only review the final code.

List of the Behaviour Questions

Can you tell me about yourself?

Hi, I'm Tuan. I am a Senior Front-End Engineer with over five years of experience. I have a degree in Computer Science, which gave me a very strong foundation in programming and problem-solving.

Throughout my career, I have specialized in React, Next.js, and TypeScript. I care a lot about the 'fundamentals'—like making sure my code is clean, SEO-friendly, and accessible for all users.

In my most recent role, I worked for a large international digital consultancy. For more than four years, I was the Senior Front-End Lead for a major e-commerce platform in the Australia and New Zealand region (ANZ). I was responsible for building and designing key features that helped the business grow.

Something that defines me is my habit of learning. For the last five years, I have read technical articles every single day. I believe a senior engineer doesn't need to know everything, but they must know how to find the right solution quickly.

I also have a blog where I share what I learn. I think my blog is the best way to see how I think and solve technical problems.

Can you tell me about your work in your recent project?

In my last project, I spent four years contributing to the front-end development for a large e-commerce website in the ANZ region.

As a senior engineer, I was responsible for the most complex parts of the project. This included things like a new login flow, color discovery features, and product detail pages. I always make sure I fully understand the requirements before I start writing any code.

My process is simple but effective:

• First, I analyze the task. If it's complex, I discuss it with my team and the lead to make sure we have a good plan.

• Second, I focus on 'Clean Code' principles. I want my code to be easy to read and easy to maintain.

• Third, I always write unit tests. This helps me find bugs early and deliver high-quality work on time.

Because of my impact on the project, I was promoted twice during my four years there.

What do you do to enhance your technical knowledge apart from your project work?

I have a very disciplined approach to learning. My first priority is always to deliver my project tasks on time and with high quality. However, I believe that staying updated is part of a senior engineer's job.

For over five years, I have maintained a daily habit of reading technical literature. I use tools like daily.dev, and I follow industry experts on Medium and Substack. This helps me stay ahead of the latest trends in the JavaScript and React ecosystem.

When I find a truly deep or useful article, I don't just read it—I save it into my personal knowledge base. Over time, this has built a massive library of resources that help me solve complex problems quickly.

To solidify my knowledge, I also run a technical blog. I believe that 'to teach is to learn twice.' Writing about advanced topics and architectural patterns helps me understand them deeply. This habit ensures that I never fall behind and that I am always ready to adopt new technologies when the project needs them.

Tell me about a time you had a disagreement with your manager.

In my experience as a Senior Engineer, I believe that a disagreement is actually an opportunity for collaboration. I generally have a very good relationship with my leads, but when we have different opinions on a technical solution, I follow a professional process.

For example, if my manager proposes a solution that I think could be more optimized, I don't just say 'no.' Instead, I prepare a clear technical proposal. I show the pros and cons of my idea compared to the original one.

My goal is never to 'win' the argument, but to find the best solution for the project. I believe in 'Strong Opinions, Weakly Held.' This means I will advocate for the best technical path, but once a final decision is made by the lead or the team, I fully support it and work hard to make it successful.

This approach has helped me maintain high technical standards while keeping a very positive and professional environment in the team.

Tell me about a situation when you had a conflict with a teammate.

I focus on maintaining a positive team environment, so I rarely have personal conflicts. However, I once had a technical disagreement during a code review.

A teammate was trying to improve performance by using Math.random() to generate React keys everywhere on the site. I knew this would cause major performance problems because React keys must be both 'unique and stable' for the reconciliation process to work correctly.

At first, he didn't realize why this was a problem. Instead of pointing out the mistake in the public group chat, I reached out to him privately. I explained how React works 'under the hood' and why stable keys are necessary. I also suggested better solutions, like using unique IDs from our data.

He understood the explanation, updated the Pull Request, and the task was completed successfully. By handling it privately and technically, I helped my teammate grow while keeping our professional relationship very strong.

Tell me about a time you failed. How did you deal with this situation?

Early in my career, I made a mistake by focusing too much on speed and not enough on quality. I wanted to prove I was fast, so I jumped straight into coding before fully understanding the requirements. I skipped unit tests and didn't confirm unclear details with the Business Analyst.

As a result, the feature was full of bugs and didn't meet the client's needs. This delayed the release and was a very tough lesson for me. I learned that 'being fast' is useless if the work is incorrect.

Since that day, I have followed a disciplined process that ensures high quality:

• First, I analyze requirements deeply and ask questions early.

• Second, I break big tasks into smaller, manageable parts.

• Third, I always write unit tests and perform thorough 'smoke tests' before delivery.

This failure helped me become the reliable Senior Engineer I am today. I now complete my tasks on time, with a very low bug rate and high-quality code.

Describe a time when you led a team. What was the outcome?

While I haven't held a formal 'Team Lead' title yet, I have naturally taken on informal leadership responsibilities in my senior roles.

For example, I am the primary person for code reviews on my team, and I mentor junior developers to help them follow best practices. I also take the lead on technical documentation and architectural proposals for new features.

I am very interested in moving into a formal leadership role. I have been studying management principles from industry experts to understand how to motivate a team and manage project risks. I believe my strong technical foundation and my ability to communicate clearly make me ready for this next step in my career.

Tell me about a time that you worked well under pressure

I remember a critical issue that appeared right on a major release day. A navigation feature that was working perfectly in testing suddenly started 'flickering' in the production environment. This was a high-pressure situation because the client needed a fix immediately to avoid delaying the launch.

Even though the pressure was high, I stayed calm and followed a logical debugging process:

• First, I reproduced the bug in a local environment to understand the root cause.

• Second, I used a 'divide and conquer' approach by isolation—commenting out sections of code to find the exact source of the flicker.

• Third, once I found the issue, I analyzed the logic and implemented a stable fix.

I was able to resolve the bug within two hours. The client was very pleased with the prompt and professional response. This experience taught me that staying calm and following a methodical process is the best way to handle high-pressure situations.

How do you handle a situation when you don’t know the answer to a question?

Answer:
"In my experience, especially during client demos, it's very important to handle unknown questions professionally to maintain trust. I remember a time when a client asked me about a specific technology I hadn't used before. Instead of pretending to know the answer, I stayed honest and professional. I told the client: 'That's a great question. I want to give you the most accurate information, so I need to do a quick research before I confirm the details. I will get back to you by the next meeting.' I then researched the topic and consulted with my team. At the next meeting, I provided a confident and correct answer. I believe being honest is the best way to build long-term trust with stakeholders."

Describe a time when you received tough or critical feedback.

Answer:
"Early in my career, my Technical Lead told me that while my delivery speed was excellent, my code quality needed more focus and I needed to be more open to teammates' opinions. At first, it was hard to hear, but I realized his feedback was a gift to help me grow. I decided to change my approach immediately by taking more time for self-reviews, performing strict 'smoke tests' before delivery, and being more open-minded during discussions. My lead was very satisfied with my improvement, and this feedback actually helped me transition into a Senior role. It taught me that a great engineer must be humble and focus on quality above all else."

Describe a time when you had to give someone critical feedback. How did you handle it?

Answer:
"In my senior role, I often mentor junior developers. I once worked with a talented developer who was misusing React memoization hooks like useMemo and useCallback everywhere. I arranged a private one-on-one meeting to provide constructive feedback. Instead of just highlighting the mistake, I explained how React works under the hood and why over-memoization can actually hurt performance. I also shared deep-dive resources to help him learn. He responded well, updated his code correctly, and thanked me for the guidance. For me, giving feedback is about helping the team grow together."

Describe a time when you anticipated potential problems and developed preventive measures

Answer:
"During a major performance refactoring phase, I noticed a significant risk in our codebase. Our team had agreed to refactor React keys to improve rendering, but a teammate incorrectly implemented a utility using Math.random() to generate keys globally. I recognized immediately that this would cause React to re-mount every component on every render, leading to a performance disaster. I rejected the Pull Request and organized a meeting to explain the reconciliation process and why keys must be both unique and stable. By catching this early and mentoring my teammate on React internals, I prevented a critical production issue and helped the team adopt a more robust implementation strategy."

Describe a situation when you had to deal with a difficult customer

Answer:
"In my role as a Senior Engineer, I primarily interface with project stakeholders and onsite partners rather than direct retail customers. I’ve found that the best way to prevent 'difficult' situations with any stakeholder is through consistent transparency and high-quality delivery. For example, by providing clear technical demos during bi-weekly standups and maintaining open communication on JIRA, I’ve built a high level of trust with our international partners. Because our team consistently hits milestones and maintains a low bug rate, my interactions with stakeholders have remained very positive and collaborative."

Tell me a time when you missed a deadline. What happened, and how did you handle it?

Answer:
"I am very disciplined with planning, so I rarely miss deadlines. However, I once encountered a situation where a critical requirement was missing from a ticket late in the sprint. Instead of rushing to code a partial solution, I immediately raised the risk to my Project Manager and Business Analyst. I worked closely with them to clarify the missing logic and provided a new, realistic estimate for the update. Even though the original internal target shifted, I committed to a new delivery time and worked diligently—including extra hours—to ensure the final feature was shipped with zero bugs for the main release. This taught me that early communication is the most important tool when facing a deadline risk."

Describe when your workload was heavy and how you handled it

Answer:
"During the implementation of a new authentication flow using Azure B2C, my workload suddenly doubled when my Lead was pulled into another urgent release. I was assigned the entire authentication UI suite—including login, sign-up, and password recovery—with a very tight deadline. These tasks required a deep dive into native HTML, CSS, and JavaScript within a complex specialized platform. I handled this by first performing a risk assessment and communicating the new effort requirements to my PM. Once the stakeholders were aligned, I focused on a methodical execution. I successfully shipped all forms on time, receiving high praise from the client for delivering a complex feature smoothly under pressure."

Describe a time you had to deal with a significant change at work. How did you adapt?

Answer:
"In my experience, significant changes are best handled through a structured technical investigation. While our project requirements are usually well-defined, I am always prepared for shifts in scope. If a major change occurs, my first step is to perform a deep-dive analysis into the existing codebase to identify similar patterns. I then research the official documentation and best practices for the new requirements. Before starting any implementation, I break the solution down into technical tasks with realistic estimations. I then proactively communicate the impact and the timeline to my Project Manager and Business Analyst. This structured approach ensures that the change is integrated smoothly without risking the stability of the overall release."

Describe a situation where you saw a problem and took an initiative to correct it

Answer:
"While working on a new feature, I noticed a critical bug in a common utility function that was being used across the entire site. A teammate had implemented an asynchronous operation inside a forEach loop, which was causing intermittent race conditions and mysterious bugs. Even though this wasn't part of my assigned ticket, I took the initiative to address it. I reached out to my teammate privately and explained why forEach doesn't wait for promises and how to correctly use for...of or Promise.all. I helped him refactor the utility and verify the fix. By taking this initiative, I not only fixed a major hidden bug but also shared important technical knowledge with the team."

Describe a time when there was a conflict with your team. How did you help resolve it?

Answer:
"Early in my career, I was sometimes too protective of my own technical choices, which occasionally led to friction during code reviews. I realized that being a great engineer isn't just about writing code; it's about collaboration. I made a conscious decision to change my mindset. Now, I view every comment as an opportunity to improve the project. When a conflict arises, I stay calm, take a breath, and evaluate the feedback objectively. If I disagree with a bug report or a review comment, I don't argue; instead, I arrange a quick call to explain my logic clearly. If we still don't agree, I involve a third party like a Tech Lead or BA to provide a neutral perspective. This transition from being 'stubborn' to being 'collaborative' has significantly boosted my productivity and strengthened my relationship with my team."

Describe a time when you went out of your comfort zone. What lessons did you learn?

Answer:
"The most significant time I stepped out of my comfort zone was when I moved from a local project to an international one with English-speaking clients in the ANZ region. Initially, I was very nervous about demoing my features in English during bi-weekly standups. I even tried to avoid them at first. However, I soon realized that to grow as a Senior Engineer, I needed to master technical communication. I started preparing for my demos much more thoroughly—writing scripts and practicing my speaking. I stopped hiding and began actively presenting my weekly achievements. This experience taught me that growth happens when you face your fears. My confidence improved, my PM noticed a huge difference, and I am now very comfortable presenting complex technical flows to international stakeholders."

Describe a time when you took a big risk, and it failed

Answer:
"I am generally a risk-averse engineer who prefers careful planning, but there was a situation where I had to step up during an emergency. A teammate went on leave right before a production release, leaving a complex GraphQL change unfinished. Even though I am primarily a Front-End expert, I volunteered to handle the backend integration. I worked extra hours to learn the new GraphQL patterns and coordinated across teams to meet the deadline. In the end, I only completed about 80% of the task on my own and needed a lead's help for the final integration. While I didn't finish everything 100% independently, it was a valuable experience. I learned how to manage high-pressure cross-stack tasks, and the client was very impressed with my willingness to take on a difficult challenge to ensure the release was a success."

Describe a time you had to explain a complex technical concept to someone non-technical

Answer:
"Early in my career, I struggled to explain technical details to non-developers like BAs or QCs. I eventually realized that effective communication is a core senior skill. My approach changed from focusing on how a feature works to why it matters for the business. Now, when I explain a technical concept, I use analogies and focus on the user impact rather than the implementation detail. For example, instead of discussing 'asynchronous state synchronization,' I talk about how the system ensures the user's data remains consistent across the whole site. This shift in perspective has made my collaborations with the QA and Product teams much smoother and more productive."

Tell me a time you disagreed with your colleague. How did you handle this situation?

Answer:
"I believe that healthy technical debate is essential for a high-quality project. When I have a disagreement with a colleague, I focus on staying objective and professional. I avoid personal tension and instead move the discussion to a dedicated technical meeting where we can look at the facts. During these sessions, I practice active listening to understand their reasoning before sharing my own perspective. If we reach a stalemate, I proactively involve our Technical Lead to provide a neutral 'third party' decision. My priority is always the best interest of the project, not 'winning' the argument. This approach ensures that we remain effective teammates even after a tough technical decision."

Tell me about a complex task you have worked on recently

Answer:
"Recently, I led the front-end implementation for a major authentication migration to Azure B2C. This was a high-stakes project delivered at the end of the year. The challenge was that I had to build a modern, high-fidelity UI using native HTML, CSS, and JavaScript, as the platform did not support modern frameworks like React. The documentation was also quite limited. I handled this by performing deep-dive research into the Azure B2C Custom Policy framework and breaking the large project into modular vanilla JavaScript classes. Despite the technical constraints and tight deadlines, I delivered the full suite of Login, Sign-up, and Password Recovery flows on time with zero critical bugs. It was a great example of using core web fundamentals to solve a complex architectural problem."

How do you stay up-to-date with the latest technological advancements?

Answer:
"I view continuous learning as a daily discipline rather than an occasional task. For over five years, I have dedicated at least two hours a day to staying updated with the JavaScript and React ecosystem. I rely on a curated library of resources, including daily.dev, Medium, and various expert newsletters. To ensure my knowledge is practical and stays with me, I maintain a technical blog where I document advanced concepts and 'lessons learned' from my projects. I believe a senior engineer's value comes from their ability to bring these new, optimized solutions into their team's workflow to prevent the project from falling behind technologically."

Give me an example of a time you had to debug a challenging technical issue.

Answer:
"I recently handled a challenging cross-device issue where a production bug only appeared on mobile Safari. Because our environment was behind a strict VPN, I couldn't use standard remote debugging tools easily. To solve this, I followed a methodical 'isolation' process. I first verified the requirement to ensure it wasn't a misunderstanding, then I used logging and targeted code removal to 'scope down' the bug locally. Once I identified the root cause—a specific CSS legacy behavior in Safari—I coordinated with the team to implement a stable fix that wouldn't impact other browsers. I find that a calm, step-by-step reproduction process is the most effective way to resolve even the most difficult technical issues."

References

https://github.com/ashishps1/awesome-behavioral-interviews

https://javascript.plainenglish.io/93-of-frontend-developers-cant-explain-react-profiler-vs-lighthouse-here-s-what-actually-2bdf07b0f253

https://javascript.plainenglish.io/the-one-frontend-interview-question-that-humbled-me-after-100-interviews-42935d92496c

https://medium.com/@jaganjvvn/real-world-frontend-interview-answers-javascript-react-typescript-b531f8298a8f

https://javascript.plainenglish.io/15-react-interview-questions-every-mid-level-developer-should-be-ready-for-in-2025-38ee70bc114c

https://javascript.plainenglish.io/mastering-the-senior-react-developer-interview-real-world-questions-you-must-prepare-for-46cda3df1c82

https://www.developerway.com/posts/server-actions-for-data-fetching

https://javascript.plainenglish.io/mastering-the-senior-react-developer-interview-real-world-questions-you-must-prepare-for-46cda3df1c82

https://thetshaped.dev/p/conscious-debugging-10-effective-debugging-strategies-debug-like-pro

https://www.developerway.com/posts/debugging-with-ai

https://medium.com/@kanishks772/every-bug-i-ever-fixed-made-sense-only-after-i-understood-these-7-layers-ebcae423399b

Next.js 16.0.1 is live, and it is not just a point release. It tightens the App Router story, clarifies caching with Cache Components, promotes Turbopack to the default, and ships practical breaking changes that you should address before merging that upgrade pull request. The official docs header shows 16.0.1 as the latest version, so let’s treat this as the new baseline.

Cache Components — The Star of Next.js 16

One of the most significant changes is the introduction of Cache Components, a new opt-in caching model powered by the 'use cache' directive.

It’s built on top of the Partial Pre-Rendering (PPR) work started in 2023 — but now, it’s simpler and more powerful.

Instead of implicit caching rules, developers can now explicitly define what gets cached and what executes dynamically at runtime.

// next.config.ts
const nextConfig = {
  cacheComponents: true,
};
export default nextConfig;

💡 Why it matters:
Before, you had to choose between fully static or fully dynamic rendering.
Now, with Cache Components, you can mix both — static shells with dynamic data chunks.
This gives you the speed of SSG with the freshness of SSR, all within a unified architecture.

Turbopack — Now the Default Bundler

After nearly two years of testing, Turbopack is finally stable and is now the default bundler for all new Next.js projects.

Built in Rust, Turbopack delivers jaw-dropping performance gains:

• 🚀 2–5× faster production builds

• 🔁 Up to 10× faster Fast Refresh during local development

You can still fall back to Webpack if you need to:

next dev --webpack
next build --webpack

💡 Why it matters:
Shorter feedback loops mean faster iteration, smaller CI/CD times, and a smoother dev experience — especially for teams working on massive codebases or micro-frontends.

Next.js DevTools MCP — AI-Assisted Debugging

This release debuts Next.js DevTools MCP (Model Context Protocol) — bringing AI-powered insights right into your dev workflow.

What it does:

• Understands your app’s routing, caching, and rendering logic

• Combines browser + server logs into one view

• Let’s AI agents (like Codex or Copilot) explain, debug, and suggest fixes contextually

💡 Why it matters:
This bridges the gap between AI assistance and real-world debugging.
You can finally ask “why is this route slow?” and get contextual answers — not just generic suggestions.

proxy.ts — Replacing middleware.ts

middleware.ts has officially been replaced by proxy.ts to make your network boundary explicit.

This runs only on the Node.js runtime and provides clearer semantics for request interception.

// proxy.ts
import { NextRequest, NextResponse } from 'next/server';
export default function proxy(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url));
}

💡 Why it matters:
It simplifies your app’s network layer and prevents confusion about where middleware logic runs.
If you were previously using middleware for redirects or auth, simply rename your file and function — you’re done.

Enhanced Routing and Navigation

Next.js 16 completely re-engineers routing and navigation for leaner page transitions.

Key highlights:

• Layout Deduplication: Shared layouts load once, even when prefetching multiple URLs.

• Incremental Prefetching: Only fetches parts not already cached.

• Smart Re-Prefetching: Automatically re-fetches invalidated data when links re-enter the viewport.

💡 Why it matters:
Large apps (think dashboards, analytics, HR portals) benefit massively — lower transfer sizes, faster navigation, and near-instant reloads between sections.

New and Improved Caching APIs

Next.js 16 refines how developers manage cache invalidation and freshness.

✅ revalidateTag() (Updated)

import { revalidateTag } from 'next/cache';
// Using built-in cacheLife profile
revalidateTag('blog-posts', 'max');
// Custom revalidation
revalidateTag('products', { revalidate: 3600 });

🆕 updateTag() (New)

For immediate “read-your-writes” consistency inside Server Actions:

'use server';
import { updateTag } from 'next/cache';
export async function updateUserProfile(userId, profile) {
  await db.users.update(userId, profile);
  updateTag(`user-${userId}`);
}

🆕 refresh() (New)

For refreshing uncached data without touching cached content.

💡 Why it matters:
You now have total control over cache lifecycle — perfect for user dashboards, analytics panels, or anything requiring instant feedback after an update.

React 19.2 Support and Compiler Integration

Next.js 16 ships with React 19.2 and full support for the React Compiler (automatic memoization).

Highlights include:

• View Transitions for smooth animations between pages

• useEffectEvent() for better effect logic isolation

• for managing background UI states

To enable the compiler:

const nextConfig = {
  reactCompiler: true,
};
export default nextConfig;

And install the plugin:

npm install babel-plugin-react-compiler@latest

💡 Why it matters:
Automatic memoization means fewer unnecessary re-renders and smoother UIs — no manual useMemo or useCallback needed.

Next.js 15

Next.js 15 Release Candidate (RC) introduces a range of new features & improvements aimed at enhancing the development experience and performance of web applications. This release builds on the strengths of the previous version while at the same time introducing innovative capabilities that promise to streamline workflows and optimize application performance. Below is a detailed overview of the key updates in Next.js 15 RC.

create-react-app upgrades: cleaner UI, 700x faster build

Reformed design

❌From this:

✅To this:

Webpack → Turbopack

Turbopack: The fastest module builder in the world.

• 700x faster than Webpack

• 10x faster than Vite

And now with v15, adding it to your Next.js project is easier than ever before:

Typescript configs - next.config.ts

With Next.js 15, you can finally create the config file in TypeScript directly.

The NextConfig type enables editor IntelliSense for every possible option.

React Compiler, React 19 Support, and User-Friendly Errors

React Compiler

React Compiler is a React Compiler (who would have thought)

A modern compiler that understands your React code at a deep level

Bringing optimizations like automatic memoization, destroying the need for useCallback and useMemo in the vast majority of cases.

Saving time, preventing errors, and speeding things up.

And it’s really easy to set up: You just install babel-plugin-react-compiler:

And add this to next.config.js

React Server Actions (Stable with React 19)

Say goodbye to complex API routes.

Next.js 15 supports React Server Actions, allowing you to handle server logic directly inside your component files.

You declare them using a special "use server" directive.

"use server";

export async function submitContactForm(data) {
  await db.contact.insert(data);
}

Then call them from a <form>:

<form action={submitContactForm}>
  <input name="email" />
  <textarea name="message" />
  <button type="submit">Send</button>
</form>

✅ Benefits:

• Eliminates boilerplate API files

• Fully type-safe and colocated

• Keeps data handling strictly server-side

• No need for fetch(), Axios, or client mutation libraries

💡 Server Actions unlock a more intuitive, secure, and maintainable full-stack pattern.

React Server Components (RSC): Less JavaScript, More Speed

React Server Components allow you to fetch data and render UI on the server without sending any unnecessary JavaScript code to the client. They are server-only by default, which improves performance dramatically:

// Server Component (default in `app/`)
export default async function ProductList() {
  const products = await fetchProducts();
  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

✅ Benefits:

• 30–50% smaller JS bundles

• No hydration costs

• Co-locates data fetching with UI

• Boosts Core Web Vitals (LCP, FID, etc.)

RSCs make your apps faster, more secure, and easier to scale.

Better hydration errors

Dev quality of life means a lot, and error messages’ usefulness plays a big part in that.

Next.js sets the bar higher: now making intelligent suggestions on possible ways to fix the error:

Before v15:

Now:

You know I have had a tough time in the past from these hydration errors, so this will certainly be an invaluable one for me.

New Caching Behavior

No more automatic caching

For all:

• fetch() requests

• Route handlers: GET, POST, etc.

• <Link> client-side navigation.

This change ensures that the data served is always fresh, reducing the chances of displaying outdated information to users. Next.js development company now has more control over caching behaviors, allowing for more precise optimization of application performance.

But if you still want to cache fetch():

Then you can cache the others with some next.config.js options.

Partial Prerendering (PPR)

PPR combines static and dynamic rendering on the same page

With PPR, you can wrap dynamic UI components in a Suspend boundary and opt in specific Layouts and Pages for partial prerendering. When a request comes in, Next.js will immediately serve a static HTML shell and then render and stream the dynamic parts in the same HTTP request.

All you need is this in next.config.js:

after

Next.js 15 gives you a clean way to separate essential from non-essential tasks from every server request:

• Essential: Auth checks, DB updates, etc.

• Non-essential: Logging, analytics, etc.

Start using it now with experimental.after:

Stable App Router with Layouts and Nested Routing

Introduced in v13 and now fully stable, the /app directory in Next.js 15 gives you modular routing with nested layouts, co-located data fetching, and component-based architecture.

📁 Folder structure:

app/
  layout.tsx
  page.tsx
  dashboard/
    layout.tsx
    page.tsx

🎯 Why it matters:

• Improved scalability for large apps

• Built-in support for error boundaries and loading states

• Cleaner structure that mirrors component trees

Ideal for: scalable dashboard, admin panels, and modular websites.

Smarter <Image /> Component

The <Image /> component in Next.js 15 is now:

• Faster

• Lighter

• Easier to use

Enhancements:

• Native loading="lazy"

• Blur/SVG placeholders

• Better AVIF/WebP support

<Image
  src="/banner.jpg"
  alt="Banner"
  width={800}
  height={400}
  placeholder="blur"
/>

✅ Benefits:

• Improves LCP and CLS

• No need for 3rd-party CDNs

• Works out of the box

Edge Middleware: Fast, Personalized Routing

Edge Middleware runs before a page is rendered and allows you to:

• Redirect by location or cookies

• Block bots

• Inject A/B testing logic

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

export function middleware(req) {
  const country = req.geo?.country;
  if (country === 'FR') {
    return NextResponse.redirect(new URL('/fr', req.url));
  }
  return NextResponse.next();
}

✅ Benefits:

• Personalization without latency

• Logic at the CDN edge

• Great for internationalization and auth flows

useLinkStatus

The useLinkStatus hook was introduced in Next.js v15.3.0. It tracks the pending state in the Next.js Link component.

You can use it to provide inline visual feedback to the user, such as displaying spinners or text effects, while navigating to the new route.

Key Features:

• You can only use the useLinkStatus hook inside the Next.js Link Component.

• Make sure to set the prefetch={false} in the Next.js Link component to use the useLinkStatus hook in your project.

• useLinkStatus hook is used to show the loading state during the navigation transitions.

• The useLinkStatus must be used within a descendant of a Link component.

• The useLinkStatus hook returns a pending boolean value

• The useLinkStatus helps improve the user experience on slow networks

We use the useLinkStatus hook for:

• The useLinkStatus hook is useful when prefetching (prefetch=false) is disabled in the Next.js Link component.

• With the useLinkStatus hook, you want to show inline visual feedback during navigation

How does the useLinkStatus hook work?

First, we create a loading indicator when we click on the link (navigation element) component. You can see the loading indicator in the link component.

// components/loading-indicator.tsx

"use client";

import { Loader2Icon } from "lucide-react";
import { useLinkStatus } from "next/link";

export default function LoadingIndicator() {
  const { pending } = useLinkStatus();
  return pending ? <Loader2Icon className="animate-spin" /> : null;
}

Use the LoadingIndicator component inside the Link component. When the user clicks on the navigation, you will see the loading indicator.

<Link
  href="/"
  className="hover:underline hover:underline-offset-2"
  prefetch={false}
>
  <Button className="rounded" size="lg"> 
    <HomeIcon className="mr-2 h-4 w-4" /> {/* show icon */}
    <LoadingIndicator /> {/* Show the indicator */}
    Home
  </Button>
</Link>

After combining the LoadingIndicator and Link components, your header component code looks like this.

// components/Header.tsx

"use client";

import Link from "next/link";
import LoadingIndicator from "./loading-indicator";
import { CircleUserRound, HomeIcon, NotebookPen } from "lucide-react";
import { Button } from "@/components/ui/button";

export function Header() {
  return (
    <header className="container flex justify-center items-center p-4">
      <div className="max-w-2xl flex gap-5 mx-auto">
        <Link
          href="/"
          className="hover:underline hover:underline-offset-2"
          prefetch={false}
        >
          <Button className="rounded" size="lg">
            <HomeIcon className="mr-2 h-4 w-4" />
            <LoadingIndicator />
            Home
          </Button>
        </Link>
        <Link
          href="/posts"
          className="hover:underline hover:underline-offset-2"
          prefetch={false}
        >
          <Button className="rounded" size="lg">
            <NotebookPen className="mr-2 h-4 w-4" />
            <LoadingIndicator />
            Posts
          </Button>
        </Link>
        <Link
          href="/about"
          className="hover:underline hover:underline-offset-2"
          prefetch={false}
        >
          <Button className="rounded" size="lg">
            <CircleUserRound className="mr-2 h-4 w-4" />
            <LoadingIndicator />
            About
          </Button>
        </Link>
      </div>
    </header>
  );
}

Finally, use the header component in the layout.tsx file.

// app/layout.tsx 

import "./globals.css";
import { Header } from "@/components/Header";

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html suppressHydrationWarning={true} lang="en">
      <body>
        <Header />
        {children}
      </body>
    </html>
  );
}

Next 14

Next 14 was released on October 26, 2023, and during the Next.js Conf, Guillermo Rauch, the CEO, talked about the new features. One of the new features, termed “Partial Prerendering“, was introduced in the preview with the goal of providing both quick initial and dynamic visuals without sacrificing the developer experience.

Next.js 14 brings notable improvements to its TuporPack, the engine responsible for efficient compilation, now it is now faster. Furthermore, the stabilization of Server Actions and partial prerendering results in a better experience and better websites.

Partial Pre-rendering

Partial prerendering is a technique that enhances the performance and user experience of dynamic web pages by extracting the static elements, such as logos, icons, page navigation, and fallbacks of dynamic slots. These elements are used to create a static shell, which can be delivered to users without delay. Meanwhile, the server continues to load the dynamic content in the background and displays it progressively when ready. With the ongoing debate between SSR and SSG, Next.js has decided to bring you the benefits of both worlds.

Here is the app/CatFacts.tsx file, which includes a component that interacts with a public API and showcases captivating cat facts from its response:

async function getData() {
  await new Promise(resolve => setTimeout(resolve, 1000));

  // call public API to retrieve cat facts and ensure cache is disabled
  const res = await fetch('https://cat-fact.herokuapp.com/facts/', { cache: 'no-store' });

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

export default async function CatFacts() {
  // call API inside the React component
  const data = await getData();

  return (
    <ul className="list-disc">
      {data.map(({ text, _id }: { text: string; _id: string }) => (
        <li key={_id}>{text}</li>
      ))}
    </ul>
  );
}

Here is the fallback display of the CatFacts component before the page is rendered, available in the app/CatFactsSkeleton.tsx file.

export default function CatFactsSkeleton() {
  return <p>Loading Cat Facts...</p>
}

Here is the modified app/page.tsx file, which displays the CatFacts component, along with its fallback UI.

import { Suspense } from 'react';
import CatFacts from './CatFacts';
import CatFactsSkeleton from './CatFactsSkeleton';

export default async function Home() {
  return (
    <main className="flex items-center p-24">
      <Suspense fallback={<CatFactsSkeleton />}>
        <CatFacts />
      </Suspense>
    </main>
  );
}

Build the production version of the app:

% yarn build
yarn run v1.22.10
warning ../package.json: No license field
$ next build
   ▲ Next.js 14.1.1-canary.17

   Creating an optimized production build ...
 ✓ Compiled successfully
 ✓ Linting and checking validity of types    
 ✓ Collecting page data    
 ✓ Generating static pages (5/5) 
 ✓ Collecting build traces    
 ✓ Finalizing page optimization    

Route (app)                              Size     First Load JS
┌ λ /                                    136 B          85.1 kB
└ ○ /_not-found                          885 B          85.9 kB
+ First Load JS shared by all            85 kB
  ├ chunks/54-42de27d3a1832522.js        29.8 kB
  ├ chunks/fd9d1056-9e0d44545602dadc.js  53.4 kB
  └ other shared chunks (total)          1.86 kB


○  (Static)   prerendered as static content
λ  (Dynamic)  server-rendered on demand using Node.js

✨  Done in 13.16s.
jenniferfu@jenniferfu my-next-app % yarn start
yarn run v1.22.10
warning ../package.json: No license field
$ next start
   ▲ Next.js 14.1.1-canary.17
   - Local:        http://localhost:3000

 ✓ Ready in 394ms

Execute the command yarn start to start the production server. Instantly, the fallback UI appears, followed by the CatFacts component once it is rendered.

Generate a Lighthouse report to analyze and audit the web page,and it shows a flawless performance score:

Turbo Mode

Turbopack is an innovative bundler specifically designed for JavaScript and TypeScript, developed in Rust by the creators of Webpack and Next.js. It serves as a compelling alternative to Webpack, offering substantial improvements in cold start and Hot Module Replacement (HMR) performance.

The exceptional performance of Turbopack can be attributed to two primary factors. First, it leverages highly optimized machine code to ensure efficient execution. Second, it incorporates a sophisticated low-level incremental computation engine that enables caching at the granularity of individual functions. As a result, once Turbopack completes a task, it never needs to repeat it. With Turbopack, we can significantly enhance the speed of an application’s startup and seamlessly handle module updates during development.

The following execution demonstrates that a cold start of the out-of-box application typically takes 1886 milliseconds without Turbopack:

% yarn dev  
yarn run v1.22.10
warning ../package.json: No license field
$ next dev
   ▲ Next.js 14.1.0
   - Local:        http://localhost:3000

 ✓ Ready in 1886ms

The following execution shows that the cold start can be reduced to 915ms with Turbopack:

% yarn dev --turbo
yarn run v1.22.10
warning ../package.json: No license field
$ next dev --turbo
   ▲ Next.js 14.1.0 (turbo)
   - Local:        http://localhost:3000

 ✓ Ready in 915ms

The performance enhancement reaches a significant 51.5%, nearly matching the official benchmark achieved with Turbopack:

• Up to 53.3% faster local server startup

• Up to 94.7% faster code updates with Fast Refresh

Turpoback has successfully completed over 5000 integration tests for App and Pages Router, accounting for 92.6% of the total tests. Once it achieves 100% pass rates, Turpopack will be considered stable and will be released in an upcoming minor release.

Stable Server Actions

Server Actions, also known as Server Side Rendering (SSR) functions, were introduced in Next.js 13 but they had some bugs and stability issues. In Next.js 14, Server Actions have reached production stability.

Developers can now define reusable server-side logic directly in their React components. This provides a seamless way to handle data fetching, API requests, and other server-side tasks without having to create separate API route files. It’s a game-changer for the developer experience. The stability improvements in Next.js 14 make it ready for production use cases. Error handling is also improved with consistent error messages.

// app/page.tsx

export default function Page() {
  async function create(formData: FormData) {
    'use server';
    await db.form.insertOne({ formData });
  }
  return (
    <form action={create}>
      <input type="text" name="name" />
      <button type="submit">Submit</button>
    </form>
  );
}

App Router, Data Fetching & Streaming

Next.js, powered by React Server Components, revolutionizes web development by providing unparalleled features such as shared layouts, nested routing, loading states, error handling, and a plethora of other capabilities. To bring this visionary concept to life, Next.js relies on three essential parts:

• The App Router

• Data Fetching System

• Streaming Architecture

The App Router

The App Router is a built-in router system that defines and handles routes in a Next.js application. It is responsible for mapping URLs to specific pages or components in the application. The App Router enhances the overall user experience. Its introduction in Next.js 13.4 firmly established its credibility, earning it recommendations ever since.

The App Router, located in the app directory, utilizes a folder structure that mirrors the segments of a URL path for seamless routing. It accommodates nested routes by organizing folders within one another. Furthermore, apart from designated files, we can conveniently place our own files (such as components, styles, tests, etc.) within the app directory’s folders.

https://medium.com/render-beyond/mastering-next-js-c7cba322a103

Streaming Architecture

Streaming architecture allows for incremental rendering and delivering components to the client as soon as they are ready. It provides faster page loading times by breaking down the rendering process into smaller chunks and streaming them to the client progressively. With streaming architecture, Next.js takes advantage of the streaming capabilities of Node.js and the HTTP/2 protocol to send the rendered content to the client in chunks, allowing the user to see and interact with the page while it is fetching data.

Data Fetching System

Next.js 14 introduces an improved data fetching system, aimed at enhancing the developer experience when working with data mutations. This system eliminates the need for manually creating an API route. Rather than creating an additional file, developers can simply define a server-side function in the component file and call it directly from a React component. This update effectively simplifies the data fetching workflow and allows for more efficient development.

Below is the modified app/page.tsx file that defines the server-side function getData, which fetches cat facts from a public API https://cat-fact.herokuapp.com/facts/. The Home component calls getData directly without writing an extra API route.

async function getData() {
  // call the public API to fetch cat facts
  const res = await fetch('https://cat-fact.herokuapp.com/facts/');

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

export default async function Home() {
  // call API inside the React component
  const data = await getData();

  return (
    <main className="flex items-center p-24">
      <ul className="list-disc">
        {data.map(({ text, _id }: { text: string; _id: string }) => (
          <li key={_id}>{text}</li>
        ))}
      </ul>
    </main>
  );
}

Execute the command yarn dev --turbo, and we see cat facts at http://localhost:3000.

What if there is an error in retrieving data?

Change the fetch URL to https://cat-fact.herokuapp_error.com/facts/, and we see the following error in the browser:

Unhandled Runtime Error
Error: Failed to fetch data

Call Stack
getData
/Users/jenniferfu/my-next-app/.next/server/chunks/[root of the server]__9d686c._.js (87:15)
process.processTicksAndRejections
node:internal/process/task_queues (95:5)
async Home
/Users/jenniferfu/my-next-app/.next/server/chunks/[root of the server]__9d686c._.js (92:18)

The data fetching system not only retrieves data but also incorporates caching and invalidation capabilities. Let’s provide examples illustrating the functioning of data caching.

1. Caches by default

Next.js includes a convenient built-in data cache that stores the results of data fetched from incoming server requests and deployments. By default, a fetch result is stored in the data cache on the server to improve performance and prevent unnecessary re-fetching of data.

// 'force-cache' is the default, and can be omitted
fetch('https://...', { cache: 'force-cache' })

In the following app/page.tsx file, we have used the public API http://www.randomnumberapi.com/api/v1.0/random to generate a unique random number each time it is called. In addition, we have implemented a component to combine the results of two API calls.

async function getData() {
  // call the public API to fetch a random number
  const res = await fetch('http://www.randomnumberapi.com/api/v1.0/random');

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

export default async function Home() {
  // call API twice inside the React component
  const data = await getData();
  const data2 = await getData();

  return (
    <main className="flex items-center p-24">
      <ul className="list-disc">
        {[...data, ...data2].map(((value: number, id: number) => (
          <li key={id}>{value}</li>
        )))}
      </ul>
    </main>
  );
}

When executing the command yarn dev --turbo, it appears that the random number generated remains the same with each call. Additionally, the data persists even when the browser is refreshed, which may not be the desired behavior.

2. Disabling caching

We have the option of 'no-store' to disable caching.

// Opt out of caching for an individual fetch request
fetch('https://...', { cache: 'no-store' })

Here is the modified app/page.tsx file:

async function getData() {
  // call the public API to retrieve a random number and ensure cache is disabled
  const res = await fetch('http://www.randomnumberapi.com/api/v1.0/random', { cache: 'no-store' });

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

export default async function Home() {
  // call API twice inside the React component
  const data = await getData();
  const data2 = await getData();

  return (
    <main className="flex items-center p-24">
      <ul className="list-disc">
        {[...data, ...data2].map(((value: number, id: number) => (
          <li key={id}>{value}</li>
        )))}
      </ul>
    </main>
  );
}

When executing the command yarn dev --turbo, we observe that the random number changes with each call.

Alternatively, we can opt out of caching for a specific route segment, using the route segment config options.

export const dynamic = 'force-dynamic'; // disable caching

async function getData() {
  // call public API to fetch a random number
  const res = await fetch('http://www.randomnumberapi.com/api/v1.0/random');

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

3. Time-based revalidation

We can also implement time-based revalidation to automatically fetch data after a specified interval. This approach proves beneficial for data that undergoes infrequent changes, where maintaining absolute real-time freshness is not as crucial.

Here is the modified app/page.tsx file:

async function getData() {
  // call the public API to fetch a random number, and ensure its revalidation after one second
  const res = await fetch('http://www.randomnumberapi.com/api/v1.0/random', { next: { revalidate: 1 } });

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

export default async function Home() {
  // call API twice inside the React component
  const data = await getData();
  const data2 = await getData();

  return (
    <main className="flex items-center p-24">
      <ul className="list-disc">
        {[...data, ...data2].map(((value: number, id: number) => (
          <li key={id}>{value}</li>
        )))}
      </ul>
    </main>
  );
}

To confirm, run the command yarn dev --turbo and observe that the random number remains constant for sequential calls made within a 1-second timeframe.

However, the random numbers will change after a second by simply refreshing the browser.

4. Revalidating tags

The revalidateTag API provides a convenient way to instantly invalidate cached data for a specific cache tag. Its tag parameter is expected to be a string that consists of 256 characters or less.

revalidateTag(tag: string): void;

Tags is an array of strings defined in the fetch request:

// define a list of tags
fetch(url, { next: { tags: ['tag1', 'tag2', ...] } });

Below is the modified app/page.tsx file, where the fetch request is tagged as 'number', and the cache is cleared after each fetch.

import { revalidateTag } from 'next/cache';

async function getData() {
  // call the public API to fetch a random number, and label the response with the tag 'number'
  const res = await fetch('http://www.randomnumberapi.com/api/v1.0/random', { next: { tags: ['number'] } });

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

export default async function Home() {
  // call API inside the React component
  const data = await getData();
  revalidateTag('number'); // revalidate the data cache
  const data2 = await getData();
  revalidateTag('number'); // revalidate the data cache

  return (
    <main className="flex items-center p-24">
      <ul className="list-disc">
        {[...data, ...data2].map(((value: number, id: number) => (
          <li key={id}>{value}</li>
        )))}
      </ul>
    </main>
  );
}

When executing the command yarn dev --turbo, we observe that the random number changes with every call.

5. Revalidating path

Alternatively, the revalidatePath function can also be utilized to manually refresh cached data for a specific path.

revalidatePath(path: string, type?: 'page' | 'layout'): void;

• path: It is either a string representing the filesystem path associated with the data to revalidate (for example, /product/[slug]/page), or the literal route segment (for example, /product/123). It must be less than 1024 characters.

• type (optional): It is a string of 'page' or 'layout' to specify the type of path to revalidate. If path contains a dynamic segment (for example, /product/[slug]/page), this parameter is required.

Below is the modified app/page.tsx file, where the cache of the data path / is cleared after each fetch.

import { revalidatePath } from 'next/cache';

async function getData() {
  // call the public API to fetch a random number
  const res = await fetch('http://www.randomnumberapi.com/api/v1.0/random');

  if (!res.ok) {
    throw new Error('Failed to fetch data');
  }

  return res.json();
}

export default async function Home() {
  const data = await getData();
  revalidatePath('/'); // revalidate the data path /
  const data2 = await getData();
  revalidatePath('/'); // revalidate the data path /

  return (
    <main className="flex items-center p-24">
      <ul className="list-disc">
        {[...data, ...data2].map(((value: number, id: number) => (
          <li key={id}>{value}</li>
        )))}
      </ul>
    </main>
  );
}

When executing the command yarn dev --turbo, we observe that the random number changes with every call.

6. Stable APIs

Server actions are deeply integrated into the entire App Router model. Here is the summary of the server API calls:

• Revalidate cached data with revalidatePath() or revalidateTag()

• Redirect to different routes through redirect()

• Set and read cookies through cookies()

• Handle optimistic UI updates with useOptimistic()

• Catch and display errors from the server with useFormState()

• Display loading states on the client with useFormStatus()

Metadata Improvements

Before your page content can be streamed from the server, there is important metadata about the viewport, color scheme, and theme that needs to be sent to the browser first.

Ensuring these meta tags are sent with the initial page content helps a smooth experience, preventing the page from flickering by changing the theme color or shifting layout due to viewport changes.

In Next.js 14, decoupled blocking and non-blocking metadata. Only a small subset of metadata options are blocking, and Next.js wants to make sure non-blocking metadata will not prevent a partially pre-rendered page from serving the static shell.

The following metadata options are now deprecated and will be removed from metadata in a future major version:

• viewport: Sets the initial zoom and other properties of the viewport

• colorScheme: Sets the support modes (light/dark) for the viewport

• themeColor: Sets the color the chrome around the viewport should render with

Image Optimization and Image Component

Next.js 14 introduces an enhanced and flexible image optimization feature, streamlining the process of optimizing images automatically. Here’s a brief overview of how Next.js facilitates image optimization:

1. Prioritizing Image Loading

Next.js intelligently prioritizes image loading. Images within the viewport are loaded first, providing a faster initial page load, and images below are loaded asynchronously as the user scrolls down.

2. Dynamic Sizing and Format Selection

The Image component in Next.js dynamically selects the right size and format based on the user’s bandwidth and device resources. This ensures that users receive appropriately sized and optimized images.

3. Responsive Image Resizing

Next.js simplifies responsive image handling by automatically resizing images as needed. This responsive design approach ensures that images adapt to various screen sizes, further enhancing the overall user experience.

4. Support for Next-Gen Formats (WebP):

The image optimization in Next.js extends to supporting next-generation image formats like WebP. This format, known for its superior compression and quality, is automatically utilized by the Image component when applicable.

5. Preventing Cumulative Layout Shifts:

To enhance visual stability and prevent layout shifts, Next.js incorporates placeholders for images. These placeholders serve as temporary elements until the actual images are fully loaded, avoiding disruptions in the layout.

Additionally, Next.js 14 enhances performance by efficiently handling font downloads. The framework optimizes the download process for fonts from sources such as Next/font/google.

Automatic code splitting

Automatic code splitting in Next.js 14 is a powerful technique that significantly contributes to optimizing web performance. As discussed in the Calibre blog post, dynamic imports, also known as code-splitting, play a key role in this process.

Code-splitting results in breaking JS bundles into smaller, more manageable chunks. Users only download what’s necessary, leading to a more efficient use of bandwidth. With less JS, the performance on slower devices sees a notable improvement.

Another insightful article on Builder.io expands on the two methods of code-splitting in Next.js:

Route-based splitting: By default, Next.js splits JavaScript into manageable chunks for each route. As users interact with different UI elements, the associated code chunks are sent, reducing the amount of code to be parsed and compiled at once.

Component-based splitting: Developers can optimize even further on a component level. Large components can be split into separate chunks, allowing non-critical components or those rendering only on specific UI interactions to be lazily loaded as needed.

These approaches collectively contribute to a more efficient, faster, and user-friendly web application experience, aligning with the continuous efforts to enhance performance in Next.js 14.

https://medium.com/render-beyond/mastering-next-js-c7cba322a103

https://medium.com/@sassenthusiast/my-epiphany-with-next-js-14s-server-components-08f69a2c1414

Next.js 13

The Vercel team posted a major announcement on their blog about the release of Next.js 13.4. To provide more context about why this is such an important release, we need to understand how the Vercel team handles releases to the public. Next.js 13 introduced so many new features, but most of them have remained in the alpha & beta versions, even though they were included in the major release.

So despite the fact that Next.js dropped some major new upgrades in Version 13 last October, the features have not quite been ready for prime time. Those changes in Next.js 13.4! The new 13.4 release finally provides a stable release of one of the most important new features: the App Router.

In this section, we will dive into some of the new features and improvements that come with this release. From the first stable release of the new app directory and app router to the latest advancements in Turpoback, there is a lot to be excited about. Let’s get started.

The New App Router

As mentioned, Next.js 13.4 is the first release that takes the new app directory and app router features out of beta!

As someone who has been playing with these features in sample projects, I can tell you that I have been getting antsy waiting to use them in production because they make the development experience in Next that much better.

Also, perhaps symbolic of the importance of this release, the Next.js document site has a major update to make the App Router the default! You can now toggle the docs between the new app Router and the previous Page Router.

Below, we will do a quick recap of the app router by diving into some of the main features.

Routing in the app directory

Routing in the new app directory is as simple as adding the page.tsx file that exports a React function component. The routing of the application is defined by the hierarchy of your folders within the app directory. For example, creating a page at the / route is as easy as adding a file page.tsx file at the root of the app directory.

.
└── app/
    └── page.tsx

// app/page.tsx
export default function Page() {
  return <SomeJsx />
}

Next, let’s show how we can create more complex application routes using the new app router:

.
└── app/
    ├── page.tsx
    ├── about/
    │   ├── page.tsx
    │   └── layout.tsx
    └── articles/
        └── article/
            └── [id]/
                ├── page.tsx
                ├── layout.tsx
                └── components/
                    ├── BlogArticle.tsx
                    └── Author.tsx

As you can see above, we are able to create a simple route such as /about, as well as create more complex routes like /articles/article/12345 using Next.js’ dynamic routes.

With the new App Router, our pages can make use of React Server Components, which allows us to simplify data fetching using the familiar async/await syntax.

// app/page.tsx
export default async function Page() {
  const res = await fetch('https://api.example.com/...');
  const data = res.json();
  return '...';
}

In Next.js 13, files are server components by default. You can opt into client components by including the 'use client' directive at the top of your module.

'use client'
export default function ClientComponent({ id }: ArticleProps) {
  useEffect(() => { //... }, [])
  return //...
}

Also, notice in our sample file tree above, we added components to our blog article folder. This was difficult in previous versions of Next.js because all files within the page directory were considered pages. Next.js 13 makes this a nicer experience by enforcing special file names for layout, page, template, etc.

Route segment configuration

Our pages can also export route segments that allow us to control how the pages render. One common practice in Next.js is to statically generate pages. We run into an issue when we use dynamic params, though. How would Next.js know what pages to statically generate? We can make use of generateStaticParams to solve this.

In the example below, we export an async function called generateStaticParams that loads all of our blog articles and returns an array of objects with a property that matches the name of our dynamic route segment, in this case id. Next.js will use this to statically generate pages for each of our blog articles.

// app/articles/article/[id]/page.tsx
type ArticleProps = Pick<Article, 'id'>

export default async function Page({ id }: ArticleProps) {
  const article = await(await fetchArticleById(id)).json();
  return <BlogArticle article={article} />
}

export async function generateStaticParams(): ArticleProps[] {
  const articles = await(await fetchArticles()).json();
  return articles.map(article => ({ id: article.id }))
}

Next.js 13 gives us several route segment configuration options to control how Next.js renders the page. Aside from generateStaticParams, the most commonly used route segment configuration that I’ve been using is revalidate. When combined with Static Site Generation (SSG), revalidate allows you to control how of the page will get regenerated.

Building on our previous example, we can set revalidate to 60 seconds to rebuild the page every 60 seconds. Note that it’s a bit more nuanced than that, so make sure to read up on ISR on the Next.js documentation site.

// app/articles/article/page.tsx
type ArticleProps = Pick<Article, 'id'>

export default async function Page({ id }: ArticleProps) {
  const article = await(await fetchArticleById(id)).json();
  return <BlogArticle article={article} />
}

export async function generateStaticParams(): ArticleProps[] {
  const articles = await(await fetchArticles()).json();
  return articles.map(article => ({ id: article.id }))
}

export const revalidate = 60

We can tell Next.js not to render pages for IDs that are not returned in generateStaticParams by making use of the dynamicParams route segment configuration.

export dynamicParams = false

Finally, we can force the page to generate statically or dynamically, depending on our use case. For example, if we have a page that is making use of query params, we may want it to be dynamically server rendered when the page is requested using the dynamic route segment.

export dynamic = 'force-dynamic'
// or: 'auto' | 'force-dynamic' | 'error' | 'force-static'

Layouts and Templates

Along with pages, Next.js 13 also introduced special files for layouts and templates. In the example above, you may have noticed that we include several layout.tsx files at the various levels of the folder hierarchy. We created a root-level layout.tsx, which is a typical practice in Next.js 13.

Within the root layout, we can create the HTML document, add scripts and other content to the head, provide semantic structure, and wrap the app in providers. We no longer have to make use of the special <Head /> and <Script /> components from previous versions of Next. We can also add metadata here, but Next.js 13.2 introduced a new dynamic Metadata API for this that we will cover in another article.

Note that layouts and pages should typically be server components, so you should avoid forcing them to be client components by adding hooks or other client-only functionality.

// app/layout.tsx
export default function RootLayout({ children }) {
  return (
    <html lang="en">
      <head>
        <script>//...</script>
      </head>
      <body>
        <main>
           <AppProvider>{children}</AppProvider>
        </main>      
      </body>
    </html>
  );
}

// app/page.tsx
export default function Page() {
  return //...;
}

Layout files can be added at each level of the app directory’s hierarchy to apply more specific layouts to different parts of the application. For example, let’s say that we want to add a specific AppWrapper surrounding our blog articles. We can add a new layout.tsx file to the /app/articles/article/[id] directory next to the page.tsx file.

// app/articles/article/[id]/layout.tsx
export default function RootLayout({ children }) {
  return (
    <AppWrapper>{children}</AppWrapper>
  );
}

Similar to layouts, templates allow you to create a shared structure. We will not go into them deeply here, so I suggest you read up on them on the Next.js documentation website.

Automatic Code Splitting

Next.js 13.4 also makes it easier than ever to code split and dynamically load content. In previous versions of Next.js, you had to make sense of next/dynamic. With Next.js 13, the entire application can opt into code splitting and dynamic loading by making use of Suspense. In fact, you can code split with a simple conditional within a client component. Check out the example below from the Next.js blog, which returns completely different bundles depending on whether the user is logged in or not.

// app/layout.tsx
import { getUser } from './auth';
import { Dashboard, Landing } from './components';

export default async function Layout() {
  const isLoggedIn = await getUser();
  return isLoggedIn ? <Dashboard /> : <Landing />;
}

Route Groups

Route Groups are a nifty feature introduced in Next.js 13, especially when your app requires multiple root layouts. Next.js 13.3 removed the deprecated head.js special file and replaced it with the generateMetadata API. One downside of this approach is that it made it difficult to add scripts and other things to the <head /> when you had pages that had different content.

For example, let’s say part of your app has navigation that is loaded from an API. The API returns its content for its script dependencies. Route Groups give a solution to this problem by allowing you to split parts of your apps into different folders that have their own root layouts.

.
├── (navigation)/
│   ├── dashboard/
│   │   └── page.tsx
│   └── layout.tsx
└── (navless)/
    ├── auth/
    │   └── page.tsx
    └── layout.tsx

In the example above, the dashboard page has its own root layout that can include the additional head content loaded from your API:

import { PropsWithChildren } from 'react'

export default async function Layout({ children }: PropsWithChildren) {
  const { head, header, footer } = await fetchNavigationMarkup()

  return (
    <html>
      <head>
        {head}
      </head>
      <body>
        {header}
        {children}
        {footer}
      </body>
    </html>
  )
}

React Server Components (RSC)

The new Next.js 13 App Router was built in close partnership with React 18. One of the major new features of React 18 is React Server Components (RSC). In order to start working in Next.js 13, you need to wrap your head around this new paradigm.

In the past, React was primarily a client-side UI rendering library. With the addition of RSCs, the intention is to render as much of your application as possible on the server at build time (we will go into the different rendering modes more below)

When a route is loaded with Next.js, the initial HTML is rendered on the server. This HTML is the progressively enhanced in the browser, allowing the client to take over the application and add interactivity, by asynchronously loading the Next.js and React client-side runtime.

From the React Essentials Section on the Next.js documentation site.

In React 18, two new directives, “use client“ and “use server“ were added in order to control where components are rendered at the file level. These new directives are used in Next.js 13 to control whether the bundle code is included in the client-side bundle or not.

With the “use server“ directive, we can indicate that a component does not need to be included in the bundle that the client loads. The component will be rendered on the server at build or run time.

As you can see in the code above, we can also make use of async await in Server Components, which makes them great for loading data.

// ServerComponent.ts
"use server"

export default async function ServerComponent() {
  const data = await fetchData()

  return //...
}

If a component needs to make use of React Hooks, such as useEffect, or it needs to access browser APIs, we can use the “use client“ directive in order to indicate that the component should be included in the client bundle.

// ClientComponent.tsx
// use client is needed here since we are using React hooks and accessing
// the localStorage browser API
"use client"
export default function ClientComponent() {
  const [todos, setTodos] = useState([])
  useEffect(() => {
    const cachedTodos = localStorage.get('todos')
    setTodos(todos)
  })

  return (
    <>
      {todos.map(todo => <Todo {...todo} />)}
    </>
  )
}

See the original React RFC where these directives were proposed for more information: https://github.com/reactjs/rfcs/pull/227

https://tushar-tmpatel.medium.com/what-is-server-components-vs-client-components-in-next-js-13-24a5e0113105

Server Components are the default in Next.js

In the world of Next.js 13, server components are now the default, which means that most of your components should not need a “use server“ or “use client“ directive.

The only time you need to use these directives is when you are creating a boundary component.

// page.tsx
// React Server Component, will not be included in the client 
export default function Page() {

  return (
    <Provider>
      <TodoList />
    </Provider>
  )
}

// TodoList.tsx
// use client is needed here since we are using React hooks
"use client"
export default function TodoList() {
  useEffect(() => {})

  return (
    <>
      {todos.map(todo => <Todo {...todo} />)}
    </>
  )
}

// TodoList.tsx
// No "use client" needed here, even though we are using hooks
// because this component is only ever rendered within another client component
export default function Todo() {
  useEffect(() => {})

  return (
    <>
      {todos.map(todo => <Todo {...todo} />)}
    </>
  )
}

Client Components are rendered on the server, too

When you use a “use client“ directive to make a client component, it doesn’t means that it only renders on the client side. In fact, most client components are rendered on the server when doing server-side rendering (SSR) or static site generation (SSG).

The only time a client component will not be rendered on the server is when you specifically instruct it not to. One way to do this is by making use of next/dynamic with the ssr: false option (note: Vercel recommends using React.lazy and Suspense directly instead of next/dynamic:)

import dynamic from 'next/dynamic';

const DynamicHeader = dynamic(() => import('../components/header'), {
  ssr: false,
});

This enables Next.js to be a truly hybrid framework and it promotes the goal of Next, which is to statically render as much content as possible and only include what’s needed by the client.

What this means is that you need to think about how a client component will be rendered on the server. A way to test this is to disable JavaScript in your browser and see how the page renders. What you should see is that the page renders in its entirety, but interactive elements are disabled.

You will want to make sure that no layout shift is introduced when the element becomes interactive, so make sure the component renders well before JavaScript is enabled, either by rendering the content by default or by making use of skeletons.

Choosing Rendering at Component Level

What is cool about this new approach is that you can you can interleave Server and Client Components in your application, and behind the scenes, React will seamlessly merge the work of both environments.

React can render on the client and the server, and you can choose the rendering environment at the component level!

In Next.js 13, all the components within the /app folder are server components by default. You will use the "use client" directive if you want to render Client Components.

In the example below, Counter is a Client Component, because it preserves local state and has event handlers for a button click. This component will have a "use client" directive placed on top of the component file, above the imports, to indicate that it is a Client Component.

Once "use client" is defined in a file, all other modules imported into it, including child components, are considered part of the client bundle.

Note: This additional step could be confusing for developers and is part of the learning curve that comes with Next.js 13.

'use client'

// Client Component, because it stores state and has the use client directive.

import { useState } from 'react'

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

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  )
}

Composing client and server components

Next.js 13 offers an enhanced level of flexibility when it comes to composing your components. Server components can also render other server components and client components. On the other hand, client components can render other client components and can only render server components if they are passed in as a prop. This layered composition model allows for a high degree of interoperability and code reusability.

For instance, the following is not allowed in React:

'use client';

// ❌ You cannot import a Server Component into a Client Component
import MyServerComponent from './MyServerComponent';

export default function ClientComponent() {
  return (
    <>
      <MyServerComponent />
    </>
  );
}

Instead, you can pass a Server Component as a child or a prop to a Client Component as a workaround, as shown below.

// ✅ You can pass a Server Component as a child or prop of a Client Component.
import ClientComponent from "./ClientComponent";
import ServerComponent from "./ServerComponent";

export default function Page() {
  return (
    <ClientComponent>
      <ServerComponent />
    </ClientComponent>
  );
}

'use client';

// ✅ You can pass a Server Component as a child or prop of a Client Component.
export default function ClientComponent({children}) {
  return (
    <>
      {children}
    </>
  );
}

I get that the paragraph above is kind of mind-numbing. Here’s a nice diagram that Vercel folks created to help you visualize this concept better.

Next.js 13 Rendering Modes

Next.js 13 introduces different render environments and modes, allowing you to choose the optimal rendering strategy for your app on a component-by-component basis.

Content is rendered in two distinct environments:

• Client side — Client Components are pre-rendered and cached on the server. JSON is generated for data used on client components and passed to React during Hydration.

• Server side —Content is rendered on the server by React, and static HTML is generated. React uses static HTML to hydrate in the browser, requiring no additional JavaScript on the client.

On the server, there are two different rendering modes that are used:

• Static — both client and server components are rendered as static HTML at build time. Static content can be revalidated, allowing it to be updated on a page-by-page basis in order to keep dynamic data up-to-date with its sources. Statically generated content is easily cacheable and leads to improved performance, user experience, and search engine optimization.

• Dynamic — both client and server components are rendered on the server when a request is made. The content is not cached.

Previous versions of Next.js had different terminology that it used for these concepts. I’m including them below and showing how they relate to the new Next.js 13 terminology.

• Static-site generation (SSG): Static rendering mode

• Incremental Static Regeneration (ISR): Static rendering mode with revalidation

• Server-side Rendering (SSR): Dynamic rendering mode

• Client-side Rendering (CSR): Client components

Make sure to check out the Next.js documentation site on the topic.

When to Use Client vs. Server Components?

You only need to mark components as “use client“ when they use client hooks such as useState or useEffect.

It’s best to leave components that do not depend on client hooks without the directive so that they can automatically be rendered as a Server Component when they aren’t imported by another Client Component.

This helps ensure the smallest amount of client-side JavaScript.

The goal is to ship the smallest amount of client-side JavaScript.

Use Client Components when:

• You use React hooks such as useState, useEffect, useReducer, etc*..*

• There is interactivity within the component, with event listeners such as onClick().

• There are custom hooks that depend on state or effects.

• Using React Class Components.

Use Server Components when:

• You fetch data from the server API.

• Sensitive information needs to be stored (tokens, API keys, etc.).

• You need to access backend resources directly.

• There are large dependencies.

Server Components Vs. SSR: What’s the Difference?

The main difference between Server Components and SSR lies in the ‘when’ and ‘what.

SSR happens at the time of each page request. The server fetches data, generates the HTML, and then sends this HTML to the client. This process repeats with every request. SSR is great for pages with data that changes frequently, and it’s a fantastic boon for SEO.

SSR is the rendering of an entire page (which is composed of several components) on the server; Server Component is executing an individual component on the server, generate a static HTML response, and send it to the client.

On the other hand, Server Components run once at build time. They execute on the server, generate a static HTML response, and send this to the client. This process doesn’t repeat with every request. As such, Server Components are best for parts of your application that don’t change frequently, and they help in significantly reducing the amount of JavaScript shipped to the client.

Streaming

Previously, the user might have had to wait for the complete page to generate. Now the server will transmit to the client small pieces of the UI as it is generated. It implies that the bigger piece won’t get in the way of the smaller ones. Of course, as of right now, just the app directory is supported for this feature, and it doesn’t seem that this will change.

This new feature won’t benefit individuals with a strong internet connection or speedy wifi as much as those with a weaker connection. There are more of them than you would have thought, in fact. It’s great that a faster site loading time will improve user experience.

Server Actions (Alpha)

Next.js 13.4 introduces Server Actions (currently in alpha), which brings a whole level of flexibility and power to your applications. Server Actions allow you to handle server-side logic, such as fetching data or interacting with APIs, directly in your application. This feature not only simplifies your application architecture but also enables you to create faster and more efficient applications.

For an in-depth look at Server Actions and how they are transforming the way we build applications, check out this article: Why Next.js Server Actions are Game-Changing.

Turbopack: Now in Beta and More Feature Complete

With the release of Next.js 13.4, Turbopack has moved into the beta phase, offering a more feature-complete and stable experience. Turbopack is Next.js’s new Rust-based bundle designed to speed up local iterations in development, and soon, production builds. Thanks to the community’s support in testing and reporting bugs, Turbopack has grown in adoption, paving the way for a significantly faster and more efficient development experience in the future.

Next.js 12

Next.js has announced at their Next.js conference that Next.js 12 is going to be one of the biggest releases ever. So in this section, let’s quickly look into what the new amazing features are that Next.js 12 has provided us with:

There are roughly 6 new features that Next.js 12 has brought out. Let’s look into all of them.

Faster Builds

The new Next.js 12 ships with a new Rust compiler. This compiler takes advantage of native compilation. This translates into a much faster build and faster refresh time.

How does that work? The compiler is built on top of SWC, which stands for Speedy Web Compiler. It does consume Typescript/JavaScript and emits JavaScript code that can be executed on old browsers. It’s a Babel replacement. It’s about 20x faster than Babel on a single thread and up to 70x on a four-core benchmark.

This Rust compiler is now enabled by default. The improvement of the Vercel.com build is about 50% faster. It went from 3 minutes 41 seconds down to 1 minute and 58 seconds.

It is still not perfect because it might lack some compatibility with popular libraries like styled-components or emotion but that support will happen soon.

You can also use it to minify files by simply enabling it in the config. Here’s the code:

// next.config.js
module.exports = {
  swcMinify: true
}

Middleware

This is one of the most exciting features. At the moment, we have to choose between CDN or Server Side Rendering for building faster apps. When we build a dynamic page that we want to cache, we might use the latter.

Vercel’s new Edge functions feature makes this possible. It gives the benefits of static caching with the power of dynamic execution. Now we can run dynamic functions aka middleware, right before our CDN requests complete. All that with no cold start.

The Cloudflare and Amazon infrastructure have also implemented a similar feature not long ago. It is called edge computing or Lamdba@Edge. What is special about the Next.js version? It’s easy and integrates within the framework.

How to use it? By just creating a _middleware function in our pages directory and deploying it. There, we can do dynamic checks right at the CDN level. These middleware functions can be scoped and composed.

# Execution order for middleware composition
- /pages
  index.tsx
  - /profile
    _middleware.ts # will run first
    profile.tsx
    - /settings
      _middleware.ts # will run second
      _settings.tsx

What does a _middleware.ts file look like? Let’s see that through an example where we create a dummy authentication middleware.

In the code above, we can check if the request contains a valid JWT and otherwise return an error response.

What are the most common use cases for using middleware?

• User Authentication

• Bot protection

• Redirects and rewrites

• Handling unsupported browsers

• Service-side analytics

• Advanced 18n routing

• Logging

URL Imports

The Next.js team has been working for a while to support ES modules. It was flagged as experimental in the previous version. In this new version, they are natively supported.

What does that mean? The URL imports can be built on top of those.

Why is this feature cool? We can now import directly tooling from the CDN without any extra builds or installs. We will be able to import those from the wire rather than having to build them locally.

You can now use cool CDN projects like Skypack in your Next.js app. It’s a package delivery network over CDN. It creates ready-for-production tools without the hassle of compiling and bundling them. It scans NPM and builds executable ES module packages that you can import from your browser.

How to enable this feature? The URL has to be specified in the next.config.js file. You need to only enable domains that you trust.

module.exports = {
  experimental: {
    urlImports: ['https://cdn.skypack.dev'],
  },
}

As you can see from the config, this URL import feature is still in the experimental phase.

What does the Next.js workflow look like?

• on next dev the will amend the download and add the file in a next.lock file

• on next build the engine will look up the generated next.lock file.

Let’s see a bit of code in action:

// next.config.js
module.exports = {
  reactStrictMode: true,
  experimental: {
    urlImports: ['https://cdn.skypack.dev'],
  },
}

// pages/index.js
import styles from '../styles/Home.module.css'
import confetti from 'https://cdn.skypack.dev/canvas-confetti'

export default function Home() {
  return (
    <div className={styles.container}>
      <main className={styles.main}>
        <h1 className={styles.title}>
          Welcome to <a href="https://nextjs.org">Next.js!</a>
        </h1>
        <button onClick={confetti}>
          Throw Confetti
        </button>
      </main>
    </div>
  )
}

Support for React 18 on the server-side

The React 18 version is coming soon, and after a boring release of React 17, it’s mainly focused on concurrency.

The Next.js framework is jumping early and anticipating some of React’s most-awaited features. Naturally, all these new features will also be under an experimental config flag.

HTML Server Side Streaming

One of the coolest React 18 features is the built-in support of server-side Suspend and streaming of HTML parts of your React application. You are no longer required to load all or nothing. You can progressively ship HTML to the browser.

The Next.js framework supports that and provides abstractions around all those mechanisms. For dynamically importing modules, you can use its next/dynamic utility.

React server-side components

The new React Server Component feature does simplify the SSR development and logic. They are always rendered on the server and streamed to the client. This reduces the need for handling different rendering scenarios. The usage of getServerSideProps and getStaticProps is not needed anymore. The shift the computation from the client to the server.

Those are big improvements; however, they still have some limitations:

• They are stateless.

• They can’t use lifecycle methods like useState or useEffect.

• They can’t make usage of browser-only APIs.

Usage

How do you opt in to all these new React 18 goodies?

1. First, you need to install React 18 Alpha using the following code:

npm install next@latest react@alpha react-dom@alpha

2. Enable the experimental concurrent features in Next.js configuration, as shown below:

// next.config.js
module.exports = {
  experimental: {
    concurrentFeatures: true,
    serverComponents: true,
  },
}

With that, you are good to go.

On-demand Incremental Static Regeneration (Stable)

How many times can you redeploy in a workday? On-demand Incremental Static Regeneration (ISR) allows you to update content on your site without the need to redeploy. This makes it easy to update your site immediately when your site changes in your headless CMS or commerce platform. This is one of the most requested features from the community, and we are excited that it’s now stable.

Incremental Static Regeneration (ISR) works for any providers supporting the Next.js Build API (next build). When deployed to Vercel, on-demand revalidation propagates globally in ~300ms when pushing pages to the edge.

Smaller Images Using Avif

The Built-in Image Optimization API now supports AVIF images, enabling 20% smaller images compared to WebP.

AVIF images can take longer to optimize compared to WebP, so we're making this feature opt-in using the new images.formats property in next.config.js:

module.exports = {  images: {    formats: ['image/avif', 'image/webp'],  },};

This list of formats is used to determine the optimized image format on demand using the request’s Accept header:

Since AVIF is first, it will be served if the browser supports AVIF. If not, WebP will be served if the browser supports WebP. If neither format is supported, the original image format will be served.

Output File Tracing

In Next.js 8, we introduced the target option. This allowed for outputting Next.js pages as standalone JavaScript bundles by bundling all dependencies using webpack during the build. We quickly realized this wasn't ideal and instead created @vercel/nft. @vercel/nft has been used for over 2 years on all deployments on the Vercel platform.

Now, we're bringing these improvements directly into the Next.js framework by default, for all deployment platforms, providing a significantly improved approach over the target option.

Next.js 12 automatically traces which files are needed by each page and API route using @vercel/nft, and outputs these trace results next to the next build output, allowing integrators to leverage the traces Next.js provides automatically.

These changes also optimize applications deployed using tools like Docker through next start. By leveraging @vercel/nft, we will be able to make the Next.js output standalone in the future. No dependencies will be required to be installed to run the application, massively reducing the Docker image size.

Bringing @vercel/nft into Next.js supersedes the target approach, making target deprecated in Next.js 12. Check out the documentation for more info.

Bot Aware ISR Fallback

Currently, Incremental Static Regeneration (ISR) with fallback: true renders a fallback state before rendering the page content on the first request to a page that was not generated yet. To block the page from loading (server-rendering), you would need to use fallback: block.

In Next.js 12, web crawlers will automatically server-render ISR pages using fallback: true, while still serving the previous behavior of the fallback state to non-crawler User-Agent. This prevents crawlers from indexing loading states.

References

https://medium.com/coding-beauty/the-new-next-js-15-changes-everything-cec14aaa50b3

https://medium.com/@mitali_shah/why-is-next-js-15-revolutionizing-web-app-development-8164875d6f0d

https://javascript.plainenglish.io/top-7-features-in-next-js-15-that-will-supercharge-your-web-apps-0c02bce2b51c

https://javascript.plainenglish.io/server-actions-streaming-and-more-the-full-power-of-next-js-15-bbfbe16cbecb

https://medium.com/@imvinojanv/next-js-14-arrives-turbocharging-react-development-with-new-features-and-enhanced-performance-e961ff122915

https://javascript.plainenglish.io/4-major-features-in-next-js-14-3e897f391068

https://focusreactive.com/breaking-down-next-js-14/

https://medium.com/@Apiumhub/whats-new-in-next-js-14-and-how-does-it-achieve-to-be-so-fast-apiumhub-faa6b512c153

https://blog.bitsrc.io/next-js-13-4-is-finally-here-and-its-awesome-e9f5b27bccda

https://levelup.gitconnected.com/a-complete-guide-to-the-routing-system-in-next-js-13-with-simple-explanations-and-code-examples-74dce5042f83

https://medium.com/better-programming/8-things-you-should-know-about-next-js-13-969291f168ec

https://adhithiravi.medium.com/the-yin-and-yang-of-next-js-13-understanding-server-components-and-server-side-rendering-6a9b774c3b06

https://adhithiravi.medium.com/what-are-server-components-and-client-components-in-react-18-and-next-js-13-6f869c0c66b0

https://medium.com/frontendweb/how-to-understand-and-use-the-uselinkstatus-hook-in-next-js-applications-7ddd5aad6924

https://medium.com/better-programming/5-new-killer-features-of-next-js-12-dfd1d766b539

https://medium.com/@badcaptain0001/next-js-16-is-here-a-major-step-forward-for-performance-dx-full-stack-architecture-77aa0bcb91f7

What is the JavaScript bundler anyway?

A tool that people struggle with for hours just to get a basic web app set up. A thing that you use when you want to bootstrap your React project? Something that your company uses, or that your colleagues/seniors have configured already? Which is apparently supposed to optimize your final JS build.

Whether you are starting your web development journey or have already used a bunch of bundlers before, you may have these questions at some point in time. I certainly did.

To answer the above question, a module bundler provides a method for arranging and merging multiple JavaScript files into a unified single file. Using a JavaScript bundler becomes necessary when your project outgrows a single file or when dealing with libraries with numerous dependencies. As a result, the end-user’s browser and client don’t have to fetch numerous files individually.

Why do we need a JavaScript bundler?

JavaScript bundlers are a tool that helps in optimizing the delivery of JavaScript files in web applications. The following are the key benefits of using a bundler.

• Merging, Splitting, and Post-processing on Modules: While working with vanilla JavaScript or any corresponding modern JavaScript framework, it’s better to split the code into multiple files for the development journey. The concept of JavaScript bundlers is a decade old now. A decade ago, for browsers to access a single file through HTTP1 protocol was a heavy operation. So, it’s better to combine all the code into one file and then make a single HTTP request. But most browsers have improved a lot since then and are now using the HTTP2 protocol for sending network requests that show no bottleneck in sending multiple requests to access files. Instead, we have started to first compile and then split the codebase to load the minimum required sources on the requested route through bundlers. We have also started to remove the unused code (tree sharking) and blank/while spaces among the combined files to minimize the requested resources (modification)

• Solving the problem of cyclic dependencies: Without bundlers, one needs to take care of the import order of the JavaScript files to avoid the “not defined“ errors. Check out this file. Developers need to take care of the import order of script tags by themselves, which is error-prone. Bundlers can traverse through all the required files and decide the loading order.

• Anchoring transpilation and pre-processing on modules: Nowadays, JavaScript has added some modern rules to improve the development journey. But modern browsers do not support these features yet, so one needs translators (which are generally called transpilers) to convert the modern JavaScript into the JavaScript that the browser can understand. Bundlers help in this process, where it first takes the help of the transpiler module to translate the files and then combine them for the browser to load directly.

Modern JavaScript bundlers can be imagined as compilers that convert all the development-friendly code into an optimized browser-readable format.

Behind the Scenes of Crafted Front-end Code Rendering in your User Browser

Ever wondered what happens behind the scenes when your code goes from your machine to the user’s browser? Well, let’s dive into it.

Meet our unsung hero: the bundler. It’s like the backstage manager, taking all your project files, doing some magic to optimize them, and then packing them up for a smooth delivery to web browsers. The result? A snappier and more responsive web app.

So, grab your coding beverage of choice, let’s break it down this journey step by step. We are about to uncover the nitty-gritty details of how your frontend code turns into that awesome experience

1. Input Files:

A bundler starts with a set of input files, which are typically your project’s source code and assets, such as JavaScript files, CSS files, images, and more.

2. Dependency Resolution:

The bundler analyzes your source code to identify dependencies. Dependencies are other files or modules that your code relies on, like importing JavaScript modules or CSS files.

3. Code Transformation

Before bundling, the bundler may apply transformations to your code. For example, it might transpile modern JavaScript (ES6+) into older versions for broader browser compatibility, or it might process CSS preprocessor syntax like SASS or LESS into standard CSS.

4. Bundling

The bundler combines all the input files, including their dependencies, into one or more modules. Each bundle is a single, optimized file containing the code and assets for your application.

5. Optimization

During bundling, the bundler performs various optimizations, such as removing whitespace and comments, minifying code (reducing variable names to shorter forms), and eliminating dead code (code that’s never used). Some bundlers support code splitting, which means breaking the bundled code into smaller parts or chunks. These chunks can be loaded on demand when needed, reducing initial loading times. Bundlers can also handle assets like images and fonts, optimizing and providing them as part of the bundle or as separate files.

6. Development Server (optional)

During development, bundlers often include a development server. This server serves your project locally, automatically rebuilds the bundle when you make a change, and may offer features like hot module replacement (HMR) for instant code updates without a full page refresh.

7. Output Files

The result of bundling is one or more output files, typically named something like “bundle.js“ for JavaScript or “bundle.css “ for CSS. These files are optimized and ready for deployment. Here’s a useful link to have hands-on knowledge of how to analyze your JavaScript bundle.

8. Deployment

The final bundled files, along with your HTML and other assets, are deployed to a web server or a hosting service to make your application accessible to everyone

9. Loading in the Browser

In the user’s browser, when they access your web application, the bundled JavaScript and CSS files are loaded, and the code is executed.

10. Rendering the Web Page

The bundled JavaScript code initializes your application, interacts with the DOM, and renders a web page according to your application’s logic and structure.

https://www.freecodecamp.org/news/javascript-es-modules-and-module-bundlers/

https://www.youtube.com/watch?v=MUSoj2JcD4A

https://www.youtube.com/watch?v=5IG4UmULyoA

Popular React Bundle Tools

Rollup vs. Parcel vs. Webpack: Which is the best bundle?

Recently, I was publishing a library to npm, and I thought of experimenting with the bundler. I was going to package my code. While Webpack has always been my standard choice, I decided to put it up against two other popular bundlers — Rollup and Parcel.

From those coming from a non-JavaScript background, a bundler is a tool that recursively follows all imports from the entry point of your app and bundles them up into a single file. Bundlers can also minify your files by removing unnecessary white spaces, new lines, comments, and block delimiters without affecting their functionality.

Let’s try to understand this through a simple code snippet:

var test = [];
for (var i = 0; i < 100; i++) {
  test[i] = i;
}

We just created an array called test and initialised its members up to 100. The minified version of this code will look somewhat like this:

for(var a=[i=0];++i<20;a[i]=i);

Fewer characters and lines. You might say the code isn’t readable, but who cares? You bundle your code once it’s ready, and minified code is easy to fetch and interpret for the browser.

It must be now easy for you to guess the importance of a bundler, right?

Suppose your code is not bundled and hosted as a package multiple times on a server. For the import of each of these files to make your code run, the browser has to send a separate HTTP request to the server. The efficiency of this transmission is directly proportional to the number and the size of the files being requested. In the case of large apps such as Facebook, this can lead to disastrous performance and UX.

However, the performance of the app substantially improves with a bundler on board, as now the browser only has to request a single file to display your app to the user. Moreover, fetching a minified file weighing a few KBs is faster than the actual file, which might run into MBs, resulting in improved load time in the app.

Why install bundlers when we can do it on our own?

Sure, you can, but when working with huge codebases, minifying an app manually isn’t a scalable solution. Let the bundler do it for you.

Making the right choice of a bundler from the many available can be life-changing for your app, depending on the use case. Coming back to the experiment I was talking about in the beginning. I thought of sharing with you my findings on how Webpack, Rollup, and Parcel fared on some important requirements a developer would have.

1. Configuration of the bundler

Parcel wins here because it doesn’t require a config file at all. Just install Parcel and run parcel build, and it will do everything for you out of the box.

Webpack and Rollup both require a config file specifying entry, output, loaders, plugins, transformations, etc. However, there’s a slight difference.

• Rollup has node polyfills for import/export, but Webpack doesn’t.

• Rollup has support for relative paths in config, but webpack doesn’t — which is why you use path.resolve or path.join

Webpack config can get complex, but it provides extensive support for third-party imports, images, CSS preprocessor, and whatnot.

I had a hard time using Rollup for bundling my app that used axios, a very commonly used library for making HTTP requests — not just axios, but for other third-party integrations too. I had to research a lot and try installing many Rollup plugins before attaining victory, at the cost of dropping some imports.

2. Dead code elimination

Dead code elimination, or Tree shaking, as it’s often called, is very important to achieve the optimum bundle size and hence app performance.

Parcel emerged as the winner here. Parcel supports tree shaking for both ES6 and CommonJS modules. This is revolutionary since most of the code in libraries on npm still uses CommonJS.

Most of the work Parcel does when tree shaking is also done in parallel through multicore processing using numerous worker processes, and is also cached on the file system. This means that it builds are still fast, and rebuilds are like blazing fast.

Roll comes second in the race. Right out of the box, it statically analyzes the code you are importing and will exclude anything that isn’t actually used. This saves you from writing more lines in your config file, adding extra dependencies, and bloating the size of your app.

Webpack requires some manual effort to enable tree-shaking:

• Use ES6 syntax (i.e. import and export).

• Set the SideEffects flag in your package.json.

• Include a minifier that supports dead code removal (eg: UglifyJSPlugin).

Rollup and Webpack have focused more on tree shaking for ES6 since it is much easier to statically analyze, but in order to truly make a big impact, we need to analyze CommonJS dependencies as well, for which they both require plugins to be imported.

However, given the fact that JavaScript is dynamic, almost every construct in the language can be altered at runtime in impossible to predict ways.

Practically, this means that an entity such as a class, which is imported as one reference, can be statically analyzed to remove members (both static and instance) that are not used. So, rather than relying on the bundler to do it for you, it will be a good practice to visualize your components before your code and analyze them afterwards to get the best results.

3. Code splitting

As your app grows, your bundle size will grow too, more so with third-party imports. The load time of your app is directly proportional to its bundle size.

Code splitting helps the browser lazy-load just the things that are needed to get the app running, dramatically improving the performance and UX.

Webpack emerges as the winner in this aspect, with minimal work and faster load time. It provides three approaches to enable code splitting available in Webpack.

• Define entry points - Manually split code using entry configuration.

• Use the commonsChunkPlugin to de-dupe and split chunks

• Dynamic imports - use inline function calls within modules

During code splitting by Rollup, your code splitting chunks themselves are standard ES modules that use the browser’s built-in loader without any additional overhead, while still getting the full benefit of Rollup’s tree-shaking feature.

Parcel supports zero-configuration code splitting. Here, code splitting is controlled by the use of the dynamic import() function syntax proposal, which works like a normal import statement or require function, but returns a Promise. This means that the module is loaded asynchronously.

It was tempting to favour Rollup and Parcel over Webpack for code splitting, but both of them have only recently introduced this feature, and some issues have also been reported. So, it’s safe to stick with the good old webpack.

One compelling fact I noticed was that for the same code with code splitting enabled, the build time was the least with webpack, followed by Rollup, and lastly, Parcel.

4. Live reload

During development, it’s great if your app gets updated with the fresh code that you write, instead of manually refreshing it to see the changes. A bundler with live reload capability does that refreshing for you.

Bundlers provide you with a runtime environment in addition to other utilities essential for debugging and development, in the form of a development server.

Parcel has been very thoughtful by having a development server built in, which will automatically rebuild your app as you change files. But there are issues associated with it when using HTTP logging, Hooks, and middleware.

When using Rollup, we need to install and configurerollup-plugin-serve, which will provide us with live reload functionality. However, it needs another plugin, rollup-plugin-livereload, to work. That means it’s not an independent plugin and comes with an extra dependency to run.

With Webpack, you just need to add one plugin, called webpack-dev-server, which provides a simple development server with live reload functionality turned on by default. What’s better? You can use Hooks to do something after the dev server is up and running, add middleware, and also specify the file to serve when we run the dev server. The customisability of Webpack trumps Rollup and Parcel.

5. Hot module replacement

Hot module replacement (HRM) improves the development experience by automatically updating modules in the browser at runtime without needing a whole page refresh. You can retain the application state as you make small changes in your code.

You might ask how HRM is different from live reload.

Well, live reloading reloads the entire app when a file changes. For example, if you were five levels deep into your app navigation and saved a change, live reloading would restart the app altogether and load it back to the landing/initial route.

Hot reloading, on the other hand, only refreshes the files that were changed while still maintaining the state of the app. For example, if you were 5 levels deep into your app navigation and saved a CSS change, the state would not change: You would still be on the same page, but the new styles would be visible.

Webpack has its own web server, called the webpack-dev-server, through which it supports HMR. It can be used in development as a live reload replacement.

Rollup released a plugin rollup-plugin-hotreload last month to support hot reload.

As this capability is fairly new in bundlers like Rollup and Parcel, I still choose Webpack as the safe bet for I don’t want to run into avoidable issues during development.

6. Module transformers.

Bundlers generally know only how to read JS files. Transformers are essentially teachers who teach the bundler how to process files other than JS and add them to your app’s dependency graph and module.

For example, in the image above, you can see a webpack config having an instruction on how to read CSS between lines 13 to 15. It basically says, “Hey Webpack, whenever you encounter a file that is resolved as .css, use css-loader imported above to read it and export it as a string“. Similarly, an HTML loader will tell Webpack how to read the .HTML files it encounters in your app and export them as strings in your bundler.

Parcel handles the transformation process very smartly. Unlike Rollup and Webpack, which need you to specify file types to transform, install, and configure, and plugins to transform them, Parcel provides built-in support for many common transforms and transpilers.

Parcel automatically runs the appropriate transformer when it finds a configuration file such as.babelrc, .postcssrc, .posthtml, etc., in a module. In addition to any transforms specified in .babelrc, Parcel always uses Babel on all modules to compile modern JavaScript into a form supported by browsers.

✅ In a nutshell

• Building a library with minimal third-party imports? Use Rollup

• Building a basic app and want to get it up and running quickly? Use Parcel.

• Building a complex app with lots of third-party integrations? Need good code splitting, use of static assets, and CommonJS dependencies? Use Webpack.

Personally, I will continue to prefer Webpack for my projects. One might argue that Parcel, in many cases, offers built-in configurations that might provide ease of development, but it’s difficult to overlook the extensive support and customizability that Webpack provides.

Webpack

Webpack is a commonly used library among modern frontend-based applications. It is one of the popular JavaScript bundlers. It’s now a decade-old and battle-tested library. Many of full full-fledged frontend frameworks like NextJs and Gatsby use Webpack for bundling and compilation purposes by default. If you ask someone what Webpack is, they will answer that it’s a JavaScript bundler. If you go a bit more and ask why we need a JavaScript bundler and how it works, only the curious might be able to answer satisfactorily. It isn’t anyone's fault, modern frontend libraries are packed in a way that you don’t need to worry about what happens under the hood. If we take an example of a ReactJS application configured through the create-react-app library, it takes care of the configuration of bundlers and transpilers. Developers can immediately start building an application with the knowledge of ReactJS. If one wants to master the art of building fast and performant frontend applications, one needs to have a clear mental model of the functioning of all these libraries.

How does Webpack work?

Webpack is an event-driven, plugin-based compiler. That means Webpack has a life cycle for bundling the files, and each life-cycle step can be imagined as an event. We can add a plugin that will listen to these different events and act accordingly. The default functionalities can also be inserted through plugins, i.e., there will be some default plugins handling some core functionalities.

Let’s say the life cycle has these 5 methods:

compilation-start → resolve → parse → bundle → compilation-end

The plugin can be integrated to listen to these events and perform the operation on the source code files. There will be some default plugins integrated to perform the core functionality.

Any plugin-based architecture can be designed similarly; it has a life cycle for any particular feature, and custom event handlers (which can be imagined as plugins) can be added to act upon at different steps of the life cycle.

Let’s not go through the Webpack life cycle:

What happens under the hood in Webpack?

Let’s understand some keywords and then connect them to form a whole story.

• Compiler: Just like a normal compiler, it will be a starting and stopping point in the webpack life cycle. It can be imagined as a central dispatcher of events.

• Compilation AKA The Dependency Graph: It’s like the brain. Through this, Webpack understands which sources you are using in your codebase. It contains the dependency graph traversal algorithm. It is created by the compiler.

• Resolver: It converts the partial path into the absolute path. This will be used to check if some files exist, and if it does, give us some information.

• Module Factory: Takes successfully resolved requests by the resolver and creates a module object with source files and some information received by the resolver.

• Parser: Takes a module object and turns it into an AST (a tree representation of the source code) to parse. Find all queries and imports and make a tree to parse for bundling.

• Templates: It is used for data binding for the dependency graph. It binds the tree object into the actual code in the module.

Now, let’s connect these dots:

First of all, Webpack will look at the configuration file and look for the entry point mentioned. The compiler will start the compilation from that file. A relative path will be sent to the resolver. The resolver will convert the relative path to the absolute path. The request will go to the module factory. The module factory will create a module object with some more information like the type of the file, size, absolute path, assigned id, etc.

Now, according to the file type mentioned in the module object, the compiler will look for the transpilers to convert the code into a browser-readable format. After converting the code, the parser will parse the file and look for the ‘require‘ or ‘imports‘ statements and update the object with the dependency information like below:

// example module object
{
  id: 0,
  absolutePath: '/path',
  fileType: '.jsx',
  dependency: [{ id1, relativePath }, { id2, relativePath }]
  // some more information
}

The compiler will parse the file recursively in this manner to finally form a complete dependency graph of module objects. Hash-map will also be maintained between the file ID, the absolute path, and the parsed file.

After building the dependency graph, the compiler will topologically sort all dependencies.

Topological sorting*: Topological sorting for a Directed Acyclic Graph (DAG) is a linear ordering of vertices such that for every directed edge u v, vertex u comes before v in the ordering.*

The Webpack merges all these topologically sorted dependencies with the help of a maintained hash map to make a bundle file. Minification or tree-shaking can be done on these bundle files now as post-processing measures through an event listener, which is also called a plugin. That’s it! Bundler has done his job in these simple steps :)

Let’s dry run the above bundling process for the following code:

// cat.js ES Module
export default "cat";

// bar.js CommonJS
const cat = require("./cat");
const bar = "bar" + cat;
module.exports = bar;

// foo.js ES Module
import catString from './cat';
const fooString = catString + "foo";
export default fooString;

// index.js - entry point
import fooString from './foo';
import barString from './bar';
import './tree.jpeg';
console.log(fooString, barString);

index.js is an entry for the bundler. The compiler will start the process with this information. It will convert the relative path into the absolute path and make a module object. We don’t need any transpiler here as it’s a simple JavaScript file. Now the parser will start parsing the index file. It contains 3 import statements, so the final object module created for index.js will look like this.

{
  "id":0,
  "absolutePath":"$home/index.js",
  "bundledFile": "bundledFile0.js",
  "fileType":".js",
  "dependency":[
    { "id": 1, "path": "./foo" },
    { "id": 2, "path": "./bar" },
    { "id": 3, "path": "./tree.jpeg"}
  ]
}

Webpack will now start compiling the dependencies of index.js. Webpack will recursively compile all the files until there are no dependencies left for any file and form the following dependency graph. Here, tree.jpeg will require a file loader/transpiler as NodeJS can’t understand it.

It will sort all the module objects in topological order and merge their converted chunks to form a bundle file for the browser to run directly.

The core concepts of Webpack

The Core Concepts of Webpack

The core concepts in Webpack:

• Entry

• Output

• Loaders

• Plugins

• Mode

• Development Server

Entry

entry is the entry point of your application. This is the place where Webpack starts its journey. We know that our React applications are like a tree. All the components span out from App.js.

But where do our App.js live? It lives inside the index.js file, and that’s why webpack enters the application via index.js and creates a dependency graph to determine which files need to be loaded first.

Output

This is another easy concept to understand. After all the work is done, Webpack creates a bundle file. In output, we can specify the name and the location of the output file.

It also has other uses. If you want to generate bundle names for the production system for version management, you can do that here.

Let’s take this a step further and try to understand how our .jsx or .css files are handled.

Loader

Loaders are a very important concept in Webpack. They are like compilers, Webpack checks for a certain type of file and uses appropriate loaders to handle them.

A typical configuration of the loader can be like the following:

module.exports = {
    entry: { ... as before}
    output: { ... as before },

    module: {
        rules: [
            {
                test: /\.[jt]sx?$/, // matches .js, .ts, .jsx and .tsx files
                use: ['babel-loader'],, // uses babel-loader for the specified file types
                include: path.resolve(__dirname, 'src'),
                exclude: /node_modules/,
            }
        ],
    }
}

Now, look at the module part. It takes an array of rules. Each rule has several parts:

• test -> It checks for a certain file type. It uses a regular expression.

• use -> It specifies the list of loaders used for this particular file type.

• include -> Which files should be processed?

• exclude -> Which should not be processed.

Sometimes we need more than one type of loader for a specific file. A good example is loading CSS files. The rule for that is:

{
    test: /\.css$/, // matches .css files only
    use: ['style-loader', 'css-loader'],
},

Here, both css-loader and style-loader are used to process the file. One important thing to note here is that these loaders are loaded in the reverse order.

That means first the css-loader will work and then style-loader will work on the output produced by css-loader.

Similarly, for our .scss files:

{
  test: /\.scss$/,
  use: ['style-loader', 'css-loader', 'sass-loader']
},

Plugins

Almost 80% of Webpack runs on plugins.

Plugins are another very important aspect of Webpack. Plugins are the main reason why Webpack is so powerful.

Plugins are like libraries. They can tap into any stage of the compilation process and do whatever they wish.

const {CleanWebpackPlugin} = require('clean-webpack-plugin')

module.exports = merge(common ,{
    entry:  {...},
    output: {...},
    module: {...}

    plugins: [ new CleanWebpackPlugin() ]
})

In the example above, we used a plugin named clean-webpack-plugin. What this plugin does is clean the output folder each time we run our build command.

There are lots of plugins that you can take advantage of. You can refer to WebPack’s official website if you are interested.

Mode

This is the simple concept to understand. You would want to use a different setup for your development and production. For this, you can use mode.

module.exports = merge(common ,{
    entry:  {...},
    output: {...},
    module: {...},
    plugins:{...},

    mode : 'development' or 'production'
})

If you set the mode to production, then your output bundle will be minified and optimized.

Development Server

This is the final setup for your application. While developing the application, you will not want to compile it every time you change something. That’s why you need a devServer setup for your application.

module.exports = merge(common ,{
    entry:  {...},
    output: {...},
    module: {...},
    plugins:{...},
    mode :  {...},

    devServer: {
        contentBase: path.join(__dirname, 'public/'),
        port: 3000,
        publicPath: 'http://localhost:3000/dist/',
        hotOnly: true,
    },
})

Now, this setup will serve your application from the dist that you set up earlier as your output.

Why Frontend Engineers Need to be WebPack experts

Modern web applications are not just about core functionalities. We also pay attention to factors like application performance, development productivity, and efficiency to get the maximum out of our effort.

But, are you aware that you could use WebPack to address some of these challenges?

However, just knowing how WebPack works won’t be enough to get the maximum from it. So, let’s see what you can achieve by being an expert in Webpack.

Improve Development Productivity

As developers, we always like to see faster feedback while we carry out modifications to the code. Besides, there are various methods we follow.

If you know WebPack well, you can easily enable its Hot Module Replacement feature to improve the development process.

Hot Module Replacement (HMR) allows us to modify modules while it is in the running state. Since HMR prevents full reload of the application, it will remain in the same state and will only be updated with what has changed.

All you need is to update the weppack-dev-server configuration and use its built-in HMR plugin.

module.exports = {
  entry: {
    app: './src/index.js',
  },
  ...
  devServer: {
    contentBase: './dist',
    hot: true,  // <--- Add this line
  },
  plugins: [
    ...
    new HtmlWebpackPlugin({
      title: 'Hot Module Replacement',
    }),
  ],
  output: {
      ...
  },
};

Pro tip: HMR becomes very handly in situations where you develop applications for multiple devices form factors. E.g., you can access the development server URL on both desktop and mobile and instantly see how it looks in both.

Get Better at Tree-Sharking

If your project has a significant amount of dead code or a large number of shared libraries, it’s common to experience a long application loading time. It’s common to see tree-shaking in such situations to avoid dead or unwanted code from bundling.

....
module.exports = {
  entry: {
    app: './src/index.js',
  },
  output: {
      ...
  },
  //add below line 
  mode: 'development',
  optimization: {
    usedExports: true,
  },
};

But, how can we guarantee that WebPack makes a correct decision about unused code in the project?

For example, it’s common to have global-level stylesheets imported into the project, and usually, those files aren’t used anywhere. But removing such files can affect the whole project.

Webpack uses a special configuration in the package.json file named sideEffects. By default, all the files in your project are considered files with side effects, and tree-shaking won’t be performed.

However, we can manually change this behavior by changing sideEffects value to false, true, or providing an array with file names.

// All files have side effects 
"sideEffects": true
// No files have side effects
"sideEffects": false
//Only these files have side effects,
 "sideEffects": [
  "./src/file1.js",
  "./src/file2.js"
 ]
}

If you enable tree-shaking in Webpack configuration, ensure to include files that don’t have side effects in package.json file settings.

Using Code Splitting to Optimize App Loading Time

If you monitor the number of unused bytes in a single bundle using Chrome DevTools, you will be amazed to see how often it happens.

Webpack provides the perfect situation by allowing you to split your code into different bundles and load them on-demand or in parallel.

Webpack provides 3 approaches for code splitting, and you will need to decide which mechanism is the most suited one for your project. For that, you should have a good understanding of Webpack.

The entry point approach is considered the most straightforward and most used code-splitting approach with Webpack. You just need to update all the separate modules in the Webpack config file manually.

....
module.exports = {
  mode: 'development',
  entry: {
    index: './src/index.js',
    second: './src/second-module.js',
  },
  output: {
   filename: '[name].bundle.js',
   path: path.resolve(__dirname, 'dist'),
   },
};

However, this approach is not very flexible, and there is a risk of having duplicate modules between chunks. If you don’t see any improvements with this approach, you can go deeper with the Prevent Duplication approach**.**

Prevent Duplication approach allows specifying the shared modules between chunks using dependOn the option. You can easily convert the entry point approach to prevent duplication with a few modifications.

....
module.exports = {
  mode: 'development',
  entry: {
    index: {
      import: './src/index.js',
      dependOn: 'shared',
    }, 
    second: {
      import: './src/second.js',
      dependOn: 'shared',
    }, 
    shared: 'shared-module',
  },
 ...
};

But the above configuration alone will not give you the desired output. You also need to enable runtimeChunk in the optimization section to prevent Webpack from copying module code between entry points.

optimization: {
  splitChunks: {
    chunks: 'all',
  },
},

If you are not satisfied with the Prevent Duplication approach, you can shift to the Dynamic Imports approach.

I think you already understand the power of Webpack code splitting and the amount of knowledge you need to configure that. So, I won’t be going into details of the Dynamic Imports approach here, and you will be able to understand it easily if you understood the previous two.

Supports Micro Frontends with Module Federation

Module federation is an exciting JavaScript architecture that allows importing code from another application dynamically at runtime.

Webpack facilitates the support you need to integrate the module federation architecture to your project through a plugin called Module Federation Plugin.

All you need to do is follow the 4 simple steps:

1. Import the plugin to both applications.

2. Make necessary modifications in the Webpack configuration for the first application and expose the components that need to be shared.

3. Import the shared component in the Webpack configurations of the second application.

However, this might not be that simple when you start the implementation. You should be very careful about Webpack configurations and only necessary changes.

For example, in the first application, you won’t need to change anything other than the plugins section.

const { ModuleFederationPlugin } = require(“webpack”).container;
...
plugins: [
  new ModuleFederationPlugin({
    name: "application1",
    library: { type: "var", name: "app1" },
    filename: "remoteEntry.js",
    exposes: {
      // expose each component
      "./Component1": "./src/components/Component1",
    },
      shared: ["react", "react-dom"],
    }),
    ...
  ],
...

Besides, if you have a good understanding of these concepts, you can refer to the relevant documentation and easily carry out the required configurations.

With this approach, you will be able to move away from the traditional way of sharing reusable components between micro frontends, and I think that would be a huge win for your development team.

How to set up your React app from scratch using Webpack

So, you have been using Create React App, aka CRA, for a while now. It’s great, and you can get straight to coding. But when do you need to eject from create-react-app and start configuring your own React application? There will be a time when we have to let go of the safety check and start venturing out of our own.

Let’s check out these articles:

https://www.freecodecamp.org/news/an-intro-to-webpack-what-it-is-and-how-to-use-it-8304ecdc3c60/

https://raphael-leger.medium.com/react-webpack-chunkloaderror-loading-chunk-x-failed-ac385bd110e0

https://medium.com/better-programming/learn-webpack-in-under-10-minutes-efe2b2b10b61

https://javascript.plainenglish.io/webpack-in-2021-typescript-jest-sass-eslint-7b4640842e27

https://www.freecodecamp.org/news/how-to-set-up-deploy-your-react-app-from-scratch-using-webpack-and-babel-a669891033d4/

https://javascript.plainenglish.io/a-complete-guide-to-use-typescript-in-web-development-with-without-react-3ab58ab4f03c

https://medium.com/better-programming/micro-frontends-using-webpack-5-module-federation-3b97ffb22a0d

https://medium.com/swlh/webpack-5-module-federation-a-game-changer-to-javascript-architecture-bcdd30e02669

Bundler Best Practices

Webpack and yarn magic against duplicates in bundles

Setting up the scene

I will assume that you have some understanding of what tools like yarn, npm, and webpack are used in modern frontend projects and want to dig deeper into the magic behind the scenes.

Some terminology used in this article:

Direct dependencies: packages on which your project relies explicitly. Typically installed via yarn add package-name. The full list of those can be found in the dependencies field in package.json at the root of the project.

Transitive dependencies: packages on which your project relies implicitly. Those are the dependencies on which your direct dependencies rely. Typically, you won’t see them in the package.json file, but they can be seen, for example, in yarn.lock file

Duplicated Dependencies: transitive dependencies with mismatched versions. If one of the project dependencies has a button package version 4.0.0 as a transitive dependency and another has the same button version 3.0.0, both of those versions will be installed, and the button dependency will be duplicated.

De-duplication: the process of elimination of duplicated dependencies according to their SemVer versions (x.x.x - major, minor, patch). Typically, a range of versions within the same major version will contain no breaking changes, and only the latest version within this range can be installed. For example, a button version 4.0.0 and 4.5.6 can be “de-duplicated, “ and only version 4.5.6 will be installed.

yarn.lock file: an auto-generated file that contains the exact and full list of all direct and transitive dependencies and their exact versions in yarn-based projects.

The problem of duplicated dependencies

“Duplicated“ dependencies in any of the middle — or large-scale projects that rely on npm packages are inevitable. When a project has dozens of “direct“ dependencies, and every one of those has its own dependencies, the final number of all packages (direct and transitive) installed in a project can be close to hundreds. In this situation, it’s more likely than not that some of the dependencies will be duplicated.

Considering that those are bundled together and served to the customers, in order to reduce the final JavaScript size it’s important to reduce the number of duplicates to a minimum. This is where the deduplication process comes into play.

Deduplication in yarn

Consider, for example, a project that among its direct dependencies has modal-dialog@3.0.0 and button@2.5.0, and modal-dialog brings button@2.4.1 as a transitive dependency. If left unduplicated, both buttons will exist in the project

and in yarn.lock , we will see something like this:

modal-dialog@^3.0.0:
  version "3.0.0"
  resolved "exact-link-to-where-download-modal-dialog-3.0.0-from"
  dependencies:
    button@^2.4.1

button@^2.5.0:
  version "2.5.0"
  resolved "exact-link-to-where-download-2.5.0-version-from"

button@^2.4.1:
  version "2.4.1"
  resolved "exact-link-to-where-download-2.4.1-version-from"

Now, we know that according to semver, button@2.4.1 and button@2.5.0 are compatible, and therefore we can tell yarn to grab the same button@2.5.0 version for both of them — “deduplicate” them. From the project perspective, it will look like this:

and in yarn.lock file, we’ll see this:

modal-dialog@^3.0.0:
  version "3.0.0"
  resolved "exact-link-to-where-download-modal-dialog-3.0.0-from"
  dependencies:
    button@^2.4.1

button@^2.4.1, button@^2.5.0:
  version "2.5.0"
  resolved "exact-link-to-where-download-2.5.0-version-from"

Deduplication in yarn - not compatible version

The above duplication technique is the only thing that we usually have in the fight against duplicates, and usually, it works quite well. But what will happen if a project has non-semver-dedupable transitive dependencies? If, for example, our project has modal-dialog@3.0.0, button@2.5.0, and editor@5000.0.0 as direct dependencies, and those bring button@1.3.0 and button@1.0.0 as transitive dependencies?

Using the same technique, we can de-duplicate buttons from 1.x.x version, and from the project perspective, it will look like this:

Two versions of the button are unavoidable, and in this case, usually, there is nothing we can do other than upgrade the version of model-dialog and editor to the versions when they both have button from 2.x.x range and it can be de-duplicated properly. Typically, in this case, we stop, say that our project has “2 versions of buttons,” and move on with our lives.

But what if we dig a little bit further and check out how exactly 2 buttons are installed on the disk and bundled together?

Duplicated dependencies installed

When we install our dependencies via classic yarn or npm (pnpm or yarn 2.0 changes the situation and are not considered here), npm hoists everything that is possible up to the root node_modules. If, for example, in our project above, both the editor and the modal dialog have the dependency on the same “deduped“ version of the tooltip, but our project does not, npm will install it at the root of the project.

And inside the node_modules folder, we’ll see this structure:

/node_modules
  /editor
  /modal-dialog
  /tooltip

And because of that, we can be sure that we only have one version of the tooltip in the project, or even if two completely different dependencies depend on slightly different versions of it.

Unless…

Unless those versions are not semver compatible and can not be deduplicated that easily. Basically, the situation in the project with buttons from above will look like this:

Even if dependencies are “deduped” on yarn.lock level, and we “officially” have only 2 versions of buttons in yarn.lock, every single package, with button@1.3.0 as the dependency that will install its own copy of it.

Deduplicated Dependencies and Webpack

So, if a project is bundled with Webpack, how exactly does it handle the situation from above? It doesn’t actually (there was a webpack dedup plugin in the long past, but it was removed after Webpack 2.0)

Webpack, behind the scenes, just builds the graph of all your files and their dependencies based on what’s installed and required in your node_modules via the normal code resolution algorithm. TL;DR: Every time a file in the editor does “import Button from ‘button’;”, the node will try to find this button in the closest node_modules starting from the parent folder of the file where the request appeared. The same story with the modal-dialog. And then, from a Webpack perspective, the very final ask for the button will be:

• project/node_modules/editor/node_modules/button/index.js — when it’s requested from within editor

• project/node_modules/modal-dialog/node_modules/button/index.js — when it’s requested from within modal-dialog

Webpack is not going to check whether they are exactly the same; it will treat them as unique files and bundle both of them in the same bundle. Our “duplicated” button just got double-duplicated.

Deduplication in Webpack - first attempt

Since those buttons are exactly the same, the very first question that comes to mind is: is it possible to take advantage of that and “trick“ Webpack into recognizing it? And indeed, it is possible, and it is ridiculously simple.

Webpack is incredibly flexible; it provides rich plugin interfaces with access to almost everything you can imagine (and to some things that you can not), and its core, most of its features are built with plugins as well. It exports a lot of them for others to use.

One of those plugins is NormalModuleReplacementPlugin — it gives the ability to replace one file with another file during a build time with a regular expression. Which is exactly what we need; the rest is just a master of coding.

First, detected all “duplicated“ dependencies by grabbing a list of all packages node_modules and filtering those that have node_modules in their install path more than once (basically all the “nested” packages from the yarn install chapter above), and grouping them by their version from package.json.

Second, replace all encounters of the “same” package with the very first one from the list

And 💥, there is no “third”, the solution works, it’s safe, and reduces bundle sizes in Jira by ~10%.

The full implementation was literally just 100 lines. Be mindful with celebrating and copying the approach, though, this is not the end of the article 😉

Check out this article for more details.

Learning by fixing: Node.js, Modules, and Packages

The project I was working on has a pretty standard frontend code setup: React, Next.js, CSS in JS, UI components from an external library to build the interface. One day I added a new component, and although everything works locally, my CI, while attempting to build the website, greeted me with this:

After a bit of “errr, wat?”, scratching my head furiously, meddling with UI configuration and doing usual clean-the-cache, nuke-node-modules, cargo-culting activities, I managed to reproduce the problem locally. Turned out that:

• It only happens with the Logengy component, which uses Compiled - a new CSS-in-JS library.

• It was working locally because the version of Node in the CI was newer than my local machine.

So clearly, the problem was either with Lozenge or with the compiled library itself, and clearly, there was something in their code that prevented it from working with the latest Node. So the solution to the problem seemed simple: downgrade the version of Node in the CI to unblock my build and raise an issue with the library in the hope that maintainers, who know their source code, can figure it out.

Only…

What can possibly a Lozenge component, that just renders a few divs, or a css-in-js library, that converts js-written styles into style tags can have, that depends on a version of Node? Especially on an old version of Node? It’s usually the other way around…

It’s a proper mystery! Time to put my Sherlock hat on and solve it.

Check out this article to explore the reason.

Three simple tricks to speed up yarn install

Dev productivity and quality of life improvements are a passion of mine. And speeding up working with code is not only fun, but also essential for building products fast. Happier and faster developers equal happier customers, who get their features and bug fixes sooner!

When dealing with an npm-based ecosystem and its myriad of packages, install dependencies time, especially in large projects, can be unreasonably long. Below are three simple tricks that can help you shave off a minute or two, or sometimes even reduce your yarn install time by half 😋

Not anymore!

Bloated yarn.lock problem

If your project runs on yarn, then more likely than not, some of your dependencies will be duplicated, even if they satisfy semver conditions. Although yarn promises that deduplication isn’t necessary, this is not exactly the truth.

Imagine the situation: you’re adding @awesome/tools library to your dependencies, which also depends on utils@^1.0.0library, which is its latest version. After installing @awesome/tools you’ll see in your yarn.lock file:

After a few months, you want to add another library that depends on those utils, let’s say @simple/button.The Utils library released a few bug fixes and features in the meantime, and its latest version is now 1.5.1, and @simple/buttondepends on it. If you just run yarn add @simple/button, then in the yarn.lock you will see this picture:

Even though 1.5.1 and 1.0.0 versions are semver-compatible, yarn will not merge them into one as you’d expect, and you’ll end up with 2 versions of the same utils in the repo.

It gets worse than that. If you have a few different libraries that depend on version 1.0.0 and a few that depend on 1.5.1, yarn will hoist one of those versions to the root of node_modules folder, but another one would have no place to go (only one version can sit at the root), and they will be installed as copies in node_modules folders of the libraries that use them. You’ll end up with this folder structure:

And although it seems like you only have 2 versions of utils library, in reality, it can be 5–6-infinite-number of its copies living in your project, all of which need to be copied into their place, and all of which will steal your yarn install time.

Check out this article to explore the solution🔥

How did we cut bundle size by 70% overnight?

An analysis of modern JavaScript projects reveals a concerning trend: many production applications include hundreds of transitive dependencies. According to Sonatype’s 2023 research, the average JavaScript contains 42 direct dependencies and 683 transitive dependencies, with 65% of projects containing known vulnerable dependencies.

The real cost goes so far beyond the megabytes:

• Security Vulnerabilities: Each dependency is a potential attack vector.

• Maintenance overhead: Keeping dependencies updated consumes developer time.

• Version conflicts: Incompatible sub-dependencies create debugging nightmares.

• Bundle bloated: Libraries often bring more code than you actually use.

Most concerning is the exponential nature of transitive dependencies. Adding a “single“ package can sometimes pull in dozens of sub-dependencies you never intended to include.

A client of ours recently added a simple date formatting library that seemed lightweight (12KB) — but it silently pulls in 267KB of additional dependencies. That’s a 22X multiplier!

That matters because every 100kB of JavaScript takes approximately 100ms to parse and compile on an average mobile device.

For users on slower devices or connections, this directly translates to frustration and abandonment.

Our dependency audit process

1. Analyzing the current state

Before making any changes, we needed visibility into our dependency mess. These tools proved invaluable:

webpack-bundle-analyzer

Gives you a visual treemap of your bundle components.

# Installation
npm install --save-dev webpack-bundle-analyzer

// # In your webpack.config.js
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
}
// # Run your build to see the analysis
npm run build

npm is

Shows your dependency tree directly in the terminal:

# Show top-level dependencies
npm ls --depth=0

# Show all dependencies including their dependencies
npm ls

# Find specific packages
npm ls react

# Show only production dependencies
npm ls --prod

dep check

Identifies unused dependencies in your projects

# Installation
npm install -g depcheck

# Run in your project root
depcheck

# With custom options
depcheck --ignores="eslint,babel-*"

import-cost

# Installation steps:
1. Open VS Code
2. Press Ctrl+P (Cmd+P on Mac)
3. Type: ext install wix.vscode-import-cost
4. Press Enter

# The extension will show size information directly in your editor
# whenever you import packages

Running webpack-bundle-analyzer was eye-opening. We immediately spotted several massive libraries dominating your bundle:

• A full-featured charting library (1.2MB), when we only used two simple chart types

• Three different date manipulation libraries (Moment.js, date-fns, and Day.js)

• Lodash is imported in its entirety rather than individual functions.

• A massive UI component library where we used just four components.

2. Setting Measurable Goals

We established clear metrics to track our progress:

• Primary: Total bundle size (initial and chunked)

• Secondary: Time to interact on mid-tier mobile devices.

• Supporting: JavaScript parse/compile time

• Business: Conversion rates and bounce rates

We set an ambitious goal of reducing bundle size by 50% within one sprint, with a stretch goal of 60%. We ultimately achieved 70%.

6 Techniques that delivered results: Our Step-by-Step Process

1. Ruless Package Evaluation

We applied a simple but effective framework to every dependency:

• Do we absolutely need this functionality?

• Can we implement it ourselves in < 100 lines of code?

• Is there a more lightweight alternative?

• If we must use it, can we only use the needed parts?

This led to some major wins:

Example 1: Replacing Moment.js (329KB) with date-fns (85KB)

// Before: Moment.js (329KB)
import moment from 'moment';
const formattedDate = moment(date).format('YYYY-MM-DD');

// After: date-fns (only importing what we need)
import { parseISO, format } from 'date-fns';
const formattedDate = format(parseISO(dateString), 'yyyy-MM-dd');

Example 2: Replacing a full chart library with a targeted solution

// Before: Importing massive chart library (1.2MB)
import { LineChart } from 'massive-chart-lib';

// After: Using a lightweight alternative (87KB)
import { Line } from 'lightweight-charts';

In total, we eliminated 18 dependencies and replaced 7 others with lighter alternatives.

2. Implementing Proper Tree-Shaking

Tree-shaking (eliminating unused code) sounds simple, but many projects don’t fully benefit from it due to configuration issues.

Common pitfalls we fixed:

• Using CommonJS modules that can’t be properly tree-shaken.

• Side effects preventing dead code elimination

• Incorrect Webpack/bundler configuration

Our webpack optimization:

// webpack.config.js improvements
module.exports = {
  mode: 'production',
  optimization: {
    usedExports: true,
    sideEffects: true,
    minimize: true,
    concatenateModules: true,
  },
}

Ensuring proper imports:

// Before: No tree-shaking (entire library included)
import _ from 'lodash';

// After: Tree-shakeable imports

// Option 1: Individual imports
import map from 'lodash/map';
import filter from 'lodash/filter';


// Option 2: Using lodash-es for ESM modules
import { map, filter } from 'lodash-es';

This alone shaved off 347KB from our bundle.

3. Dynamic Imports & Code Splitting

Rather than loading our entire application upfront, we implemented aggressive code splitting:

Route-based splitting:

// Before: All routes imported eagerly
import UserProfile from './UserProfile';
import Dashboard from './Dashboard';
import Settings from './Settings';


// After: Routes loaded dynamically
const UserProfile = React.lazy(() => import('./UserProfile'));
const Dashboard = React.lazy(() => import('./Dashboard'));
const Settings = React.lazy(() => import('./Settings'));

Feature-based splitting:

// Before: Advanced features loaded upfront
import { DataExport } from './features/export';

// After: Load on demand
const handleExport = async () => {
  const { DataExport } = await import('./features/export');
  DataExport.run(currentData);
};

We used React.Suspense to handle loading states gracefully:

<Suspense fallback={<Spinner />}>
  <Route path="/profile" component={UserProfile} />
</Suspense>

This approach reduced our initial bundle size by 35% by deferring non-critical features.

4. Micro-frontends for Targeted Loading

For our most complex product area — the analytics dashboard — we implemented module federation using Webpack 5’s features to load different sections independently. While this approach took us around three weeks to fully implement (longer than our initial one-week estimate), the performance benefits justified the investment.

// webpack.config.js (simplified)
const { ModuleFederationPlugin } = require('webpack').container;

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'dashboard',
      filename: 'remoteEntry.js',
      exposes: {
        './ReportingModule': './src/components/Reporting',
        './VisualizationModule': './src/components/Visualization',
      },
      shared: {
        react: { singleton: true },
        'react-dom': { singleton: true },
        // other shared dependencies
      },
    }),
  ],
};

This approach allowed us to:

• Load only the dashboard components that the user actually views

• Share common dependencies between micro-frontends

• Update individual modules independently

When Not to Use Micro-frontends

While powerful, this approach isn’t for everyone:

• Small teams with limited DevOps resources may find the operational complexity overwhelming

• Applications with heavy cross-module communication might face performance penalties

• Projects requiring SSR/SSG optimization may need different architectural approaches

⚠️ Not for everyone — Micro-frontends introduce DevOps and architectural complexity. Avoid them for small apps or SSR-focused builds.

For our use case — a large dashboard with distinct functional areas — the benefits far outweighed the complexities.

5. Building Dependencies Approval Process

To prevent future bloat, we implemented a dependency approval workflow:

1. Proposed dependency form: Developers must justify new packages

2. Bundle impact analysis: Automated testing of bundle size impact

3. Alternatives checklist: Documented consideration of lighter options

4. Regular audits: Monthly dependency reviews

We added bundle size budgets to our CI pipeline:

// package.json
{
  "bundlesize": [
    {
      "path": "./dist/main.*.js",
      "maxSize": "250 kB"
    },
    {
      "path": "./dist/vendors.*.js",
      "maxSize": "700 kB"
    }
  ]
}

This process has prevented at least seven unnecessary dependencies from entering our codebase in the three months since implementation.

6. Compression & Caching Strategies

Beyond dependency optimization, we implemented several network-level optimizations:

• Brotli compression: We replaced gzip with Brotli, which provides ~11% better compression

• Long-term caching: Set far-future cache headers (1 year) with content-based hashing

• CDN-hosted dependencies: Used public CDNs for common libraries when appropriate

• Preloading critical assets: Implemented <link rel="preload"> for essential resources

These changes further reduced perceived load times by optimizing how resources were delivered to users, complementing our bundle size reductions.

The results: Before and After Analysis

The final results, measured using Lighthouse, WebPageTest, and our internal analytics platform, exceeded even our stretch goals:

Beyond the performance metrics, we saw several unexpected benefits:

• Faster build times: CI builds went from 8 minutes to under 4 minutes

• Fewer bugs: Removing complex dependencies eliminated subtle integration issues

• Improved developer experience: The codebase became more understandable and maintainable

13 Webpack Optimization Tips You Should Know

I will share some of my commonly used techniques from these aspects:

• Improving the building speed

• Reducing the size of the packaged files

• Improving the user experience.

Improving the Building Speed

1. thread-loader

Multithreading can improve the efficiency of the program; we can also use it in Webpack. And thread-loader is a loader that can enable multi-threading in Webpack.

Installation of the loader:

npm i thread-loader -D

Configuration:

{
        test: /\.js$/,
        use: [
          'thread-loader',
          'babel-loader'
        ],
}

2. cache-loader

In the process of deploying our project, Webpack needs to build the project several times. To speed up subsequent builds, we can use caching. The cache-related loader is cache-loader.

Installation:

npm i cache-loader -D

Configuration:

{
        test: /\.js$/,
        use: [
          'cache-loader',
          'thread-loader',
          'babel-loader'
        ],
}

3. Hot update

When we modify a file in a project, Webpack will rebuild the entire project by default, but this is not necessary. We only need to recompile this file, which is more efficient; this strategy is called a hot update.

Webpack has a built-in hot update plugin; we just need to enable hot update in the configuration.

Configuration:

// import webpack
const webpack = require('webpack');

then:

{
  plugins: [
      new webpack.HotModuleReplacementPlugin()
  ],

  devServer: {
      hot: true
  }
}

4. exclude & include

In our project, some files and folders never need to participate in the build. So we can specify these files in the configuration file to prevent Webpack from retrieving them, thereby improving compilation efficiency.

Of course, we can also specify that some files need to be compiled.

• exclude : files that don’t need to be compiled

• include : files that need to be compiled

Configuration:

{
    test: /\.js$/,

    include: path.resolve(__dirname, '../src'),

    exclude: /node_modules/,    use: [
        'babel-loader'
    ]
}

Reducing the size of the packaged files

5. Minify CSS code

css-minimizer-webpack-plugin can compress and deduplicate CSS code.

Installation:

npm i css-minimizer-webpack-plugin -D

Configuration:

const CssMinimizerPlugin = require('css-minimizer-webpack-plugin')

and:

optimization: {
    minimizer: [
      new CssMinimizerPlugin(),
    ],
  }

6. Minify JavaScript code

terser-webpack-plugin can compress and deduplicate JavaScript code.

Installation:

npm i terser-webpack-plugin -D

Configuration:

const TerserPlugin = require('terser-webpack-plugin')optimization: {
    minimizer: [
      new CssMinimizerPlugin(), 
      new TerserPlugin({
        terserOptions: {
          compress: {
            drop_console: true, // remove console statement
          },
        },
      }),
    ],
  }

7. tree-sharking

Tree-sharking is: to compile only that code that is actually used, not the code that is not used in the project.

In Webpack 5, tree-shaking is enabled by default. You just need to make sure to use production mode when final compiling.

module.exports = {
  mode: 'production'
}

8. source-map

When there is a bug in our code, source-map can help us quickly locate the location in our source code. But this file is huge.

In order to balance performance and accuracy, we should: generate a more accurate (but larger) source map in development mode; generate a smaller (but not as accurate) source map in production mode.

Development mode:

module.exports = {
  mode: 'development',
  devtool: 'eval-cheap-module-source-map'
}

Production mode:

module.exports = {
  mode: 'production',
  devtool: 'nosources-source-map'
}

9. Bundle Analyzer

We can use webpack-bundle-analyzer to review the column of the bundle file after packaging, and then perform corresponding volume optimization.

Installation:

npm i webpack-bundle-analyzer -D

Configuration:

const {
  BundleAnalyzerPlugin
} = require('webpack-bundle-analyzer')// config
plugins: [
    new BundleAnalyzerPlugin(),
]

Improving the user experience

10. Module Lazy Loading

If the module is not lazy-loaded, the code of the entire project will be packaged into one JS file, resulting in a very large size of a single JS file. Then, when the user requests the webpage, the loading time of the first screen will be longer.

After module lazy loading, the large JS file will be divided into multiple small JS files, and the webpage will be loaded on demand when loading, which greatly improves the loading speed of the first screen.

To enable lazy loading, we just need to write code like this:

// src/router/index.jsconst routes = [
  {
    path: '/login',
    name: 'login',
    component: login
  },
  {
    path: '/home',
    name: 'home',    // lazy-load
    component: () => import('../views/home/home.vue'),
  },
]

11. Gzip

Gzip is a common algorithm for compressing files, which can improve transmission efficiency. However, this function requires back-end cooperation.

Installation:

npm i compression-webpack-plugin -D

Configuration:

const CompressionPlugin = require('compression-webpack-plugin')
// config
plugins: [

    // gzip
    new CompressionPlugin({
      algorithm: 'gzip',
      threshold: 10240,
      minRatio: 0.8
    })
  ]

12. base64

For some small pictures, they can be converted into base64 encoding, which can reduce the number of HTTP requests for users and improve the user experience. url-loader has been deprecated in webpack5, we can use asset-module instead.

Configuration:

{
   test: /\.(png|jpe?g|gif|svg|webp)$/,
   type: 'asset',
   parser: {      // Conditions for converting to base64
      dataUrlCondition: {
         maxSize: 25 * 1024, // 25kb
      }
   },
   generator: {
    filename: 'images/[contenthash][ext][query]',
   },
},

13. Properly configure the hash

We can add a hash to the bundle file, which makes it easier to handle caching.

output: {
    path: path.resolve(__dirname, '../dist'),
    filename: 'js/chunk-[contenthash].js',
    clean: true,
  },

How to Fully Optimize Webpack 4 Tree Shaking

Before going into technical details, let me summarize the benefits. Different applications will see different levels of benefits with this exercise. The main deciding factor is the amount of dead, tree-sharkable code in your application. If you don’t have much, then you won’t see much of a benefit from tree-sharking. We had a lot of dead code in ours.

In our department, the biggest problem was a number of shared libraries. These ranged from simple homegrown component libraries to corporate standard component libraries to giant blobs of code shoved together into a library for no rhyme or reason. A lot of it is tech debt, but a big problem was that all of our applications were importing all of these libraries, when in reality each one only needed small pieces of them.

Overall, once tree-shaking was implemented, our applications shrank from between 25% to 75%, depending on the application. The average reduction across all of them was 52%, primarily driven by these bloated shared libraries being the majority of the code in small applications.

What is considered Dead Code?

This is the simple: It’s code that Webpack can’t see you using. Webpack follows the trail of import/export statements throughout the application, so if it sees something being imported but ultimately not being used, it considers that to be “dead code“ and will tree-shake it.

Dead code isn’t always clear, though. Below will be a few examples of dead code vs “live” code, which I hope will make this more clear. Keep in mind that there will be cases where Webpack will see something as dead code even though it really isn’t. Please see the section on Side Effects to learn how to handle this.

// Importing, assigning to a JavaScript object, and using it in the code below
// This is considered "live" code and will NOT be tree-shaken
import Stuff from './stuff';
doSomething(Stuff);
// Importing, assigning to a JavaScript object, but NOT using it in the code below
// This is considered "dead" code and will be tree shaken
import Stuff from './stuff';
doSomething();
// Importing but not assigning to a JavaScript object and not using it in the code
// This is considered to be "dead" code and will be tree shaken
import './stuff';
doSomething();
// Importing an entire library, but not assigning to a JavaScript object and not using it in the code
// Oddly enough, this is considered to be "live" code, as Webpack treats library imports differently from local code imports
import 'my-lib';
doSomething();

Writing Tree-Shakable Imports

When writing tree-shakable code, your imports are important. You should avoid importing entire libraries into a single JavaScript object. When you do so, you are telling Webpack that you need the whole library, and Webpack will not tree-shake it.

Take this example from the popular library Lodash. Importing the entire library at once is a big NO, but importing individual pieces is much better. Of course, Lodash specifically needs other steps to be tree-shaken, but this is a good first step.

// Import everything (NOT TREE-SHAKABLE)
import _ from 'lodash';
// Import named export (CAN BE TREE SHAKEN)
import { debounce } from 'lodash';
// Import the item directly (CAN BE TREE SHAKEN)
import debounce from 'lodash/lib/debounce';

Check out this article to figure out more techniques about tree shaking.

References

https://sayanmondal342.medium.com/the-what-why-and-how-of-javascript-bundlers-f617f82aa09a

https://levelup.gitconnected.com/bundler-behind-the-scenes-of-your-crafted-frontend-code-rendering-in-users-browser-411d7b7d5e29

https://medium.com/better-programming/the-battle-of-bundlers-6333a4e3eda9

https://blog.lyearn.com/how-webpack-works-236f8cc43ae7

https://mvskiran.medium.com/the-core-concepts-of-webpack-customing-webpack-414483a86fb7

https://medium.com/ekino-france/beyond-webpack-esbuild-vite-rollup-swc-and-snowpack-97911a7175cf

https://rahuulmiishra.medium.com/exploring-four-core-concepts-every-frontend-developer-should-know-b51f6e0e1cd2

https://medium.com/better-programming/6-webpack-concepts-for-advanced-react-developers-d016da2cad52

https://blog.bitsrc.io/why-frontend-developers-need-to-be-webpack-experts-32e734b6f04a

https://www.developerway.com/posts/webpack-and-yarn-magic-against-duplicates-in-bundles

https://medium.com/the-syntax-diaries/the-hidden-cost-of-npm-dependencies-how-we-cut-bundle-size-by-70-overnight-4d913fcf9dde

https://medium.com/frontend-canteen/13-webpack-optimization-tips-you-should-know-668666f8c020

Git is a version control software developed by Linus Torvalds (the creator of Linux), in order to coordinate the work with his collaborators.

Keep in mind that Git has a distributed architecture, so instead of the code being in a single place, when a developer makes a working copy of this code, it generates a repository that can contain the full history of changes that have been made in that code.

Repository, revision, commit… Some vocabulary

When working with Git and version control, we come across a series of terms that it is necessary to know what they are.

• Branch: A branch is a separate line of development in your project. It allows you to work on new features or fixes without affecting the main codebase.

• Checkout: The git checkout command is used to switch between branches or restore files to a previous state.

• Clone: git clone creates a full local copy of a remote repository, including its history, branches, and files.

• Commit: A commit is a snapshot of your changes. It includes a message describing what was done, along with metadata like author and date.

• Conflict: A conflict happens when Git cannot automatically merge changes from different sources. You'll need to manually resolve these.

• Diff (Difference): A diff shows what has changed between two versions of a file or set of files — additions, deletions, or modifications.

• HEAD: HEAD refers to the latest commit on the current branch you're working on.

• Merge: git merge integrates changes from one branch into another. Often used to bring feature branches into the main branch.

• Pull: git pull fetches and merges updates from a remote repository into your local branch.

• Pull Request (PR): A request to merge your changes into another branch, often reviewed before approval. Commonly used in collaborative workflows.

• Push: git push uploads your local commits to a remote repository to share with others.

• Repository (Repo): A storage location for your project code and history. Can be local or remote (e.g., GitHub).

• Tag: A tag marks a specific point in your project’s history, often used for releases (e.g., v1.0.0).

• Staging Area (Index): The place where files go when you run git add. Only staged files are included in the next commit.

• Fork: A personal copy of someone else's repository, typically used to propose changes or contribute to the original project.

• Rebase: git rebase moves or combines commits to a new base commit. Helps keep a clean, linear project history.

• Revert: git revert creates a new commit that undoes the effects of a previous commit.

• Reset: git reset changes your current branch’s history. It can remove commits or unstage files depending on the flags used.

• Stash: git stash temporarily saves uncommitted changes so you can work on something else, then come back to them later.

• Origin: The default name for the remote repository you cloned from. Used to refer to it in Git commands (e.g., git push origin main).

• Blame: git blame shows which commit and author last modified each line of a file. Useful for tracking down when and why a line was changed.

• Cherry-pick: git cherry-pick allows you to apply a specific commit from one branch onto another. Helpful when you want to copy just one change instead of merging everything.

• Hook: Git hooks are scripts that run automatically before or after certain events (like committing or pushing). Used for tasks like code formatting, testing, or enforcing rules.

• Submodule: A Git repository inside another Git repository. Useful for managing dependencies or separate components in a project.

• Upstream: Refers to the remote branch that your local branch is tracking. For example, if you're working on a feature branch that is based on origin/main, then origin/main is the upstream.

• Detached HEAD: A state where your HEAD points to a specific commit instead of a branch. You're not on any branch, so commits won’t be saved to any branch unless you explicitly create one.

• Fast-forward Merge: A type of merge that doesn’t require a merge commit. Git just moves the pointer forward because there were no divergent changes.

• Squash: The process of combining multiple commits into one. Often used before merging to keep history clean.

• Tracking Branch: A local branch that is set to track a remote branch. This allows you to easily pull/push without specifying the remote and branch name every time.

• Worktree: A working tree (or worktree) is a directory with a checkout of a branch. Git allows multiple worktrees linked to one repository—useful for working on multiple branches at once.

Git Advanced Concepts

https://github.com/mike-rambil/Advanced-Git

What is inside .Git Folder?

The Moment of Truth: Opening .git

Here's what most developers think .git contains: "Uh... git stuff?"

Let me show you what's actually in there. Open any git repository and run:

ls -la .git/

You'll see something like this:

.git/
├── HEAD
├── config
├── description
├── hooks/
├── index
├── info/
├── objects/
├── refs/
└── logs/

Each piece has a purpose. Each file tells a story. Let's decode them one by one.

The Directory Structure

Before we dive deep, here's the map:

The two most important directories? objects/ and refs/. Everything else is supporting infrastructure.

HEAD: Your Location Marker

Let's start simple. Check what's in HEAD:

cat .git/HEAD

Output:

ref: refs/heads/main

That's it. That's the file. HEAD is just a pointer telling Git which branch you're on. When you run git checkout feature-branch, Git rewrites this file:

ref: refs/heads/feature-branch

When you check out a specific commit (detached HEAD state), it changes to:

a3f2d8b9c1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8

Mind-blowing realization #1: Your "current branch" is just a text file containing a reference.

refs/: Where Branches Live

Look inside the refs directory:

tree .git/refs/

.git/refs/
├── heads/
│   ├── main
│   ├── feature-auth
│   └── bugfix-login
├── remotes/
│   └── origin/
│       ├── main
│       └── develop
└── tags/
    └── v1.0.0

Each branch is just a file containing a commit hash. Let's prove it:

cat .git/refs/heads/main

Output:

f3e4d5c6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2

That's your latest commit on main. That's literally what a branch is—a 40-character hash pointing to a commit.

When you create a new branch:

git branch feature-new

Git creates .git/refs/heads/feature-new and copies the current commit hash into it. That's it. No magic.

Mind-blowing realization #2: Branches are just files with commit hashes. Creating a branch is almost free because it's just writing 40 bytes to a file.

objects/: Git's Time Machine

This is where the real magic happens. The objects/ directory is Git's database—every commit, every file, every version you've ever created lives here.

ls .git/objects/

00/  0f/  1a/  2b/  3c/  4d/  5e/  6f/  7a/  8b/  9c/  ...
info/  pack/

Those two-character directories? They're organizing objects by their hash prefix (for performance). Let's look deeper:

ls .git/objects/a3/

f2d8b9c1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8

Combine the directory name with the filename: a3f2d8b9c1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8

That's a complete SHA-1 hash. But what is it?

What's a Git Object?

Git stores everything as objects. There are only four types:

1. Blob - File contents

2. Tree - Directory structure

3. Commit - Snapshot in time

4. Tag - Named reference (annotated tags)

You can inspect any object:

git cat-file -t a3f2d8b9  # Type
git cat-file -p a3f2d8b9  # Content

The Three Types of Objects

Let's see them in action. I'll create a simple file and commit it:

echo "Hello Git" > test.txt
git add test.txt
git commit -m "Add test file"

Now let's follow the trail.

1. The Commit Object

git cat-file -p HEAD

Output:

tree 5e8b9c0d1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6
parent f3e4d5c6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2
author John Doe <john@example.com> 1733654400 +0000
committer John Doe <john@example.com> 1733654400 +0000

Add test file

The commit points to a tree (the directory structure) and has metadata (author, timestamp, message).

2. The Tree Object

git cat-file -p 5e8b9c0d1a2b

Output:

100644 blob a3f2d8b9c1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8    test.txt
100644 blob 7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6    README.md
040000 tree b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7    src/

The tree lists files (blobs) and subdirectories (trees). It's like a snapshot of ls -l.

3. The Blob Object

git cat-file -p a3f2d8b9c1e4

Output:

Hello Git

The blob is just the file contents. No filename, no metadata—pure content.

Mind-blowing realization #3: Git doesn't store diffs. It stores complete snapshots. Every commit points to a full tree of all files.

Following the Chain

Here's how it connects:

HEAD
  ↓
refs/heads/main (contains: f3e4d5c6...)
  ↓
Commit f3e4d5c6...
  ├── tree 5e8b9c0d...
  │     ├── blob a3f2d8b9... (test.txt)
  │     ├── blob 7a8b9c0d... (README.md)
  │     └── tree b9c0d1e2... (src/)
  └── parent e2f3a4b5... (previous commit)

When you run git log, Git walks this chain backwards through parent commits.

index: The Staging Area Revealed

The staging area isn't virtual—it's a binary file:

file .git/index

Output:

.git/index: Git index, version 2, 3 entries

When you run git add, Git:

1. Creates a blob object for the file

2. Updates the index to point to that blob

3. Doesn't create a commit yet

You can peek inside (it's binary, but git can read it):

git ls-files --stage

Output:

100644 a3f2d8b9c1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8 0   test.txt
100644 7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6 0    README.md

Each entry shows: permissions, blob hash, stage number, and filename.

Mind-blowing realization #4: git add creates the object immediately. The staging area is just a list of "these blobs should be in the next commit."

config: Your Repository Settings

Open .git/config:

cat .git/config

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = git@github.com:username/repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "main"]
    remote = origin
    merge = refs/heads/main

[user]
    name = John Doe
    email = john@example.com

This is where git config --local writes settings. Global settings live in ~/.gitconfig, but repository-specific overrides live here.

Want to change your email for just this project?

git config user.email "work@company.com"

Check the file—it's been updated.

hooks/: Automation Paradise

The hooks/ directory contains scripts that run automatically on git events:

ls .git/hooks/

applypatch-msg.sample
pre-commit.sample
pre-push.sample
prepare-commit-msg.sample
post-commit.sample
...

Remove the .sample extension to activate a hook. For example, create .git/hooks/pre-commit:

#!/bin/bash
# Run tests before every commit

npm test
if [ $? -ne 0 ]; then
    echo "Tests failed! Commit aborted."
    exit 1
fi

Make it executable:

chmod +x .git/hooks/pre-commit

Now every git commit runs your tests first. If they fail, the commit is blocked.

Popular hooks:

• pre-commit - Lint code, run tests

• commit-msg - Enforce commit message format

• pre-push - Run full test suite before pushing

• post-merge - Install dependencies after pulling