DEV Community: JavaScript Mastery

AI wrote it, you merged it: 4 JavaScript bugs to catch in review

JavaScript Mastery — Mon, 09 Nov 2026 04:54:39 +0000

GitHub's Octoverse 2026 report says that by September, more than 40% of pull requests started with an agent, up from 17% in March. Stack Overflow's 2026 survey found that 73% of developers who use AI coding tools use them daily.

So a growing share of the code you approve was drafted by something that has never run your app.

This post is for anyone who reviews that code, which is now most of us. Each example below looks correct, would pass a skim, and is broken. All of them run in Node 22. Paste them into a file and see for yourself.

I'm not claiming these are the bugs AI makes most often. Nobody has published that data. They're here because they're the kind of plausible code that slips through when the reviewer is skimming instead of reading.

1. `async` inside `forEach` doesn't wait

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
const rows = [];
const save = async (u) => { await sleep(10); rows.push(u); };

async function saveAll(users) {
  users.forEach(async (u) => {
    await save(u);
  });
  return rows.length;
}

console.log(await saveAll(['a', 'b', 'c'])); // 0

forEach ignores the promises your callback returns. saveAll resolves before a single row is saved. In a request handler, that means responding "saved" while the writes are still in flight, or silently failing.

Fix: decide whether the writes can run in parallel.

// parallel
await Promise.all(users.map((u) => save(u)));

// sequential (order matters, or you're rate-limited)
for (const u of users) await save(u);

Review check: any async callback passed to forEach, filter, or reduce deserves a second look.

2. `.sort()` without a comparator sorts strings

console.log([10, 9, 1, 100].sort()); // [ 1, 10, 100, 9 ]

The default sort converts elements to strings and compares UTF-16 code units. It works on the small test array in the PR description, then breaks on real prices or scores.

Fix:

[10, 9, 1, 100].sort((a, b) => a - b); // [ 1, 9, 10, 100 ]

If you need a copy, toSorted((a, b) => a - b) doesn't mutate the original.

Review check: a bare .sort() on anything numeric.

3. `map(parseInt)` passes the index as the radix

console.log(['1', '2', '3'].map(parseInt)); // [ 1, NaN, NaN ]

map calls its callback with (value, index, array). parseInt takes (string, radix), so '2' gets radix 1, which is out of range, and '3' gets radix 2, where 3 isn't a valid digit. Both return NaN.

Fix:

['1', '2', '3'].map(Number);              // [ 1, 2, 3 ]
['1', '2', '3'].map((s) => parseInt(s, 10)); // [ 1, 2, 3 ]

Review check: point-free callbacks (map(fn)) where fn takes more than one parameter.

4. Spread is a shallow copy

const defaults = { theme: 'dark', flags: { beta: false } };

function withBeta(cfg) {
  const copy = { ...cfg };
  copy.flags.beta = true;
  return copy;
}

withBeta(defaults);
console.log(defaults.flags.beta); // true (the shared default changed)

The spread copies the top level only, so copy.flags is the same object as defaults.flags. Now every user gets the beta flag.

Fix:

const copy = structuredClone(cfg);
// or, if you only change one branch:
const copy2 = { ...cfg, flags: { ...cfg.flags, beta: true } };

Review check: "copy, then mutate a nested field" anywhere near shared config, state or caches.

Let tools take the first pass

Review is a human job, but you don't have to catch everything by eye. Set up the cheap checks so your attention goes to logic:

Lint for the known traps. ESLint's radix rule (also available in Oxc) flags parseInt calls without an explicit radix, which would have caught example 3.
Type your data. In TypeScript, a number[] that's being sorted, or a config object marked Readonly, makes intent visible in the diff. It also gives an agent more to work with when it drafts the next change.
Write one test per bug class. For example 1: assert that the rows exist after saveAll resolves, not just that it resolved. That single assertion turns a silent bug into a red build.
Give the agent your rules. If your repo has an agent instructions file, add a line like "never use async callbacks in forEach". GitHub's Octoverse data shows new repos with an agent config file logged 8× as many commits as those without one. That's a correlation, not proof, but it's cheap to try.

A 60-second review routine for AI-drafted PRs

Read the diff, not the description. The summary tells you what was intended. The diff tells you what happened.
Find the async boundaries. Every await, callback and promise: is anything floating?
Check the tests assert behaviour. A test that only checks that a function "doesn't throw" proves very little.
Ask "what's shared?" Config, module-level state, caches, defaults.
Run it. If you can't run it locally, ask for a reproduction.

None of this is new. It's the same review discipline as always. What's changed is how much code arrives for review, and how convincing it looks.

Wrap-up

AI-assisted coding makes writing code cheaper. It doesn't make knowing why code is wrong any cheaper, and that's the part you're paid for. Practise on the four examples above. Then try spotting them in your own last few PRs.

If you'd rather learn this by building, our YouTube channel walks through full production apps step by step: JavaScript Mastery.

Sources: GitHub Octoverse 2026 · Stack Overflow Developer Survey 2026 results

[Boost]

JavaScript Mastery — Fri, 06 Nov 2026 04:41:22 +0000

Ben Miller for WaterMill | Digital Agency

Nov 5

Let’s Talk About Claude Code, Part 2: Container or Sandbox VM?

#claudecode #ai #docker #security

2 min read

[Boost]

JavaScript Mastery — Fri, 06 Nov 2026 04:35:38 +0000

VibeiDE

Nov 5

Run multiple Claude Code sessions without file conflicts

#claudecode #git #ai #productivity

6 min read

We Gave Our AI Coding Agents an Office. These Are the House Rules.

JavaScript Mastery — Fri, 06 Nov 2026 04:20:48 +0000

One coding agent on your repo is a pair programmer. Four agents on the same repo, with no rules, is a merge conflict with a token bill.

The failure modes are predictable. Two agents edit the same file. One makes a failing test pass by deleting it. Another hits a blocked API and writes a workaround instead of asking. Nobody knows which PR should land first.

So we built JSM HQ, an open-source pixel-art office where a lead agent plans the work and a team of worker agents builds it on your repo. This post is less about the pixels and more about the rules underneath them. You can steal the rules even if you never install HQ.

If you run more than one agent at a time, or want to, this is for you.

The office, running on demo data. Michael leads, Dwight and Jim build. Jim's card is red because he's waiting on a decision.

The setup in one paragraph

You run HQ inside a git repo that has a GitHub remote. You pick a lead and some workers, and each one runs Claude Code or Codex. HQ gives every agent its own full clone of the repo and, by default, its own Docker Sandbox, a small VM that can't reach the rest of your machine. The agents talk to each other through an MCP server called hq. HQ watches GitHub through your gh login and turns all of it into an office you can watch.

Now the rules.

Rule 1: The lead never writes app code

The lead's job is to plan and assign. It creates boards (one per phase, for example), splits the work into tasks, and hands each task to a free worker. That's it.

This sounds wasteful. Why pay for an agent that doesn't code?

Because the moment a planner starts coding, it stops planning. It loses track of who's doing what, and it starts editing files a worker already owns. Keeping one agent with the whole picture and no keyboard is the cheapest coordination we found.

The lead gets a different set of tools from the workers to match:

lead:    list_workers, get_status, list_tasks, create_board, create_task,
         update_task, assign_task, send_message, ask_user, request_access

worker:  get_my_task, set_my_status, list_workers, get_status, list_tasks,
         send_message, ask_user, request_access

Only the lead can create or assign tasks. Workers can only pick up the one they were given.

Rule 2: One task = one branch = one PR

Every task is small enough to land as a single pull request. The lead writes each task with two things attached: the files it may edit and a clear done-when.

A worker's loop looks like this:

Call get_my_task.
git pull origin main and create a branch.
Do the work.
Open a PR titled [TASK-ID] Short title.
Call set_my_status with in-review and the PR number.

That [TASK-ID] prefix isn't cosmetic. HQ polls GitHub about every 20 seconds and uses it to match each PR to its task. New review comments go back to the PR's author to fix. A merge marks the task done.

Rule 3: Edit only the files your task lists

This rule answers a question we keep getting: what happens when two agents need the same file?

Mostly, they don't get the chance. The lead decides up front which files each task may touch, so two parallel tasks shouldn't claim the same module. If a worker discovers mid-task that it needs another file, it doesn't just open it. It asks the lead with send_message.

When overlap does happen, it gets caught at the PR stage. The lead decides the order PRs should land in and flags any PR that blocks another. If a PR conflicts with main, HQ tells its author to fix it.

So the answer is both: scope is serialized at planning time, and anything that slips through is reconciled at review.

Rule 4: Every agent gets its own desk

"Desk" here means three concrete things:

Its own clone at ~/.jsmhq/<project>/<agent>/. Your working folder is never touched.
Its own instructions. HQ writes a .jsmhq-role.md file with the agent's role, the team, the rules and its tools, and keeps it out of git through .git/info/exclude.
Its own sandbox. On macOS and Linux each agent also runs in a tmux session, so it keeps working if you close the browser. You can watch any of them with tmux attach -t hq-<project>-<agent>.

Teammates can't see each other's files or terminals. They talk only through messages. That forced isolation is what makes parallel work safe.

Dwight's drawer: his live Claude Code session on the right, and three requests his sandbox blocked, each waiting for Allow or Dismiss.

Rule 5: Ask, don't work around

This is the rule we care about most, and it's where the red desk comes from.

Sandboxes use a network policy you pick once. The recommended one, balanced, allows AI services, package registries and GitHub, and blocks everything else. Agents will hit that wall all the time: a library's docs, a third-party API.

An agent that's been told "get it done" will try to route around a block. Ours are told the opposite. Here's the actual line from the role file HQ writes:

If a request you need is blocked (a docs page or an API: usually a 403 saying
'Approval required for <host>'), call request_access with the domain and why,
then continue with other work until HQ tells you it was answered.
Never work around the block.

When that happens, the agent's card turns red and you get three buttons: Allow for this agent, Allow for everyone, Deny. Allowing adds a rule for that one sandbox. Your base policy is never touched.

The same goes for anything outside the sandbox. Need a database created or an API key added? The agent calls ask_user with exact steps, and it names the variable, never the secret. Everything waiting on you collects in one Action items list in the top bar.

Keys get the same treatment. Service keys go into Docker Sandboxes' secret store, and the sandbox's proxy adds them to matching requests, so the key itself never enters the VM. HQ never stores key values and never reads your env files.

Rule 6: HQ never merges

Agents open PRs. Reviews run through the tool you pick in Settings → Workflow: CodeRabbit, Greptile, Copilot, yourself, or your own. When a PR passes, the lead is told it's ready.

Then you merge, on GitHub.

That's the default, and it's deliberate. Review is where you catch the agent that made a test pass by deleting it. If you trust your review pipeline, there's a "Who merges" switch in Settings → Workflow that hands merging to the lead, one PR at a time. HQ itself still never merges.

Steal the rules without installing anything

You don't need HQ to get most of the benefit. If you run parallel agents today, paste something like this into your CLAUDE.md or AGENTS.md:

## Rules for parallel work
- One task = one branch = one PR. Title PRs `[TASK-ID] Short title`.
- Edit only the files your task lists. Need another file? Stop and ask.
- If a website or API is blocked, say so and continue with other work.
  Never work around the block.
- Never put secret values in messages or code. Name the variable instead.
- Never merge. A human merges after review.

The office just makes those rules visible and enforces the plumbing around them.

Try it

You'll need Node.js 20+, git, the GitHub CLI, tmux (macOS and Linux), Docker Sandboxes, and a Claude or ChatGPT account for the agents. The getting-started guide says the first setup takes about 15 minutes, mostly installing tools. HQ also shows a setup checklist with the exact command for anything missing.

From your project folder:

npx @therealjsmastery/jsm-hq@latest

Pick your team on the welcome screen, press Start team, then message the lead. The guide suggests a first message like:

Read plan.md. Create a board for Phase 1, plan its tasks with the files
each one touches, and assign them.

The honest limits

Platform support. Sandboxes need macOS 14+ on Apple silicon, Ubuntu 24.04+, or Windows 11. Windows is experimental: there's no tmux, so agents stop when HQ stops. Elsewhere you can run agents in Local mode, without the sandbox isolation.
Usage adds up. Every agent runs on your own Claude or ChatGPT account. Four agents use your plan's limits roughly four times as fast as one.
Rules reduce conflicts, they don't remove them. A lead can still plan two tasks that collide. Review is still your job.
Small tasks work best. Our rule of thumb (an opinion, not a benchmark): if a task can't be described with a file list and a done-when, it's too big for one agent and should be split.

What's next

The code is MIT-licensed on GitHub, and the How it works doc covers everything we skipped here: MCP servers per agent, port forwarding, app variables, and what HQ saves where.

We're curious how other people split work between agents. Do you plan file ownership up front, or let branches collide and sort it out at review?

The full walkthrough is on the JavaScript Mastery YouTube channel.

This Week in AI for Developers: IPOs, Texting Agents & Self-Replicating Models

JavaScript Mastery — Sun, 01 Nov 2026 12:35:28 +0000

AI had a wild last week of October 2026. Anthropic opened up its books to go public. OpenAI put its agents inside your text messages. And Microsoft offered buyouts to a quarter of its workforce while AI spending keeps climbing.

If you write code for a living, none of this is just business news. It changes what you build, what you build it on, and which skills are worth your next 100 hours.

Here is what happened, and what it means for you as a developer.

1. Anthropic filed to go public (ticker: ANT)

On Monday, October 26, Anthropic made its S-1 public. It plans to list Class A shares on the Nasdaq Global Select Market under the ticker ANT. Share count and price range are not set yet. (Free Press Journal)

The numbers worth knowing (IPOScoop):

What	Number
Expected market cap at listing (Reuters)	~$1.5 trillion
Expected raise	~$75 billion
Revenue, 12 months to June 30, 2026	$19.7 billion
Customers paying $1M+ a year	1,900+
Customers paying $10M+ a year	~250
Earliest roadshow (Bloomberg)	Week of Nov 9

The company is still not profitable, and the filing itself flags the technology as carrying existential risks.

Why devs should care: a big part of this story is Claude Code. Anthropic's coding agent reportedly hit over $2.5 billion in run-rate revenue by February 2026 (AI2Work). Developers paying for AI that writes code helped build one of the most valuable companies on the planet.

A public company also behaves differently. Expect more predictable pricing, stricter enterprise terms, and more pressure to keep shipping developer tools. If you build on any single model provider, now is a good time to put an abstraction layer between your app and the API.

2. OpenAI's agents moved into your text messages

On October 28, OpenAI let US ChatGPT Pro users text their Dots (its always-on AI agents) through iMessage and RCS. You send a text, a photo or a voice note, and the agent picks up the task. It keeps a persistent memory of context, so it remembers what you asked last time. It is a beta for select Pro users, set up by verifying your phone number in the Dot profile. (Crypto Briefing)

The same week, reports said OpenAI is negotiating a raise of up to $30 billion at a $1.25 trillion pre-money valuation, led by Coatue and UAE-based investors. Terms are not final. (Winzheng, citing CNBC)

Why devs should care: this is the "your next app might not have a UI" moment. For years, building a product meant building screens: forms, menus, dashboards, a Submit button. Dots skip all of that. The interface is a conversation in the inbox you already use.

That does not kill frontend work. It shifts where the hard problems live:

Tool calling: the agent needs clean, well-described actions it can safely call.
Memory: what the agent remembers, for how long, and who can see it.
Judgment: when the agent should act on its own and when it should ask first.
Trust: showing the user what happened, since there is no screen to click through.

If you have only ever built UIs, learning to build the agent behind the UI is the highest-leverage skill you can pick up right now.

3. Anthropic says small models may soon copy themselves

This one landed a couple of weeks ago, but it is still all over dev timelines. Anthropic's Frontier Red Team tested whether AI models could find vulnerable devices, copy themselves onto them and keep spreading without human help. (The Star, via Reuters)

What they found:

Models under 30 billion parameters could already complete many of the individual steps, but struggled to chain them end to end.
In simplified tests with some security steps removed, GLM-5.2 and stronger models did manage full replication.
Cheap IoT hardware like off-brand Android TV boxes could provide enough compute to run a small model.
If small models keep improving at their historical rate, Anthropic expects this capability by the end of 2026.

Not everyone bought it. The Register called it a threat that does not exist yet, and a former head of the UK's National Cyber Security Centre dismissed running a small model on cheap TVs as no security crisis. (The Register, Canberra Times)

Why devs should care: whether or not the worst case ever happens, the lesson for anyone shipping agents is the same. Agents should get the smallest set of permissions that does the job. Keep a human approval step for anything that sends, deletes, pays or deploys. Log every tool call so you can see what your agent actually did. And if you ship IoT or edge devices, default credentials and unpatched firmware are now an AI problem, not just a botnet problem.

4. Big Tech is spending more on AI and fewer people

Two stories from the same week tell you where the money is going.

The market got nervous. On Thursday, October 22, the Nasdaq fell 2.6%, its steepest drop since early June. Meta fell nearly 7% after raising its 2026 capital spending forecast to $135 to $145 billion. Nvidia, Amazon, Alphabet and Microsoft all dropped too, as investors questioned whether this level of AI spending can pay off. Gartner forecasts $2.7 trillion of global AI investment in 2026. (Al Jazeera)

Microsoft offered buyouts to about 60,000 people. On October 26, Microsoft announced a Voluntary Exit Offer for roughly 27% of its global workforce, in Canada, India, the UK and the US. The company did not tie it directly to AI, but it comes as industry data center spending is on track to top $700 billion this year. (WCAX, via AP)

Why devs should care: budgets are moving from headcount to compute. Teams will be smaller and expected to ship more, with AI doing a bigger share of the routine work. The developers who stay valuable are the ones who can direct that AI well, review its output, and build the systems around it.

What to actually do this week

News is only useful if it changes what you do on Monday. Here is the short list:

Build one small agent. Pick a boring task you do every week and wire an LLM to two or three tools that handle it. You will learn more from one working agent than from ten tutorials.
Wrap your model provider. Put a thin layer between your app and any single AI API. Pricing and terms are about to get more corporate on both sides of the OpenAI vs Anthropic race.
Design for "no UI". For your next feature, ask what it would look like as a single message to an agent. Then design the API that agent would need.
Lock down your agents. Least privilege, human approval for anything destructive, and logs for every tool call.
Get good at reviewing AI code. Smaller teams plus more AI output means review is where your judgment shows.

The big picture

Put the week together and the pattern is clear. The AI labs are turning into trillion-dollar public companies. Their products are leaving the app and moving into the places you already spend your day. And the companies paying for all of it are rethinking how many people they need.

The app era is not over, but it is folding. The developers who do well next are the ones who learn to build what sits behind the conversation.

Over to you: would you rather tap through an app, or just text an agent and let it handle things? Drop your take in the comments.

If you want a weekly breakdown like this, follow JavaScript Mastery here on dev.to.

Sources

Anthropic files S-1, plans Nasdaq listing under ANT (Free Press Journal)
The IPO Buzz: Anthropic files its S-1 (IPOScoop)
Anthropic files confidential S-1 as revenue run-rate hits $47B (AI2Work)
OpenAI lets US Pro users text their Dots through iMessage and RCS (Crypto Briefing)
OpenAI working on new $30B raise at $1.25T valuation (citing CNBC)
AI models may soon self-replicate without access to data centers (The Star, via Reuters)
Anthropic conjures another threat that doesn't exist yet (The Register)
Anthropic warns AI models may soon self-replicate (Canberra Times, via AAP)
US tech stocks tumble as investors fret over AI spending (Al Jazeera)
Microsoft offers 60,000 employees voluntary buyouts (WCAX, via AP)

AI Writes Half Our Code Now. Nobody Taught Us How to Review It.

JavaScript Mastery — Thu, 29 Oct 2026 05:00:00 +0000

AI wrote this function. It passed linting. It got approved. It shipped.

async function getUsers(ids) {
  const users = [];

  ids.forEach(async (id) => {
    const res = await fetch(`/api/users/${id}`);
    users.push(await res.json());
  });

  return users;
}

It returned an empty array. Every. Single. Time.

No error. No warning. Just [].

If you spotted it in 5 seconds, nice. If you didn't, you're not alone, and that's exactly the problem we want to talk about.

The numbers changed. Our habits didn't.

The State of AI 2026 developer survey collected answers from 7,258 developers, including how much of their code is AI-generated. The average answer was 54%. A year earlier, it was 28%.

(Fair caveat: an AI survey probably attracts people who use AI a lot. But even if the real number is lower, the direction is obvious.)

In one year, AI went from "helps with boilerplate" to "writes more than half the code."

But think about how most of us learned to code. We learned to write it. Tutorials, courses, bootcamps, LeetCode: almost all of it trains the writing muscle.

Almost nobody trained us to review code we didn't write, at speed, all day. And that's now the main job.

AI-generated code has a specific personality. It looks clean, it's confidently formatted, it has nice variable names, and it's wrong in subtle ways that don't throw errors.

Here are 5 bugs we see AI write over and over in JavaScript and React. Every snippet below has been run, and the output is real.

Bug #1: `forEach` doesn't wait for `async`

That's our opening example. forEach calls your async callback, gets back a promise, and ignores it. It doesn't wait. So return users runs before a single fetch finishes.

What you get: []

The fix: use map to collect the promises, then Promise.all to wait for them.

async function getUsers(ids) {
  return Promise.all(
    ids.map(async (id) => {
      const res = await fetch(`/api/users/${id}`);
      return res.json();
    })
  );
}

🔍 Review rule: If you see async inside forEach, stop. It's almost always a bug.

Bug #2: The `try/catch` that catches nothing

async function saveUser(user) {
  try {
    db.insert(user);
    return { ok: true };
  } catch (err) {
    console.error("Save failed:", err);
    return { ok: false };
  }
}

Looks safe, right? There's error handling and everything.

But db.insert() returns a promise, and there's no await. So the function returns { ok: true } immediately. When the insert fails later, the error is outside the try block. Your catch never runs.

What you get: { ok: true }, even when the save failed. The real error shows up as an unhandled promise rejection, which in modern Node.js crashes the process by default.

The fix: one word.

await db.insert(user);

🔍 Review rule: Any call that returns a promise inside a try block needs an await, or the catch is just decoration.

Bug #3: Sorting numbers like they're words

const prices = [100, 25, 9, 1200, 50];
prices.sort();

What you get: [100, 1200, 25, 50, 9]

By default, .sort() converts everything to strings and sorts alphabetically. "1200" comes before "25" because "1" comes before "2".

AI loves this one because it reads perfectly in plain English. "Sort the prices." Done. Except it isn't.

The fix:

prices.sort((a, b) => a - b);
// [9, 25, 50, 100, 1200]

🔍 Review rule: .sort() with no comparator on anything that isn't a plain string array is a red flag.

Bug #4: The timer that's stuck on 1

function Timer() {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      setSeconds(seconds + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <p>{seconds}</p>;
}

It even cleans up the interval. Very responsible. Very wrong.

The empty dependency array means the effect runs once, so the interval callback captures seconds from the first render, when it was 0. Every tick sets it to 0 + 1.

What you get: 1. Forever.

The fix: use the functional updater so you always get the latest value.

setSeconds((s) => s + 1);

🔍 Review rule: A state variable used inside setInterval, setTimeout, or an event listener in a useEffect with [] deps? Check for a stale closure.

Bug #5: The list that never updates

function TodoList() {
  const [todos, setTodos] = useState([]);

  function addTodo(text) {
    todos.push(text);
    setTodos(todos);
  }

  // ...
}

todos.push() mutates the existing array. Then setTodos(todos) passes React the same array reference. React compares the old and new state, sees they're the same object, and skips the re-render.

What you get: You click "Add". Nothing appears on screen.

The fix: create a new array.

setTodos([...todos, text]);

🔍 Review rule: .push(), .splice(), or direct property assignment on something that came from useState means the UI won't update.

The 30-second review checklist

Save this. Run through it every time AI hands you code.

[ ] Async: Is every promise actually awaited? Any async inside forEach?
[ ] Errors: Will the catch actually catch what you think it catches?
[ ] Defaults: Is it relying on a default behavior (like .sort(), ==, or parseInt) that might not do what the name suggests?
[ ] State: Is anything from useState being mutated directly?
[ ] Closures: Is a callback reading a value that might be stale?
[ ] The empty case: What happens with [], null, "", or 0?
[ ] Can you explain it? If you can't explain every line to a teammate, you're not done reviewing.

That last one matters most.

The real skill in 2026 isn't prompting

Here's our honest take.

Prompting is getting easier every month. The tools are getting better at understanding what you mean. That's great, but it also means prompting is becoming less of a differentiator.

What's getting more valuable is the thing AI is still bad at: knowing when the confident, clean, well-formatted code in front of you is wrong.

Every one of the bugs above:

passes a linter
throws no error on the line where the bug is
looks like something a senior dev would write

You can only catch them if you actually understand how JavaScript and React work under the hood. Event loop. Closures. References. Promises.

The fundamentals didn't become less important when AI showed up. They became the whole job.

Your turn 👇

What's the sneakiest bug AI has ever shipped into your codebase?

Drop it in the comments. Bonus points for a snippet. Let's build the ultimate list of "AI code that looked fine."

If you want to go deeper on building with AI agents without losing your engineering skills, we cover exactly this in our Agentic Engineering Course.

Your First Dev Job in 2026: The Roadmap Nobody Gave You

JavaScript Mastery — Thu, 22 Oct 2026 04:50:09 +0000

You finished the degree, the bootcamp, or the 100 tutorials. You open LinkedIn, hit "Easy Apply" 80 times... and hear nothing back.

It's not just you. The market in 2026 is weird. Overall software hiring is growing again, but the classic junior job ("here's a ticket, build this form") is shrinking, because AI now does a big chunk of that work.

The good news is that companies still hire new engineers. They just look for different signals now.

So here's the roadmap we'd follow if we were starting the job hunt today. It's high level on purpose, so you can see the whole path first and then go deep where you're weak.

The roadmap at a glance

Stage	Focus	Proof you have it
1	Fundamentals AI can't fake	You can debug code you didn't write
2	AI fluency, not AI dependence	You can explain every line AI wrote for you
3	1–2 real projects	Live URL, real users, clean README
4	Testing and shipping	Tests + CI + deployed app
5	System thinking	You can sketch how your app scales
6	Show your work	GitHub, a few posts, a clear LinkedIn
7	Interview ready	You've done mock interviews until they're boring

Let's go through each one.

Stage 1: Fundamentals AI can't fake

AI can write a function in seconds. What it can't do is tell you why your app breaks in production at 2am.

That's why fundamentals matter more now, not less. In BairesDev's Q2 2026 Dev Barometer (1,569 developers surveyed), nearly half of juniors picked problem-solving as the top hiring skill, about 3x more than those who picked AI proficiency.

Focus on:

JavaScript/TypeScript in depth: closures, async/await, the event loop, types
Debugging: reading stack traces, using breakpoints, not just console.log everywhere
Reading other people's code: most real jobs start with an existing codebase, not a blank file

👉 Quick test: open a random open-source repo, pick a small bug, and try to trace it. If that feels scary, this is your stage.

Stage 2: AI fluency, not AI dependence

In 2026, not using AI tools is like not knowing Git in 2015. AI skills now show up in roughly 4 in 10 software job descriptions, up from about 8% in 2022.

But here's the catch: hiring managers don't care that you can prompt. They care that you can judge what comes back.

Get comfortable with:

An AI coding tool (Claude Code, Cursor, Copilot, whatever you like)
Reviewing AI-generated code like a senior would: is it secure, readable, actually correct?
Building small features with AI APIs, like a chatbot, a summarizer, or an agent that calls a tool

The rule: if you can't explain a line of code in an interview, it shouldn't be in your portfolio.

If you want to go deeper on building real AI-powered products, our upcoming Agentic Engineering Course covers models, APIs, and production pipelines. The waitlist is open now.

Stage 3: Build 1–2 real projects, not 10 clones

Todo apps and Netflix clones all look the same to a recruiter. One real project beats ten tutorials.

A "real" project has:

✅ A live URL anyone can open
✅ Auth + a database, not just static pages
✅ At least a few real users (friends, a Discord, a local business)
✅ A README that explains why you made your decisions, not just how to install it

Pick a problem you or someone you know actually has. That story ("my friend's shop was tracking orders on paper, so I built...") is gold in interviews.

Stage 4: Testing and shipping

This is the stage most new devs skip, and it's exactly what separates "knows how to code" from "can work on a team."

Learn the basics of:

Unit and integration tests (Vitest, Jest, Playwright)
CI, so tests run automatically on every push (GitHub Actions is enough)
Deploying properly, with environment variables and basic error logging

When an interviewer sees tests in your repo, they immediately read you as "safe to hire." Our Complete Testing Course is built around exactly this skill.

Stage 5: System thinking

You don't need to design Netflix as a fresh grad. But you should be able to answer: "What happens when 10,000 people use your app at once?"

Know the basics of:

How a request travels from the browser to your server and database
When to use caching, queues, and background jobs
How to design a simple database schema and why indexes matter

A good exercise: draw your own project's architecture on one page. If you can explain that diagram for 5 minutes, you're ahead of most applicants.

Stage 6: Show your work

Skills that nobody can see don't get you interviews.

GitHub: pin your 2 best projects, with clean READMEs
Write: a short post on what you learned building something (yes, right here on DEV counts)
LinkedIn: one clear headline, e.g. "Full-Stack Developer · Next.js · AI Integrations", not "Aspiring developer looking for opportunities"

Writing about your work also proves the skill companies keep asking for: communication.

Stage 7: Interview ready

Most people walk into their first interview having never done one. That's where the nerves come from.

Prepare for three types of rounds:

Technical: solve problems out loud, and explain your thinking before you code
Project deep dive: walk through your project's decisions, trade-offs, and what you'd change
Behavioral: have 3–4 short stories ready (a bug you fixed, a deadline you hit, a mistake you learned from)

Then practice until it feels boring. Our Dev Career Accelerator covers portfolio strategy, interview prep, and the mindset that gets callbacks.

Your "before I hit apply" checklist

[ ] I can debug code I didn't write
[ ] I use AI tools daily, and I can explain everything they generate
[ ] I have 1–2 deployed projects with real users
[ ] My projects have tests and run on CI
[ ] I can sketch my app's architecture and explain how it scales
[ ] My GitHub, LinkedIn, and at least one post show my work
[ ] I've done at least 5 mock interviews

If you can tick most of these, stop preparing and start applying. If not, you now know exactly which stage to work on next.

The 2026 market is harder, but it's not closed. It just rewards developers who can think, ship, and explain, not only type code. AI raised the bar, and it also gave you the tools to clear it.

Which stage are you on right now? Drop it in the comments 👇 and we'll share resources for it.

JavaScript Mastery is officially on DEV!

JavaScript Mastery — Wed, 21 Oct 2026 10:07:36 +0000

Hey DEV community! 👋

We're JavaScript Mastery, and yes, this is our official account (you'll find this profile linked from jsmastery.com and our YouTube channel).

If you've ever followed one of our project-based tutorials, built a full-stack app with us, or binge-watched a 5-hour build on a Saturday, thank you. You're the reason we're here. 💙

Why DEV?

We've been creating tutorials on YouTube for years, but DEV is where developers actually talk about what they're learning and building. We don't want to just post content here. We want to be part of the conversation.

What you can expect from us

🛠️ Real-world project breakdowns: how we structure apps, not just what we build
🤖 AI-powered development: building with LLMs, agents, and AI SaaS apps
⚛️ React & Next.js deep dives: patterns we actually use in production
💡 Quick dev tips: short, practical things you can use today

Now it's your turn 👇

We want our first DEV article to come from you. Which topic should we write about first?

🤖 Building AI agents (agentic engineering)
🎬 Scroll animations with GSAP
⚡ Getting started with TanStack Start
💼 Launching a SaaS in under 7 days

Drop your vote (or your own idea) in the comments. The most-requested topic becomes our first full article! 🔥

Want to go deeper right now? Check out all our courses.

DEV Community: JavaScript Mastery

AI wrote it, you merged it: 4 JavaScript bugs to catch in review

1. async inside forEach doesn't wait

2. .sort() without a comparator sorts strings

3. map(parseInt) passes the index as the radix

4. Spread is a shallow copy

Let tools take the first pass

A 60-second review routine for AI-drafted PRs

Wrap-up

[Boost]

Let’s Talk About Claude Code, Part 2: Container or Sandbox VM?

[Boost]

Run multiple Claude Code sessions without file conflicts

We Gave Our AI Coding Agents an Office. These Are the House Rules.

The setup in one paragraph

Rule 1: The lead never writes app code

Rule 2: One task = one branch = one PR

Rule 3: Edit only the files your task lists

Rule 4: Every agent gets its own desk

Rule 5: Ask, don't work around

Rule 6: HQ never merges

Steal the rules without installing anything

Try it

The honest limits

What's next

This Week in AI for Developers: IPOs, Texting Agents & Self-Replicating Models

1. Anthropic filed to go public (ticker: ANT)

2. OpenAI's agents moved into your text messages

3. Anthropic says small models may soon copy themselves

4. Big Tech is spending more on AI and fewer people

What to actually do this week

The big picture

Sources

AI Writes Half Our Code Now. Nobody Taught Us How to Review It.

The numbers changed. Our habits didn't.

Bug #1: forEach doesn't wait for async

Bug #2: The try/catch that catches nothing

Bug #3: Sorting numbers like they're words

Bug #4: The timer that's stuck on 1

Bug #5: The list that never updates

The 30-second review checklist

The real skill in 2026 isn't prompting

Your turn 👇

Your First Dev Job in 2026: The Roadmap Nobody Gave You

The roadmap at a glance

Stage 1: Fundamentals AI can't fake

Stage 2: AI fluency, not AI dependence

Stage 3: Build 1–2 real projects, not 10 clones

Stage 4: Testing and shipping

Stage 5: System thinking

Stage 6: Show your work

Stage 7: Interview ready

Your "before I hit apply" checklist

JavaScript Mastery is officially on DEV!

Why DEV?

What you can expect from us

Now it's your turn 👇

1. `async` inside `forEach` doesn't wait

2. `.sort()` without a comparator sorts strings

3. `map(parseInt)` passes the index as the radix

Bug #1: `forEach` doesn't wait for `async`

Bug #2: The `try/catch` that catches nothing