DEV Community: Pratush Bose

ByteBlaze: Supercharging Code Search with AI

Pratush Bose — Sat, 31 May 2025 14:15:03 +0000

In my previous articles, I shared numerous research papers showing that AI-generated code is taking over codebases worldwide. From my own experience, this AI code tends to be really verbose — I’ve seen it in Bash, Groovy, TypeScript, and more. Put these facts together, and what we’re facing is an explosion in the number of lines of code.

Here’s the thing: the big difference between a software engineer and an AI code assistant is accountability. When AI gets stuck and just keeps spitting out the same code, it’s an experienced engineer who has to step in and solve the problem.

Over time, I’ve realized the biggest gap between a junior and a senior engineer isn’t just what code they write — it’s how fast they can navigate a codebase. And trust me, that gap is huge. The difference between knowing which private method to expose and deciding to rewrite an entire component comes down to deep understanding. Because at the end of the day, reading code is still about 90% of what software engineering is.

Before the era of large language models (LLMs), searching code was a pain because:

You had to rely on keyword-based searches — meaning you had to know the exact terms or names to look for.
You needed to already know the entry point of the logic flow to find anything useful.
Searching for a method name with grep would often return dozens of hits from different libraries with the same method name — so you still had to dig through a lot of code.
And honestly? Searching across multiple code repositories with grep? That’s just trying to find a needle in a haystack — slow, frustrating, and error-prone.

I want to introduce you to the future of navigating code repositories: ByteBlaze, an AI-powered tool that can supercharge the way you search code.

ByteBlaze understands your code semantically, which, in simple language, means it understands the logic of what is happening. This makes it super easy to search code in natural language.
ByteBlaze also understands code in multiple languages like Java and TypeScript, which makes it not only easy to search code but also an excellent tool to learn new codebases.
Lastly, ByteBlaze can query multiple code repositories to provide you with the relevant code snippets at your fingertips.

Integrating ByteBlaze into your coding workflow can:

Drastically reduce the time it takes to search code. This minimizes the friction between engineers and significantly improves engineering productivity.
Serve as an excellent tool to learn and discover new codebases. It enables engineers to explore parts of codebases which were previously inaccessible and makes everyone in your team a 10x engineer.
Reduce the time it takes to fix bugs. Instead of spending hours trying to find and understand the codebase, you can directly target the buggy code, leading to faster resolution times for your customers.
Significantly reduce the time it takes to onboard new software engineers, boosting overall engineering productivity with ByteBlaze providing a helping hand for exploring new codebases.

Ready to Supercharge Your Code Navigation?

ByteBlaze is currently available in a free limited preview — start using it today to spend less time searching and more time building.

Get Started Now | Learn More

From Fog to Clarity: 4 Months as a Solo SaaS Founder

Pratush Bose — Tue, 27 May 2025 02:55:31 +0000

I’ve always wanted more freedom—time, money, and people who get where I’m coming from. That’s what pushed me to go solo, but I’d be lying if I said I knew what I was getting into.

This wasn’t my first shot. My last project, a financial app, ended when my cofounder and I split over the direction. Looking back, I threw everything I knew at it: Spring Boot backend, Next.js frontend, Elasticsearch, Postgres, Redis, all Dockerized. At the time, I thought that was what “real” startups did. But honestly? I spent more time configuring services than shipping anything useful. When it all fell apart, I realized I was building complexity, not momentum.

Lesson #1: Simple wins. This time, I picked the T3 stack. One repo, one server, straight to Vercel—suddenly, I was actually building features instead of fighting with infrastructure.
It was the first time I realized: shipping fast feels better than being clever.

Payments were next. Stripe was out for new Indian businesses, so I had to untangle Razorpay and jump through compliance hoops just to get live keys.
For a few days, I honestly wondered if all this “real business” stuff was worth it. Suddenly, code felt like the easy part.

When I finally launched, I hit the next wall: users.
My instinct was to go full hustle—scrape emails, fire off cold messages, chase leads on LinkedIn. It felt like “doing sales” for the sake of it. Around then, I read Magnetic Marketing by Dan Kennedy, and it hit me—maybe attracting people by sharing value was smarter than just chasing.
It felt uncomfortable at first, putting myself out there. But getting a reply on a blog post or a Twitter thread started to feel as good as deploying new code.

The biggest surprise? How much my definition of “productive” had to change. For years, shipping code was my metric. But after a few weeks of heads-down building with zero users, I realized none of it mattered if nobody cared.
That’s when I started counting a week as productive if I shipped content that someone actually read or responded to. It’s a weird shift, and honestly, I’m still getting used to it.

What I wish I’d known starting out:

You’re not lazy for keeping your stack simple. The fastest way forward is often the least glamorous.
Business “paperwork” and payments always take longer than you expect. Don’t fight it, just factor it in.
You’re going to feel like an imposter when you start writing or marketing. Do it anyway—the feedback matters more than your comfort zone.
Progress isn’t lines of code—it’s evidence that someone, somewhere, cares about what you built.

I’m only four months in, and I still don’t have all the answers. But for the first time, the path actually feels real. The fog is clearing a little. If you’re somewhere in the middle of the uncertainty, you’re not alone.

If you’re on a similar journey, have thoughts about building solo, or just want to swap stories, feel free to reply or DM me. Always happy to connect with others figuring it out as they go.

Onboarding Engineers in an Era of Code Explosion

Pratush Bose — Mon, 26 May 2025 04:00:07 +0000

Why Onboarding to Modern Codebases Is Harder Than Ever
We live in an era where writing code is easier—and faster—than ever before. Large Language Models (LLMs) have exploded the size and complexity of codebases. You don’t have to take my word for it—there’s mounting evidence (links at the end of this article) that AI-powered coding tools are fundamentally changing how much code gets written, and how quickly.

From my own experience, I’ve generated Jenkins pipelines with an LLM in hours—work that would have previously taken me weeks.

But here’s the trade-off:
As code creation becomes easier, the complexity and volume of code each engineer has to manage also skyrockets.

One Engineer, Many Repos, Endless Context Switching
The average engineer today works across far more repositories than ever before. As a senior engineer, I routinely touch at least 10 repositories every quarter. These aren’t just minor tweaks—they span frontend (JavaScript), backend microservices (Spring Boot), shared libraries (Java), and infrastructure as code (Helm, Terraform, Jenkins).

Being established in my organization helps. I have the social capital to reach out to repo owners, ping people for tribal knowledge, and navigate the web of internal documentation. But even then, I’ve run into situations where critical functionality was hidden away in some internal library—missed simply because there’s no effective way to search across all codebases. The result? Duplicate work, wasted time, and frustration.

Onboarding: The Pain Multiplies for New Engineers
Now imagine you’re a new engineer joining the team. Your entry point is usually a Knowledge Transfer (KT) session with a senior engineer. But let’s be real—those sessions are rarely comprehensive. We forget what we’ve worked on. Context slips through the cracks. Docs get outdated. The result:

New hires spend weeks asking questions, digging through repos, and rediscovering what’s already been built.

Senior engineers are repeatedly interrupted for help, burning their own focus and productivity.

A Smarter Way: Introducing ByteBlaze
These challenges led me to build ByteBlaze—an AI-powered onboarding and code search tool for engineering teams. ByteBlaze offers a single, powerful search interface that lets you instantly find relevant files, functions, or examples across all your repositories.

For new engineers: You get answers at your fingertips, drastically reducing the time it takes to get productive in a new codebase.

For experienced engineers: Fewer interruptions, less context switching, and more time for deep work.

Knowledge sharing sessions will always matter—but with ByteBlaze, much of the “where is X?” and “how does Y work?” can be answered instantly. The result: faster onboarding, less duplicated effort, and a more productive team.

I built ByteBlaze to help engineers ramp up faster and waste less time searching for answers in sprawling codebases.

If you’ve ever struggled with onboarding or code search, I’d love to hear your story in the comments—or just connect and chat.

Curious about ByteBlaze? Check it out here!

References:
Microsoft: CEO Satya Nadella stated that up to 30% of Microsoft's code is now written by AI, a figure that continues to grow.
New York Post

Atlassian Research: With the integration of LLM-powered tools, the size and complexity of codebases are expected to grow rapidly, raising concerns about code readability and maintainability.
arxiv

A Springboot developer's perspective on using TRPC

Pratush Bose — Mon, 24 Mar 2025 16:40:05 +0000

This isn't the first time I'm trying to build a SaaS. I've tried before. Looking back the tech stack that I used was perhaps a bit excessive. A quick breakdown would be as follows:

Springboot
NextJS
Postgres
Spring Security for Authentication
Elasticsearch for supporting text search in documents
Redis

This is a bit too much. On top of using too many components in my backend, I was also kind of slowed down by using different languages for front end and backend.

But we all learn. I've come back with a vengeance, the tech stack being as simple as follows:

NextJS frontend
NextJS server side + TRPC backend
Postgres(Transactional+Vector DB)
Clerk authentication
Supabase as DB provider

To be honest, I've loved working in T3 stack thus far. The feature that I've loved the most is the seamless transition between backend and frontend code, with end to end type safety.