DEV Community: James Mateer

AI wrote my bug. I shipped it anyway. Here’s what I learned.

James Mateer — Wed, 20 May 2026 11:08:43 +0000

Last month, I let AI “help” me refactor a small but performance-critical bit of frontend code. It confidently gave me a clean, modern solution. Types checked, tests were green, and the code looked nicer than what I’d written before. I merged it.

Two days later, a user reported that a key interaction was randomly failing. Turned out the bug was subtle, intermittent, and 100% introduced by that AI-generated snippet. The worst part: the code looked so reasonable that my brain just rubber-stamped it.

This is how AI is in my workflow now: incredibly useful, occasionally dangerous, and something I treat more like a junior teammate than a trusted source of truth.

Tools in my day-to-day workflow
Here’s what I actually use as a JavaScript/web dev working on real projects:

GitHub Copilot for inline suggestions, writing boilerplate React components, and quick refactors.

Claude for “bigger brain” tasks: explaining legacy code, generating first-draft docs, and exploring alternative designs.

Browser devtools + tests as the “reality check” layer when AI feels too confident.

AI’s job in my workflow is to speed up the “typing” and help me explore ideas, not to replace my thinking.

When AI really helped: reducing noisy event handlers
I had a React component that attached a scroll listener and did some heavy work on every event. It wasn’t catastrophic, but it caused jank on low-end devices. I asked Copilot to suggest a lightweight throttling solution.

AI-generated suggestion (good enough start)
js
// AI suggestion: basic throttle for scroll handler
function throttle(fn, delay) {
let lastCall = 0;

return function (...args) {
const now = Date.now();
if (now - lastCall >= delay) {
lastCall = now;
fn.apply(this, args);
}
};
}

function handleScroll() {
// expensive calculation
}

window.addEventListener('scroll', throttle(handleScroll, 100));
This was actually pretty decent for my use case. It avoided calling handleScroll on every scroll event and eliminated most of the jank.

I still made adjustments:

Extracted the throttle into a shared utility.

Added proper typing and tests.

Verified behavior in the browser with real scrolling patterns.

Final version after review
ts
// utils/throttle.ts
export function throttle void>(
fn: T,
delay: number
) {
let lastCall = 0;
let timeoutId: number | null = null;

return function (this: unknown, ...args: Parameters) {
const now = Date.now();
const remaining = delay - (now - lastCall);

if (remaining <= 0) {
  lastCall = now;
  if (timeoutId !== null) {
    window.clearTimeout(timeoutId);
    timeoutId = null;
  }
  fn.apply(this, args);
} else if (timeoutId === null) {
  timeoutId = window.setTimeout(() => {
    lastCall = Date.now();
    timeoutId = null;
    fn.apply(this, args);
  }, remaining);
}

};
}
AI got me 60–70% of the way. I added the rest: better handling of calls at the edges, reuse, and type safety.

This is AI at its best in my workflow: drafting something reasonable that I then refine.

When AI misled me: a subtle async bug
Now the painful story.

I had some code that needed to ensure a DOM element existed before measuring it. I asked Copilot for a small helper that “waits for an element to exist then resolves with it or times out.” Copilot produced something like this:

AI suggestion (looked correct, wasn’t)
js
function waitForElement(selector, timeout = 3000) {
return new Promise((resolve, reject) => {
const element = document.querySelector(selector);
if (element) {
resolve(element);
return;
}

const observer = new MutationObserver(() => {
  const el = document.querySelector(selector);
  if (el) {
    observer.disconnect();
    resolve(el);
  }
});

observer.observe(document.body, { childList: true, subtree: true });

setTimeout(() => {
  observer.disconnect();
  reject(new Error('Element not found'));
}, timeout);

});
}
At a glance, it looked fine: observe DOM mutations, resolve when the element appears, reject on timeout. I skimmed it, tests passed, and I shipped it.

The bug? Under certain conditions, the timeout fired after the element was found and resolved. In rare race conditions, the promise would resolve and then later be rejected, causing unpredictable error handling elsewhere.

Corrected version with proper cleanup
js
function waitForElement(selector, timeout = 3000) {
return new Promise((resolve, reject) => {
const existing = document.querySelector(selector);
if (existing) {
resolve(existing);
return;
}

let settled = false;
const observer = new MutationObserver(() => {
  const el = document.querySelector(selector);
  if (el && !settled) {
    settled = true;
    observer.disconnect();
    window.clearTimeout(timeoutId);
    resolve(el);
  }
});

observer.observe(document.body, { childList: true, subtree: true });

const timeoutId = window.setTimeout(() => {
  if (!settled) {
    settled = true;
    observer.disconnect();
    reject(new Error(`Element not found: ${selector}`));
  }
}, timeout);

});
}
Key differences:

Introduced a settled flag.

Cleared the timeout when resolving.

Guarded both paths so the promise only settles once.

This is exactly the kind of subtle bug AI is prone to: the logic is “plausible” and looks idiomatic, but it hasn’t been truly thought through.

My framework for trusting AI (or not)
Here’s how AI fits into my decision-making:

Use AI for:

Boilerplate and repetitive patterns.

Utility functions that I heavily review.

Alternative approaches I might not think of on my own.

Writing tests and docs drafts that I refine.

Be skeptical when:

The code touches async, concurrency, or subtle browser behavior.

It involves security, authentication, or data validation.

The code “just works” and I don’t fully understand why.

Non-negotiables before merging AI code:

Read it line by line and explain it in plain language.

Add tests that would have caught the bug if the code were wrong.

Run it in a realistic environment, not just unit tests.

The mindset shift: AI is a junior engineer with infinite stamina but no real understanding. If it writes something you don’t fully get, that’s your bug waiting to happen.

Your turn
AI is now part of most dev workflows, for better or worse. For me, it’s worth the risk—but only when paired with a strong review habit and healthy skepticism.

How are you using AI in your workflow right now, and what’s one time it either saved you hours or nearly burned you—what happened?

The Scientific Method Made Me Better at Debugging Than I Expected

James Mateer — Fri, 08 May 2026 13:21:00 +0000

One of the first major bugs I hit as a junior developer looked simple at first.

My React frontend refused to talk to my Express backend. The terminal kept throwing errors, the browser showed failed requests, and after a few hours I was convinced I had fundamentally misunderstood how APIs worked.

At first, I did what I think a lot of beginners do: randomly changed things until something worked.

Bad idea.

Eventually I stopped, took a breath, and approached it the same way I used to approach problems in scientific environments: isolate variables and identify root causes.

I started using a simple “5 Whys” approach.

Problem: Frontend couldn’t connect to backend.

Why?
→ The request was failing.

Why?
→ The API endpoint returned a CORS error.

Why?
→ Express wasn’t configured to allow requests from the Vite frontend.

Why?
→ I never added CORS middleware.

Why?
→ I didn’t fully understand how frontend/backend communication actually worked yet.

That single debugging session changed how I think about development.

Instead of treating bugs like random disasters, I started treating them like experiments.

import express from "express";
import cors from "cors";

const app = express();

app.use(cors());

app.listen(3000, () => {
console.log("Server connected on port 3000");
});

The fix itself was tiny.

The lesson was not.

What surprised me most about software development is that professional developers don’t seem to know everything either. Before I started coding, I honestly thought experienced engineers just remembered entire frameworks and instantly knew solutions.

What I’ve discovered instead is that good developers:

Read documentation constantly
Break problems into smaller problems
Search intelligently
Debug methodically
Document what they learn

That last one surprised me most.

I used to think documentation was just corporate busywork. Now I understand it’s one of the most practical skills in development. Half the battle of solving future problems is leaving breadcrumbs for yourself.

I’ve started keeping notes on:

recurring errors
useful terminal commands
ESLint fixes
Git commands I always forget
project setup issues
debugging patterns

Something as simple as this has saved me hours:

git status
git add .
git commit -m "fix: resolved auth middleware issue"
git push origin main

Another thing that surprised me was how emotionally challenging development can be.

There were days where I felt genuinely underqualified. I’d spend hours on something that turned out to be a missing bracket or incorrect import path.

But I’m starting to realise that debugging is not proof that you’re failing.

Debugging is the work.

Every bug forces you to understand the system better than you did before.

One of the most encouraging moments I’ve had so far was seeing this message after hours of troubleshooting:

Server connected on port 3000

Tiny win. Massive confidence boost.

I’m still early in my journey, but I already think my previous experience outside tech gave me an advantage: learning how to think systematically under pressure.

Turns out that skill transfers surprisingly well into software development.

If you're career changing into dev, what's the biggest thing your old career taught you?