DEV Community: Armand al-farizy

The AI Code Trap: Why Junior Developers Should Use AI to Read Code, Not Write It

Armand al-farizy — Thu, 05 Mar 2026 10:28:48 +0000

Introduction

We are living in the golden age of code generation. With tools like GitHub Copilot, Cursor, and ChatGPT, building a full-stack application has never felt faster. You type a prompt, hit enter, and suddenly you have a fully functional React component or a Node.js API route.

It feels like a superpower. But for junior developers and students stepping into the industry, this superpower is quietly becoming a massive trap.

I see a growing trend of developers outsourcing the "struggle" of programming to Artificial Intelligence. While this boosts short-term productivity and gives a dopamine hit of "getting things done," it is actively destroying long-term engineering skills.

Here is my perspective on why we need to fundamentally flip our relationship with Artificial Intelligence: Stop using AI to write your code, and start using it to read your code.

The Illusion of Competence

When you are learning a new framework, architectural pattern, or even a new language, the true value isn't found in the final, working code. The value is forged in the mental model you build while fighting through the errors.

Let’s look at the standard "Prompt-to-Code" pipeline today:

You encounter a problem (e.g., "How do I build a secure JWT authentication flow in Node.js?").
You ask an LLM.
The LLM spits out 100 lines of perfectly formatted code.
You paste it into your editor. It works. You move on.

You feel incredibly productive. But this is the Illusion of Competence.

What happens when a critical bug appears in production a month later? What happens when the underlying cryptography library updates and deprecates a function? Because you skipped the struggle of building it from scratch, you have no mental map of how the system actually works. You don't know how the tokens are signed, where they are stored, or how the middleware intercepts the request.

You are no longer an engineer; you are a passenger in your own codebase.

Using AI to write all your code doesn't make you a 10x developer. It makes you a 0.1x developer who is highly dependent on a 100x tool.

The "Ghost Bug" Case Study

Let me illustrate this with a backend scenario. Imagine a developer who uses AI to generate a file upload handler in vanilla Node.js using data streams.

The AI generates a block of code using req.on('data') and req.on('end'). The developer pastes it, uploads a 2MB image, and it works flawlessly.

Six months later, the company scales. Users start uploading 50MB PDF files, and suddenly, the Node.js server starts crashing with Out of Memory errors.

If the developer wrote that stream handler themselves, they would immediately recognize the bottleneck: they are buffering the entire file into the RAM before saving it, instead of piping it directly to the file system. But because the AI wrote it, the code is a "black box." The developer will likely just paste the error back into ChatGPT, hoping for another magic fix, trapping themselves in a cycle of ignorance.

The Paradigm Shift: The "Reverse-AI" Workflow

If we shouldn't use AI to write code, how do we use it? We treat it like a Senior Engineer sitting next to us. We use it to review, critique, and explain.

Here is a practical framework for interacting with LLMs that builds your skills instead of bypassing them:

1. The Struggle Phase (Write it yourself first)

Before opening any AI tool, write the code yourself. Let it be messy. Let it be inefficient. Use console.log everywhere. Hit the inevitable error wall. Force your brain to map out the logic and the data flow.

2. The Code Reviewer Prompt

Once you have a working (or semi-working) piece of code, then bring the AI in.

Instead of: "Write a function to merge arrays."
Try this: "Here is my JavaScript code to merge and filter these data arrays. It works, but the Big O notation feels like O(n^2) and it might be slow for large datasets. Can you review this architecture, point out any memory leak risks, and suggest a more efficient way to structure the loops? Please explain the 'why' behind your suggestions."

3. The Log Decoder Prompt

When you hit a massive error trace, don't ask for the solution. Ask for the translation.

Instead of: "Fix this Vercel deployment error."
Try this: "My deployment failed with this specific Node.js stack trace. Don't give me the exact code to fix it. Instead, explain what this error fundamentally means about my server configuration, and tell me which file or module I should investigate first."

4. The Socratic Mentor Prompt

You can even instruct the AI to refuse to give you code.

Try this: "I am trying to learn how Redux state management works. I want to build a shopping cart. Do not write the code for me. Instead, ask me guiding questions one by one to help me design the architecture myself. If I get stuck, give me a hint, not the answer."

Conclusion

The developers who will thrive in the AI era are not the ones who can type the fastest prompts to generate boilerplate code. Code generation will eventually become completely commoditized.

The developers who will win are the ones who deeply understand system architecture, data flow, and fundamental logic. They will be the ones who can look at 10,000 lines of AI-generated code, spot the architectural flaw, and know exactly how to fix it.

AI is arguably the greatest learning tool ever invented for software engineers, but only if you use it to upgrade your own brain, rather than outsourcing your brain to the machine.

Embrace the struggle. Write the bad code yourself. Then, let the AI teach you how to be better.

What are your thoughts?
Have you ever fallen into the trap of copy-pasting AI code without understanding the underlying logic? How do you balance the need for fast delivery with the need for deep learning? Let’s share our workflows in the comments!

Beyond the API Wrapper: A Web Developer's Deep Dive into RAG (Retrieval-Augmented Generation)

Armand al-farizy — Wed, 04 Mar 2026 16:03:57 +0000

Introduction

Take a look around the tech ecosystem today. Every week, hundreds of new "AI startups" launch on Product Hunt. However, if you peek under the hood, 90% of them are just thin UI wrappers around the OpenAI or Anthropic APIs.

While building a basic chatbot is a fun weekend project, it provides zero defensive moat for a real business. Enterprise clients don't just want an AI that can write poems; they want an AI that can read their proprietary PDF reports, query their private databases, and provide accurate answers without hallucinating.

To bridge the gap between a generic Large Language Model (LLM) and a company's private data, the industry has settled on a standard architecture: Retrieval-Augmented Generation (RAG).

For web developers transitioning into the AI space, understanding how to build a RAG pipeline is no longer optional—it's the most valuable skill you can acquire. In this deep dive, we will break down the mechanics of RAG and look at how to implement it using Node.js.

The Problem: Hallucinations and Knowledge Cutoffs

LLMs are essentially massive prediction engines trained on a snapshot of the public internet. This introduces critical flaws for enterprise use cases:

Outdated Information: If the model was trained in 2023, it knows nothing about your company's latest API documentation.
Context Window Limits: You cannot just paste a 10,000-page PDF into the prompt. The API will reject it or charge you an exorbitant amount of money.
Hallucinations: If you ask an LLM a highly specific question about a private document it has never seen, it will confidently invent a plausible-sounding lie to satisfy the prompt.

You cannot simply retrain (fine-tune) a massive LLM every time your company updates a document. It is too slow and too expensive.

The Solution: The RAG Architecture

Instead of forcing the LLM to memorize everything, RAG treats the LLM like a highly intelligent student taking an open-book exam.

Instead of asking the LLM to answer from memory, our backend first retrieves the relevant pages from the textbook, hands those pages to the LLM, and explicitly commands it to answer using only the provided context.

To build this, we must construct two distinct pipelines: The Ingestion Pipeline and the Retrieval Pipeline.

Phase 1: The Ingestion Pipeline (Preparing the Data)

Before an AI can search your documents, those documents must be mathematically translated. Computers do not understand words; they understand numbers.

1. Parsing and Chunking

You cannot feed an entire 50-page PDF into an embedding model at once. You must break the document down into smaller, semantic "chunks" (e.g., 500 characters per chunk).
Pro tip: Always add an "overlap" (e.g., 50 characters) between chunks so you don't accidentally cut a sentence in half.

2. Vector Embeddings

Once chunked, we pass each piece of text through an Embedding Model (like OpenAI's text-embedding-3-small). This model converts the text into a long array of floating-point numbers (a Vector).

Sentences with similar meanings will have vectors that are mathematically closer to each other in a multi-dimensional space. "Apple" the fruit will be far away from "Apple" the tech company.

3. The Vector Database

We store these vectors, along with the original text chunk, in a specialized Vector Database (like Pinecone, Qdrant, or pgvector).

Phase 2: The Retrieval & Generation Pipeline

Now that our database is populated, how does a user actually interact with it? Let's write the backend logic for this phase using Node.js and the OpenAI SDK.

The Backend Implementation (Node.js)

Imagine a user asks our Next.js/Node backend: "What is the company's remote work policy?"

Here is the exact code to process that request:

import { OpenAI } from "openai";
import { Pinecone } from "@pinecone-database/pinecone";

// Initialize our clients
const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
const pinecone = new Pinecone({ apiKey: process.env.PINECONE_API_KEY });
const index = pinecone.index("company-handbook");

export async function handleUserQuery(userQuestion) {
  try {
    // STEP 1: Vectorize the user's question
    const embeddingResponse = await openai.embeddings.create({
      model: "text-embedding-3-small",
      input: userQuestion,
    });
    const questionVector = embeddingResponse.data[0].embedding;

    // STEP 2: Query the Vector Database for the top 3 most relevant chunks
    const searchResults = await index.query({
      vector: questionVector,
      topK: 3,
      includeMetadata: true, // We need the original text, not just the numbers
    });

    // Extract the text from the results
    const retrievedContext = searchResults.matches
      .map((match) => match.metadata.text)
      .join("\n\n---\n\n");

    // STEP 3: Construct the dynamic Prompt
    const systemPrompt = `
      You are a helpful HR assistant. 
      Answer the user's question strictly using ONLY the following context. 
      If the answer is not in the context, explicitly say "I don't have enough information to answer that." Do not invent information.

      Context:
      ${retrievedContext}
    `;

    // STEP 4: Generate the final answer
    const completion = await openai.chat.completions.create({
      model: "gpt-4-turbo",
      messages: [
        { role: "system", content: systemPrompt },
        { role: "user", content: userQuestion }
      ],
      temperature: 0.2, // Keep it deterministic and factual
    });

    return completion.choices[0].message.content;

  } catch (error) {
    console.error("RAG Pipeline Error:", error);
    throw new Error("Failed to process query.");
  }
}

Breaking Down the Code

We don't send the text query to the database; we convert the user's question into a vector first using openai.embeddings.create.
Pinecone performs a Cosine Similarity Search to find the 3 chunks in our database that mathematically match the question's vector.
We inject those 3 chunks into a strict systemPrompt. We set the temperature to 0.2 to stop the LLM from being overly creative.

Why Web Developers Have the Ultimate Advantage

Data scientists are excellent at training and fine-tuning models, but deploying a production-ready RAG system is ultimately a software engineering problem.

Building this architecture requires:

Designing robust API routes.
Managing database connections and indexing.
Handling asynchronous streams (Server-Sent Events) for real-time typewriter UI effects on the frontend.
Ensuring strict security, rate limiting, and user access control (so User A cannot retrieve User B's vectorized documents).

If you already know how to build a scalable backend in Node.js or a full-stack application in Next.js, you already possess 80% of the skills required to build enterprise AI applications. You just need to swap out your traditional SQL queries for Vector Searches.

Conclusion

The era of the "thin API wrapper" is effectively over. The startups and engineers that survive the AI hype cycle will be the ones that effectively integrate proprietary data with generative models.

By mastering the RAG architecture, you elevate yourself from a standard web developer to an AI Engineer capable of solving complex, data-heavy business problems. Stop relying on the model's static memory, and start building intelligent, dynamic context engines.

What are your thoughts?
Have you integrated a Vector Database into your web apps yet? Which stack do you prefer for building RAG pipelines (orchestration frameworks like LangChain/LlamaIndex, or building the raw logic from scratch like above)? Let’s discuss in the comments!

Under the Hood: Building a RESTful API from Scratch with Vanilla Node.js

Armand al-farizy — Wed, 04 Mar 2026 15:46:45 +0000

Introduction

We live in an era of npm install magic-framework. If a modern developer needs to spin up a backend API, the immediate instinct is to install Express, NestJS, or Hapi. While these frameworks are incredible for productivity, they act as massive black boxes.

When a complex network bug occurs, or when a memory leak happens in the routing layer, developers who only know the framework often hit a wall. They understand how to use the tool, but they don't understand how the machine actually works.

To truly master backend engineering, you need to understand what happens underneath the framework. In this article, we are going to ditch the external dependencies. We will build a fully functional CRUD RESTful API using nothing but Vanilla Node.js and its core http module.

The Challenge of a Framework-Less Server

When you use a framework like Express, handling a route is as simple as app.get('/notes', handler).

Without a framework, Node.js doesn't know what a "route" is. It only gives you a raw incoming Request stream and an outgoing Response object. You have to manually:

Parse the requested URL.
Check the HTTP method (GET, POST, PUT, DELETE).
Manually collect incoming data buffers (because data over the internet doesn't arrive all at once; it arrives in chunks).

Let's build a simple API to manage a notebook application to see this in action.

Step 1: The Raw HTTP Server and Routing

Create a file named server.js. We will import the built-in http module and set up the foundation of our router.

const http = require('http');

// Our temporary in-memory database
const notes = [];

const server = http.createServer((req, res) => {
    // Standardize the response headers to return JSON
    res.setHeader('Content-Type', 'application/json');
    res.setHeader('Access-Control-Allow-Origin', '*');

    // Extract the URL and Method from the raw request
    const { url, method } = req;

    // --- ROUTING LOGIC ---
    if (url === '/notes') {
        if (method === 'GET') {
            // Handle GET /notes
            res.statusCode = 200;
            res.end(JSON.stringify({ status: 'success', data: notes }));
            return;
        }

        if (method === 'POST') {
            // Handle POST /notes (We will implement this next)
            handlePostRequest(req, res);
            return;
        }
    }

    // Fallback for 404 Not Found
    res.statusCode = 404;
    res.end(JSON.stringify({ status: 'fail', message: 'Route not found' }));
});

const PORT = 5000;
server.listen(PORT, () => {
    console.log(`Vanilla Node.js server running on port ${PORT}`);
});

Step 2: The Tricky Part - Handling Data Streams

This is where framework developers usually get lost. When a client sends a POST request with JSON data, Node.js doesn't just hand you a neatly parsed JavaScript object. It streams the data in binary chunks.

We have to listen for the dataevent, collect the chunks into an array, and then combine them when the endevent fires.

Let's implement the handlePostRequest function above our server block:

const { randomUUID } = require('crypto'); // Built-in Node.js module

function handlePostRequest(req, res) {
    let body = [];

    // 1. Collect data chunks as they arrive
    req.on('data', (chunk) => {
        body.push(chunk);
    });

    // 2. When the stream is finished, process the data
    req.on('end', () => {
        try {
            // Convert Buffer array to string, then parse to JSON
            const parsedBody = JSON.parse(Buffer.concat(body).toString());

            const newNote = {
                id: randomUUID(),
                title: parsedBody.title,
                body: parsedBody.body,
                createdAt: new Date().toISOString()
            };

            notes.push(newNote);

            res.statusCode = 201; // Created
            res.end(JSON.stringify({
                status: 'success',
                message: 'Note added successfully',
                data: { noteId: newNote.id }
            }));
        } catch (error) {
            // Handle bad JSON format
            res.statusCode = 400;
            res.end(JSON.stringify({ status: 'error', message: 'Invalid JSON body' }));
        }
    });
}

Step 3: Testing the Raw API

Because we have absolutely zero external dependencies, you don't even need npm install. Just run:

node server.js

You can test this using cURLor Postman. To add a note, send a POST request:

curl -X POST http://localhost:5000/notes \
-H "Content-Type: application/json" \
-d '{"title": "My First Note", "body": "Understanding vanilla Node.js is awesome."}'

And you will receive a clean, framework-less JSON response.

Architectural Verdict

Will I ever write an enterprise-level API in production using strictly Vanilla Node.js? Absolutely not. Writing manual stream handlers, dealing with complex nested routing paths (like /notes/:id/comments), and managing security headers manually is a waste of engineering time when tools like Express or Hapi exist.

However, building this raw server is a mandatory rite of passage. Once you understand how to manually parse a Buffer stream and construct an HTTP response header, you stop seeing frameworks as magic. You see them for what they truly are: utility wrappers around the http module. This fundamental knowledge is what separates framework operators from true software engineers.

What are your thoughts?
Have you ever tried building a backend without relying on external NPM packages? How deep do you think developers need to understand the underlying modules before jumping into modern frameworks? Let me know in the comments!

Evaluating Client-Side Document Processing in Next.js: Architectural Trade-offs

Armand al-farizy — Wed, 04 Mar 2026 15:19:13 +0000

Introduction

When building document utility applications, developers inevitably face a critical architectural crossroad: Should file manipulation occur on a backend server, or directly within the user's browser?

Historically, heavy lifting was always delegated to the server. However, with the rise of strict data privacy regulations (like GDPR) and the increasing power of modern browsers, client-side processing—often referred to as the Local-First approach—has become a highly attractive proposition.

To evaluate the true viability of this architecture, I built a Next.js application designed to merge, split, and manipulate PDF documents entirely in the browser using JavaScript. The goal was simple: zero server compute costs and absolute data privacy.

In this article, we will examine the mechanics of client-side PDF manipulation, walk through a core implementation using pdf-lib, and critically analyze the severe technical bottlenecks developers must consider before adopting this architecture for production workloads.

The Appeal of the Local-First Architecture

Before diving into the code, it is important to understand why companies are pushing for in-browser compute:

Absolute Privacy: Sensitive documents (medical records, legal contracts) never leave the user's local machine. This mitigates massive legal liabilities for the developer.
Zero Compute Costs: By shifting the processing load to the client's CPU and RAM, cloud hosting bills are reduced to practically nothing. You only pay to serve the static frontend assets.
Offline Capabilities: Once the JavaScript bundle is loaded, the application can function entirely offline.

"The best way to secure user data is to never collect it in the first place."

The Implementation: Merging PDFs in Next.js

To handle PDF manipulation without a Node.js or Python backend, the browser needs to read the physical file into its memory as an ArrayBuffer. We can then use libraries like pdf-lib to modify the binary data.

Here is a core implementation within a Next.js environment. This function takes an array of uploaded files, merges them, and prepares a new document for download.

import { PDFDocument } from 'pdf-lib';

/**
 * Merges multiple PDF files entirely on the client side.
 * @param {File[]} fileList - Array of File objects from an HTML file input.
 * @returns {Promise<Uint8Array>} - The merged PDF as a byte array ready for download.
 */
export async function mergePDFsClientSide(fileList) {
  try {
    // 1. Initialize a new, empty PDF document
    const mergedPdf = await PDFDocument.create();

    // 2. Iterate through each uploaded file
    for (const file of fileList) {
      // Read the file into browser memory
      const arrayBuffer = await file.arrayBuffer();
      const loadedPdf = await PDFDocument.load(arrayBuffer);

      // Extract all pages from the current document
      const pageIndices = loadedPdf.getPageIndices();
      const copiedPages = await mergedPdf.copyPages(loadedPdf, pageIndices);

      // 3. Append copied pages to our new canvas
      copiedPages.forEach((page) => mergedPdf.addPage(page));
    }

    // 4. Serialize the PDFDocument to bytes (a Uint8Array)
    const pdfBytes = await mergedPdf.save();
    return pdfBytes;

  } catch (error) {
    console.error("Failed to merge documents:", error);
    throw new Error("Client-side merging failed.");
  }
}

Triggering the Download

Once the Uint8Array is generated, we can force the browser to download it using a Blob URL:

const blob = new Blob([pdfBytes], { type: 'application/pdf' });
const url = URL.createObjectURL(blob);
const link = document.createElement('a');
link.href = url;
link.download = 'merged-document.pdf';
link.click();
URL.revokeObjectURL(url); // Clean up memory

The Reality Check: Where Client-Side Falls Short

While the implementation above works flawlessly for lightweight, text-based files, rigorous testing reveals significant bottlenecks that make pure client-side processing dangerous for heavy workloads.

Memory Heap Limitations (The Silent Crash): Browsers enforce strict, hard-coded limits on the amount of RAM a single tab can consume (often around 2GB to 4GB depending on the browser and OS). When a user attempts to merge large, image-heavy PDFs (e.g., a 100MB scanned document), the browser must load the entire uncompressed data into its memory heap. This frequently leads to severe UI freezing, thread blocking, and eventual browser crashes with the dreaded "Out of Memory" error. There is no graceful way to catch this error in JavaScript; the tab simply dies.
Single-Threaded UI Blocking: JavaScript executes on a single main thread. Heavy mathematical operations—like parsing and serializing complex PDF binary trees—will completely block the UI thread. Even within a highly optimized framework like Next.js, unless this workload is intentionally offloaded to Web Workers, the entire application becomes unresponsive. Animations freeze, buttons cannot be clicked, and the user assumes the app is broken.
Format Conversion is a Nightmare: Merging PDFs is one thing, but converting a .docx (Word document) into a .pdf purely via client-side JavaScript is highly inefficient. Word documents are essentially complex XML archives. Browsers lack the native rendering engines required to interpret complex XML structures, pagination rules, and proprietary fonts accurately. Attempting this on the client side usually results in broken layouts and missing text. Robust document conversion inherently requires heavy backend dependencies like headless browsers (Puppeteer) or LibreOffice binaries.

Architectural Verdict

Building a purely client-side document processor highlights a clear dividing line in system design. Here is when you should use each approach:

Choose Client-Side (Browser) When:

The expected file sizes are strictly small (under 10MB).
Absolute data privacy is the core selling point of your application.
You want to eliminate server processing costs entirely.

Choose Server-Side (Node.js/Python) When:

You expect large, image-heavy files.
You need to perform complex format conversions (e.g., Word/Excel to PDF).
You require stable, predictable performance regardless of the user's hardware.

Conclusion
The local-first approach is incredibly powerful for privacy-centric utility apps. However, developers must be acutely aware of browser memory limits and the single-threaded nature of JavaScript. For enterprise-grade applications, offloading compute to a dedicated server—or leveraging WebAssembly (Wasm) for near-native in-browser performance—remains mandatory to ensure application stability.

What are your thoughts?
Have you ever tried pushing the limits of client-side processing in your Next.js apps, or do you strictly rely on backend architectures for heavy tasks? Let’s discuss the trade-offs in the comments below!