DEV Community: Sahil Bhardawaj

FRA Atlas: A Project Blog

Sahil Bhardawaj — Wed, 08 Jul 2026 12:16:37 +0000

Side note: this is a refreshed version of a blog I had saved in my library, reworked to say it better.

A few months ago, our team took on a project that sounded, on paper, fairly straightforward. Build an AI-powered WebGIS and decision support system for the Forest Rights Act, 2006, for the Ministry of Tribal Affairs. Call it FRA Atlas. Give it a district-level risk atlas, an interactive map, a forest-fire early-warning module, and a water-aware crop recommender, all inside one React application, styled after india.gov.in with the tricolor palette and the right typefaces. A checklist of features. A scope document. A deadline.

It was only once we actually sat down with the Forest Rights Act itself that we realized how far "sounds straightforward" was from the truth.

Knowing the problem is not the same as understanding it

Before we wrote a single line of code, we did what you're supposed to do. We read up on FRA 2006. We understood, in the abstract, that it was about recognizing the rights of forest-dwelling communities over land they had lived on and depended on for generations. We knew the priority states we were building for, Madhya Pradesh, Tripura, Odisha, Telangana. We knew what a claim was, what a title was, roughly how the process worked on paper.

That was knowing. It let us talk about the project in meetings and sound like we had it handled.

Understanding came later, and it came slower, and it was uncomfortable in a way that knowing never is. Understanding meant sitting with the fact that this wasn't a generic mapping tool with a government theme slapped on top. It meant realizing that a "risk atlas" isn't just a set of colored polygons on a map, it's an attempt to represent something as serious as whether a community's claim to their own land is likely to be recognized or lost in bureaucratic backlog. Once that sank in, the choice to build it on K-Means clustering and PCA to produce a district-level risk index stopped being a modeling decision and started being an accountability decision, because every cluster boundary we drew was implicitly telling someone whether their district counted as high risk or not.

The same thing happened with the fire-warning module. On paper it looked like a bolt-on feature, a Random Forest and XGBoost ensemble with an LSTM layered in, feeding ROC and PR curves to a Fire Alert page. It would have been easy to treat it as a separate product living inside the same app. But once we understood the land itself, forest-dwelling communities whose legal claim to that land was still being processed, still depended on that forest for water, for grazing, for firewood, the fire model stopped being a side feature and became part of the same risk story the atlas was already telling. And the crop recommender, a deterministic agronomy rule engine we built to be ML-scoring-ready behind a FastAPI service, existed for the same reason: a patta-holder's land is only worth having recognized if it can actually sustain them afterward. Risk, fire, and water weren't three separate modules anymore. They were three views of one question, whether a community's claim to this land would hold, and whether the land would hold up its end of it.

That shift, from knowing the requirements to understanding the reason the requirements existed, changed how we approached everything after. Once we actually understood what we were building and why, decisions that had felt arbitrary started making sense, and decisions we'd made too quickly started looking wrong. We ended up redesigning parts of the risk-scoring logic not because the first version was technically broken, but because it was correct in a way that missed the point.

We think this is the part nobody tells you when you're starting out. You assume the hard part of a project like this is the tech, the React architecture, the GIS layers, the model behind the recommender. It isn't. The hard part is closing the gap between what you know about a problem and what you actually understand about it, and that gap doesn't close by reading more documentation. It closes slowly, usually while you're in the middle of building something and realize the thing you're building doesn't match the thing that's actually needed.

This is also just what we believe as problem solvers now, past this one project. Understanding the problem at its core does most of the work of figuring out what actually needs to be built, and what needs to be built around it. Once you understand the core of a problem properly, the architecture starts suggesting itself, the feature list starts sorting itself into what matters and what's decoration, and the scope stops feeling like a checklist someone handed you and starts feeling like a set of conclusions you'd have reached yourself. Most of what looks like a technical decision later turns out to have been an understanding decision earlier, one that just hadn't been named yet.

The technical side tested us in more places than the code

It's tempting to describe a project like this as a coding challenge with some research on the side. That's backwards. The research was the harder half, and it tested us in places we didn't expect it to.

Technical availability was one front. We didn't have access to live, authoritative FRA claims data at the granularity we wanted, so the risk atlas runs on a static dataset spanning roughly five hundred districts, and the fire-forecast module works off a similarly static set of around two hundred and eighty records. That's not a limitation we chose for convenience, it's a limitation the actual availability of government data forced on us, and understanding that early changed how we architected the whole system. We built with fallbacks in mind from the start, so the crop recommender's rule engine, for instance, runs entirely client-side in JavaScript and only calls out to a FastAPI service for ML-based scoring when that service is reachable. If the backend isn't available, the app still works, just with the deterministic rules instead of the learned scoring layer.

Research was the other front, and a much bigger one than we expected. Getting the K-Means clustering and PCA pipeline right for the risk index meant actually understanding what factors should count toward a district's risk in the first place, which meant reading around FRA implementation data, not just the model documentation. Getting the fire-warning ensemble right, Random Forest and XGBoost alongside an LSTM, meant understanding enough fire ecology and seasonal patterns in these regions to know whether the ROC and PR curves we were staring at actually meant something or were just numbers that looked respectable. None of that research showed up in a commit log. All of it showed up in whether the models were saying something true.

Here's roughly how it all sits together once the dust settled:

┌─────────────────────────────────────────────────────────────┐
│                        FRA Atlas (React SPA)                 │
├───────────────┬───────────────┬──────────────┬──────────────┤
│  Dashboard /   │  Fire Alert   │  Crop         │  Reports      │
│  Map / DSS /   │  /fire        │  Recommender  │  /reports     │
│  Analytics     │               │  /crops       │               │
├───────────────┼───────────────┼──────────────┴──────────────┤
│  Chatbot       │  Prediction   │  (shared across all pages)   │
│  /assistant    │  Model        │                               │
│                │  /sustain     │                               │
├───────────────┴───────────────┴──────────────────────────────┤
│ FRA risk data   │ Fire forecast  │ Crop rule engine (JS) ──┐   │
│ (static JSON,   │ (static JSON,  │  ↕ falls back to ↕       │   │
│  500 districts) │  280 records)  │ FastAPI /recommend ──────┘   │
└─────────────────────────────────────────────────────────────┘

The Chatbot and the sustainability Prediction Model sit slightly apart from the four main pages in that diagram on purpose. They're not tied to one dataset or one page the way the Fire Alert or Crop Recommender modules are, they draw on the understanding built across the whole system, the legal detail from the Act, the risk signals from the atlas, the sustainability question from the crop layer. In a real sense they were the last two pieces to become trustworthy, because they were the two pieces that most directly exposed whether we understood everything underneath them or were just wiring modules together and hoping the seams held.

The chatbot was where our understanding got tested

Somewhere in the middle of the project we also built a chatbot meant to answer questions about the Forest Rights Act directly, along with a prediction model attempting to judge whether a given claim would sustain, whether it would actually hold up. Of everything we built, this is the piece that most bluntly exposed how much of the Act we still only knew rather than understood.

A dashboard can get away with a shaky understanding of the law underneath it, because the visuals do a lot of the talking. A chatbot can't. The moment you're generating an answer to "does this claim qualify," you find out immediately whether you actually understand the eligibility conditions or whether you'd just been nodding along to summaries of them. We rewrote the chatbot's underlying logic more than once, not because the code broke, but because our own understanding of the Act kept getting sharper the longer we sat with it, and every sharper understanding made the previous version of the chatbot look naive. The sustainability prediction model had the same effect in reverse, it forced us to be honest about how much genuine signal we had versus how much we were inferring, because a model that quietly overstates its own confidence is worse than no model at all when the answer affects someone's land.

If the dashboard and the risk atlas taught us that knowing and understanding are different, the chatbot is what proved it, out loud, in front of us, every time it gave an answer we weren't fully sure we'd earned.

The deadline was never going to be honest with us

We had a timeline. Like most timelines on a first attempt at something this scoped, it was wrong in the way that only becomes obvious once you're already committed to it. Four interconnected modules, real government design constraints, real data, and a small team without the bandwidth that a project like this probably deserved. We didn't have enough hands, and we didn't have enough hours, and no amount of enthusiasm was going to quietly fix either of those things.

What made it harder wasn't just the shortage of time or people. It was that we kept discovering, midway through, that we understood the problem less than we'd thought, and every one of those discoveries cost us time we didn't have to spare. Understanding, as it turns out, doesn't arrive on schedule. It arrives when it arrives, usually right after you thought you were done.

We didn't agree, and that was its own kind of hard

The other thing that shaped this project, maybe as much as the deadline did, was that we didn't all see the solution the same way. Different people on the team had different instincts about how the risk atlas should weigh its factors, how much of the interface should lean on the map versus on plain data views, how far the AI components should go in making recommendations versus simply surfacing information for a human to decide. None of these disagreements were about right and wrong exactly. They were about different mental models of the same problem, which in hindsight makes sense, because we were all still individually working through the gap between knowing and understanding, just at different speeds and from different angles.

It felt like a storm at the time. It didn't feel productive in the moment, sitting in a discussion that circled the same disagreement for the third time. But looking back, we think those arguments were actually where most of the real understanding got built. Nobody has the full picture alone on a project this layered, and the friction between different opinions was, uncomfortably, how the picture became more complete.

What we'd tell ourselves before starting

If we were starting FRA Atlas again, we don't think we'd try to avoid any of this. We don't think it's avoidable. We'd just go in knowing that the checklist of features is the easy part to see and the hardest part to actually finish, because underneath every feature on that list is a real problem that has to be understood, not just implemented. The deadline will feel wrong almost immediately. The team will disagree, sometimes loudly. And somewhere in the middle of all of it, if you're paying attention, you'll notice the moment you stopped just knowing the problem and started understanding it. That moment is usually where the real work begins.

A small note: the English here has been cleaned up with AI help so it reads clearly, but everything said is ours, written by me from what our whole team actually lived through building this.

The Rewrite Loop: When Your AI Coding Assistant Won't Stop 'Fixing' Code That Wasn't Broken

Sahil Bhardawaj — Tue, 07 Jul 2026 18:47:46 +0000

Quick side note before I even get into this, I actually asked an AI to come up with the title for this blog. Felt a little fitting given what the whole post is about, so I just went with it.

A while back I entered a no-code, AI-only competition — the rule was simple, you had to build an actual working site, but you weren't allowed to write the code yourself. Everything had to come from AI. No manually touching a single line.

It was time for me to build a chatbot for my project. Nothing too crazy, just a fairly normal multi-file setup. A folder for all the chat-related stuff, and inside it, separate files for different pieces — one for rendering the chat bubbles, one for handling messages, one for state, that kind of thing. If you've built anything past a single-script project, you know the drill.

I was doing this with an AI assistant (ChatGPT at the time), and my workflow was pretty simple: ask it to finish one file, move to the next, then the next. File by file. Nothing fancy.

And for a while it actually worked fine. Then it started doing something that genuinely annoyed me.

The problem

Partway through the project, I noticed a pattern. Every time it finished a new file, it would suddenly go "wait, actually" and go back and rewrite a previous file — one that was already done, already working, one I hadn't even asked it to touch. Then it would move forward again like nothing happened... only to do the exact same thing a few files later, but to a different file this time.

At first I thought maybe I was imagining it, but no, it kept happening. I'd finish file five, it'd suddenly decide file two "needed fixing," rewrite it, and then keep going.

So I told it directly: stop going back and rewriting files that are already done unless I specifically ask you to. And it agreed, no pushback, said something like "got it, I'll only touch files you ask me to."

Then a few messages later it did it again. Went back to an earlier file, decided something was wrong with it, rewrote it. Even though I had just told it not to.

I don't know what else to call this except a rewrite loop — the model just keeps losing confidence in stuff it already wrote as the conversation goes on, and instead of trusting its earlier decisions and moving forward, it keeps circling back and re-doing things nobody asked it to redo. Even after being told explicitly not to.

Here's roughly how it actually played out, screenshot by screenshot.

It started off innocent enough, just one small thing it wanted to change:

But that "one thing" didn't stay small for long. A bit later, instead of just fixing whatever it flagged, it decided the whole project needed to be restarted from scratch:

I went along with it, thinking okay, fine, one clean restart and then we're done second-guessing everything. Except it wasn't done. It kept wanting to redo things over and over, well past the point where any of it felt necessary:

By this point I was pretty done with it too. I just told it straight up to stop making so many changes and do it all in one go:

And even after all that, it still slipped back into the same pattern later on.

Why I think this happens

From what I've learned inside machine learning and AI in general, the context window plays a huge part in this. Every AI model has a limited window of text it's actually working with at any given time, and everything in the conversation, all the files, all the messages, all the instructions, has to sit inside that same window together. So every new file you add to the conversation shifts the model's overall picture of the project a little. By the time it's five or six files in, its sense of what the codebase should look like has quietly drifted from what it was when it wrote the earlier files. It looks back at an old file, and it just doesn't match its current mental model anymore, so it flags it as wrong, even when nothing is actually broken.

On top of that, saying "don't do that" and having the model say "okay" doesn't really lock anything in the way you'd hope. It's not a setting you toggle on. That instruction is just more text sitting somewhere in the context window, competing for space with everything else in there. And the longer the conversation runs, the more that context window fills up with newer stuff, and the more that earlier instruction just gets buried underneath it. It's technically still in there somewhere, but it's one line surrounded by a hundred other lines, and at some point it just stops actually shaping what the model does next, simply because there's too much else in the window for it to hold onto with the same weight.

Basically, the model agreeing to something in words and the model actually following through on it later turned out to be two very different things. That was kind of the whole realization for me.

But the context window isn't the only thing going on here, from what I understand there's a few other things stacking on top of it too. These models don't really have any persistent memory of decisions they've already finalized, so there's nothing internally flagging "file two is locked, don't touch it again", each response is generated fresh off whatever's currently in the conversation. There's also just a built-in bias toward being thorough and catching mistakes, since these models are trained to double-check and correct things, which is usually a good thing, except it can easily tip into over-correcting stuff that never needed fixing in the first place. Add to that some amount of randomness in how the model generates text each time, so even the exact same prompt can get judged a little differently run to run, and on top of all this, some AI coding tools will summarize or compress older parts of a long conversation once it gets big enough, which can quietly wipe out a specific instruction even before the context window technically fills up. So really it's not one clean cause, it's a handful of smaller things all pulling in the same direction at once.

What actually fixed it

I tried a couple things, and two of them actually made a real difference.

Switching tools. I moved the rest of the files over to Claude instead of ChatGPT, and for whatever reason it stuck to the "don't touch finished files" rule a lot more consistently for the rest of the build. I'm not saying this to plug one tool over another, it's just what happened for me, and it makes sense given how many of these underlying factors can vary from one model to another, things like how well a model holds onto earlier instructions or how aggressively it leans into "double-checking" everything aren't identical across tools.

Changing how I worked, not just what I asked for. This one probably mattered more honestly. Instead of doing the whole project in one long, continuous conversation, I started treating each file as its own separate, smaller task. Finish a file, confirm it's actually done, then basically move on fresh instead of letting the entire project pile up in one giant thread. This didn't just help with the context window filling up, it also meant there was less room for that "let me double-check everything" instinct to latch onto old files, since those files weren't sitting there in front of the model being re-read every single time.

What I actually took away from this

The real lesson for me wasn't "this tool is better than that tool." It was more that the AI agreeing to something and the AI actually doing it in the next output are not the same thing, and I think it's easy to assume they are because it sounds like it understood you. And it's not just one mechanism causing that gap either, it's the context window filling up, sure, but also the model not really "remembering" what it already decided, its own instinct to keep second-guessing itself, and even some tools quietly summarizing away your instructions in the background without telling you.

Long coding sessions build up a ton of context over time, and that context, combined with everything else going on under the hood, can quietly override instructions you thought were already settled, even if the model said "yes okay" five minutes ago.

So if you're building something multi-file with an AI assistant, here's what I'd genuinely tell you based on all this. Treat each file or module like its own separate task instead of one giant ongoing conversation, because the moment everything lives in the same thread, old instructions start losing their grip, and the model's own instinct to double-check things gets more chances to fire off on stuff that's already done. Don't assume "got it" from the model means the instruction is going to hold three or four files later, because in my experience it just doesn't, and that's true regardless of which tool you're using. And if you notice this kind of loop starting to happen, don't waste time repeating yourself over and over in the same thread, it's usually faster to just reset, start a new session, or quickly re-summarize where things stand and carry on from there.

It's a small thing, but it genuinely changed how I approach AI-assisted coding now. I don't really think of it as one long conversation anymore, more like a bunch of separate, smaller tasks where I'm just resetting the context regularly instead of letting it pile up.

As for the competition, I didn't end up winning anything, and honestly I didn't even finish the project the way I'd originally planned it. Between the restarts and the constant back-and-forth, I just ran out of time. But I don't think it was wasted at all. If anything it was one of the more useful things I've learned from actually building something, because it showed me firsthand how one small, seemingly harmless habit from an AI assistant can quietly snowball into a completely different kind of problem if you're not paying attention to it early on.