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

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?

推荐订阅源

DEV Community