Step 1. Measure how much AI you actually use

Before changing anything, you need visibility. Most developers have no idea how many requests they send or how much context they include.

Start by logging your usage patterns manually for one day.

# Create a simple tracking file
touch ai-usage.log

Then every time you send a request, append a line:

echo "Claude | Debugging | Large context | 1500 tokens approx" >> ai-usage.log

You are not aiming for precision. You are mapping behavior. By the end of the day, you will see patterns like repeated long conversations or unnecessary context reuse.

This matters because token cost scales with input size and conversation length. Long sessions are the hidden cost driver.

Step 2. Split your workflow into AI-required and non-AI tasks

Right now most developers use AI for everything. That is no longer viable when each request has a cost.

Create two clear categories in your workflow.

AI_REQUIRED:
- Complex debugging
- Architecture decisions
- Refactoring across multiple files

NO_AI:
- Writing simple functions
- Minor UI tweaks
- Reading logs

This forces a decision before every request. You stop treating AI as a default and start using it as a targeted tool.

Teams that do this typically reduce token usage by 30 to 50 percent without losing output.

Step 3. Replace long conversations with stateless prompts

The biggest cost mistake is continuing long threads. Every new message resends the entire context.

Instead, move to stateless prompts where each request is self-contained.

BAD:
"Here is the entire component again. Still broken. Fix it."

GOOD:
"Fix this specific bug: WebSocket disconnect after 30s. Relevant code below:"

// Only include what matters
function connectWebSocket() {
  const ws = new WebSocket(url)

  ws.onclose = () => {
    setTimeout(connectWebSocket, 1000)
  }
}

Shorter prompts reduce token usage immediately and often improve response quality.

If you want to go deeper into how AI actually affects productivity and where it breaks down, the uncomfortable truth about AI productivity connects directly to why long conversations become inefficient over time.

After this step, you should see shorter responses and fewer retries.

Step 4. Introduce a local model for low-value tasks

Not every task needs a frontier model. A large portion of your daily work can run locally.

Install a local model runtime:

# Example with Ollama
curl -fsSL https://ollama.com/install.sh | sh
ollama run mistral

Use it for predictable tasks:

- Generate unit tests
- Convert code formats
- Write boilerplate

Example:

ollama run mistral "Generate Jest tests for this function:"

This step offloads 50 to 70 percent of your requests away from paid APIs.

You are reserving expensive tokens for high-leverage work.

Step 5. Add a token budget to your workflow

Once pricing becomes visible, you need a limit. Otherwise usage expands to fill the available budget.

Define a simple monthly cap:

Monthly AI budget: $100
Daily working days: 20
Daily budget: $5

Track against it:

echo "Day 3: $4.20 used" >> ai-budget.log

This creates immediate feedback. If you burn through your budget early in the day, you adjust behavior.

This is the same model used in cloud infrastructure. AI is becoming another metered resource.

Step 6. Refactor your coding habits to reduce dependency

This is the step most developers skip, and it is where the real leverage is.

Reintroduce manual problem solving deliberately:

Daily routine:
- 30 minutes debugging without AI
- 1 feature implemented manually
- Only escalate to AI if blocked

Example workflow:

1. Try to fix bug manually
2. Read stack trace
3. Identify root cause
4. Only then ask AI for optimization or alternative

This rebuilds core skills that degrade when AI is always available.

Developers who maintain this balance adapt faster when access is limited or expensive.

Step 7. Optimize prompts for cost efficiency

Not all prompts are equal. Structure directly impacts token usage and output quality.

Use this format:

Context:
<minimal relevant code>

Task:
<specific request>

Constraints:
<edge cases or requirements>

Example:

Context:
Node.js API route returning 500 on large payload

Task:
Identify root cause and fix

Constraints:
Must support payloads up to 5MB

This reduces unnecessary back-and-forth and prevents repeated queries.

Efficient prompting is becoming a measurable skill, not just a convenience.

Step 8. Monitor output versus cost

At this stage, your workflow is structured. Now you need to validate efficiency.

Track two metrics:

- Features shipped per week
- AI cost per week

Example:

Week 1:
Features: 5
AI cost: $40

Week 2:
Features: 5
AI cost: $22

If output stays constant while cost drops, your system is working.

If output drops, you cut too aggressively and need to reintroduce AI in high-impact areas.

You now have a workflow where AI is integrated but controlled. You are no longer dependent on unlimited tokens or vulnerable to pricing changes. The next step is applying this system in a real project and refining your budget and prompt strategy based on actual usage.

Step 1. Extract the raw job description into a structured format

Before you can filter anything, you need to stop reading job posts as unstructured text. Convert them into a consistent structure so you can scan quickly.

function parseJobDescription(text) {
  return {
    title: extract(text, /title/i),
    location: extract(text, /location/i),
    requirements: extract(text, /requirements/i),
    restrictions: extract(text, /(must|required|only|authorized|timezone|visa)/gi),
    notes: text
  };
}

At this stage, you are not evaluating anything. You are isolating signals. The key is to separate “marketing text” from “filtering conditions.”

Step 2. Check for geographic lockout first

This is the fastest hard filter. If the job requires a specific country or region, everything else becomes irrelevant.

function checkGeographicRestriction(job) {
  const patterns = [
    /US only/i,
    /EU only/i,
    /UK only/i,
    /must be based in/i,
    /authorized to work in/i
  ];

  return patterns.some(p => p.test(job.notes));
}

If this returns true and your location does not match, stop immediately.

Most remote jobs are not actually global. Only a small fraction are truly open worldwide . This step alone can eliminate the majority of useless applications.

Step 3. Detect timezone constraints that look optional but are not

Timezone requirements often look flexible but behave like hard constraints in practice.

function checkTimezoneRestriction(job) {
  const patterns = [
    /must work in .* time/i,
    /timezone overlap/i,
    /business hours/i,
    /\d{1,2}\s?(AM|PM)\s?to\s?\d{1,2}\s?(AM|PM)/i
  ];

  return patterns.some(p => p.test(job.notes));
}

If you see strict overlap windows, calculate your real working hours before applying.

If your schedule would shift into evenings or nights long-term, treat this as a rejection signal, not a “maybe.”

At this point, your filtering logic starts to resemble how ATS systems operate, which is exactly what you want. If you want a deeper understanding of how automated filters behave, this breakdown of the AI-driven hiring pipeline for JavaScript developers helps explain why location is evaluated before skills.

Step 4. Identify hidden EOR and tax entity restrictions

This is where most developers lose time without realizing it. Jobs may say “worldwide” but still filter by country behind the scenes.

function checkEORRestriction(job) {
  const patterns = [
    /EOR/i,
    /Employer of Record/i,
    /Deel/i,
    /Remote.com/i,
    /Oyster/i,
    /subject to location/i
  ];

  return patterns.some(p => p.test(job.notes));
}

If this triggers, you need to manually verify whether your country is supported by the hiring platform.

This step prevents invisible rejections. Many candidates never realize they were filtered by a third-party hiring system.

Step 5. Scan for language requirements beyond English

Language constraints are often buried in the middle of the description.

function checkLanguageRestriction(job) {
  const patterns = [
    /German/i,
    /French/i,
    /Spanish/i,
    /Dutch/i,
    /fluent in/i,
    /working proficiency/i
  ];

  return patterns.some(p => p.test(job.notes));
}

If a second language is required and you do not meet it, treat it as a hard stop.

Do not assume English is enough. Many teams operate internally in another language even if the codebase is English.

Step 6. Check for visa or travel requirements

Some roles are technically remote but require physical presence occasionally.

function checkVisaRestriction(job) {
  const patterns = [
    /must be able to travel/i,
    /quarterly onsite/i,
    /annual meetup/i,
    /visa required/i
  ];

  return patterns.some(p => p.test(job.notes));
}

If travel is required and you cannot easily obtain a visa, this is effectively a geographic restriction.

Treat it the same way as Step 2.

Step 7. Combine everything into a 30-second filter function

Now you connect all checks into a single decision system.

function shouldApply(jobText) {
  const job = parseJobDescription(jobText);

  if (checkGeographicRestriction(job)) return false;
  if (checkTimezoneRestriction(job)) return false;
  if (checkEORRestriction(job)) return false;
  if (checkLanguageRestriction(job)) return false;
  if (checkVisaRestriction(job)) return false;

  return true;
}

This function represents your decision boundary.

If it returns false, you close the tab immediately. No second guessing. No “maybe I will try anyway.”

If it returns true, only then do you invest time in tailoring your application.

Step 8. Apply only to filtered jobs with full effort

Once a job passes all filters, your strategy changes completely.

function applyWithFocus(job) {
  return {
    research: true,
    tailoredResume: true,
    coverLetter: true,
    followUp: true
  };
}

At this point, you are no longer competing randomly. You are applying only to roles where you are not disqualified by default.

This is where most developers fail. They invert the process. They optimize resumes first and filtering last.

You do the opposite.

After implementing this system, you end up with fewer applications but significantly higher response rates. You stop competing in pools where you were never eligible in the first place.

From here, the next step is refining how you stand out inside the filtered pool. The constraints do not disappear. They just move from legal filters to competitive ones.

Step 1. Strip out the company marketing section

Most job postings start with 300 to 500 words about the company. This section does not help you understand the role and often hides weak requirement definitions

Create a quick script or mental filter to skip everything before the first technical keyword.

const extractRelevantSection = (text) => {
  const keywords = ["Requirements", "Responsibilities", "Tech stack", "You will"];
  const lines = text.split("\n");

  const startIndex = lines.findIndex(line =>
    keywords.some(keyword => line.toLowerCase().includes(keyword.toLowerCase()))
  );

  return startIndex !== -1 ? lines.slice(startIndex).join("\n") : text;
};

At this step, you reduce cognitive noise. You are left with the part that actually describes the job. Verify that you can clearly identify technologies and responsibilities. If not, that is already a negative signal.

Step 2. Extract the core tech stack and ignore the rest

Many postings list 8 to 12 technologies. In reality, only 2 to 3 define the role. The rest are often noise or internal wishlist items

Parse and prioritize technologies based on frequency and positioning.

const extractCoreStack = (text) => {
  const stack = ["react", "vue", "angular", "node", "typescript", "python", "aws"];
  
  const counts = stack.reduce((acc, tech) => {
    const regex = new RegExp(`\\b${tech}\\b`, "gi");
    acc[tech] = (text.match(regex) || []).length;
    return acc;
  }, {});

  return Object.entries(counts)
    .sort((a, b) => b[1] - a[1])
    .slice(0, 3)
    .map(([tech]) => tech);
};

You now have the real stack. For example, if React and TypeScript dominate, treat the job as a React role even if it also lists Python and C#.

Verify that the extracted stack aligns with your experience. If not, decide quickly whether to skip or adapt.

Step 3. Normalize vague requirements into actionable skills

Job postings often use phrases like “strong experience” or “modern frameworks” with no detail. You need to translate these into concrete expectations.

const normalizeRequirements = (requirements) => {
  const mapping = {
    "strong react skills": "build production React apps with hooks, state management, API integration",
    "modern javascript": "ES6+, async patterns, modules, bundlers",
    "experience with apis": "REST or GraphQL integration, error handling, auth"
  };

  return requirements.map(req => {
    const key = req.toLowerCase();
    return mapping[key] || req;
  });
};

This step forces clarity. Instead of abstract phrases, you now have tasks you can demonstrate.

If you want a deeper breakdown of how hiring signals actually work, the JavaScript job search patterns in 2026 directly affect how you interpret these requirements.

Verify that each requirement can be mapped to something you have built or can quickly build.

Step 4. Build a targeted project or proof for one role

Instead of applying with a generic portfolio, create a small focused project that matches the extracted stack.

// Example: React + TypeScript + API integration
import { useEffect, useState } from "react";

type User = {
  id: number;
  name: string;
};

export default function Users() {
  const [users, setUsers] = useState<User[]>([]);

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

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

This is not about complexity. It is about alignment. The closer your project matches the job, the easier it is for a hiring manager to say yes.

Verify that your project demonstrates at least one real requirement from the posting.

Step 5. Rewrite your resume for that specific posting

Generic resumes fail because they do not match the filtered requirements. You should adjust keywords and examples per role.

Before:
- Built web applications using JavaScript

After:
- Built React + TypeScript application with API integration and async state handling

Focus on outcomes and technologies that match the extracted stack. Ignore unrelated experience even if it is impressive.

Verify that every bullet point in your resume connects to the job description.

Step 6. Apply only when the signal is clear

Some postings are too vague or contradictory. These usually indicate unclear internal requirements and lead to mismatched roles after hiring

Create a simple filter.

const shouldApply = (job) => {
  const hasClearStack = job.coreStack.length >= 2;
  const hasDefinedResponsibilities = job.text.includes("build") || job.text.includes("develop");

  return hasClearStack && hasDefinedResponsibilities;
};

If you cannot identify what you would be doing daily, skip the role. This saves time and reduces frustration.

Verify that the job passes your clarity threshold before investing effort.

Step 7. Iterate based on feedback or silence

In a competitive market, even strong applications may get no response. The key is to iterate, not randomize.

const improveStrategy = (applications) => {
  return applications.map(app => ({
    ...app,
    improved: true,
    adjustments: ["better project alignment", "clearer resume keywords"]
  }));
};

Track which roles you applied to and adjust based on patterns. If React roles respond more than others, double down.

Verify that each iteration improves alignment, not volume.

At the end of this process, you are no longer reacting to job postings. You are filtering them, extracting signal, and aligning your profile intentionally. The next step is to scale this across multiple roles while maintaining precision.

Step 1. Create your first closure and verify persistence

You need a minimal example that proves a variable survives after a function returns. Without this, everything else feels abstract.

function createCounter() {
  let count = 0;

  return function increment() {
    count = count + 1;
    return count;
  };
}

const counter = createCounter();

console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

You just created a closure. The inner function keeps access to count even after createCounter has finished. Verify that calling createCounter again gives a fresh counter with its own state.

Step 2. Inspect the closure in DevTools to see the environment

Understanding comes from seeing the captured environment, not memorizing definitions. Use the debugger to make the invisible visible.

function createCounter() {
  let count = 0;

  return function increment() {
    debugger;
    count = count + 1;
    return count;
  };
}

const counter = createCounter();
counter();

Run this in the browser and open DevTools. When execution pauses, look at the Scope panel. You will see a "Closure" section containing count.

This confirms the key idea. The function carries a reference to its variable environment. The variable is not copied. It is referenced.

Step 3. Build the full scope chain and trace variable resolution

Closures are rarely flat. Real code involves multiple nested scopes. You need to see how the engine walks the chain.

const globalValue = "global";

function outer() {
  const outerValue = "outer";

  function middle() {
    const middleValue = "middle";

    function inner() {
      console.log(globalValue);
      console.log(outerValue);
      console.log(middleValue);
    }

    return inner;
  }

  return middle();
}

const fn = outer();
fn();

Each lookup walks upward until it finds the variable. This chain is preserved because inner still exists.

If you want to understand how this affects real applications, especially long running processes, the Node.js memory leaks detection and resolution guide explains how retained closures show up in heap snapshots and why they are hard to trace.

At this point, you should be able to explain where each variable lives and why it is still accessible.

Step 4. Reproduce the classic closure bug with loops

Now you intentionally break things. This is critical because most production bugs come from misunderstanding how variables are shared.

function attachHandlers() {
  const buttons = document.querySelectorAll("button");

  for (var i = 0; i < buttons.length; i++) {
    buttons[i].addEventListener("click", function () {
      console.log(i);
    });
  }
}

Every button logs the same number. The reason is that var creates one shared variable across all iterations.

Fix it using let.

function attachHandlers() {
  const buttons = document.querySelectorAll("button");

  for (let i = 0; i < buttons.length; i++) {
    buttons[i].addEventListener("click", function () {
      console.log(i);
    });
  }
}

Now each iteration gets its own binding. Each closure captures a different environment.

Verify this in the browser by clicking multiple buttons. This step forces you to connect theory with actual behavior.

Step 5. Reproduce a real React stale closure problem

Closures become dangerous in frameworks because they interact with rendering cycles. This is where many developers get stuck.

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

  React.useEffect(() => {
    const id = setInterval(() => {
      console.log(count);
    }, 1000);

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

  return (
    <button onClick={() => setCount(count + 1)}>
      {count}
    </button>
  );
}

The interval always logs 0. The closure captured count from the first render.

Fix it by adding dependencies.

React.useEffect(() => {
  const id = setInterval(() => {
    console.log(count);
  }, 1000);

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

Or use a ref to store the latest value.

const countRef = React.useRef(count);

React.useEffect(() => {
  countRef.current = count;
}, [count]);

React.useEffect(() => {
  const id = setInterval(() => {
    console.log(countRef.current);
  }, 1000);

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

Verify by clicking the button. The logged value should now update correctly. This step connects closures to real frontend bugs.

Step 6. Prevent memory leaks caused by closures

Closures can keep more data than you expect. This becomes a problem in Node or long running apps.

function createProcessor() {
  const hugeData = new Array(1000000).fill("data");

  const map = {};
  hugeData.forEach((item, index) => {
    map[index] = item;
  });

  return function getItem(id) {
    return map[id];
  };
}

const processor = createProcessor();

Even though getItem only uses map, the entire hugeData array stays in memory.

Fix this by limiting the scope.

function createProcessor() {
  const map = (function () {
    const hugeData = new Array(1000000).fill("data");

    const result = {};
    hugeData.forEach((item, index) => {
      result[index] = item;
    });

    return result;
  })();

  return function getItem(id) {
    return map[id];
  };
}

Now hugeData is discarded after the IIFE runs. Only map is captured.

Verify memory usage using Chrome DevTools heap snapshots or Node inspector. You should see a significantly smaller retained size.

Step 7. Implement a real closure-based utility

You now combine everything into a practical pattern. Debounce is a standard example that requires correct closure handling.

function debounce(fn, delay) {
  let timeoutId;

  return function (...args) {
    clearTimeout(timeoutId);

    timeoutId = setTimeout(() => {
      fn.apply(this, args);
    }, delay);
  };
}

const log = debounce((value) => {
  console.log(value);
}, 500);

log("a");
log("b");
log("c");

Only the last call executes. The closure stores timeoutId across invocations.

Verify by calling the function multiple times quickly. You should see only the final value logged.

This step proves you can use closures intentionally, not just debug them.

You now have a working mental model of closures, scope chains, stale state, and memory retention. You can build them, inspect them, break them, and fix them.

The next step is applying this consistently in your codebase, especially in React hooks and long running Node services where closure mistakes are expensive.

Step 1. Define constraints before looking at options

Most bad decisions start with comparing features instead of constraints. You need to narrow the decision space before evaluating anything.

type Constraints = {
  teamExperience: string[];
  deadlineWeeks: number;
  performanceRequirement: 'low' | 'medium' | 'high';
  environment: 'browser' | 'node' | 'edge';
};

const constraints: Constraints = {
  teamExperience: ['React', 'TypeScript'],
  deadlineWeeks: 4,
  performanceRequirement: 'medium',
  environment: 'browser',
};

This forces you to anchor the decision in reality. If your team has zero experience with a tool and you have a tight deadline, that tool is already a weak candidate.

Before moving on, confirm that your constraints reflect real limitations. Not assumptions.

Step 2. Run the 5-minute npm validation

Every dependency is a risk. This step filters out weak or dangerous options quickly.

# Example checks you should run manually
npm view zustand downloads
npm view zustand version

# Then open:
# https://www.npmjs.com/package/zustand
# https://github.com/pmndrs/zustand

You are checking four things:

• Download trend

• Last commit recency

• Issue responsiveness

• Dependency count

If a package fails two or more checks, eliminate it immediately.

At this point, you should have 2 to 4 viable options left. Not 10.

Step 3. Build a weighted decision matrix

Now you compare options using your actual context, not generic opinions.

type OptionScore = {
  name: string;
  familiarity: number;
  bundleSize: number;
  ecosystem: number;
  learningCurve: number;
};

const weights = {
  familiarity: 0.3,
  bundleSize: 0.2,
  ecosystem: 0.3,
  learningCurve: 0.2,
};

const options: OptionScore[] = [
  { name: 'Zustand', familiarity: 8, bundleSize: 9, ecosystem: 8, learningCurve: 9 },
  { name: 'Redux Toolkit', familiarity: 10, bundleSize: 6, ecosystem: 10, learningCurve: 6 },
];

function calculateScore(option: OptionScore) {
  return (
    option.familiarity * weights.familiarity +
    option.bundleSize * weights.bundleSize +
    option.ecosystem * weights.ecosystem +
    option.learningCurve * weights.learningCurve
  );
}

options.map(o => ({ name: o.name, score: calculateScore(o) }));

The key is not the scores. It is the weights.

If your team already knows Redux, familiarity might be 40 percent. If bundle size matters for mobile, increase its weight.

At this stage, you should see a clear winner or at least eliminate one option.

Step 4. Apply the “build vs install” test

Before committing to any library, ask whether you even need it.

// Example: simple utility instead of dependency
export function formatRelativeTime(date: Date): string {
  const now = new Date();
  const diffMs = now.getTime() - date.getTime();
  const diffMins = Math.floor(diffMs / 60000);

  if (diffMins < 1) return 'just now';
  if (diffMins < 60) return `${diffMins}m ago`;

  const diffHours = Math.floor(diffMs / 3600000);
  if (diffHours < 24) return `${diffHours}h ago`;

  return date.toLocaleDateString();
}

If you can implement the functionality in under 50 lines and fully understand it, building is often safer.

If the problem involves edge cases, performance, or standards, installing is usually correct.

If you are working on larger systems, understanding how architectural decisions compound over time helps avoid unnecessary complexity. The JavaScript application architecture in 2026 patterns show how these small choices scale into system-wide impact.

Before moving on, confirm that you are not installing something out of habit.

Step 5. Set a strict decision time limit

The most common failure mode is over-analysis.

const decisionTimeLimit = {
  library: '60 minutes',
  framework: '4 hours',
  architecture: '1 day',
};

Set a timer and commit to deciding within that window.

The first 30 minutes eliminates bad options. The next 30 minutes refines the best one. Beyond that, you are optimizing edge cases that may never matter.

If you cannot decide within the time limit, it usually means your constraints are unclear.

Step 6. Document the decision with an ADR

This step prevents future confusion and repeated debates.

# ADR-001: State Management Choice

## Status
Accepted

## Context
Dashboard with 10 widgets sharing filters.
Team of 3 React developers.

## Decision
Use Zustand.

## Alternatives
- Redux Toolkit: familiar but more boilerplate
- Context API: causes unnecessary re-renders

## Consequences
- Faster implementation
- Smaller ecosystem than Redux

This takes 10 to 15 minutes and saves hours later.

Without this, you will revisit the same decision in two weeks when someone questions it.

Step 7. Validate with a small proof of concept

Before fully committing, test the chosen option in isolation.

// Example: quick Zustand proof
import { create } from 'zustand';

type Store = {
  count: number;
  increment: () => void;
};

export const useStore = create<Store>((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

Build a minimal use case that reflects your real application.

This step catches integration issues early, before the decision becomes expensive to reverse.

Verify that:

• The API feels intuitive

• It integrates with your stack

• It does not introduce unexpected complexity

Step 8. Move forward and stop revisiting the decision

Once chosen, commit and build.

const decision = {
  selected: 'Zustand',
  date: new Date(),
  revisitIf: 'performance issues or scaling problems',
};

Do not reopen the discussion unless you have new evidence.

Revisiting decisions without new data is how teams lose weeks.

If the decision turns out to be wrong, you will have real context from usage, not speculation.

After completing this process, you have a defensible decision made quickly, with documented reasoning and minimal risk. The next step is applying the same workflow consistently across your project so decisions compound into clarity instead of chaos.

Step 1. Create the target folder structure before moving anything

You need a clear destination before touching existing files. Without this, you will move files twice and break imports repeatedly.

mkdir -p src/features
mkdir -p src/shared/components
mkdir -p src/shared/hooks
mkdir -p src/shared/utils
mkdir -p src/shared/types
mkdir -p src/lib

At this point, you are not moving any code. You are defining boundaries. Verify that your app still runs exactly the same before continuing.

Step 2. Configure subpath imports to avoid breaking imports during migration

Relative imports will explode as soon as you start moving files. Fix this first.

// package.json
{
  "type": "module",
  "imports": {
    "#/*": "./src/*"
  }
}

// tsconfig.json
{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "#/*": ["src/*"]
    }
  }
}

Now replace a few imports manually to verify:

// before
import { Button } from '../../../components/Button';

// after
import { Button } from '#/shared/components/Button';

If your app compiles and runs, you are ready. This step prevents cascading breakage later.

Step 3. Move one small feature as a proof of concept

Do not migrate the entire project. Pick one isolated feature, something like auth or jobs.

mkdir -p src/features/auth/components
mkdir -p src/features/auth/hooks
mkdir -p src/features/auth/api
mkdir -p src/features/auth/types

Move files:

mv src/components/LoginForm.tsx src/features/auth/components/LoginForm.tsx
mv src/hooks/useAuth.ts src/features/auth/hooks/useAuth.ts
mv src/api/auth.ts src/features/auth/api/auth.ts
mv src/types/auth.ts src/features/auth/types/auth.ts

Update imports:

import { useAuth } from '#/features/auth/hooks/useAuth';

At this step you will notice how scattered your feature was before. This is exactly the problem you are solving.

If you want to understand why navigating large codebases becomes slow without this structure, the guide to reading large JavaScript codebases explains how developers mentally reconstruct features across folders.

Run the app. If everything works, your migration pattern is validated.

Step 4. Add a barrel export to define feature boundaries

Without a public API, other parts of your app will import internal files directly again.

// src/features/auth/index.ts
export { LoginForm } from './components/LoginForm';
export { useAuth } from './hooks/useAuth';
export * from './types/auth';

Now update imports:

// GOOD
import { LoginForm, useAuth } from '#/features/auth';

// BAD
import { LoginForm } from '#/features/auth/components/LoginForm';

This step prevents tight coupling. If you later refactor internal files, nothing outside the feature breaks.

Verify that your imports resolve correctly and nothing is importing deep internal paths anymore.

Step 5. Introduce shared folder rules and move common code

Now that one feature is clean, identify duplicated or shared logic.

Move only what is used by multiple features.

mv src/components/Button.tsx src/shared/components/Button.tsx
mv src/hooks/useDebounce.ts src/shared/hooks/useDebounce.ts
mv src/utils/formatDate.ts src/shared/utils/formatDate.ts

Update imports:

import { Button } from '#/shared/components/Button';
import { useDebounce } from '#/shared/hooks/useDebounce';

Do not overdo this. If something is used by one feature, it stays inside that feature.

At this step, you should see a clear separation:

• features contain business logic

• shared contains reusable primitives

Run the app again and confirm no regressions.

Step 6. Migrate remaining features incrementally

Repeat the same pattern feature by feature. Never do everything at once.

mkdir -p src/features/jobs
mv src/components/JobCard.tsx src/features/jobs/components/JobCard.tsx
mv src/hooks/useJobSearch.ts src/features/jobs/hooks/useJobSearch.ts
mv src/api/jobs.ts src/features/jobs/api/jobs.ts

Each migration should follow the same checklist:

# 1. Move files
# 2. Fix imports
# 3. Add index.ts
# 4. Run app
# 5. Commit

This avoids massive pull requests and keeps your codebase stable during the transition.

Teams typically migrate a 20 to 30 feature codebase in a few days using this approach.

Step 7. Clean up and enforce structure rules

Once most features are migrated, enforce the architecture so it does not degrade again.

// .eslintrc.js
module.exports = {
  rules: {
    'import/no-restricted-paths': ['error', {
      zones: [
        {
          target: './src/features/auth',
          from: './src/features/jobs',
          message: 'Do not import internal files across features. Use barrel exports.'
        }
      ]
    }]
  }
};

Also remove old folders:

rm -rf src/components
rm -rf src/hooks
rm -rf src/api

At this point, your structure is consistent and enforced.

You now have a feature-based architecture where each feature is isolated, testable, and easy to navigate. New developers can open one folder and understand the system without jumping across five directories.

Next step is watching bundle size and import patterns as your app grows. The structure is stable, but how you use it determines long-term performance.

Step 1. Build your application for production

Before deployment, you need a production build. Development mode includes debugging features and unoptimized assets. Production builds generate optimized bundles that browsers can load efficiently.

npm run build

For a Vite or React app, this creates a dist/ directory with static files. For Next.js, it creates a .next/ folder with both server and client code.

After this step, verify that the build completes without errors. If it fails locally, it will fail in production.

Step 2. Decide if your app is static or requires a server

This determines your hosting strategy. Static apps can be deployed to a CDN. Server-side apps need a runtime like Node.js.

# Example: check if your app runs as static
npm run preview

If your app works entirely from built files like dist/index.html, it is static. If it depends on API routes, server components, or backend logic, it requires a server.

At this step, confirm whether you need Node.js in production. This decision affects everything that follows.

Step 3. Configure environment variables correctly

Environment variables separate sensitive configuration from code. Misconfiguration here is one of the most common production failures.

# .env.local

DATABASE_URL=postgresql://user:password@host:5432/db
API_SECRET=supersecret

NEXT_PUBLIC_API_URL=https://api.example.com

// Server-side usage
const db = process.env.DATABASE_URL;

// Client-side usage
const apiUrl = process.env.NEXT_PUBLIC_API_URL;

Variables without a public prefix remain server-only. Anything prefixed is exposed to the browser.

If you want a deeper breakdown of how environment variables interact with build systems and deployment pipelines, the CI/CD for JavaScript Developers in 2026 article explains how this step fits into automated deployments.

Before moving on, verify that your app runs locally using only environment variables. Remove hardcoded secrets.

Step 4. Deploy a static app or set up a server

Choose the correct deployment path based on your app type.

For static apps, deploy directly to a platform like Vercel:

npm install -g vercel
vercel login
vercel --prod

For Node.js apps, set up a server:

ssh root@your-server-ip

apt update && apt upgrade -y

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
source ~/.bashrc
nvm install 22

npm install -g pm2

git clone https://github.com/your-username/your-app.git
cd your-app
npm install
npm run build

pm2 start npm --name "app" -- start
pm2 save
pm2 startup

Static deployment gives you instant global distribution. Server deployment gives you full control.

At this step, confirm your app is accessible via IP or temporary domain.

Step 5. Add Nginx and HTTPS

Users should not access your app on port 3000. You need a reverse proxy and TLS encryption.

# /etc/nginx/sites-available/app
server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

ln -s /etc/nginx/sites-available/app /etc/nginx/sites-enabled/
nginx -t
systemctl restart nginx

Now enable HTTPS:

apt install certbot python3-certbot-nginx -y
certbot --nginx -d yourdomain.com

This configures TLS, redirects HTTP to HTTPS, and sets up automatic renewal.

After this step, your app should be accessible via your domain over HTTPS.

Step 6. Set up CI/CD for automatic deployment

Manual deployment does not scale. You need automation to prevent broken releases.

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /var/www/app
            git pull origin main
            npm ci --production
            npm run build
            pm2 reload app

This pipeline ensures that code is tested before deployment. If tests fail, deployment stops.

At this stage, push a commit to main and verify that deployment happens automatically.

Step 7. Add monitoring and rollback capability

Deployment is not complete without observability and recovery.

import * as Sentry from '@sentry/node';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
});

# Rollback example
git checkout <previous-commit>
npm ci
npm run build
pm2 reload app

Monitoring tools detect errors in production. Rollbacks allow you to recover quickly.

Before finishing, simulate a rollback. Do not wait for a real incident to test this.

You now have a complete deployment pipeline. Your app builds correctly, runs in production, deploys automatically, and can recover from failures. The next step is optimizing performance and scaling infrastructure once real users start hitting your application.

Step 1. Replace Promise.all with Promise.allSettled for independent calls

Most apps start with Promise.all. That breaks as soon as one API fails because everything fails together. In real systems, partial data is usually better than no data.

async function loadDashboard() {
    const results = await Promise.allSettled([
        fetchUsers(),
        fetchOrders(),
        fetchAnalytics(),
    ]);

    return {
        users: results[0].status === 'fulfilled' ? results[0].value : null,
        orders: results[1].status === 'fulfilled' ? results[1].value : null,
        analytics: results[2].status === 'fulfilled' ? results[2].value : null,
        errors: results
            .filter(r => r.status === 'rejected')
            .map(r => r.reason),
    };
}

This ensures one failing service does not take down the entire page. Verify this by forcing one API to fail and confirming the rest still render.

Step 2. Add retry with exponential backoff for unstable APIs

External services fail. If you do not retry, your system becomes fragile. If you retry incorrectly, you can overload services.

async function withRetry<T>(
    fn: () => Promise<T>,
    maxAttempts = 3
): Promise<T> {
    for (let attempt = 1; attempt <= maxAttempts; attempt++) {
        try {
            return await fn();
        } catch (error) {
            if (attempt === maxAttempts) throw error;

            const delay = Math.min(1000 * Math.pow(2, attempt - 1), 10000);
            await new Promise(res => setTimeout(res, delay));
        }
    }

    throw new Error('Unreachable');
}

Wrap unstable calls like payments or external APIs. Confirm behavior by simulating a temporary failure and watching retries happen with increasing delays.

Step 3. Introduce request cancellation with AbortController

Without cancellation, your app suffers from race conditions and wasted requests. This is critical in React and any UI-driven system.

function useSearch(query: string) {
    const [results, setResults] = useState([]);

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

        async function run() {
            try {
                const res = await fetch(`/api/search?q=${query}`, {
                    signal: controller.signal,
                });
                const data = await res.json();
                setResults(data.results);
            } catch (e) {
                if (e.name !== 'AbortError') {
                    console.error(e);
                }
            }
        }

        run();

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

    return results;
}

At this stage, you prevent stale requests from overwriting new ones. If you want to go deeper into failure handling patterns that interact with cancellation and retries, this connects directly with how production error handling is structured in real systems like described in .

Step 4. Add timeout protection for slow requests

Some requests hang. Users should not wait indefinitely. Introduce timeouts to enforce limits.

async function fetchWithTimeout(url: string, timeout = 5000) {
    const controller = new AbortController();
    const id = setTimeout(() => controller.abort(), timeout);

    try {
        const res = await fetch(url, { signal: controller.signal });
        return await res.json();
    } catch (e) {
        if (e.name === 'AbortError') {
            throw new Error('Request timed out');
        }
        throw e;
    } finally {
        clearTimeout(id);
    }
}

Test this by delaying your API artificially. You should see controlled failures instead of infinite loading states.

Step 5. Limit concurrency for large workloads

If you fire 100 requests at once, you risk hitting rate limits or exhausting resources. Introduce a concurrency limiter.

async function withConcurrencyLimit<T>(
    tasks: (() => Promise<T>)[],
    limit: number
): Promise<T[]> {
    const results: T[] = [];
    let index = 0;

    async function worker() {
        while (index < tasks.length) {
            const i = index++;
            results[i] = await tasks[i]();
        }
    }

    await Promise.all(
        Array.from({ length: limit }, () => worker())
    );

    return results;
}

Use this when processing large datasets or batch API calls. Verify by logging concurrent requests and ensuring they never exceed your limit.

Step 6. Fix multi-step async flows with compensation logic

The biggest production bug is partial success. One step succeeds, the next fails, and your system is left inconsistent.

async function processOrder(orderId: string) {
    const order = await fetchOrder(orderId);

    let payment;
    try {
        payment = await chargeCustomer(order.customerId, order.total);
    } catch {
        throw new Error('Payment failed');
    }

    try {
        const shipment = await createShipment(order.items);

        await sendConfirmation(order.customerId);

        return { payment, shipment };
    } catch (e) {
        await refundPayment(payment.id).catch(() => {
            console.error('Refund failed, manual action needed');
        });

        throw new Error('Shipment failed, payment refunded');
    }
}

This ensures your system remains consistent even when failures occur mid-process. Test this by forcing shipment failure and confirming refunds happen automatically.

Step 7. Run independent and dependent async work correctly

Most developers either run everything sequentially or everything in parallel. Production code mixes both.

async function loadData() {
    const independent = fetchAnalytics();

    const user = await fetchUser();
    const orders = await fetchOrders(user.id);

    const analytics = await independent;

    return { user, orders, analytics };
}

This reduces total execution time while respecting dependencies. Measure execution time to confirm the improvement.

You now have a system that handles partial failures, retries intelligently, cancels stale requests, enforces timeouts, limits concurrency, and protects against inconsistent state.

The next step is to integrate logging and monitoring around these patterns. Without observability, even the best async architecture will fail silently in production.

Step 1. Install TypeScript 6.0 alongside your existing setup

You do not want to upgrade blindly because TypeScript 6.0 changes defaults that can break builds immediately.

npm install -D typescript@latest

Add a temporary compatibility flag to your tsconfig.json:

{
  "compilerOptions": {
    "ignoreDeprecations": "6.0"
  }
}

This allows your project to compile while still surfacing warnings. At this stage, your goal is visibility, not correctness.

Step 2. Run the compiler in diagnostic mode

Before changing anything, you need a full list of issues introduced by the new version.

npx tsc --noEmit

You will typically see three categories of problems:

• strict mode errors

• module system mismatches

• deprecated options warnings

TypeScript 6.0 is designed as a transition release, so these warnings are intentional signals for what will break in 7.0

Do not fix everything at once. Treat this output as a checklist.

Step 3. Update your tsconfig to modern defaults

Most migration issues come from outdated configuration rather than code.

Replace your existing config with a minimal modern baseline:

{
  "compilerOptions": {
    "target": "es2022",
    "module": "esnext",
    "moduleResolution": "bundler",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "outDir": "./dist",
    "rootDir": "./src",
    "types": ["node"],
    "lib": ["es2025", "dom"]
  },
  "include": ["src/**/*"]
}

The important changes:

• strict is now enabled by default

• module is now ESM

• target moves away from ES5

If your project still relies on legacy settings like CommonJS or ES5, explicitly override them. Otherwise, align with the new defaults.

If your project architecture is tied to framework-level decisions like bundling or module resolution, the interaction is similar to what is described in the Next.js production architecture guide, where the runtime often overrides your compiler assumptions.

Step 4. Fix strict mode errors incrementally

Enabling strict mode surfaces hidden issues that previously passed silently.

Example problem:

function getUser(id) {
  return fetch(`/api/users/${id}`).then(res => res.json());
}

Error: implicit any type.

Fix:

function getUser(id: string): Promise<User> {
  return fetch(`/api/users/${id}`).then(res => res.json());
}

Another common issue:

const user = getUser("123");
console.log(user.name); // possibly undefined

Fix:

if (user) {
  console.log(user.name);
}

Work through errors one file at a time. After each fix:

npx tsc --noEmit

This keeps the feedback loop tight and prevents cascading issues.

Step 5. Resolve module system conflicts (ESM vs CommonJS)

TypeScript 6.0 defaults to ESM. Many Node.js projects still use CommonJS.

Typical error:

Module has no default export

Fix option 1: enable interop

{
  "compilerOptions": {
    "esModuleInterop": true
  }
}

Fix option 2: switch import style

import * as express from "express";

If your runtime requires CommonJS, explicitly set:

{
  "compilerOptions": {
    "module": "commonjs"
  }
}

Do not mix assumptions. Your compiler and runtime must agree.

Step 6. Remove deprecated options before they break in 7.0

TypeScript 6.0 deprecations are not optional. They will be removed entirely in the next release

Common ones to remove:

ES5 target

{
  "compilerOptions": {
    "target": "es2020"
  }
}

outFile

Remove completely. Use a bundler instead.

AMD or UMD modules

{
  "compilerOptions": {
    "module": "esnext"
  }
}

Import assertions

// old
import data from "./data.json" assert { type: "json" };

// new
import data from "./data.json" with { type: "json" };

After removing each deprecated feature, run the compiler again. Your goal is zero warnings.

Step 7. Verify Node.js types and environment compatibility

One subtle breaking change is that TypeScript no longer auto-loads Node types.

Typical error:

Cannot find name 'process'

Fix:

{
  "compilerOptions": {
    "types": ["node"]
  }
}

Install types if missing:

npm install -D @types/node

This step is often overlooked because nothing in your code changed, but the compiler behavior did.

Step 8. Test your codebase with the TypeScript 7.0 preview

Once your project compiles cleanly, you can validate future compatibility.

npm install -D @typescript/native-preview
npx tsgo --noEmit

This runs the Go-based compiler that delivers the 10x speed improvement.

If it passes, your migration is complete. If it fails, the errors will point to edge cases in type resolution or ordering.

This step is optional but valuable for teams working on large codebases where compiler performance directly impacts productivity.

Closing

You now have a TypeScript 6.0-ready project with modern configuration, no deprecated features, and compatibility with the upcoming Go-based compiler. The next step is to monitor how your build and IDE performance change when TypeScript 7.0 becomes stable.

Step 1. Set up and run the application before reading any code

If you start by reading random files, you will build the wrong mental model. You need to see how the app behaves first.

git clone <repo-url>
cd project
npm install
npm run dev

# Inspect available scripts
cat package.json | grep -A 20 '"scripts"'

Run the app in your browser and click through real flows. Open DevTools and watch network requests. You now know what the system does from a user perspective. Verify you can reproduce at least one core flow like viewing a page or submitting a form before moving on.

Step 2. Map the project structure without opening files

You are building a high-level map. Folder names and file counts reveal architecture faster than reading implementations.

# Top-level structure
ls -la src/

# Two levels deep
find src -maxdepth 2 -type d | head -40

# File type distribution
find src -name "*.tsx" | wc -l
find src -name "*.ts" | wc -l
find src -name "*.test.ts" | wc -l

Look for patterns like components, features, services, api, hooks. This tells you whether the project is component-driven or feature-based. Verify you can point to where UI, business logic, and API calls likely live.

Step 3. Identify the entry point and global architecture

Every application has a root that wires everything together. This is where you learn the stack and core abstractions in minutes.

// app/layout.tsx (Next.js example)
export default function RootLayout({ children }) {
    return (
        <html>
            <body>
                <AuthProvider>
                    <QueryProvider>
                        <ThemeProvider>
                            <Navbar />
                            {children}
                        </ThemeProvider>
                    </QueryProvider>
                </AuthProvider>
            </body>
        </html>
    );
}

From one file, you can detect authentication, data fetching, theming, and global UI. If you want a deeper breakdown of how architecture decisions affect navigation speed, the JavaScript application architecture in 2026 article explains why these abstractions matter.

Verify you can list the main providers and what responsibility each one has before moving on.

Step 4. Trace one feature end to end

Do not try to understand everything. Pick one user flow and follow it through the stack.

User clicks job listing
    → app/jobs/[id]/page.tsx
        → lib/api/jobs.ts
            → app/api/jobs/[id]/route.ts
                → lib/db/queries/jobs.ts

Open each file in that chain. Focus on how data moves, not every line. Identify where data is fetched, transformed, and rendered.

At this step, you will notice repetition. Every feature follows the same pattern with different data. Verify you can explain one full request lifecycle from UI to database and back.

Step 5. Use your IDE as a navigation engine

Manual searching does not scale in large codebases. You need to rely on tooling.

F12 → Go to Definition
Shift + F12 → Find All References
Ctrl + T → Go to Symbol
Ctrl + Shift + F → Search across files

Example workflow:

// You see this call
const job = await fetchJobById(id);

// Press F12 to jump here
export async function fetchJobById(id: string) {
    return db.job.findUnique({ where: { id } });
}

Now you can jump directly to the database layer. Use references to see who else calls this function.

Verify you can jump from UI to database and back without manually browsing folders.

Step 6. Read tests to understand behavior faster

Complex code is often easier to understand through tests than implementation.

describe('resolveFilters', () => {
    it('returns all items when no filters are applied', () => {
        const result = resolveFilters({}, config);
        expect(result.where).toEqual({});
    });

    it('filters by remote flag', () => {
        const result = resolveFilters({ remote: true }, config);
        expect(result.where.remote).toBe(true);
    });
});

Tests show expected inputs and outputs. They define behavior in plain terms.

When a function is confusing, locate its test file first. Verify you can describe what the function does without reading its implementation.

Step 7. Use Git history to understand why code exists

Code often looks wrong until you understand its history.

git blame src/lib/jobs/filters.ts

git log -1 <commit-hash>

git show <commit-hash>

This reveals context like bug fixes or API inconsistencies. It explains why edge cases exist.

At this step, you will notice that many “weird” lines have a reason. Verify you can explain at least one non-obvious piece of code using commit history.

Step 8. Ship a small change to force real understanding

Reading alone is not enough. You need to modify the code.

# Create a branch
git checkout -b fix-small-bug

# Make a small change
# Example: fix null handling or adjust UI text

git add .
git commit -m "fix: handle null job salary"
git push origin fix-small-bug

Pick something small like a UI fix or validation tweak. This forces you to navigate dependencies, run the app, and verify behavior.

At this step, you will notice gaps in your understanding. That is expected. Verify your change works locally and does not break existing behavior.

Step 9. Build a mental model of the system

Now connect everything you learned into a simplified structure.

pages/
  → components/
  → hooks/
  → api/
  → services/

services/
  → database
  → external APIs

This mental model lets you predict where code lives without searching.

You are not memorizing files. You are understanding patterns. Verify you can answer questions like “where would I add a new feature” or “where would a bug likely exist.”

Step 10. Document what you learned for future use

Write a short internal note. This speeds up your future work and helps others.

Authentication: src/features/auth
Job data flow: page → api → db
Email logic: src/services/email

Keep it simple. Focus on where things live and how they connect.

Verify you can onboard yourself again using only your notes.

You now have a repeatable system for navigating large JavaScript codebases. The next step is applying it to multiple projects until the pattern recognition becomes automatic.

Step 1. Check whether your app is on an exposed version

Before changing code, confirm whether your project is actually running a vulnerable release line. This step matters because many teams assume “latest enough” is safe, then discover they are still behind the patched versions.

npx next --version

cat package.json | grep '"next"'

npm ls next react react-dom

If your app is below the patched release line for your branch, stop here and upgrade before doing anything else. You want a precise baseline because every other fix depends on knowing whether you are patching in place or also crossing into the Next.js 16 migration surface.

Step 2. Upgrade to a patched version first, then rebuild

Do not start hardening an unpatched app. Patch first, because application-level fixes do not compensate for framework-level vulnerabilities. In a real migration, this is the step that removes the highest-risk exposure fastest.

# Recommended automated path
npx @next/codemod@canary upgrade latest

# If you are staying on the Next.js 15 line
npm install next@15.5.13 react@latest react-dom@latest

# If you are moving to Next.js 16
npm install next@latest react@latest react-dom@latest

# Optional framework-specific check
npx fix-react2shell-next

# Rebuild after upgrade
npm run build

After this, your app should at least compile on the patched dependency set. Do not move on until the build is green. You are not looking for perfect runtime behavior yet. You are confirming that the vulnerable framework version is gone and the project still boots.

Step 3. Fix the breaking changes that affect your security layer

This is the step many teams underestimate. A version bump can silently weaken security if your old middleware or request handling patterns stop applying correctly. In Next.js 16, middleware becomes proxy, and request APIs that were previously synchronous are now async.

// proxy.ts in Next.js 16
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function proxy(request: NextRequest) {
  const response = NextResponse.next()

  response.headers.set('X-Frame-Options', 'DENY')
  response.headers.set('X-Content-Type-Options', 'nosniff')
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')

  return response
}

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

export default async function DashboardPage() {
  const cookieStore = await cookies()
  const token = cookieStore.get('auth_token')

  if (!token) {
    return <div>Unauthorized</div>
  }

  return <div>Secure dashboard</div>
}

At this point, verify that your old security headers, auth gate checks, and request-dependent logic still run in the new model. If your team works heavily in App Router codebases, the Next.js production scaling patterns are directly relevant because framework architecture decisions and security boundaries now overlap more than they did in older React apps.

Step 4. Lock down every Server Action like a public API endpoint

This is the most important code-level mindset change in modern Next.js. Server Actions feel internal because they live next to components, but they are still network entry points. If you skip validation and authorization here, patching the framework only solves half the problem.

'use server'

import { z } from 'zod'
import { getSession } from '@/lib/auth'
import { db } from '@/lib/db'

const createJobSchema = z.object({
  title: z.string().min(3).max(200),
  company: z.string().min(2).max(100),
  remote: z.boolean().default(false),
})

export async function createJobPosting(formData: FormData) {
  const session = await getSession()

  if (!session?.userId) {
    throw new Error('Unauthorized')
  }

  const parsed = createJobSchema.safeParse({
    title: formData.get('title'),
    company: formData.get('company'),
    remote: formData.get('remote') === 'true',
  })

  if (!parsed.success) {
    return { error: parsed.error.flatten().fieldErrors }
  }

  const job = await db.jobs.create({
    data: {
      ...parsed.data,
      authorId: session.userId,
    },
  })

  return { success: true, id: job.id }
}

What you are verifying here is simple. Untrusted input gets validated before use. Mutations require an authenticated user. Ownership or permission checks happen before database writes. Once this pattern is in place, the rest of your Server Actions become mechanical to migrate.

Step 5. Rebuild your defensive defaults around headers, secrets, and image settings

Framework patching removes known CVEs. Defensive defaults reduce the damage from the next mistake, the next package issue, or the next rushed deploy. This step is where you harden the app as a system rather than only as a dependency graph.

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

export function proxy(request: NextRequest) {
  const response = NextResponse.next()

  response.headers.set(
    'Content-Security-Policy',
    "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:;"
  )
  response.headers.set('X-Frame-Options', 'DENY')
  response.headers.set('X-Content-Type-Options', 'nosniff')
  response.headers.set('Referrer-Policy', 'strict-origin-when-cross-origin')

  return response
}

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

const nextConfig: NextConfig = {
  images: {
    maximumDiskCacheSize: 500 * 1024 * 1024,
    qualities: [75, 90],
    localPatterns: [{ pathname: '/images/**', search: '' }],
  },
}

export default nextConfig

// Good secret handling in a Server Action
'use server'

export async function fetchBillingData() {
  const res = await fetch('https://api.example.com/billing', {
    headers: {
      Authorization: `Bearer ${process.env.BILLING_API_SECRET}`,
    },
  })

  return res.json()
}

Now verify three things before moving on. Secrets are no longer hardcoded in source. Your headers still reach the browser in local and production builds. Your image settings are explicit enough that abuse paths like unbounded cache growth are harder to trigger.

Step 6. Use the new development tooling to verify the migration instead of guessing

A secure upgrade is not finished when the app compiles. It is finished when you confirm that forms, auth, streaming, and server mutations still behave correctly after the patch. Next.js 16.2 gives you better feedback here, so use it.

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

const nextConfig: NextConfig = {
  logging: {
    fetches: {
      fullUrl: true,
      hmrRefreshes: true,
    },
    serverFunctions: true,
  },
}

export default nextConfig

npm run dev
npm run build
npm start

With server function logging enabled, submit your forms and watch the terminal. Confirm that the expected action fires once, receives the expected input shape, and returns without hidden retries or silent failures. Then trigger your authenticated routes, invalid payloads, and missing-field scenarios. This is where you catch the subtle breakage that usually gets misread as “random Next.js issues” after an upgrade.

By the end of this step, you should have a patched app, restored security boundaries, and a cleaner path for future upgrades. The next thing to watch in production is operational discipline. Rotate secrets after a high-severity patch cycle, keep dependency monitoring on, and treat every future Server Action like an exposed endpoint from day one.

Step 1. Restrict AI to specific task boundaries

The biggest mistake is using AI to write business logic. That is where most bugs and debugging time come from.

// Allowed AI tasks
- Boilerplate generation
- Type definitions
- Test scaffolding
- Refactoring (JS → TS, class → function)

// Forbidden AI tasks
- Business logic
- API orchestration
- State management decisions
- Security-sensitive code

You are not removing AI. You are constraining it. This immediately reduces the 1.7x bug multiplier effect because AI no longer touches critical logic.

At this step, your goal is clarity. If you cannot describe what AI is allowed to do in your project, it will slowly take over everything.

Step 2. Force a human-first architecture before writing code

AI fails at system design because it lacks context. If you skip this step, you inherit structural bugs that are hard to detect.

// Before writing any code, define this manually

type FeaturePlan = {
  dataFlow: string;
  apiContracts: string[];
  edgeCases: string[];
};

const plan: FeaturePlan = {
  dataFlow: "Client → API → DB → API → Client",
  apiContracts: ["GET /user", "POST /user/update"],
  edgeCases: ["No data", "Timeout", "Partial failure"]
};

This is not documentation for others. It is a constraint for AI. When you later use AI, you are guiding it inside a predefined architecture.

At this step, you eliminate most “looks correct but fails in production” problems.

Step 3. Generate only isolated pieces, never full features

AI performs well when the problem is narrow and context-independent. It performs poorly when generating end-to-end features.

// GOOD: isolated function generation

function calculateDiscount(price: number, discount: number): number {
  return price - price * discount;
}

// BAD: "generate full checkout flow"
// (this introduces bugs across UI, API, and business logic)

Never ask AI to build a full React page, API route, and database interaction in one prompt. That is exactly where debugging time explodes.

At this step, you convert AI into a “function-level assistant” instead of a “system-level author.”

Step 4. Introduce a strict AI code review checklist

Treat AI output like code from a junior developer. Every time.

AI Code Review Checklist:

1. Async safety
   - Any missing await?
   - Any race conditions?

2. Type safety
   - Any usage of "any"?
   - Incorrect inference?

3. Error handling
   - Are errors swallowed?
   - Missing logs?

4. Performance
   - Sequential vs parallel calls?
   - Unnecessary re-renders?

5. Security
   - Input validation?
   - Unsafe queries?

You should be able to review AI-generated code in under 2 minutes using this checklist. If you cannot, you are relying on AI blindly.

At this step, you reduce debugging time later by catching issues immediately.

Step 5. Separate generation from integration

Most time loss happens when AI-generated code does not match your existing architecture.

// Step 1: generate function (AI-assisted)
export async function getUserData(id: string) {
  return db.users.findById(id);
}

// Step 2: integrate manually (human-controlled)
import { getUserData } from "@/services/user";

export async function handler(req, res) {
  const user = await getUserData(req.query.id);
  res.json(user);
}

Never paste AI-generated code directly into production files. Always isolate it first, then integrate it manually.

At this step, you avoid mismatches in naming, patterns, and dependencies that usually cost hours.

Step 6. Measure real productivity, not perceived speed

AI feels fast because generation is instant. But your real metric is total time to production.

Track this for 5 days:

- Time to write feature (AI vs manual)
- Time to debug
- Bugs reported after release
- Total hours spent

Compare:
AI-assisted total time vs manual total time

Most developers discover that AI saves time only in specific scenarios. Without measurement, you optimize for the wrong thing.

At this step, you make AI usage data-driven instead of emotional.

Step 7. Move your skill focus to what AI cannot do

AI is replacing code generation. It is not replacing judgment.

Focus areas:

- System design
- Debugging production issues
- Performance optimization
- Security analysis
- Business logic decisions

This is where senior-level value comes from. The market is already shifting toward developers who can review and fix AI output rather than generate code.

If you want a deeper breakdown of how this shift affects long-term productivity and career positioning, the AI productivity reality for developers explains why output metrics are misleading.

At this step, you future-proof your role instead of competing with AI.

Closing

You now have a workflow where AI reduces effort instead of extending your day. The difference is not the tool. It is how narrowly you control it. Apply this system to one feature this week and compare your total time spent.

Step 1. Extract the baseline stack from real job demand

You need a starting point grounded in actual hiring data, not opinions. The fastest way is to define a minimal stack that appears across the majority of postings.

# Baseline stack you should assume as required
Frontend: React
Language: TypeScript
Backend: Node.js
Framework: Next.js (optional but high leverage)

This stack covers the largest surface area of the market. React appears in more than half of postings. TypeScript is expected even when not explicitly listed. Node.js is the default backend for JavaScript teams.

At this step, you are not learning anything new yet. You are deciding what counts as “non-negotiable.” If your current stack does not include all three, you already know where to focus.

Step 2. Audit your current skill gaps against that baseline

Before adding new technologies, you need a precise gap analysis. Most developers overestimate their readiness because they can build features but not production systems.

// Example: self-check for a React + TypeScript developer

type SkillAudit = {
  react: "basic" | "intermediate" | "production";
  typescript: "none" | "basic" | "advanced";
  node: "none" | "api-only" | "production";
};

const yourSkills: SkillAudit = {
  react: "intermediate",
  typescript: "basic",
  node: "none"
};

Define your level honestly. “Production” means you can handle performance, architecture, and debugging under real constraints. Not just building components.

At this point, you should clearly see your weakest link. That becomes your immediate priority. If you lack Node.js, you are limited to frontend-only roles. If your TypeScript is weak, you are filtered out early.

Step 3. Add one high-leverage multiplier skill

Once the baseline is covered, you need a differentiator. The data shows that AI integration is the fastest-growing requirement and appears in a significant portion of postings.

// Example: simple AI integration using an API

import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

export async function generateResponse(prompt: string) {
  const response = await client.responses.create({
    model: "gpt-4.1",
    input: prompt,
  });

  return response.output_text;
}

This is not machine learning. This is product integration. You are building features on top of APIs.

At this step, you are positioning yourself for a subset of roles with less competition and higher pay. You should be able to explain how to build chat interfaces, streaming responses, and basic RAG flows.

If you want to understand how these skills translate into hiring outcomes, the JavaScript developer to AI engineer transition breaks down the exact path companies expect.

Step 4. Expand into full-stack to increase your job surface

Most postings labeled “frontend” still expect backend and infrastructure awareness. This is where many developers fall behind.

// Example: minimal full-stack route in Next.js

// app/api/jobs/route.ts
import { NextResponse } from "next/server";

export async function GET() {
  const jobs = await fetch("https://api.example.com/jobs").then(res => res.json());

  return NextResponse.json(jobs);
}

You do not need to become a backend specialist. You need to be able to build APIs, connect databases, and deploy.

At this step, your goal is to move from “frontend developer” to “engineer.” This shift alone expands your eligible job pool significantly and increases salary potential.

Step 5. Add infrastructure awareness to unlock senior roles

A major pattern in job descriptions is the expectation of DevOps and infrastructure familiarity. Even if not tagged, it appears in descriptions.

# Example: basic CI/CD pipeline (GitHub Actions)

name: Deploy

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Build
        run: npm run build

You do not need to be a DevOps engineer. You need to understand deployment pipelines, Docker basics, and cloud environments.

At this step, you become significantly more valuable. Companies prefer developers who can ship features end-to-end without relying on multiple teams.

Step 6. Align your job search with real market structure

The final step is not technical. It is strategic. Most developers apply randomly. You should filter based on patterns visible in the data.

Priority order for applications:

1. Jobs with published salaries
2. Full-stack roles (React + Node)
3. Roles mentioning AI integration
4. Remote positions outside your local market

The data shows that most jobs are full-time. Freelance roles are almost invisible on job boards. If you rely on job boards, optimize for full-time roles.

Also, do not limit yourself geographically. A large portion of the market exists outside the US. Many roles are remote or flexible, even if not explicitly labeled.

At this step, you are no longer guessing where opportunities are. You are targeting them deliberately.

Step 7. Remove low-value skills from your profile

Just as important as what you add is what you remove. Some technologies have effectively zero market demand.

Remove or de-prioritize:
- jQuery
- Deno (for now)
- Bun (for now)
- Framework hopping without depth

These do not increase employability in the current market. They may be interesting, but they are not high-leverage.

At this step, your resume and portfolio become aligned with what companies are actually hiring for, not what the community is discussing.

Step 8. Rebuild your portfolio around this strategy

Your portfolio should reflect the exact stack and patterns companies are hiring for.

Portfolio project checklist:

- React + TypeScript frontend
- Node.js or Next.js backend
- One AI-powered feature
- Deployed with CI/CD
- Uses a real database

Do not build five small projects. Build one or two that demonstrate end-to-end capability.

At this step, you are signaling readiness for the roles that dominate the market, not just demonstrating isolated skills.

Closing

You now have a concrete system for aligning your skills with real hiring demand instead of guesswork. The difference is not what technologies exist. It is which ones companies actually pay for. Your next move is to implement one step per week and update your portfolio as you go.