Fixing a memory leak in a legacy Node.js project using AI refactoring

I spent four hours last Thursday fighting a FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory error in a production-adjacent environment. The culprit was a 400-line function that handled PDF parsing and data transformation—a classic "God function" written by a developer who left the company three years ago.

The problem with using LLMs for this kind of work is that they are too eager to please. If you just ask an AI to "clean this up," it will rename variables to be more descriptive and add comments. That's not refactoring; that's cosmetics. Real refactoring solves a technical debt problem without changing the external behavior.

Why the initial prompt failed

My first attempt was lazy. I pasted the function into Claude 3.5 Sonnet and asked it to "refactor for performance and readability." It gave me a version that looked beautiful—broken into smaller functions, lovely variable names—but it actually made the memory leak worse. Why? Because the AI decided to map the entire PDF buffer into an array of objects for "better readability," which spiked the heap usage immediately.

The mistake was giving the AI too much autonomy over the data structure. To fix this, I had to shift from "make this better" to "isolate the state."

The diagnostic process and the actual fix

I stopped treating the AI as a magic wand and started treating it as a pair programmer. I fed it the specific error message and the heap dump analysis. I told it: "The memory leak is happening during the loop on line 142. Do not change the data structure to an array. Suggest a way to stream this data."

The breakthrough happened when I stopped asking for a "refactor" and started asking for a "memory-efficient transformation."

Here is the before and after of the critical section.

The "Before" (The Leak):

// This was loading the entire parsed set into memory
const data = pdfParser.parseSync(buffer); 
const processed = data.map(item => {
    return transform(item); // Massive object creation here
});
return processed;

The "After" (The Fix):

// AI suggested using a generator to handle items one-by-one
async function* processPdfStream(buffer) {
    const parser = new PdfStreamParser(buffer);
    for await (const page of parser) {
        yield transform(page);
    }
}

By switching to a generator pattern, the heap usage dropped from 1.8GB to 240MB. The code was actually shorter, but the architectural change was huge.

Avoiding the "Hallucinated Optimization" trap

When you do AI refactoring, you will hit a point where the AI suggests a library you've never heard of to "optimize" a loop. Be careful. Last month, an LLM tried to convince me to use a deprecated version of a streaming library that didn't even support my Node version.

My rule now: if the AI suggests a new dependency during a refactor, I manually verify the npm downloads and last-commit date before adding it.

To keep my prompts consistent across different projects, I've started using Prompt Sharing to save the specific "Constraint-Based Refactoring" templates that actually work. Instead of repeating "don't change the data structure" every time, I have a saved prompt that defines the boundaries of the refactor first.

My refactoring workflow comparison

I've tried three different ways to handle this. Here is how they actually stack up in a real project.

| Method | Speed | Risk of Regression | Result |
| :--- | :--- | :--- | :--- |
| Bulk Paste | Fast | High | Cosmetic changes, hidden bugs |
| Iterative Prompting | Medium | Medium | Better, but takes a lot of chatting |
| Constraint-Driven | Slow | Low | Production-ready, solved the leak |

The "Constraint-Driven" approach means I give the AI the current memory limit, the expected input size, and a list of "forbidden" changes (e.g., "Do not use .map() on the main buffer").

Leveraging community knowledge for better prompts

The wild part is that I didn't come up with the "Constraint-Driven" approach myself. I found a thread in the PromptCube community where a senior dev explained that LLMs struggle with spatial reasoning in large files. They suggested breaking the code into "logic blocks" and refactoring them individually rather than the whole file.

If you're struggling with a codebase that feels like a house of cards, don't just blindly trust a chat window. Checking out the Resources section of a developer community can give you a better framework for how to actually prompt for architectural changes. It's the difference between getting "cleaner code" and getting "code that doesn't crash."

The cost of the "Quick Fix"

I'll be honest: AI refactoring can be a trap. It's so easy to hit "Apply" in Cursor or Copilot that you stop thinking about the complexity. I once spent an entire afternoon refactoring a module, only to realize I'd introduced a race condition because the AI shifted a synchronous call to an async one without adding the proper await chain in the parent component.

It took me two hours to find that bug. The lesson? AI is great at suggesting patterns, but it's terrible at understanding the temporal execution of your specific app.

If you want to move away from haphazard chatting and start building a library of proven patterns, head to the PromptCube homepage and look into how to structure your prompts as assets. Treating a prompt like a piece of code—versioned, tested, and shared—is the only way to make AI refactoring predictable.

The fix for my memory leak didn't come from a "better" model; it came from better constraints. Stop asking the AI to "improve" your code. Tell it exactly what the bottleneck is and forbid it from changing the core data flow. That's where the actual wins are.