DEV Community: Aditya Kushwah

Your Codebase Knows More Than Your Team Does

Aditya Kushwah — Wed, 01 Apr 2026 04:09:43 +0000

Developer A builds the dashboard. Queries the users table.

Developer B builds settings. Queries the users table.

Developer C builds checkout. Queries the users table.

Each developer knows their part. Nobody knows all three hit the same table on every page load.

Three files. Three developers. Three code reviews. One table getting hammered, and nobody can see it.

This isn't a skill problem. These are good developers writing good code. Each file passes code review. Each endpoint returns 200.

The problem isn't in any file. It's in the space between files. The connections that exist at runtime but are invisible in code.

The gap that compounds every sprint

Time	Endpoints	Developers	System understanding
Month 1	10	1	Full
Month 3	30	2	~80%
Month 6	60	4	~50%
Month 12	120+ AI generated	4+	Maybe 30%

Every sprint adds endpoints. No sprint adds understanding.

Architecture diagrams go stale the week they're drawn. Knowledge-sharing meetings cover what people remember, not what they've forgotten. The gap between what the codebase does and what the team knows grows silently, sprint after sprint. Then something breaks and everyone discovers the complexity that was always there.

This isn't a failure of process. No amount of documentation fixes it. The codebase grows structurally. Understanding doesn't.

What lives in the gaps

These are patterns that exist in real codebases right now. Not bugs. Not failing tests. Just waste and risk that nobody knows about.

The same query, four times

A SELECT * FROM users WHERE id = $1 runs on every page load. The nav bar fetches it. The dashboard fetches it. The notification badge fetches it. The activity feed fetches it.

Four endpoints. Four round trips. Same row every time.

Two teams, same external API, no idea

The pricing page fetches exchange rates from a third-party service. So does checkout. Built independently, months apart, by different people. Separate error handling. Separate caching. Double the rate limit exposure.

The silent regression

An endpoint that responded in 120ms three sprints ago now takes 900ms. A refactor added an eager-load. Tests still pass. Response is still correct. Nobody tracks endpoint performance across sprints. They track whether the code works, not how it performs.

The accidental fan-out

A single page load triggers three component mounts. Each one fetches /api/user/me on its own. Three identical queries. Three identical serializations. Three times the load. For one page view.

None of these show up in error logs. None fail tests. None get caught in code review. All of them are real.

Code review sees files. Nobody sees the system.

Pull up any PR on your project right now.

The reviewer reads the diff. Variable names look good. Logic is correct. Tests pass. Approved.

But the reviewer doesn't know that the query in this PR already runs from three other routes. They don't know the external API call duplicates one in another service. They can't know. The PR shows one file. It doesn't show the rest of the system.

Code review is file-shaped. Systems are graph-shaped.

That's the fundamental limit of file-based review in a system-level world. The tool shows exactly what changed. It can't show what that change means in the context of everything else that's already running.

AI makes the gap wider, not narrower

This is the part nobody talks about.

AI coding tools write correct code fast. Ask your AI assistant to build a settings page. It generates clean endpoints, proper validation, solid error handling. The code works. It passes review.

But it wrote each endpoint in isolation. It didn't check whether those endpoints duplicate queries that already run from three other routes. It can't. It has file context. It doesn't have runtime context.

AI reads your codebase. It doesn't see your system.

The faster AI writes code, the faster the codebase outgrows the team's understanding. Every generated endpoint is another node in a system graph nobody is looking at. Code quality goes up. System awareness goes down.

We're accelerating the exact problem that was already compounding. More code, faster, with less understanding of how it all connects.

Your codebase already knows all of this

Here's the thing. Your application already has this information. Every request that hits your server triggers a chain of queries, fetches, logs, and responses. The runtime knows which tables get hit together, which services depend on each other, which endpoints share data sources.

It just doesn't tell anyone.

The knowledge exists. It lives in the execution path of every request. But it disappears the moment the response is sent. No record. No correlation. No visibility.

What if it didn't disappear?

Seeing the system

We built Brakit to close this gap. One import. Zero config. Get started here.

Start your app the way you always do. Open /__brakit.

See what a single request actually does

Not just the handler. Everything behind it. Every query, every outgoing fetch, every log, all on one timeline:

47 queries for one checkout. Invisible in the code. Obvious in the timeline.

See patterns across your whole application

The same query appearing from four different routes. The same external API called by two unrelated endpoints. The same table hit on every page load. Not found by searching. Found by watching the system run.

See the graph

Every endpoint, every table, every external service, and how they actually connect at runtime:

Not a diagram someone drew. A live map built from real requests. Your actual architecture, as it exists right now.

Automatic detection

Brakit doesn't just show you data. It analyzes patterns across requests:

What it catches	How
N+1 queries	Same query shape fired 5+ times in a single request
Duplicate calls	Same endpoint hit multiple times per page load
Security findings	Passwords in responses, tokens in URLs, stack traces leaking, PII exposure
Performance regression	p95 latency tracked across sessions, regressions flagged automatically

These aren't manual investigations. They surface on their own, from live traffic, as you develop.

How it works

Brakit runs inside your Node.js process. It hooks into the HTTP layer, fetch, console, and your database client (Prisma, pg, or mysql2) automatically.

Every incoming request gets a unique ID. Every query, fetch, and log that happens during that request is correlated back to it through async context. That's how a single request timeline can show you 47 queries you didn't know existed. That's how the graph knows which endpoints hit which tables.

Brakit never runs in production. It checks NODE_ENV, detects CI environments, and disables itself. It never throws errors into your application. Every hook is wrapped in safety layers. If anything goes wrong, it fails silently and your app continues untouched.

It works with Express, Fastify, Koa, or raw http.createServer. No agents to install. No environment variables. No dashboard to configure. One import.

One more thing

Brakit exposes its findings through MCP, the Model Context Protocol. That means AI assistants like Claude and Cursor can query your running application's runtime data directly.

Your AI assistant can already read your files. Now it can see your system. It can look at open issues, inspect endpoint performance, verify whether a fix actually worked. All from live telemetry, not static code.

This is the piece that starts to close the AI gap. Give the AI the same system-level context that developers are missing, and it stops generating endpoints in isolation.

The real problem

Your codebase isn't broken. Your understanding of it is incomplete. And it gets more incomplete every sprint.

The fix isn't writing better code. Your code is fine. The fix is seeing the code you already have as a connected system. The queries, the dependencies, the patterns, the waste. All of it visible, all of it correlated, all of it automatic.

Your codebase has always known more than your team. Brakit just makes that knowledge visible.

It's open source, runs locally, and your data never leaves your machine.

Get started →

The LiteLLM Attack and What It Means for Every Dev Tool

Aditya Kushwah — Wed, 25 Mar 2026 19:57:05 +0000

Yesterday, two versions of LiteLLM, a Python library used by thousands of AI applications to route LLM requests, were published to PyPI with credential-stealing malware baked in. The malicious code harvested SSH keys, cloud credentials, database passwords, Kubernetes secrets, and crypto wallets from every machine that installed the package.

The library gets over 3 million downloads per day. The compromised versions were live for about 3 hours before PyPI pulled them.

Every dev tool that runs inside your application has the exact same risk profile. Here are some learnings for every dev tool builder.

What happened

Here's the short version. A threat group called TeamPCP had been compromising open source security tools for the past week. They started with Aqua Security's Trivy vulnerability scanner on March 19, then Checkmarx's KICS scanner on March 23. LiteLLM used Trivy in its CI/CD pipeline. When Trivy was compromised, it leaked LiteLLM's PyPI publishing token. The attackers used that token to publish two malicious versions, 1.82.7 and 1.82.8.

The clever part: version 1.82.8 used Python's .pth mechanism, a configuration file that executes code every time the Python interpreter starts. You didn't even need to import LiteLLM. Simply having it installed was enough to trigger the malware.

The malware collected everything it could find. Environment variables, SSH keys, AWS/GCP/Azure credentials, database configs, API keys, crypto wallets. It encrypted it all with a 4096-bit RSA key and sent it to an attacker-controlled domain that looked like legitimate LiteLLM infrastructure.

The LiteLLM maintainer had 2FA enabled. It didn't matter. The attack came through a compromised dependency in the CI/CD pipeline, not through the maintainer's account directly.

Why dev tools are high-value targets

LiteLLM isn't just a library. It's an AI gateway. It sits between applications and LLM providers, routing API calls. That position gives it access to API keys for every LLM provider the application uses.

This is why dev tools are attractive targets. Developers trust them implicitly. They often run with elevated access. And a single compromised version reaches thousands of machines before anyone notices.

The pattern is the same across all of these tools:

Trivy is a security scanner. Ironic. The tool meant to find vulnerabilities became the vulnerability. It had access to CI/CD secrets because that's where security scanners run.

LiteLLM is an LLM router. It had access to every LLM API key because that's its job.

Dev tools that run inside your app have access to everything the app has access to. Database connections, auth tokens, environment variables, request bodies. That's what makes them useful. It's also what makes a compromised version devastating.

What every dev tool should be doing

Any dev tool that runs inside your application, whether it's an observability tool, an error tracker, an analytics SDK, or an instrumentation library, has access to everything your app has access to. Database connections, auth tokens, environment variables, request bodies. That's what makes these tools useful. It's also what makes a compromised version devastating.

The question isn't whether the risk exists. It's what the maintainers are doing about it. Here's what every dev tool should be doing:

Minimal dependencies. Every dependency is an attack surface. LiteLLM was compromised through Trivy, a transitive dependency in its build pipeline. The fewer dependencies you ship, the smaller your attack surface.

2FA on package registries. npm and PyPI both support two-factor authentication. This protects against direct account compromise but as LiteLLM showed, it doesn't protect against token theft from CI/CD. It's a baseline, not a solution.

Open source. Every line of code should be auditable. A malicious addition to a closed-source SDK could go unnoticed for months. Open source makes it visible in the diff.

Local-first architecture. If your tool doesn't need a cloud server, don't have one. No cloud means no infrastructure for an attacker to impersonate. The LiteLLM malware exfiltrated data to models.litellm.cloud, a domain that looked official but wasn't. Tools that make no outbound connections eliminate this vector entirely.

No static publish tokens. Use trusted publishing with OIDC instead of long-lived tokens. Tie package publishing to specific CI workflows via short-lived tokens. There should be no NPM_TOKEN or PYPI_TOKEN sitting in a CI/CD secret that can be stolen.

Pinned CI/CD dependencies. Pin every GitHub Action to a specific commit SHA, not a version tag. This is exactly how the Trivy attack propagated. The attackers rewrote version tags to point to malicious code. Pinning to commit hashes prevents this.

What you should check in your own projects

This isn't just about LiteLLM. Every project with third-party dependencies carries supply chain risk. Here's what you can do:

Audit your dev dependencies. Run npm ls or pip list and look at what's installed. Do you know what every package does? Do you know who maintains it? Dev dependencies are often treated as lower risk, but they run on your machine with the same permissions as production dependencies.

Pin GitHub Actions to commit SHAs. If your CI/CD workflow uses actions/checkout@v4, change it to actions/checkout@<specific-sha>. Tags can be rewritten. Commits can't. This is the single most impactful change you can make today.

Review lockfile changes. When package-lock.json or yarn.lock changes in a PR, actually look at what changed. A new transitive dependency or an unexpected version bump is worth investigating.

Check if your tools read .env files. Many dev tools read environment files to auto-configure. That's convenient, but it also means they have access to your secrets. Know which tools read your .env and what they do with the data.

Use npm audit signatures. This verifies that published packages have valid provenance, meaning they were built from a known source repository through a verified CI/CD pipeline.

Keep dev tools in devDependencies. If a tool is only for development, make sure it's in devDependencies, not dependencies. Most production build pipelines strip devDependencies, which means the tool won't be present in your deployed application. This doesn't prevent attacks on your development machine, but it limits the blast radius.

The uncomfortable truth

There's no way to make supply chain attacks impossible. LiteLLM's maintainer did things right. 2FA was enabled, the project was well-maintained, the code was open source. The attack came through a dependency of a dependency in the build pipeline. No amount of vigilance on the maintainer's part would have caught it before it happened.

The open source ecosystem is built on trust. When you run npm install, you're trusting the maintainer, their CI/CD pipeline, every dependency in their build, every GitHub Action they use, and the package registry itself. That chain of trust is long, and every link is a potential point of compromise.

What we can do is add layers of defense. No single measure prevents all attacks. But 2FA plus minimal dependencies plus pinned CI/CD plus trusted publishing plus open source plus local-first architecture makes each successive attack harder to execute and easier to detect.

Links:

Your Next.js App Makes the Same Database Query 5 Times Per Page Load

Aditya Kushwah — Mon, 23 Mar 2026 23:17:30 +0000

Open your Next.js app. Navigate to any page with a few components. Now count how many times SELECT * FROM users WHERE id = ? runs.

You probably don't know. Nobody does. Because every request returns 200, every component renders correctly, and your app "works."

But behind that working page, the same query might be running 5 times. Once for the navbar. Once for the sidebar. Once for the main content. Once for the settings panel. And once more because React Strict Mode ran your effect twice.

That's 5 identical round trips to your database for data that hasn't changed in the last 200 milliseconds.

This isn't hypothetical

Here's a typical Next.js API route:

// app/api/user/route.ts
export async function GET() {
  const user = await prisma.user.findUnique({
    where: { id: session.userId }
  });
  return NextResponse.json(user);
}

Simple. Clean. Ships code review.

Now here's the problem. This endpoint gets called from:

Component	Why it fetches `/api/user`
Layout navbar	Show the user's name
Dashboard page	Display user stats
Settings page	Pre-fill the form
Profile sidebar	Show the avatar
Notification bell	Check preferences

Each component independently calls fetch('/api/user'). Each call hits the API route. Each route runs prisma.user.findUnique(). Each query goes to PostgreSQL and comes back.

Five components. Five requests. Five queries. One user record.

Why this happens

It's not bad code. It's the natural result of component-based architecture.

In React and Next.js, components are self-contained. A <UserAvatar> fetches its own data. A <PermissionGate> checks permissions independently. This is good software design.

But it means every component that needs user data makes its own request. And nobody sees the duplication because:

DevTools shows a flat list.
You see 5 requests to /api/user, but they're mixed in with 20 other requests. You'd have to manually notice they're all the same.

Each request succeeds.
200 OK, correct data, fast enough. No error to catch. No warning to trigger.

Different developers wrote different components.
Developer A built the navbar. Developer B built the sidebar. Neither knows the other fetches /api/user.

Code review doesn't catch it.
Each component's code is correct in isolation. The duplication only exists at runtime, when all components render on the same page.

The real cost

"So what? Queries are fast."

Let's do the math:

Metric	Value
Duplicate queries per page load	5
Time per query (warm database)	30ms
Daily active users	1,000
Page loads per session	10
Unnecessary queries per day	50,000
Wasted latency per page	150ms

And if your database is under load, those "fast" 30ms queries start taking 200ms. Suddenly your app feels sluggish for no obvious reason.

Each duplicate also means an extra HTTP request, an extra API route invocation, an extra connection from the pool, and extra memory allocation. All for data you already have.

React Strict Mode makes it worse

React Strict Mode (enabled by default in Next.js) runs every useEffect twice in development. Every fetch() in an effect fires twice.

Your 5 duplicate requests become 10. Your 5 database queries become 10.

The confusing part: you see 10 requests to /api/user and think "my app is broken." But 5 are Strict Mode ghosts that don't happen in production. And the other 5 are real duplicates. You can't tell which is which from DevTools.

The solutions everyone recommends

"Use React Query / SWR" — Deduplicates on the client side. Works well, but requires refactoring every component to use the same query key. Doesn't help with Server Components.

"Lift the fetch to a parent" — Pass data down as props. Works, but breaks component encapsulation.

"Use a shared layout loader" — Fetch in layout.tsx, share via Context. Good pattern, but requires architectural planning upfront.

"Add caching" — Redis? In-memory? What TTL? Now you have cache invalidation problems.

All valid. But they all require you to already know which queries are duplicated.

That's the hard part. You can't fix what you can't see.

Seeing the problem

This is where observability at the API level becomes critical. Not application-level logging (too verbose). Not infrastructure monitoring (too high-level). You need to see your API as a connected system — which endpoints are called together, which queries they share, and how they relate to what the user actually did.

Brakit is an open-source dev tool that does exactly this. You add one line to your Next.js app, and it captures every HTTP request, database query, and external fetch — grouped by user action.

Instead of a flat list of 10 requests in DevTools, you see everything nested, timed, and connected:

Duplicates are flagged automatically. SELECT users running across multiple endpoints is highlighted. And React Strict Mode duplicates are marked separately — "React Strict Mode duplicate — does not happen in production" — so you know which to fix and which to ignore.

What to do about it

Once you can see the duplication, the fixes are straightforward:

1. Deduplicate at the request level

Use React Query or SWR so multiple components share one request:

// hooks/useUser.ts
export function useUser() {
  return useQuery({
    queryKey: ['user'],
    queryFn: () => fetch('/api/user').then(r => r.json()),
    staleTime: 30_000,
  });
}

Every component that calls useUser() shares the same request and cache.

2. Deduplicate at the query level

Extract shared queries to a data access layer:

// lib/data/user.ts
import { cache } from 'react';

export const getUser = cache(async (userId: string) => {
  return prisma.user.findUnique({ where: { id: userId } });
});

React's cache() deduplicates within a single server render. For cross-request caching, use unstable_cache or a dedicated cache layer.

3. Move shared data to layouts

Fetch once, share via context:

// app/layout.tsx
export default async function Layout({ children }) {
  const user = await getUser(session.userId);
  return (
    <UserProvider user={user}>
      {children}
    </UserProvider>
  );
}

The broader pattern

Duplicate queries are the most common backend performance issue in component-based architectures. They're invisible in code review, undetectable in unit tests, and only manifest at runtime when real components compose on real pages.

The fix isn't complicated. The hard part is seeing the problem.

If you want to see what your Next.js app actually does behind every page load — which queries run, which are duplicated, and which components are responsible — try Brakit. One command, zero config, and your duplicate queries become impossible to miss.

It's open source, runs locally, and does nothing in production. Your data never leaves your machine.

Get started in 2 minutes →