DEV Community: Harshith Halejolad

Plug-and-Play Context and Memory Layer for Any LLM API — CRISP

Harshith Halejolad — Sun, 12 Apr 2026 05:12:13 +0000

I recently built CRISP (Compressed Retrieval and Intelligent Semantic Processing), a Python library that acts as a lightweight, modular wrapper around any LLM API. It allows you to process massive conversation histories and complex datasets (like meeting transcripts) while only sending the most semantically dense context to your API provider.

The goal is simple: maximize the information-per-token ratio in LLM pipelines.

The Problem

Prompts often contain context bloat—redundant, repeated, low-signal information. In large-scale use cases involving tens to hundreds of thousands of tokens, this leads to higher cost, latency, and noise.

Optimizing this typically involves advanced, time-consuming solutions such as:

complex RAG pipelines
custom embedding + vector database setups
multi-stage preprocessing systems

But these come with tradeoffs:

heavy setup and infrastructure overhead
harder integration into existing workflows
not truly plug-and-play for most developers

As a result, developers either:

over-engineer their stack
or settle for inefficient prompt stuffing

There’s a clear gap for something that is:

significantly more efficient than naive prompting
but still simple, lightweight, and plug-and-play

This is the gap that CRISP is designed to fill.

Core Features of CRISP

Zero manual setup: Automated dependency management—no local LLM runtimes required
Deterministic processing: Uses TextRank for semantic extraction, ensuring consistent results
Massive compression: Typically achieves 95–99% reduction from raw history to final prompt
Privacy-first design: Local-first architecture with plain text storage and an isolated vector database
API agnostic: Generates high-density RAG prompts optimized for any provider (Groq, OpenAI, Anthropic, Gemini, etc.)

Architecture Summary

CRISP is built as a modular pipeline of deterministic components:

Semantic memory: Summarizes each turn to <10% before logging to a .txt file
Embedder: Uses all-MiniLM-L6-v2 for high-speed 384-dimensional semantic matching
Retriever: Manages persistent ChromaDB collections per wrapper instance
Compressor: A multi-stage engine performing TextRank extraction, redundancy filtering, filler-word removal, and rule-based stripping

Real-World Use Case

The primary test case involved processing a messy, repetitive 30,000+ character meeting transcript with 20 speakers. The results were as follows:

Input history: ~30,672 characters (filled with "uh", "um", "so basically", etc.)
CRISP processing: semantic retrieval of pricing facts, deduplication, and stripping
Output context: 422 characters
Net reduction: 98.6%
Final LLM response: precise extraction of the 3 pricing tiers and discount decisions with zero hallucinations

A full demo of this use case is available in the CRISP repository:
https://github.com/Antiproton2023/crisp

Installation

Since CRISP is currently available as a local repository, you can clone it and install the dependencies:

# Clone the repository
git clone https://github.com/Antiproton2023/crisp.git
cd crisp

# Install required dependencies
pip install -r requirements.txt

Alternatively, CRISP will auto-install core dependencies like chromadb and summa on first import.

Each part of the pipeline is modular, so you can customize it to fit your needs. If you build something useful, consider contributing to the project on GitHub.

I Built A Monster Model Before I Built a Working One

Harshith Halejolad — Mon, 06 Apr 2026 05:36:47 +0000

I spent 10 days building my first competition ML model.
It had transformers, attention pooling, multiple input branches.

It scored 0.500.

The Competition

With about 2 weeks of summer left, I decided to jump into my first ML competition. I had always browsed Kaggle competitions and found them fascinating, if not a tiny bit intimidating. I kept waiting for the perfect opportunity to jump in, something easy, but not boring.

At some point, I realized that there’s no point waiting. If I was going to fail, I might as well fail early.

So I took the plunge.

I started working on this competition called BIRDCLEF+ 2026, where the goal was to build a model that understands what specific animal/bird sounds are present in a clip of audio, and predicts the probabilities of each one being present. I wasn’t going to code everything myself, I decided to use some level of AI assistance for the coding and understand the overall workflow of finishing a model from end to end, while getting comfortable with the code.

The Plan

This was the first real-world ML problem that I was building a model on.
The hard part was not building the model itself, but it was everything around it - the strenuous data preprocessing, debugging environment mismatches, spotting issues amidst tons of code, working on a limited GPU availability and trusting the process.

I didn’t realize this at the start. I naively thought the key part was a revolutionary model. Something that turned heads. Something impressive.
Multiple input branches. Transformers. CNNs. Attention pooling. If it sounded advanced, I wanted it in.

I thought this was going to be my edge. I soon realized, learning about complex neural network architectures, and actually implementing them are two completely different things. Here’s the first model I tried to build:

For this, I had to split two training datasets into 5-second segments, generate Mel spectrograms and Perch embeddings, and correctly align them with their primary and secondary labels.
This turned out to be far more complicated than I expected. I ran into multiple issues—XLA incompatibility with my PyTorch environment, Kaggle cache limits filling up quickly, and several other small but frustrating bugs. What I thought would take a day or two ended up taking an entire week. But slowly, I worked through each problem and got the pipeline running.

Once that was done, setting up the model itself was relatively straightforward. I loaded the preprocessed data and started training. The main issue here was running out of CPU RAM, since data loading was happening on the CPU while the GPU handled training. Each session would run for about 1.5 to 2 hours before crashing, so I implemented checkpointing to save progress every 50 batches.

In total, I ran the notebook for around 12–15 hours across multiple sessions and managed to complete just over one epoch of training.

The 0.500 Moment

Then I set up the inference notebook, and submitted it to the competition. I finally understood how the submission process works. After just two tries, it ran successfully.

I scrolled down to see my score.

0.500

After 10+ days of work, that number hit harder than I expected.

And then I realized - I had trapped myself in complexity.
Somewhere across my 1000+ lines of code, there was a bug – and I had no way of finding it.

What I Should Have Done

I should have started out with simplicity. One model. One pipeline. One thing I could actually debug. Something like this:

The key to making this better is not a whole model revamp, but rather simple stuff that would give a high ROI.

For example while splitting the dataset into 5s chunks, instead of splitting into: 0–5s, 5–10s …. I could use a 2.5 s sliding window and split it like this: 0–5s, 2.5–7.5s, and so on.
This alone would have hugely increased volume of the dataset

I could have gotten this to work in < 3-4 days. After this, the inherent nature of preprocessing would make it easy for me to add in stuff like attention pooling layers later on, without breaking anything.

Lessons

Even though the result wasn’t great, I learned a lot from this attempt. I understood the entire competition pipeline and gained confidence in handling environment issues, timeouts, and GPU limits.

One thing I missed: I only had 2 weeks so I didn’t participate in the competition discussions or try out teaming. But there is a lot to learn from that and it can help speed up your own submission by spotting patterns of issues everyone has undergone before - saving you a lot of time.

Conclusion

In conclusion, my first Kaggle competition was an enriching experience and there was a lot to learn from my failure.

Complexity is not a starting point.
Debuggable code beats sophisticated code.
Iteration speed matters.

Complex models aren’t bad.
But you don’t start with a monster.

You grow into one.

If you’ve ever overengineered something like this, I’d love to hear your experience !

418, Angry Teapot in Your Terminal

Harshith Halejolad — Fri, 03 Apr 2026 10:21:55 +0000

This is a submission for the DEV April Fools Challenge

What I Built

TeaTerminus418 is a web based Terminal window housing a fully sentient teapot that strictly enforces the Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) RFC 2324. While the terminal is normally the one tool any self-respecting developer can’t live without, this terminal has become an utterly useless lair for one moody teapot, that roasts the user as they try to use it, and undergoes a meltdown at any mention of coffee.

Its key USELESS features -

A Sentient Personality Engine: The terminal tracks your "Heresy" (mentions of coffee) and "Chaos" (consecutive errors) to shift between Calm, Judging, Disappointed, and full Coffee Corrupted states.
Tiered Chaos Feedback: Low stress triggers subtle full-screen red pulses, while high stress triggers a total "Crashout" mode with screen-shaking, glitching, and fatal system warnings.
Historical Memory: It remembers your past failures across sessions and achievements (like the "HERESY" badge for trying to brew coffee).
The Masinter Protocol: A deep, slightly unhinged tribute to RFC 2324.

Demo

Try out the project at :https://tea-teminus418.vercel.app/

Make sure to notice these completely useless components:

Top Bar: A real-time Stress Meter that builds up as you annoy the teapot. You can track the teapot’s mode as it works itself up into a caffeine-fuelled rage. There’s also a theme toggle and a snapshot feature that lets you share a snap of your interaction with the teapot
The Terminal: A fully functional xterm.js implementation with custom "Roast" injections on every command.
The Effects: High-intensity full-screen red flashes and corruption overlays that react to user behaviour, specifically at mentions of coffee or any stupid errors

Code

Here's the code :https://github.com/Antiproton2023/TeaTeminus418
The project is built with a modular architecture:

components/Terminal.tsx: The heart of the sentient UI.
lib/chaos.ts: The engine behind the rare "Angered Ceramic Deities" events. These are Masinter- tribute events and have a REALLY low chance of occurring.
lib/personality.ts: Logic that translates user "heresy" into system aggression.
lib/memory.ts: Persistent session tracking for brewing history.

How I Built It

Vibe coded it with Google Antigravity

Frontend: Next.js (Turbo) for lightning-fast brewing.
Terminal Implementation: xterm.js & xterm/addon-fit for that authentic CLI feel.
Styling: Tailwind CSS for modern glassmorphism and custom CSS keyframe animations for the "Crashout" effects.
Logic: A custom state machine that balances subtle humor with "fatal" system failures.

Prize Category

Best Ode to Larry Masinter
This project immortalizes Larry Masinter's HTCPCP RFC 2324's "I'm a teapot", giving that teapot a personality and capability to sabotage your daily terminal and roast you as you work. By residing in your daily terminal and roasting you every time you try to work, this turns a 28 year old internet joke into a living, breathing, USELESS experience. It's the only terminal that truly understands why a teapot shouldn't be asked to brew coffee.

I Built Vivid AI to Fix Vibe Coding Chaos

Harshith Halejolad — Fri, 27 Mar 2026 07:45:27 +0000

Most vibe coding projects fail before they start.
Not because of bad code — but because the idea is unclear.
I built Vivid AI to fix that.

This is a tool I built that helps you :

Transform vague concepts into well thought of systems
Weave end to end workflows and architectures visualized via stunning diagrams, make changes on the fly with well-contextualized tools
Get multi perspective analysis that help you spot redundancies, risks and issues in the idea, architecture and from an investor POV
Produce High quality prompts and rules for seamless vibe coding

Problem Statement :

Most people start vibe coding projects with a cloudy idea and jump straight into building, resulting in confusion, poorly generated systems and endless trial and error. They lack technical understanding of the system and often fail to explain how their own project works, regarding it as a mystery black-box.

Vivid AI fixes this. It turns your imagination into a clear, structured, and actionable plan — so both you and your AI coding agent know exactly what’s happening. No more frustrating generic outputs. Only well structured and well coded systems that are easy to understand.

The Vivid AI workflow

I have included example screenshots from the application for each layer.

Layer 1 - Conversational Idea Extraction
A powerful reasoning chatbot asks targeted, high signal questions to clarify your idea, remove ambiguity and make strong project decisions. It generally asks you 7-8 pointed questions and seeks to gain context to help you build your project

*Layer 2(a) - Instant System Visualization *
Once enough context is gathered, you get a

Workflow diagram
Proposed architecture diagram
Proposed Step by step Implementation diagram

(The above image is just one simple example diagram of the tech stack for a sample project)

This leaves you with a clear picture of how everything connects, and visualizations that you could use to effectively convey your idea to others.

Layer 2(b) - Expert Level Analysis
Your idea is evaluated from three critical perspectives :

Risk Analyst
Systems Architect
Investor

This gives you a clear idea of flaws and failure points, structural redundancies and scalability as well as market viability.

Layer 2(c) - Interactive Builder Mode
A powerful BUILDER chatbot allows you to

Refine or pivot your system
Apply expert suggestions instantly
Update workflow and architectures in real time

You can even surgically implement certain parts suggestions from any one expert analysis if you wish, I have given it contextual capabilities to handle such a request.

NOTE - I have designated the last three layers as 2(a), 2(b) and 2(c) because in the tool architecture they are structured under one User Review page as three separate subtabs

Final Output (Build Ready)

Final project workflow and architecture visualizations
Structured project overview
Detailed prompts and rules for vibe coding

Outcome

You move into a vibe coding with clarity of the project, structured and refined ideas and complete control.

No more guesswork, no more crossing your fingers while the coding agent runs.

You know what you’re building
And your AI knows how to build it

Check out the latest MVP version at
https://vivid-ai-v2.vercel.app/

Would love feedback from builders here !!!

FYI, this project was built via Antigravity using the following tech stack :

Next.js 15 (App Router)
React 19
Tailwind CSS
Zustand for Global Context
Groq Cloud API
Supabase Auth & Database
Mermaid.js integration (for flowcharts)

Using Google Antigravity Without Launching Yourself Into Orbit

Harshith Halejolad — Mon, 23 Mar 2026 13:33:18 +0000

There are two ways to use a powerful AI coding agent like Google Antigravity.

The first is to walk in with a thoroughly defined plan, tightly scoped instructions, properly framed rules, and realistic expectations.

The second is to do what I did.

I recently used Google Antigravity for updating my portfolio website, and the experience can be summarized like this:

Seamless. Insanely fast. Mind-boggling. I could never code at this speed !!!

Followed immediately by:

Wait. Why does this look like that?

It was THE MOST IMPRESSIVE yet EYE OPENING coding experiences I’ve had.

The Portfolio project

The goal was to build a good looking portfolio website to record my progress so far, while familiarizing myself with Google Antigravity.

This is the stack I decided to use, after consulting AI on various options:

Next.js 16 for fast rendering and smooth transitions
TypeScript 5.9 so the code doesn’t collapse from bad assumptions
pnpm because disk space deserves rights too
Tailwind CSS for quick styling
8px grid system because professionalism is apparently measured in multiples of eight
Glassmorphism and dark mode because if it doesn’t look futuristic, did you even build a portfolio?
A custom AnimatedSection component using the Intersection Observer API
Markdown-based content with gray-matter ( I wanted to manually edit the content through placeholders in markdown files before deploying it )
Deployment planned for Vercel, the natural habitat of portfolio websites

This was my first time working on such a multi-layered project, but thankfully I had Gemini at my side.

On paper, this looked elegant.

In practice, it became a fascinating tug-of-war between me and an extremely fast machine.

The first 10 minutes: pure automatic magic

I have to give Antigravity credit where it’s due.

It produced the initial website in around 10 minutes after I did some basic environment setup, which is satisfying, mind boggling and absurd in the best way possible. Watching the agent generate the whole website genuinely felt like the future had arrived early and brought Tailwind with it. I wouldn’t have believed it if I hadn’t seen it with my own eyes.

For a brief shining moment, I believed I had just witnessed the holy grail of software development

Then I actually opened the website and looked at it.

The next hour: me vs. my inexperience and lack of planning

That’s when the real lesson hit me:

I had excitedly jumped into AntiGravity without a properly detailed design plan for each page.

And Antigravity, being an obedient and highly capable agent, did exactly what a powerful system does when the human is vague: it filled in the blanks.

Confidently.

Creatively.

Incorrectly, according to my personal taste.

So while it gave me a fully usable first version very quickly, I then had to spend about an hour morphing it into something that actually showed who I am, and my cough cough highly refined taste. Not because the agent was bad, but because my prompt had left too many blanks for it to fill in. And flexibility without specificity is how you end up saying things like:

“Technically this is good, but I guess it could be better.”

Finally after a few hours of changing the AI’s initial creation this is what I got:

I have to make some changes in the projects section, after which I will host it on Vercel and put the link here.

My Mistake #1: Vague prompts produce beautifully efficient Chaos

My biggest takeaway is simple:

Do not start with vibes only. Give your ideas proper structure.

Before using Antigravity for something like web dev, define things like:

what exactly each page should contain
what sections go where and how do i make each one pop
what colour schemes should be used
what kind of spacing, typography, and visual hierarchy you want
what should definitely NOT happen

Because if you don’t define it, the agent will assume. And once the AI has “helpfully” made 37 design decisions on your behalf, you’ll be the one undoing them one by one, wasting quota and breaking your head over it.

A good prompt is not a luxury here. It is a MUST HAVE.

Mistake #2: Not setting rules for the agent

This one is huge.

Don’t just tell the agent what to build. Tell it how to behave while building.

Go one step further and set rules. Actual rules.

Things like:

keep components modular
don’t over-engineer
reuse existing styles
avoid unnecessary dependencies
maintain consistent spacing
prioritize readability over cleverness
write code that is easy to edit manually later

Without guardrails, agents sometimes code like they’re trying to win an award for Most Enthusiastic Interpretation of a Request.

With rules, they’re far more useful.

Antigravity lets you manually specify these UNBREAKABLE rules in agent customizations. Don’t just put them in the prompt like I did.

Here’s a screenshot of where I changed it later on:

Mistake #3: using the WRONG model and burning through tokens

I also ran out of tokens much faster than expected.

This was partly because I used the wrong models for my simple job. Not every task needs the smartest, most expensive, most computationally dramatic option available.

One practical rule I will now implement is:

Use the smallest model that can handle the task, until it breaks.

That’s a much better strategy than sending a premium model to do the equivalent of rearranging padding and renaming a button component.

Save the stronger models for actual hard problems. Don’t waste your quota and cry till it refreshes.

Fixing errors: stop doing one at a time

Another lesson: don’t micromanage every tiny issue in separate prompts if you can avoid it.

If there are multiple errors, weird styles, broken components, or consistency issues, bundle them together.

Instead of:

fix this one error
now this one
now this one too
actually also this thing

Try:

Here are 10 issues, fix them in one pass and preserve the current design direction

This can save time, reduce prompt overhead, and probably save quota too. It also helps the model see patterns across issues instead of treating every bug like a totally unrelated act of God.

Agent Manager vs. manual prompting

The best way to vibe code on Antigravity is using Agent Manager / Mission Control effectively. Not the small agent next to the editor.

The difference is basically this:

In the normal editor-style workflow, you keep doing everything step by step:

Outline, code, tweak, test, fix, document, refine.

Each step is a new prompt. Each prompt costs quota. And each shift in attention forces context switching for both you and the model wasting time.

With Mission Control, the idea is more like:

Define the requirement clearly, assign the overall objective, make several agents split the work, and only check major milestones and focus on decision making.

I haven’t personally used the Mission Control side deeply enough to make bold claims, but conceptually it makes a lot of sense. It gives each agent their own fixed context/space in the project and one agent doesn’t have to waste time going back on forth between different areas.

Turbo Mode: excellent, unless your agent is quietly losing its mind

A very important warning from personal experience:

Check on your agents once in a while if you’re using Turbo Mode.

At one point, I had completely forgotten to install Node.js and Git Bash, and my agent got stuck in a loop trying to run terminal commands that had absolutely no chance of succeeding.

It kept trying. Repeatedly. Heroically. Futilely. It Never Gave Up.

And my quota was the one paying for that optimism.

So yes, autonomy is great. But occasionally peeking in to verify that the agent is not trapped in a digital version of pushing a door marked “pull” is a very good idea.

What Antigravity is actually good for

Despite the chaos, the bigger picture painted by Antigravity is exciting.

The coding landscape is changing fast. The bottleneck is no longer purely “how many languages do you know” or “how quickly can you manually debug syntax errors at 2 AM.”

What matters more now is:

understanding what tools work well together
knowing how to structure projects
being able to evaluate outputs critically
orchestrating workflows
and above all, prompting REALLY REALLY WELL

That last one is not hype. It’s increasingly a real skill.

A decade ago, one person might have spent an hour making a PowerPoint about a product idea.

Now, that same hour can be used to build an end-to-end prototype of the idea itself.

That is a massive shift.

But no, you still cannot completely outsource understanding

This part matters.

AI can write a lot of code. It can scaffold systems ridiculously fast. It can even create frameworks that look AMAZING.

But when things break — and on large projects, things will break at one point— the person who wins is still the one who understands what’s going on. If no one knows what the code was, who will fix it?

So while using agent-generated code, spend time manually inspecting it.

At least understand the framework structure.

Try to catch redundancies.

Notice risky patterns.

See where complexity is growing for no reason.

Because if your project becomes a giant mystery box held together by AI confidence and your own hope, debugging it when it fails will be impossible.

Key Points to use Google Antigravity effectively

Here’s the condensed version of the whole reflection:

Go in with a concrete plan for every single thing.
Write prompts with all kinds of specifics, not just broad intent.
Set rules for code quality and agent behavior.
Use smaller models first; escalate only when needed.
Batch errors and fixes instead of handling everything one by one.
Use Agent Manager for larger, parallel workloads when possible.
Monitor autonomous agents occasionally, especially in Turbo Mode.
Always understand the codebase enough to step in when things go wrong.

Or even more simply:

Antigravity works best when you think before the agent thinks for you.

Final reflection

Using Google Antigravity made one thing very clear to me:

The future of building is less about manually doing every step yourself and more about directing agents effectively.

The developers who thrive won’t be the ones who can code everything from scratch. They’ll be the ones who can design workflows, communicate intent clearly, spot bad outputs quickly, and guide intelligent tools toward useful results.

So yes, AI can build fast.

Sometimes terrifyingly fast.

But the human still matters — especially the human taste, judgment, and ability to say:

“No, that button absolutely should not be doing that.”

Some Other Useful Resources

Mastering the Antigravity Agent Manager by Kotcyn : https://youtu.be/zP_9mJ5vv_8

Google Antigravity Agent Manager Explained: Deep Dive : https://www.arjankc.com.np/blog/google-antigravity-agent-manager-explained/

Google Antigravity Model Quotas : https://antigravity.google/docs/plans