DEV Community: Gautam

AI Can Write Your React Code. It Still Can't Tell You Why It's Wrong.

Gautam — Thu, 16 Jul 2026 07:17:00 +0000

Every few months there's a new wave of "AI just made developers obsolete" takes, and every few months React developers specifically get singled out as the easiest to replace — "it's just JSX and hooks, the model's seen a million examples of that." I've been building with React for a while now, and I've been using AI tools daily for just as long. Here's the actual gap nobody talks about, and it's not the one you'd expect.

AI is genuinely great at the part everyone worries about

Ask any decent model to write a useDebounce hook, a controlled form, a memoized list — it'll produce something that looks right, compiles, and probably works for the happy path. That part of the fear is legitimate. The boilerplate-to-competent-code gap has basically closed.

The part it's still bad at: telling you why your version is wrong

Here's the thing that doesn't show up in demos. AI-generated code looks confident regardless of whether it's actually correct. It'll happily hand you a useEffect with a subtly wrong dependency array, a debounce hook that breaks on rapid unmount, a memoized callback that isn't actually stable — and it'll explain the code with the same confident tone whether the explanation is right or completely made up.

The failure mode isn't "AI can't write React." It's "AI can't reliably tell you when your React is broken, and it can't force you to confront the gap between code that looks plausible and code that's actually correct under real conditions."

Why this matters more for React specifically than people think

React bugs are rarely syntax errors. They're timing bugs, stale closures, unstable references causing silent re-renders, cleanup functions that don't run when you assumed they would. None of that shows up by reading the code. It shows up when the code actually runs against real interaction — fast clicks, rapid typing, a component unmounting mid-effect.

An AI model reading your code can miss all of that, the same way a human skimming a pull request can. The only thing that reliably catches it is running the code against real conditions and checking the actual behavior, not the code's appearance.

So what's actually changing for developers

Not "will AI replace you." The real shift is: the value of writing boilerplate correctly is dropping fast, while the value of knowing whether code is actually correct — being able to reason about edge cases, verify behavior, and catch what an AI-generated confident explanation glossed over — is going up. If your entire skill was typing out a useEffect from memory, that's genuinely less valuable now. If your skill is knowing that a debounce hook needs to survive an unmount mid-timer and being able to verify that it does, that's more valuable than ever, because it's exactly the thing AI output doesn't reliably self-check.

Practically, this means practicing differently

Reading AI-generated React code and nodding along teaches you nothing about whether you could catch the same bug yourself. The instinct that actually matters — spotting a stale closure, knowing when a dependency array is wrong, recognizing an unstable reference — only builds by writing code yourself and getting real, immediate feedback on whether it's actually correct, not whether it looks correct.

This is part of why I built ReactGrind — React-specific coding challenges checked by real automated test suites instead of a written answer key. The whole point is closing that exact gap: you write the component, real tests mount it and interact with it the way a user actually would, and you find out immediately whether it holds up — not whether it merely resembles a correct answer.

AI can write plausible React code all day. Practicing against real tests is still how you build the instinct to know the difference.

Curious what others are seeing here — has your day-to-day debugging shifted at all now that AI writes a bigger share of first-draft code? What's actually catching the bugs for you these days?

I built a LeetCode-style platform, but for only for React (not DSA)

Gautam — Tue, 14 Jul 2026 23:15:10 +0000

If you've ever prepped for a frontend interview, you've probably hit this weird gap: LeetCode will happily grill you on binary trees and dynamic programming, but it has almost nothing to say about the thing you'll actually be asked to build in a real frontend interview — a debounced search box, a modal that traps focus correctly, a component that doesn't quietly re-render itself into a performance problem.

That gap is why I built ReactGrind.

What ReactGrind actually is?

ReactGrind is a coding practice platform built specifically around React — not algorithms, not data structures, just the actual behavior of React itself: hooks, rendering, state, effects, memoization, and the kind of edge cases that only show up once real user interaction is involved.

Every challenge comes with a real automated test suite, not a static answer key. You write a component, hit run, and the tests mount it, click it, type into it, and check the result — the same way a real pull request gets reviewed before it ships. If it passes, you know it actually works. If it fails, you know exactly where.

What's on there right now

50+ problems (adding questions daily) across Hooks & State, Custom Hooks, Performance, Context & Patterns, Forms & Events, and a FAANG-style Interview Set
A React Interview Prep section — 200+ questions with plain-English explanations, analogies, and code examples, not just one-line definitions
A free online React compiler/playground — no signup, no setup, just write and run React code instantly in the browser
A blog covering practical React engineering topics — React 19's actual production impact, MERN stack interview prep, and things like whether React counts as frontend or backend (yes, people really do ask that)

Why test-based practice, specifically?

Writing a debounced search box is easy. Writing one that still works when someone types fast, deletes everything mid-debounce, or unmounts the component while a timer is pending — that's the part that actually gets caught in code review, and it's the part a written answer key can't check for you. A real test suite catches it immediately, which is a much better habit to build than comparing your code to someone else's "correct" solution and hoping it's equivalent.

If you're prepping for a frontend role, or you just want to stay sharp on React outside of whatever you're building at work, it's free to start: reactgrind.com

Since this is early and actively evolving — if you try it and something feels off, missing, or like it should exist but doesn't, I'd genuinely like to hear it. Bug reports, feature ideas, "this problem's test cases are wrong," all of it is useful right now.

10 React Hooks Interview Questions That Actually Trip People Up (With Explanations)

Gautam — Sun, 12 Jul 2026 12:42:05 +0000

If you've been prepping for React interviews, you've probably noticed most interview question lists online are either too basic (what is useState) or copy-pasted from the same five articles. So I put together a list of hooks questions that come up often in real interviews — the kind that sound simple but expose whether you actually understand what's happening under the hood.

Let's go through them.

Why does this useEffect cause an infinite loop?

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

  useEffect(() => {
    setCount(count + 1);
  });

  return <div>{count}</div>;
}

Answer: No dependency array means the effect runs after every render.
Since it updates state on every run, it triggers another render, which
triggers the effect again — forever. Add [] if you want it to run once, or a proper dependency array if it should run on specific value changes.

What's the difference between useMemo and useCallback?

Both cache something between renders, but:

**useMemo **caches a value (the result of a computation)
**useCallback **caches a function reference

A common gotcha: useCallback(fn, deps) is literally equivalent to
useMemo(() => fn, deps). If you understand that, you understand both.

Why does my state update not reflect immediately after setState?

const [name, setName] = useState("Aman");

function handleClick() {
  setName("New Name");
  console.log(name); // still logs "Aman"
}

Answer: State updates are **asynchronous **and batched. name inside
handleClick is a snapshot from the current render's closure — it won't
reflect the update until the component re-renders.

What problem does useRef solve that useState can't?

useRef gives you a mutable object that persists across renders without
triggering a re-render when it changes. Great for:

Storing a DOM node reference
Keeping a mutable value (like a timer ID) that shouldn't cause a re-render

Why do custom hooks need to start with "use"?

It's not just convention — it's how React's linter (and React itself) knows to apply the Rules of Hooks (no conditional calls, no calls inside loops) to your custom hook. Name it getSomething instead of useSomething and ESLint's hooks plugin won't catch violations inside it.

What's a stale closure, and how does it happen with hooks?

useEffect(() => {
  const interval = setInterval(() => {
    console.log(count); // always logs the initial value
  }, 1000);
  return () => clearInterval(interval);
}, []);

Answer: The effect's closure captures count from the render it was
created in. With an empty dependency array, that closure never updates —
so count is frozen at its initial value forever inside the interval.

When would you use useLayoutEffect instead of useEffect?

Answer: useLayoutEffect runs synchronously before the browser paints. Use it when you need to measure or mutate the DOM before the user sees anything (e.g., preventing a visual flicker when adjusting an element's position). useEffect runs after paint, which is fine for most side effects (data fetching, subscriptions).

Can you conditionally call a hook?

No — and interviewers love asking why, not just that. React tracks hooks
by call order per render, not by name. If a hook is skipped in one render
and called in another, the entire hook-state mapping shifts, causing bugs
that are hard to trace.

What does the dependency array in useEffect actually compare?

Shallow equality (Object.is), not deep equality. This is why passing an
object or array literal as a dependency causes the effect to run on every
render — a new reference is created every time, even if the contents are
identical.

How would you debounce a search input using hooks?

function useDebounce(value, delay) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debounced;
}

The cleanup function is the key part — it cancels the previous timer
whenever value changes before the delay finishes, so only the last
keystroke actually triggers the debounced update.

If you want to test yourself on questions like these interactively (with
instant feedback instead of just reading answers), I've been building
ReactGrind — a LeetCode-style platform specifically
for React.js practice. Still actively adding new challenges, so feedback is very welcome if you try it out.

What's a hooks question that stumped you in an interview? Drop it in the
comments — might turn it into a follow-up post.