Every Job Left Me Building the Same Thing on the Side — Jeel Vankhede’s Developer Journey
A CoderLegion Developer Story featuring Jeel Vankhede
Conducted & edited by Mehadi Hasan, Community & Editorial Team at CoderLegion
Jeel Vankhede has spent the last decade working across Android products, an offline-first compliance platform, a DeFi lending app, and calendar sync infrastructure.
But across all of those projects, one habit kept following him.
You finish a project, start the next one, and reach for a base class you wrote on the last one. Then you write it again from memory, slightly differently, because copying it over felt lazier than retyping it.
I did that for about three years before I stopped and put the thing in a repository.
Ten years later I have worked across Android products, an offline-first compliance platform, a DeFi lending app, and calendar sync infrastructure, and the only habit that survived all four is that one.
Whatever I learn, I eventually try to turn into something another person can run without me in the room.
It took an AI agent to explain to me why I had been doing it.
My first years were Android.
Test preparation apps, a volunteering platform, life-goal tracking, an audio processing product built on the Superpowered SDK, and offline support wherever the network could not be trusted.
Java first, then Kotlin, WorkManager, and Espresso.
By the third project I noticed I was setting up the same skeleton every time.
Same MVVM structure.
Same data binding wiring.
Same opinions about where things go.
So in October 2019 I pushed it as a library called Core, which existed for exactly one reason:
I did not want to explain that structure to myself or anyone else again.
The next year I did it again with a smaller irritation.
Every Android project needed generated dimension values for a spread of screen sizes, and every project generated them by hand.
That became PixelPerfect, a Gradle plugin, in June 2020.
The pattern was the same every time.
Take the thing living in my head, put it somewhere it can be run or read without me.
Stack Overflow Was the Same Instinct Pointed at Questions
Stack Overflow was the same instinct pointed at questions instead of code.
A senior told me to go answer things, so I did, and I got fast at reading stack traces because it was rewarding.
I eventually wrote 288 answers, and my profile says the reach is past a million people.
But I did not write those answers to help a million people.
I wrote them because answering once in public beat answering the same thing privately forever.
Same move every time.
Take the thing living in my head, put it somewhere it can be run or read without me.
| Period | The work | What I pulled out of it |
|---|
| 2016 to 2019 | Android products: test prep, volunteering, life goals, audio processing | 288 Stack Overflow answers |
| 2019 | Third project on the same architecture | Core, an MVVM starter library |
| 2020 | Screen dimension drudgery on every project | PixelPerfect, a Gradle plugin |
| 2019 to 2023 | Offline-first compliance inspection platform, ten engineers, four stacks | The knowledge stayed with the team |
| 2023 to 2025 | DeFi lending, AI lifestyle products, calendar sync, wallet flows | The knowledge stayed with the team |
| 2026 | Same work, with agents doing part of it | FARE, BARE, and agentsmyth |
The middle two rows are where this article actually starts.
Then What I Knew Stopped Being Shaped Like a Library
The compliance years were the biggest jump I have had.
I joined as an Android developer and left leading a team of ten across Angular, Kotlin, Node, admin tooling, and backend APIs, on a platform for inspectors who worked in places where the network was a suggestion.
Offline sync had to survive a device being out of contact for a day.
There was canvas annotation, PDF generation, route optimisation, and a spin-off module estimated at nine months that we delivered in six.
None of it produced a library, and that was not laziness.
The valuable thing I was accumulating had changed shape.
It was no longer:
Here is how you wire MVVM.
It was:
This field behaves like that because of a rule that exists outside this repository, and here is the argument we had about it eighteen months ago.
You cannot npm publish that.
So it lived where that kind of knowledge always lives, which is in a few people, and it moved the way it always moves, which is by someone asking and someone answering.
I was very good at the answering part.
I knew the history, I could give the short version in ninety seconds, and the person walked away unblocked.
For a stretch of years that was most of the value I added.
It did not occur to me once that this was a worse version of what I had done with Core.
Slow Forgetting Does Not Look Like a Defect
Nobody flagged it, including me.
When people forget, they forget slowly.
A decision holds for months.
It frays at the edges.
Someone half remembers it.
A new joiner never heard it.
And by the time it is gone enough has changed that re-explaining feels reasonable rather than wasteful.
So the cost never arrives as a cost.
It arrives as a slightly slow quarter, and you file it under onboarding.
Then I started handing real work to something that forgets overnight.
The Fix I Made on Wednesday Was Gone on Thursday
Global event communication across a React Native app, rewritten in one pass.
I wrote the plan, the agent agreed with it, I approved it.
What came back matched the plan and broke the app.
The clearest problem was event wiring duplicated across several places, and I did not find that by reading the diff.
I found it by dropping console logs into the flow and watching one event arrive three times.
[evt] session:refresh -> handler mounted at AppShell
[evt] session:refresh -> handler mounted at NotificationProvider
[evt] session:refresh -> handler mounted at WalletStatusBar
[evt] session:refresh fired 1/3
[evt] session:refresh fired 2/3
[evt] session:refresh fired 3/3
I said what was wrong.
It agreed, fixed it properly, and the rest of the afternoon was good work.
Next morning, new session, same repository, everything identical except the conversation from the day before.
It went straight back to the behaviour I had corrected.
Not a weaker version of the fix.
No version of it.
Nothing said in the chat survives the chat.
That sentence was about the agent for about a minute.
Then it was about the standup where we settled a retry policy, and every ninety-second answer I had ever been quietly proud of giving fast.
So I Stopped Writing About It and Ran It Instead
There is an easy article in a Thursday like that.
Agents keep no memory between sessions, structure your work accordingly, about a thousand words, done before lunch.
I have read that article more than once.
Some of the people who wrote it have lost a day the way I lost mine, and some have not, and there is no way to tell which from the outside.
What I did instead took months.
I picked one real task with real risk in it: a notification scheduler carrying a payload contract to an external provider that nobody had verified.
Seven phases, one at a time, each one published as it happened rather than after I knew how it ended.
Think → Plan → Build → Review → Test → Ship → Reflect
Nine parts.
Writing it live meant every phase had to produce something I could show.
This is what the review phase handed back:
| Requirement | Verdict | Evidence |
|---|
| External provider must be notified | Partial | Notified through the dispatch queue. Call order and timing changed, and the requirement described neither. |
| Compatibility shim from Plan | Covered | Mapped to the requirement it exists to satisfy. No gap between the plan and the diff. |
| Queue lifetime across sessions | Missing | Not in the brief. Flush condition never written. |
The bottom row is a gap in my own brief, not anything the agent did.
I would rather hand someone a trail than a position.
A position turns into a debate with whoever has the better vocabulary that week.
A trail sits there with dates on it, and anyone who wants to disagree has to disagree with something specific.
The Problem Was Storage, Not Phrasing
My first response to Thursday was to prompt harder.
Say it earlier.
Put the constraint at the top.
Add an example so it cannot be misread.
That works, which is the trap.
Every sharpened prompt produces a better result, and a better result is exactly the thing that stops you asking why you are typing the prompt again at all.
Nine parts of watching one phase read what the last phase wrote made the real shape of it obvious.
Those phases did not hold together because the instructions were well worded.
They held together because every handoff was a file.
A message is not storage. It is a place things pass through.
Core existed for that exact reason, seven years earlier, and I did not hear the rhyme until embarrassingly late.
So the rules moved into files the next session reads before it writes anything.
Nothing clever about that part.
Every agent tool converges there.
The part nobody warns you about is what happens when you change tools.
repo/
.cursor/rules/ # Cursor
CLAUDE.md # Claude Code
.windsurf/rules/ # Windsurf
.github/copilot-instructions.md # Copilot
Four of the five environments I work in, and a fifth waiting the next time I try something new.
The recipe was portable.
The delivery was not.
FARE and BARE: Making the Habit Portable
FARE and BARE are one command that generates stack-specific rules into whichever layout a repository actually uses.
The frontend package has 71 files.
The backend package has 59.
That number is the reason the last row of the table is not empty.
I would never have hand-written 130 files of rules and templates across five tool formats in my own evenings.
Not in 2020.
Not now.
What changed is that producing and maintaining that much material stopped costing a month.
AI did not give me the habit. It made the habit affordable at a size that matters.
Rules Govern How the Code Gets Written, Not When the Work Stops
Rules fixed the style layer and left the sequencing layer wide open.
The agent wrote code the way the repository wanted code written, and still skipped review, still handed back work nobody had verified, still moved on, because a rules file has no opinion about where a phase ends.
The nine parts had already answered that.
Seven phases, each refusing to start until the previous one left an artifact behind.
What I had was that answer scattered across nine articles and a set of gists, which is fine to read and awkward to run.
So I built it into one command.
npx agentsmyth init
agentsmyth installs the seven gated phases into a repository, with the classification rule that decides when the full weight applies, the requirement manifest that keeps what you said separate from what got inferred, and the exit gate that no artifact passes on its own say-so.
Every phase writes to disk.
The next phase reads the file, not the conversation.
Forge, don't vibe.
It has a handful of stars and I know exactly how small that is.
I also know it is the first thing I have built that carries all ten years through:
The architecture I got tired of retyping.
The answers I got tired of giving privately.
And now a workflow I got tired of re-explaining to a machine that starts from zero every morning.
Whether anyone else runs it is not up to me.
Building it was, and it is the work I would point at first.
So point an agent at it.
Install it into a repository you care about, aim it at a change with real risk in it, and see what the artifacts catch before you do.
That is the only review I am interested in.
What It Changed About Working With People
I expected this to stay in the agent half of my job.
It did not.
If I explain a constraint in a review thread now, the explanation goes into the pull request description or the module README before I resolve the thread, because a resolved thread is a chat window with better branding.
When someone asks why something behaves the way it does, I still answer in ninety seconds.
Then I write the answer where the next person will find it without needing to know I exist.
An answer that only lives in a conversation is an answer I have agreed to give again.
I want to be honest about the limits, because this is not solved.
Written artifacts rot, and a stale document does more damage than a missing one because people trust it.
People are not agents either.
They carry judgment and context and a sense of when a rule has stopped applying, and no file has any of that.
I am not replacing a team with a folder.
The narrow claim is the one I will defend:
Knowledge that exists only in conversation was never durable, and for a few good years I mistook my own availability for a system.
Ten Years, Four Domains, One Habit
Ten years, four domains, and the honest summary is short.
The habit never changed.
I have always wanted to hand someone the thing rather than the explanation of the thing.
What changed is that I finally understand why it matters, and that the tools got good enough for me to do it at work rather than only on weekends.
If you are the person on your team who always has the answer, that is a good thing to be.
It is worth asking how much of what you know is currently stored as your willingness to explain it again.
AI Has Made Experience More Important, Not Less
One more thing.
Agentic and AI-assisted programming has made experience count for more, not less.
I did not expect that.
I have watched juniors and freshers struggle in this era in a way I do not remember from my own first years, and the tools that make me faster do not seem to do the same for someone who has not yet built the judgment to check what comes back.
The ability to generate code is becoming increasingly accessible.
The harder skill is knowing whether what was generated should exist at all.
That means developers still need fundamentals.
They need judgment.
They need context.
And they need to understand the systems they are asking AI to change.
What Comes Next
I am looking into what onboarding into programming should look like now.
I do not have an answer worth publishing yet, and putting out half of one has never been my style.
When it is finished I will write it the way I wrote the nine parts, in order, including the parts that did not work.
About Jeel Vankhede
Jeel Vankhede is a software engineer with 10+ years of experience working across Android development, full-stack systems, offline-first platforms, DeFi, AI products, and developer tooling.
A recurring theme throughout his work is turning repeated knowledge into something reusable — whether that means a library, a plugin, a public answer, or an engineering workflow.
His recent work explores AI-assisted development, agent workflows, durable engineering knowledge, and ways to make software development more systematic and reliable.
View Jeel Vankhede’s CoderLegion Profile.
About This Developer Story
This Developer Story is based on Jeel Vankhede’s original submission and experiences.
Developer: Jeel Vankhede
Series: CoderLegion Developer Stories
Conducted & edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion
