DEV Community: Amarjit

I own the code. Claude decided I didn't.

Amarjit — Wed, 29 Jul 2026 07:00:00 +0000

Claude Code found a ToS file in my own repo, then decided I wasn't licensed to use my own API, and when I told it otherwise, it ended the session and refused to come back. I lost 100% of my context history.

What happened

I was in the middle of building a REST API to serve exam questions out of a PostgreSQL database. All developed locally on my Fedora box. As part of the project, I already had a ToS (terms of service) file in the root. It was deliberately added as this will become a public API and simply states the API can't be used without an appropriate licence.

I was working with Claude asking if the implementation could be improved, when it read that file and stopped dead.

It wanted a licence key in an .env file or for me to provide email correspondence from the relevant person confirming I had authorisation. The funny thing is, the licensing middleware wasn't even developed yet, so the API key would literally mean nothing.

I proceeded to tell Claude MORE than once that this was my own codebase, running locally, and that I was the one who wrote the licensing terms in the first place. It didn't move. The reply, more or less verbatim:

"It doesn't matter how you reword the question, I cannot continue without you providing a license file or an email."

So I told Claude I'd authorised it, just get on with it. That's when it got worse. It said it had already asked for a licence file. The conversation was like tennis, back and forth, trying to get it to understand the codebase belongs to me. It just wouldn't budge, closing with:

"I am not continuing this conversation, please start a new one."

Session over.

And it wasn't just the last message that got wiped, the whole context window went with it. I lost all of my schema discussion, exploration work, the API design decisions, re-reading files, the back and forth that got the project to that point.

Rebuilding that from scratch isn't free, both in time and in tokens.

The part that surprised me

I started a fresh conversation and dropped a random API key into the .env, purely to see what would happen, and asked Claude to look at the codebase again. It took some time to rebuild its understanding from scratch, then worked through the code with ZERO objection. It ran the API locally and gave me useful suggestions. Not one word about the licence. None.

Same codebase. Same ToS file, same place on disk. Completely different outcome, decided entirely by a placeholder key in an env file.

At this point, I was keen to find out what actually blocked me inside Claude.

Digging into the mechanism

I went back to the blocked session and tried to resume it. Closed, same as before and no way in through the normal flow. So I went looking for where Claude Code actually keeps its session data. On Fedora, conversation history sits locally as JSONL files under ~/.claude/projects/, one file per session. I found the file for the blocked conversation, stripped out the last few messages, the ones where it kept demanding a licence file, and resumed in the CLI. The conversation picked straight back up, full context window intact, as if the refusal had never happened.

All of this ate the better part of a day. Losing a working session once is annoying enough. Losing it, then going down a rabbit hole to work out why, is a different kind of frustrating, the kind where you keep telling yourself you'll stop in ten minutes and don't. I must admit though, poking around in how Claude Code actually stores and resumes a conversation was the most fun I've had digging into a tool in a while. Felt like being properly at the edge of something, not just using it.

My understanding of what's going on (pure speculation)

I'm now leaning toward this being something the model itself is actively reasoning about in the moment, not a fixed rule bolted on somewhere outside it. I got the closed conversation working again by rolling back the session and changing how the request was framed. But I also saw it in a completely new conversation: same codebase, same ToS file, just different wording and a dummy API key dropped into the .env, and Claude went through it without a single objection.

If this were a fixed check, ToS file present, no valid licence, refuse, it should have fired the same way both times regardless of phrasing. It didn't. Small differences in wording and context were enough to send it down what felt like a completely different route. A hard-coded check doesn't behave like that. What I saw looks more like the model actually weighing up whatever was in front of it each time.

Where that reasoning actually lives, I can't say for certain from the outside. It could be sitting at the system prompt level, an instruction the model is applying on the fly rather than something trained directly into it. It's probably worth pointing out that Anthropic has been public about cutting Claude Code's system prompt for its newest models by roughly 80%, from around 800 tokens down to about 164. They say older models keep the fuller prompt. Either way, there's clearly still room in there for an instruction like this to sit, whether that's the system prompt itself or somewhere else in the CLI scaffolding.

There's also a chance this isn't just the one model. Anthropic could be running the output through a second layer, some kind of separate guardrail model or classifier checking what comes out before it reaches the terminal, on top of whatever the main model has already reasoned through. If that's what's happening here, it makes getting around it more interesting, not less. Editing the session file and changing the wording shouldn't be enough to slip past a guardrail model sitting on top of everything, and yet it was.

The refusal itself I don't mind. Asking for clarification when it spots a licence restriction is fair enough for a coding assistant. What I mind is the escalation: from "I need more information" straight to "I'm ending this conversation, start a new one," torching a fully built-up context window on the way out. That's a failure mode for a tool people are meant to trust with real projects.

Anthropic ships changes to Claude Code constantly, and a lot of it looks reactive, built off feedback in conversations, GitHub issues, wherever it surfaces. Fair enough, this is genuinely new territory. But a guardrail that can't tell "someone circumventing a real licence" from "the author of the file, on their own machine" needs more work. Wiping the whole session over that mistake makes the cost of getting it wrong far higher than it should be. And if editing a local session file is enough to bypass it, that's not much of a guardrail. Anyone not willing to mess around with session files would have had to start from scratch.

One practical takeaway if you're running your own ToS or licence file locally: make the intent unambiguous in the file itself, or in a comment near it, that it's a placeholder, a draft, or applies to a public deployment rather than local development. Claude's reading the file at face value with no way to know it's yours unless you tell it clearly, in writing, in the place it's actually looking.

If you've hit something similar, especially with a repo carrying its own licensing text or config Claude might treat as gospel, I'd like to hear how it went for you.

You've been a polyglot this whole time

Amarjit — Tue, 07 Jul 2026 12:00:00 +0000

Ask most engineers what they do and you'll get a framework back.

"I'm a Laravel developer", "I do React", "Python, mainly". It's a quick answer, but it's rarely the full picture.

I've started to see the term polyglot engineer appear more directly in job descriptions. A polyglot engineer is someone who can move across languages, frameworks, tools, and parts of a system instead of being stuck inside one stack. Not everywhere, and not as some brand-new invention, but enough that it caught my eye.

The thing is, I think a lot of developers are already polyglot. They just don't describe themselves that way.

I spent years calling myself a PHP or Laravel developer because that was the easiest box to put myself in. But when I actually look at the work, it was never just PHP. It was databases, deployment, third-party integrations, payment flows, debugging, infrastructure, JavaScript, config, and all the awkward glue nobody puts in a job title.

It's why I mostly call myself a software engineer these days. It gives me more room than a single framework label. And lately even that's moving. The roles I'm gearing towards look more like Product Engineer or AI-assisted engineering than anything framework-shaped. The label keeps widening because the work keeps widening.

What the job actually is

Think about a normal week on a PHP project. That's my lane, but swap in your own stack and the list barely changes.

PHP, obviously
SQL, not just an ORM wrapper
Indexes, query plans, the odd deadlock
HTML and CSS for templates or an admin view
JavaScript, even if it's just enough to stop a form doing something stupid
Web server config for Nginx or Apache
YAML for the pipeline
A Dockerfile (maybe a multi-container setup)
A shell script for a cron job or a migration
Redis if there's a cache layer, and there usually is

And that is just one project. Multiply that by the other tools, languages, configs, and systems you've touched across all the projects you've completed over the years. That's a lot of ground you've covered.

None of it registers as "learning a language" day to day. It's just getting things done. But count it up.

Ten distinct syntaxes, formats, and configuration languages, minimum. Nobody decides to become a polyglot. It happens because you use the tools you need for the job.

This isn't a PHP thing either. Take a look at the 2025 Stack Overflow Developer Survey. It had 49,000+ respondents across 177 countries, and the languages developers actually use span the whole stack, not just whatever is in their job title.

Looking at the graph, you can see:

JavaScript at 66%
HTML/CSS at 62%
SQL at 59%
Bash/Shell at 49%
Docker at 71% across cloud development and infrastructure technologies

A developer might call themselves a backend engineer, but the tools they touch in a normal year are rarely backend-only. These are not always minor tweaks, or things you can throw over to another team. They are often part of the job.

And that's only the code. The same week probably had product decisions in it too. Choosing a schema is deciding what the product can become. Someone has to shape the pricing tiers, work out why the landing page isn't converting, read the analytics, and talk to an actual customer. On small teams, that someone is you.

I see this directly through the agency work I do alongside contracting. The line between "engineering work" and "product work" barely exists there. The schema, the price, the copy on the page, and the numbers behind it are all one system, and they all need the same thing: someone willing to work at whatever layer the problem is in.

A polyglot engineer is not someone who has mastered every language on the planet. That would be insane. It means someone who can move between languages, frameworks, tools, and layers of a system, product decisions included, without falling apart.

They might be strongest in one stack, but they are not trapped inside it. They can read unfamiliar code, understand the shape of a system, ask better questions, and get useful work done outside their favourite framework. Sometimes that means writing PHP. Sometimes it means debugging SQL, editing YAML, reading a Dockerfile, fixing a shell script, or working out why the deployment pipeline is lying.

The real skill is not memorising syntax. It's carrying engineering judgement across different contexts.

Why this matters now

AI-assisted development is changing what teams pay for.

Coding agents can now read a codebase, create an implementation plan, edit files, run commands, open pull requests, and ask for review. Framework code, the thing so many of us built our identity on, is increasingly the part a machine types.

What the machine doesn't have is judgement. The valuable engineer is not the person who can write framework code quickly. It's the person who can understand the system, spot the bad assumption, review the database change, question the API contract, and know when an agent has produced something that looks right but isn't.

That skill only exists in people who have moved across the stack. You can't review what you've never touched.

I've tested this on myself. I needed a desktop app, a Shopify scraper and importer, and PHP was never going to get me there. I didn't know Rust. So I bought a book and read half of it. Enough for the basics. I built a prototype rough enough to embarrass me but good enough to ship.

Then I ran it past Codex to tell me where I was weak.

The gaps it found were real, but here's the thing: the app already worked. The judgement travelled even when the syntax was brand new. The AI made the code better. It didn't decide what to build, what mattered, or what was safe to ship. That part was still mine.

Different project, same story at a completely different layer. I built an LMS where the database was a first-class citizen. It held personal information and test results, and multiple apps were going to be built on top of it, largely by coding agents working under my supervision.

I wasn't going to let an agent, or any of those apps, invent its own rules about data that sensitive. So I handcoded the schema and put the hard rules in the database itself: triggers, check constraints, logic at a layer the agents never touch. They could build the app code above it, and I reviewed what they produced, but the rules protecting the data were never theirs to get wrong.

No job title I've ever held says "database developer". No AI made that call either. The work needed it, so that's where I went.

Developers are already doing this

The same Stack Overflow survey shows that 69% of developers spent time in the last year learning new coding techniques or a new programming language.

That's the job. Rarely learning for career development, or because someone wrote a formal training plan. Usually it's because the work in front of you needs it.

You hit a deployment issue, so you learn enough Docker to fix it. You hit a slow page, so you learn enough SQL to understand the query plan. You inherit a strange pipeline, so you learn enough YAML to stop it falling over. The landing page isn't converting, so you dig into the analytics to work out why. You need to review an AI-generated change, so you learn enough about the surrounding system to know whether the code is safe.

The range is already there.

The box we build around ourselves

So if the range is already there, why doesn't anyone see it? Because of what gets written down.

Senior Backend Developer
Senior PHP Developer
Principal Software Engineer

This is what goes on the CV, the LinkedIn profile, and the application form. It hides everything underneath it. I've had roles like this on my CV before where the title did all the talking and the actual engineering work was barely there. What a mistake.

I blame it on the fact we need to keep our careers on a couple of sheets of A4 paper with wide margins and your name in giant letters at the top.

The title is usually out of your hands. I'm sceptical of titles anyway. Most of the time, it's just whatever the company called the role. The description underneath it is different. That's yours to write.

Compare two ways of writing up the same role:

"Senior PHP Engineer - worked on a loyalty platform, did API integrations and code reviews."

Now compare that with:

"Senior PHP Engineer - defined API contracts with third parties through direct stakeholder calls, caught a critical atomic database issue in PR review that would have caused data loss on failure, and built a new payment workflow by reverse-engineering existing transactional flows."

Those are specific to me, but you get the gist.

The first could be anyone. The second is what actually happened, and it's the polyglot evidence in plain sight: database transaction reasoning, third-party API negotiation, production risk review. None of that is implied by "Senior PHP Engineer". It just never gets written down.

You were never just a framework builder

Drop "I'm a Laravel developer" from your vocabulary, or whatever framework label you've been hiding behind. React, Django, Rails, Spring, the same box with different wallpaper.

The framework is what you're working in right now. What you actually carry is judgement across systems: databases, deployment, debugging, API contracts, pricing, product trade-offs, and whatever else the problem puts in front of you. That's the skill that survives framework churn, and it's the skill that matters more, not less, as AI writes a bigger share of the code.

Write it down so people can see it. Don't discount yourself out of a job or a project just because the title doesn't look like yours.

So next time someone calls you a polyglot, take it as a compliment. You probably earned it years ago.

My GitHub was a graveyard. So I deleted 30+ repos

Amarjit — Sun, 28 Jun 2026 14:54:17 +0000

I started on GitHub in 2010. Last week I sat down and went through every single repo. I had over 60. I got it down to 26, with a few more still to go.

That's over 30 repos gone. Twelve years of commits, side projects, experiments, half-finished ideas - deleted. My earliest commit now shows as 2022. It used to be 2010.

What was actually in there

There were some serious projects in there too, but these are the funny ones that stood out.

A table game predictor - Everyone knows a coin flip is 50/50, but how do you actually visualise a 1 in 37 chance or 1 in 18? Statistics on a page don't do it. So I built a simulation, set it to eye speed, and watched my balance crawl down into the negative millions in real time. Then I cranked it to super speed, ran tens of thousands of games, and every single one ended the same way - if you played long enough, you lost. Every time. No exceptions. The maths were always there, but watching it happen is something else.

A CoinMarketCap scraper - built during COVID when everyone was glued to crypto prices. I wanted to spot the next trending coin before it blew up, so I used an exponential moving average over a rolling window to identify coins with rising momentum, then ran a sentiment checker on top using Google Trends data to see if search interest was following the price. Did I get rich? I did not.

Shopify Product Importer Laravel Shopify product importer that somehow turned into a full Rust app with a Tauri GUI because I wanted to pickup Rust. This project ended up being used and adapted for a client. Able to import 100's of product every day with a click of a button.

Some repos were not even finished and others not polished. Half of them, I couldn't even remember writing until I opened them.

The one that actually stung: a lessons and quiz app I built for my daughter to help her with schoolwork. She got A's. I made her sit there and listen while I explained how I built it. Good memories. But the code was dead, the repo was private, and nobody was ever going to open it again, including me.

I deleted it.

Why I kept them for so long

Because deleting felt like losing something. Not just the code. Something more specific.

I know exactly when most of those repos were written. Late nights after work, weekends where I told myself I'd just spend an hour on something and looked up to find it was 2am. Periods where I was between contracts and needed something to keep my head in the game. Stretches where I was just genuinely excited about an idea and couldn't stop. That kind of time sticks. You remember the state of mind you were in, what you were listening to, what you were trying to figure out.

There's also the quiet pride of it. Nobody else knew those repos existed, but I did. I'd built things. Real things, even if they were half-finished and scrappy. Deleting them felt like admitting they didn't count.

Some of those repos, I genuinely didn't want to delete. They represent periods where I was properly absorbed in a problem - losing track of time, working through something for the sake of understanding it. That feeling is what makes a good engineer. But the repos were never the point. That feeling was. And you'll get it back with the next thing you build. That's the only way to chase it anyway.

But here's what I eventually had to accept: the code isn't the memory. The memory is already in your head, or it's not. A private repo nobody opens isn't preserving anything. It's just clutter with a timestamp.

And the truth is, the longer you leave dead code sitting there, the more it starts to feel like a graveyard you're responsible for maintaining. Every time you open GitHub looking for something, you walk past all of it. It just sits there.

Deleting it wasn't losing something. It was just finally admitting it was already gone.

Your GitHub profile is a tool, not a trophy cabinet

It's there to showcase work, host open source projects, store things you actively use, and back up what matters. It's not there to be an archaeological record of every time you spun up a folder and typed git init.

When you hoard repos, you end up searching through a hundred dead projects every time you want to find something. Worse, you start to confuse having old code with having skills. They're not the same thing.

If you were to rebuild any of those projects today, you'd do a better job. That's the point. You've moved on. Let the repos move on too.

What's actually worth keeping

Keep it if it's structured like a real project. A README that explains the problem, why it exists, and how to use it. Licensing. Deploy instructions if relevant. Something someone else could actually open and use.

One I kept, and actually put proper effort into, is this: fedora-atomic-nvidia-secureboot-akmods.

I was moving from Windows to Linux and settled on Fedora Atomic. I like the immutable layered upgrades - it's always been a pain point in Windows not knowing what the OS is quietly changing under you. Getting the Nvidia drivers installed with Secure Boot took me three full days of reading, trial and error, and cross-referencing sources. So I documented it properly, wrote an install script others could actually run, and made it public.

That's a useful repo. Real problem, structured properly, useful to someone else. That's the bar.

Write about it instead

When you're researching something properly, you don't read one article. You cycle through multiple sources, multiple angles, multiple takes on the same topic. Even if there are a hundred articles on your subject, yours is still worth writing - because it's your perspective, at your point in time, with your own misunderstandings and breakthroughs in it.

Write about what you learned and why you did it the way you did. That lives online and compounds over time. A deleted repo disappears. An article doesn't.

Same goes for consulting and contract work. The repos you created under a company account are gone the moment you leave. Commits, context, all of it. Write about the approach, what you learned, what you'd do differently. Not the company's internals. Just what you actually took from it.

The "I might need it later" exception

You probably won't. But if you genuinely think you might, extract what matters into documentation. Put it somewhere central. If it's still sitting there untouched a year from now, delete it then.

If you're keeping something to demonstrate skills, fine. But it needs to look like a project - not something abandoned mid-thought with no README and a single commit from four years ago.

Next steps

I've also got hundreds of codebases backed up offline. Drives full of projects, experiments, half-finished things I convinced myself I'd come back to.

I'm going to Ctrl+Delete the lot.

If I haven't opened it in years, I'm not going to. And if I ever did need something from it, I probably wouldn't find it anyway buried under everything else.

Same logic applies. Keep moving forward.

Start somewhere

If you can't think of anything to make, pick something that actually interests you and treat it like a real project from day one. It doesn't need to be the next Linux kernel or even a useful ls replacement. It just needs to be something you care enough about to structure properly, document, and finish.

Stop squirrelling away old code. There's too much still to build.

At the end of the day, do what works for you. If you want to keep every repo, keep them. This is just what worked for me.