DEV Community: Deepansh Bhargava

Read about how AI Agents are developed in real world scenarios

Deepansh Bhargava — Mon, 27 Jul 2026 11:14:00 +0000

Deepansh Bhargava

Jul 27

Building an AI Coding Agent: 80% Engineering, 20% LLM

#ai #llm #programming #webdev

7 min read

Building an AI Coding Agent: 80% Engineering, 20% LLM

Deepansh Bhargava — Mon, 27 Jul 2026 09:33:58 +0000

Few months into building Piper, I watched the agent confidently edit the wrong file.

The user asked: "Add pagination to the Jobs page."

The agent searched the codebase, found a file with "Jobs" in the name, and modified it.

Except it was a test file, not the component.

The resulting PR broke the entire test suite.

That's when I realized something fundamental: building an AI coding agent isn't about choosing the right LLM.

It's about everything that happens before and after the LLM thinks.

What Makes a Coding Agent Useful?

A coding agent is more than autocomplete on steroids.

Instead of answering questions, it completes tasks.

Real tasks:

Understand an existing codebase
Find the right files to modify
Make changes without breaking things
Run tests to verify the fix
Commit and open a pull request

I spent the first month thinking the hard part was prompting the LLM. It wasn't.

The hard part was everything else.

How Context Selection Broke Everything

The Problem

I started simple. I'd send the entire repository to the LLM.

It worked for small codebases.

Then I tried Piper on a 50,000-line monorepo.

Two things happened:

Token limits kicked in — I could only send 10% of the code
The agent got confused — too much irrelevant context made it hallucinate

So I tried searching. If the user asked about "pagination," I'd find files with "pagination" in the name.

Better, but still broken.

The Jobs example shows why: the test file was named jobs.test.ts. It matched the search perfectly. The agent couldn't distinguish between the real component and the test.

The Iteration

I realized the indexer needed to understand repository structure, not just filenames.

The breakthrough came from thinking about how I search a codebase:

I look at the folder structure
I identify patterns (components in /src/components, tests in __tests__)
I read imports to trace dependencies
I understand which files are related

So I built an indexer that does exactly that.

It analyzes:

Directory patterns
Import relationships
File naming conventions
The AGENTS.md file (if it exists)

Now when asked about "Jobs," the indexer understands that src/pages/jobs.tsx is probably more relevant than __tests__/jobs.test.ts.

It's still not perfect, but it's radically better.

The lesson: Good retrieval beats bigger models. I've seen a smaller model with the right 5 files outperform a bigger model with 50 irrelevant ones.

When the Model Kept Editing the Wrong Files

The Failure

Even with better retrieval, the agent still made mistakes.

It would understand the problem, read the right files, then somehow edit the wrong one.

I realized the agent needed to think before acting.

So I added a planning phase.

Plan Mode

Before executing code changes, the agent now:

Analyzes the problem
Searches the repository
Reads relevant files
Proposes a plan
Waits for user approval
Then executes

Here's what that looks like:

The user can review this before the agent touches any files.

It sounds simple, but it eliminates the majority of mistakes.

The lesson: Making the model "think out loud" before acting reduces errors dramatically. Users also trust the agent more when they can see its reasoning.

Why One Model Wasn't Enough

The Discovery

I was using the biggest, most powerful model for everything.

Searching for files? Overkill.

Refactoring complex code? Necessary.

But I was paying for powerful reasoning on every simple task.

My costs were terrible. My latency was worse.

The Solution

I built automatic model routing.

For simple tasks (searching, reading files, answering questions), the agent uses Gemini 2.5 Flash Lite.

For complex tasks (refactoring, debugging, architecture decisions), it uses Gemini 2.5 Flash.

How does it decide? By analyzing the user's message:

Keywords like "implement," "debug," "refactor" → use Flash
Just reading or searching → use Flash Lite
Code blocks in the message → use Flash
Message longer than 80 words → use Flash

If the primary model fails, it automatically falls back to the other.

Cost dropped 60%. Latency improved. Quality stayed the same.

The lesson: Not every task needs maximum capability. Intelligent routing is worth the complexity.

Git Integration Made It Feel Like a Teammate

Why It Matters

Making code changes is only half the workflow.

A developer still needs to:

Review changes
Commit with a message
Push the branch
Open a PR

Adding this in the cycle changes everything.

An Example

User: "Fix the sorting bug in the Jobs page."

↓ Agent reads files

readFile("src/pages/jobs.tsx")
readFile("src/hooks/useSortJobs.ts")

↓ Agent identifies the bug

terminal("npm test") — tests fail
terminal("npm test -- --grep 'sorting'") — isolated failure

↓ Agent makes changes

writeFile("src/hooks/useSortJobs.ts") — fix the bug

↓ Agent verifies

terminal("npm test") — all pass

You can ask the agent to commit the changes & raise the PR, it'll ask for your approval and you can approve or reject it.

The lesson: Finishing the workflow matters as much as the individual steps.

Things That Didn't Work

Looking back, here's what I tried and abandoned:

Sending the Entire Repository

What I tried: Load every file, let the LLM figure out what matters.

Why it failed: Token limits, context confusion, hallucinations.

What replaced it: Intelligent indexing with repository structure awareness.

One Giant System Prompt

What I tried: Put all instructions in the system message.

Why it failed: Too long, contradictory, hard to maintain.

What replaced it: Modular instructions, runtime context, AGENTS.md support.

Letting the Model Edit Files Directly

What I tried: writeFile with no verification.

Why it failed: Syntax errors, broken imports, wrong files edited.

What replaced it: Plan mode + user approval before write operations.

Using the Biggest Model for Everything

What I tried: Always use the most powerful LLM.

Why it failed: Unnecessary cost, slower latency, no benefit for simple tasks.

What replaced it: Automatic model routing based on task complexity.

Skipping the Planning Phase

What I tried: Jump straight to implementation.

Why it failed: Logical errors, editing wrong files, breaking code.

What replaced it: Mandatory planning before any write operations.

No Checkpointing or State Management

What I tried: Each tool call was independent.

Why it failed: Lost conversation history, no audit trail, couldn't resume interrupted tasks.

What replaced it: SQLite checkpointing with LangGraph.

No Human Approval Mechanism

What I tried: Let the agent do everything automatically.

Why it failed: Users didn't trust it. Risky operations happened without consent.

What replaced it: ask_user tool for approval gates.

What I'd Do Differently

Start With Trust, Not Features

I built tools first and trust later.

I should have done it backwards.

Start by asking: "What operations do users need to approve? What's irreversible?"

Then build the approval mechanism first.

Measure Against Real Workflows

I tested with toy examples.

Real workflows are messier: interrupted tasks, conflicting edits, unclear requirements.

Testing against real repositories would have surfaced the planning problem months earlier.

Plan Mode From Day One

Every agent eventually needs planning.

Instead of bolting it on later, build it in from the start.

What's Actually True About AI Agents

After building Piper, here's what I believe:

The LLM is 20% of the work.

The other 80% is:

Context retrieval (finding the right files)
State management (knowing what happened)
Planning (thinking before acting)
Verification (did it work?)
User control (approval gates)
Error recovery (what to do when things break)

Bigger models help less than you think.

The difference between Flash and Flash Lite disappears when you give the LLM good context.

A smaller model with the right 5 files beats a bigger model with 50 irrelevant ones.

Human approval is non-negotiable.

Users trust agents that ask permission.

Agents that "just do things" lose trust fast.

Shipping teaches you more than planning.

I learned more from the broken agent than from architecture diagrams.

The planning phase, the timeouts, the state management — all came from failures, not design documents.

What This Means If You're Building Something Similar

Don't spend months perfecting your prompt.

Don't optimize model selection before you have state management.

Don't skip the planning phase.

Instead:

Build retrieval first (find the right context)
Add checkpointing immediately (preserve state)
Implement planning (think before acting)
Add approval gates (build trust)
Then optimize everything else

The fundamentals matter more than any particular LLM or framework.

Four months ago, I thought the hard part was choosing the right model.

Today I spend far more time thinking about context retrieval, state management, planning, and user trust than I do about prompts or which LLM to use.

That's the biggest lesson Piper taught me.

If you're building an AI agent, spend less time on prompts and more time on everything around it.

That's where the magic actually happens.

Try Piper

Want to see these lessons in action?

Piper is live at https://piper.codecoves.in

Clone a GitHub repository, ask it to fix a bug or add a feature, and watch it:

Search the right files
Propose a plan
Ask for approval
Make changes
Commit and open a PR

It's built exactly as described in this article — retrieval first, planning before acting, human approval for risky operations.

What's Next

Piper is intentionally a V1. My goal wasn't to compete with Cursor or Claude Code overnight. It was to build a complete end-to-end coding agent that could take a request from understanding a repository all the way to creating a pull request. There are dozens of features I still want to build, but I wanted to ship a solid foundation first and learn from real usage.

Virtual DOM in React

Deepansh Bhargava — Sun, 16 May 2021 11:31:57 +0000

Today we gonna learn about the Virtual DOM present in React, which is responsible for its fast performance and declarative nature.

What is DOM?

DOM stands for Document Object Model, which represents the node tree of all the UI elements present on a page. If any element on the UI changes, the DOM updates itself with the new changes.

This process of updating the DOM frequently makes the web page slow, so that's why there was a need for Virtual DOM. As we know DOM represents Tree Structure so the changes and updates are done quickly but the rerendering part takes a long time to complete.

If you know the Critical Rendering Path, the last step of it i.e Paint takes the longest time to complete, that's why browsers are optimized to repaint in minimum time.

Source: https://guillermo.at/browser-critical-render-path

What is Virtual DOM?

Virtual DOM represents a copy of the actual DOM. React maintains a copy of the DOM and renders the UI according to this DOM.

React works on the concept of observable pattern. It listens to all the changes made in the actual DOM and updates the virtual DOM only with that changes. React then renders the UI only with the changes that happened in the virtual DOM. This process is called diffing.

The process of maintaining sync between the actual DOM and the virtual DOM is called reconciliation.

How Virtual DOM is faster?

As soon as any update is done in the actual DOM, the reconciliation algorithm marks the element as dirty, and goes on to process the next update. When all the updates are processed in the DOM, they are passed to the virtual DOM in batches, instead of one by one as we have in the actual DOM. This makes the virtual DOM a lot faster and thus makes React performant.

Keys - A solution of rerenders

The reference of a UI element in the actual DOM and in the Virtual DOM need not be the same. So what happens in this case, the react will rerender everything even though we changed a single line.

Suppose we have this piece of code. The DOM will render it fully as it's the first time.

<div>
  <p>Hello! I am a piece of text.</p>
  <p>Don't underestimate me!</p>
</div>

Now, if we add another paragraph the DOM will render again all the unchanged paragraphs too.

<div>
  <p>Hello! I am a piece of text.</p>
  <p>Don't underestimate me!</p>
  <p>You don't know my powers!</p>
</div>

Now you'll be like why React is not behaving as it's supposed to be.

So here as I said the reference need not be the same, the first two paragraphs in the actual DOM and in the virtual DOM are different for React and it's considering them as new additions to the DOM. This lead to rerendering of the DOM unnecessarily. This problem can be solved with the help of keys.

<div>
  <p key="1">Hello! I am a piece of text.</p>
  <p key="2">Don't underestimate me!</p>
</div>

While rendering lists, generally we give keys to the element and for many developers, it's a headache to decide what will be the key. So to solve this problem I stumbled upon this syntax of React.

<div>
  {React.Children.toArray(texts.map((text) => <p>{text}</p>))}
</div>

That's it for now folks. Thanks for reading this article. Let me know if anything is not clear.

Connect with me on Twitter, Instagram & LinkedIn

Happy Coding!

Async Await in Javascript

Deepansh Bhargava — Mon, 10 May 2021 08:04:05 +0000

So in the last post, we learned about how promises work in javascript.

Today, we gonna learn about how async-await works together for the seamless working of promises and makes the developer experience better.

The concept of async-await comes into use when we have more than 2 promises, the code becomes messy and sometimes unbearable.

If you remember the previous example of making a promise, that's great. If not here it is:

const isNumEven = (num) => new Promise((resolve, reject)=> {
  if(num % 2 === 0) {
    resolve(true)
  } else {
    reject(false)
  }
})

Now this promise can be used as:

async function isEven(num) {
  try {
    const result = await isNumEven(num);
    return result;
  } catch(err) {
    console.log('Something went wrong!')
  }
}

isEven(4); // true

As you can see, it makes our code less sloppy and easier to manage. Now if the isNumEven function returns another promise, then we can use await again and get the result.

Now some of you must be wondering why try catch is used in this example?

The answer to this is error handling. If any of the statements fail in the try block, then the code directly goes into the catch block. So, if our promise fails, the error will be handled by the catch block.

Some important points related to async await:

Avoid using it inside for loops, and if there is a need to perform an operation on all entities use Promise.all rather than async await.
If you have used the async keyword before a function, it'll return a promise every time.
Async await is just syntactic sugar for promises, the code runs the same way as it runs for promises. The code looks synchronous and the program waits until the promise is resolved.
If a function is async, then only you can use await inside it.

Connect with me on Twitter, Instagram & LinkedIn

Happy Coding!

Hooks in React

Deepansh Bhargava — Sun, 09 May 2021 06:55:02 +0000

Today we'll learn about the widely used hooks in React. First, let me tell you the need for hooks. As we all know React has functional and class components. Previously, the functional components were only used to render the data but didn't consist of the business logic or any side effect in itself.

So hooks were introduced to implement lifecycle methods and states in functional components. They also bought the idea of code reusability along with them, that's why it was so quickly accepted within the React Community.

** Drum rolls 🥁 **

Let's move ahead with the main topic.

useState hook

This hook helps us to use and maintain a state within the functional component. It's very easy to use. The useState hook returns an array having two elements, the first one is the state variable and the second is the function that modifies the state variable.

import { useState } from "react";

export default function App() {
  const [number, setNumber] = useState(0);

  return (
    <div className="App">
      <button onClick={() => setNumber(number - 1)}>Subtract</button>
      <input
        type="number"
        value={number}
        onChange={(e) => setNumber(e.target.value)}
      />
      <button onClick={() => setNumber(number + 1)}>Add</button>
    </div>
  );
}

Here, we have number as the state variable and setNumber as the function which will modify the number.

useEffect hook

This hook works as a replacement for all the lifecycle methods which were used in class components. It contains a callback and a dependencies array. The hook will run every time when any of the values in the dependencies array changes.

import { useEffect, useState } from "react";

export default function App() {
  const [number, setNumber] = useState(0);
  const [isEven, toggleEven] = useState(true);

  useEffect(() => {
    if (number % 2 !== 0) {
      toggleEven(false);
    } else {
      toggleEven(true);
    }
  }, [number]);

  return (
    <div className="App">
      <button onClick={() => setNumber(number - 1)}>Subtract</button>
      <input
        type="number"
        value={number}
        onChange={(e) => setNumber(e.target.value)}
      />
      <button onClick={() => setNumber(number + 1)}>Add</button>
      <p>{isEven ? "Even" : "Odd"}</p>
    </div>
  );
}

Here as you can see, the dependencies array contains number. So every time the user presses any of the buttons or changes the input value, the useEffect hook will trigger and it'll check the number whether it's odd or even.

Within this hook, you can call side effects such as changing something in DOM, fetching data from an API, etc.

One more thing used in this hook is the cleanup function, which runs when we return a function in the callback. This function helps in cleaning of side effects i.e clearing a timer, closing a web socket, etc.

useContext hook

As in the class components, we had the Context API in the same way, we have useContext hook in functional components. This hook basically helps you to maintain a common global state across components. When the state changes it triggers re-renders across all the child components under the Context, even if the parent component uses shouldComponentUpdate or React.memo.

This hook can be used to implement a loading state within the application, passing data to children components, etc.

To create it, we use the createContext function and pass the initial value. In the context provider, we pass a prop called value which consists of the context variables and functions to modify the context.

import { createContext } from "react";

export const UserContext = createContext({
  name: "Initial Name"
});

Then we use this context in our Parent Component and wrap our app inside the Context Provider and pass a value. So now all the child components have the access to the value prop.

import { useContext, useState } from "react";
import Person from "./Person";
import { UserContext } from "./Context";

export default function App() {
  const user = useContext(UserContext);

  const [person, togglePerson] = useState(user);

  return (
    <UserContext.Provider value={[person, togglePerson]}>
      <div className="App">Hello {user.name}!</div>
      <Person />
    </UserContext.Provider>
  );
}

Now in the child component Person we can access the value prop and we can change the context value too.

import { useContext } from "react";
import { UserContext } from "./Context";

function Person() {
  const [person, togglePerson] = useContext(UserContext);

  return (
    <div>
      Person: {person.name}
      <button
        onClick={() => {
          togglePerson({ name: "Stuart Little" });
        }}
      >
        Change
      </button>
    </div>
  );
}

export default Person;

This way you can use the useContext hook. Make a context, wrap the parent component with the context's provider and you are good to go!

You can experiment with the above code here.

useReducer hook

If you know Redux then you already know what this hook does, if not then simply it changes the state according to the action passed. It helps in maintaining a local state easily whereas in Redux we can do that globally.

To use the reducer globally, we can make a context and pass it across the components. Geddit!

Here we have an initial state and a dispatch to modify the state. Within the dispatch, we pass actions along with some info called payload. The action then goes to the reducer which in turn changes the state.

import { useReducer } from "react";
import "./styles.css";

const initialState = [
  {
    name: "Mad Angles",
    quantity: 5
  },
  {
    name: "Pringles",
    quantity: 3
  },
  {
    name: "Lays",
    quantity: 2
  },
  {
    name: "Kurkure",
    quantity: 1
  },
  {
    name: "Uncle Chips",
    quantity: 9
  }
];

function reducer(state, action) {
  switch (action.type) {
    case "add":
      return [...state, action.payload];
    case "delete":
      return state.filter((_, index) => index !== action.payload);
    default:
      return state;
  }
}

export default function App() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <ul>
        {state.map(({ name, quantity }, index) => (
          <div className="list-item">
            <li key={name}>
              <b>{name}</b> - {quantity}
            </li>
            <button
              onClick={() => {
                dispatch({ type: "delete", payload: index });
              }}
            >
              delete
            </button>
          </div>
        ))}
        <button
          onClick={() => {
            dispatch({
              type: "add",
              payload: {
                name: "Doritoes",
                quantity: 5
              }
            });
          }}
        >
          add
        </button>
      </ul>
    </div>
  );
}

You can find the above code here.

That's it for now. There are other hooks too like useRef, useCallback but they are rarely used. Thanks for reading this article. Let me know if anything is not clear.

Happy Coding!

Promises in Javascript

Deepansh Bhargava — Sun, 09 May 2021 06:28:32 +0000

A Promise represents the state of an asynchronous operation. This asynchronous operation can be anything i.e fetching data from an API, reading contents from a file, etc.

Before promises we had callbacks, but they had fewer capabilities and lead to a sloppy code. When dealing with multiple callbacks, our code will become a callback hell which becomes difficult to manage.

A Javascript Promise consists of four states:

Fulfilled: The operation was completed successfully.
Pending: The operation isn't completed, it's still in process.
Rejected: The operation is failed.
Settled: The operation is either fulfilled or rejected.

A promise can be created by using
Promise constructor.

const isNumEven = (num) => new Promise((resolve, reject)=> {
  if(num % 2 === 0) {
    resolve(true)
  } else {
    reject(false)
  }
})

Now the above-created promise can be used as

isNumEven(5)
  .then(res => console.log(res))
  .catch(err => console.log(err))

The then handler is invoked when the promise is fulfilled while the catch handler is invoked when the promise is rejected.

Here in this case the catch handler is invoked as the number we have passed to the function is not even.

Chaining Promises

When the result of a promise is another promise, we have to chain them to get the results.

isNumPrime(5)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.log(err))

This method of handling asynchronous operations looks fine when we have 2 to 3 promises but it gets unmanageable when there are more than that. Then async await comes into the picture. They help you to handle multiple promises very easily.

That's it for now. Thanks for making it to the last. Let me know any feedback or suggestions you have for this article. Also, let me know if you want me to write on async await.