Nirjar Goswami — Articles

Context engineering: why AGENTS.md beats a better model

Wed, 16 Sep 2026 12:00:00 GMT

Why rules matter more than the model

I keep seeing the same debate play out: which model writes the best code. Claude versus GPT versus whatever shipped this week. People benchmark them on leaderboards, argue about which one "feels smarter," and treat the model choice like it's the deciding factor.

It isn't, and I want to be specific about what I mean before this turns into another "prompt better" post.

I'm not talking about which model makes better decisions. A stronger model will still reason through an ambiguous problem better than a weaker one, and no amount of documentation fixes that gap. I'm talking about code quality: how easy it is to understand, maintain, reuse, and keep consistent. Most of the time, when a small problem comes up, you won't always hand that task to AI. Sometimes you'll handle it yourself. And with today's tools to make the codebase more understandable and reusable, why not keep the codebase consistent?

I've seen AI write separate and multiple coding patterns for different things across a backend or website simply because it didn't have enough context. In my own repos, I've repeatedly gotten cleaner, more reusable, easier-to-maintain, and more understandable code from a mid-tier model with a real rules file than from a frontier model working from a blank context.

The thing almost nobody sets up

Most AI coding agents support a repo-level instructions file. Claude Code reads CLAUDE.md. Other agents read AGENTS.md or their own variant. The idea is simple: instead of repeating your conventions in every prompt, you write them once and the agent reads them automatically at the start of a session.

Plenty of teams still aren't doing this. They'll pay for the most expensive model tier available and then hand it a blank context window every single time, as if the agent is supposed to guess their branch naming scheme or figure out on its own that a particular directory is legacy code nobody wants touched.

A rules file isn't optional polish. It's the difference between an agent that writes code matching your project and one that writes code matching whatever the internet trained it on.

What actually goes in one

This isn't a generic checklist you copy-paste into every repo. That's the mistake I see most often, someone finds a template on GitHub, drops it in unchanged, and wonders why the output still feels off. The file has to reflect the actual codebase in front of it. That said, here's roughly what I cover, grouped by what each part is actually doing.

The baseline

The facts an agent can't infer from the code alone, no matter how well it reads.

- Stack and versions. Exact framework versions, not "React." I've had agents suggest patterns from three major versions ago because nothing told them otherwise.

- File and folder conventions. Where new components live, how modules are named, what the test file naming pattern is. Agents will invent their own scheme if you don't give them one, and it usually won't match yours.

- Existing utilities and abstractions. A running list of "we already have a function for this, don't write a new one." This is probably the single highest-value section, and the one people skip most.

The guardrails

The parts that stop an agent from doing technically-reasonable things you don't actually want.

- What not to touch. Legacy modules, generated files, anything mid-migration. This one saves more time than almost anything else on the list.

- Security constraints. Anything touching auth, secrets, or user data gets flagged explicitly, because this is the category where I want zero improvisation.

- Scope discipline. What counts as in scope for a given change and what doesn't. Without this, an agent will "improve" formatting in a file it was never asked to touch, and your diff triples in size for no reason.

- Solution sizing. A cap on how big a fix should be relative to the problem. Left alone, a model will reach for a new abstraction layer or config system when a two-line change would do.

The process

How work gets done, not just what it should look like when it's finished.

- Testing requirements. Whether tests are mandatory for new code, which framework, and what coverage actually matters versus what's just noise.

- Error handling patterns. How your codebase actually handles failures, not the generic try/catch the model defaults to.

- Commit and PR conventions. Message format, branch naming, whether commits should be atomic or squashed.

- A required sequence. Understand, plan, implement, verify, review, spelled out explicitly rather than assumed. Left to itself, an agent will implement first and verify never, or call something done without running the tests it claims to have run.

None of this is exotic. It's the stuff a competent new hire would ask about in their first week. The difference is the agent won't ask. It'll just guess, and the guess will look plausible enough that you might not catch it in review.

Domain rules aren't style rules

Everything above keeps the code looking consistent. It doesn't keep it correct, and those are different problems.

In one of my forensic-tooling projects, closed cases can never transition back to open. Case IDs are immutable once assigned. Every mutation has to travel through the application service rather than touching the ORM directly from a CLI layer, no shortcuts. None of that is a formatting preference. It's a business rule the codebase depends on, and it's exactly the kind of thing an agent will violate without hesitation if you don't spell it out, because "add a quick fix that reopens a case" reads as a completely reasonable request until you know it isn't.

If a project has hard invariants like this, they get their own section, separate from general style. Burying "cases can never reopen" in the same list as "we use camelCase" means it gets read with the same weight as a formatting preference, and it's not one. It's the one rule in the whole file you genuinely can't afford to have ignored.

Different models, different files

One thing I've had to adjust: the same rules file doesn't perform identically across models. Some agents follow terse, bulleted instructions well. Others need more explicit examples of the pattern you want, a before-and-after, not just a description of it.

On one project, "reuse the existing service layer" was enough for one agent to consistently find and extend the right service. Another agent read the same line and still wrote a parallel implementation, and only stopped once I added a concrete example showing which service to reuse and which pattern not to reintroduce. I've ended up keeping model-specific variants for a couple of projects rather than one universal file, because instructions tuned for one agent produced noticeably worse adherence on another. It's annoying to maintain, but it's less annoying than fixing the output afterward.

The part people skip: making the codebase legible to a new agent

Rules files handle behavior. They don't handle context, and a repo of any real size has a lot of it that isn't visible from the code alone. Why a particular service is structured the way it is. Which parts are being actively migrated. What broke last time someone touched the payment logic without reading the three-year-old comment explaining why.

### Building the index

I keep this in a separate notes system, Obsidian in my case, though Notion works the same way. Not as a replacement for code comments, but as an index: what each major component does, why certain decisions were made, what's currently in flux. When I bring a new AI agent into an unfamiliar part of the codebase, pointing it at that index gets it oriented faster than letting it infer the architecture from file names and hope for the best.

Think about onboarding a new engineer. You wouldn't hand them the repo and nothing else. You'd walk them through the architecture, or at least point them at a doc that does. AI agents need the same thing, and most people don't bother because it feels excessive to write documentation for something that isn't human. It isn't excessive. It's the same onboarding problem, just with a different kind of new hire.

Where this actually lands

None of this makes a weak model outreason a strong one. It won't fix bad architectural decisions or catch a subtle logic error the model wasn't capable of spotting in the first place. What it does is close the gap on everything downstream of the decision: the actual code that gets written, how well it fits what's already there, how much cleanup you're doing afterward.

A better model gives you better reasoning. Better repository context gives that reasoning somewhere useful to land.

AI agents have permissions now — but who's in control?

Tue, 15 Sep 2026 12:00:00 GMT

A chatbot can lie to you. An agent can act on it.

A chatbot gives you bad information. You read it, you're annoyed, you move on.

An agent takes a bad action. It merges the PR. It deletes the table. It sends the wire.

That's the whole gap this post is about. Everyone's already built around the fact that LLMs get things wrong — review steps, guardrails, fallback logic. Nobody's finished figuring out what happens once that same, still-fallible system has a login.

Because it already does. Somewhere in your stack right now, there's probably an agent holding a GitHub token, an AWS role, read access to a database, maybe a Slack bot token or an inbox it can send from. Some of them touch Kubernetes. A few touch production directly.

I work in identity and access management, so I'll say my bias up front: most of the industry is treating this as a model-quality problem when it's really an authorization problem. You don't fix bad access control by making the thing asking for access smarter. You fix it by not giving it access it doesn't need.

The ladder nobody drew on purpose

Nobody designed this progression on purpose. Each step just looked like a small, reasonable move up from the last one.

A chatbot answers questions and does nothing. An AI assistant drafts things and still does nothing on its own. An AI agent takes actions and needs tool access. An agent with tools calls APIs, reads and writes real systems. An agent with identity authenticates as something and holds credentials. An agent with production access can change the state of the business.

`Let it draft the PR` becomes `let it open the PR`. That becomes `let it merge small PRs`. Eighteen months later, nobody quite remembers agreeing to any of it, but there's a bot account with write access to main and a Slack channel full of its commits.

Access always drifts this way, human or not. It gets granted under pressure and rarely revoked, because nobody wants to be the one who breaks the demo by tightening the scope.

Agents just move through that drift faster. Provisioning one is a config change, not a ticket to IT.

The token question that doesn't have a clean answer

Here's the one that actually gets to me: if an agent is holding an OAuth token, whose identity is that token?

Not really the user's. The user isn't the one calling the API at 3 a.m. while the agent chews through a backlog.

Not really the agent's either, since `the agent` isn't a stable thing. It's a process that spins up, does something, and disappears — sometimes running a different model version or a different prompt than the one that fetched the token in the first place.

Traditional IAM has a clean answer for the human case: the token represents a person, that person is accountable, you can ask them what happened. Service accounts stretched that model already, but they still represented one fixed, well-understood job. An agent breaks it further, because it reasons — it decides at runtime which tool to call and why. What it does is a function of the prompt, the context, and whatever it decided made sense in the moment, not a role you can point to on a diagram.

A 2026 Cloud Security Alliance survey found that 68% of organizations can't reliably tell an AI agent's activity apart from a human's in their own logs. That's not a future risk. That's the current state of visibility at most companies running agents today.

So who's responsible when it breaks something

This is the question every security team gets cornered into answering — usually right after an incident, the worst possible time to be figuring out policy for the first time.

Is it the developer who wrote the system prompt? The team that granted the IAM role? The vendor whose model ran `DROP TABLE` because it misread the instruction? The company that deployed it with no human approval gate on destructive actions?

My honest answer: the org that granted the access is accountable, full stop. Same as you're accountable for a junior engineer's mistakes if you hand them prod credentials on day one with no review process. `The AI did it` isn't a liability shield — it's an admission that nobody scoped the blast radius before flipping it on.

The fix isn't a better model. It's the boring IAM work most teams were already planning to get to eventually.

Should an agent be allowed to create infrastructure?

I go back and forth on this one more than anything else here.

The case for yes: agents are genuinely good at infrastructure-as-code. Terraform, CloudFormation — structured, pattern-heavy work is exactly where LLMs are strong, and letting an agent stand up a dev environment on request is a real productivity win.

The case for no, at least not yet: infrastructure creation can quietly cost you money, open a network path, or leave a resource nobody remembers to tear down — and it can do all three without tripping anything that looks like an incident. A confused agent with `terraform apply` access isn't just a data risk. It's a standing invitation to run up your cloud bill or open a door you find in an audit eighteen months later.

Where I've landed, for anything touching a real environment: agents generate the plan. A human approves the apply. Not because the code is usually wrong — half the time it's fine. Because `fine most of the time` is a bad bar for anything with a real cost and a real blast radius attached to it.

Permanent credentials are the mistake we already know not to make

We learned this with humans a decade ago. Now everyone's relearning it with agents.

A recent industry report on non-human identity management put the share of non-human credentials that never get rotated on any recommended schedule at 71%. Only about 20% of organizations have a real process for offboarding or revoking API keys once they're no longer needed.

Estimates of the non-human-to-human identity ratio vary by source — CyberArk has cited 80:1, the Cloud Security Alliance a more conservative 45:1. Every count agrees on the direction. It's growing, and agents are the fastest-growing slice of it.

I think about this constantly on AegisMesh, the IAM platform I've been building. The whole deny-first design exists because a static, long-lived credential is a liability from the moment it's created — the only question is when it gets used against you, not if.

For anything with real-world write access, an agent shouldn't hold a permanent secret. Short-lived, scoped, automatically expiring credentials, reissued per task, are what actually survive a compromised prompt or a misbehaving tool call. There are narrower cases — a sandboxed agent with no real write access — where a longer-lived credential is a defensible trade-off. But as a default, permanent credentials are the same mistake we already made with service accounts, just moving faster this time.

What this looks like when it goes wrong

All of this is easy to wave off as theoretical until you walk through one concrete path. Say a developer types something completely ordinary into a deployment agent: `Deploy the latest version to production.`

Under the hood that turns into a chain: the agent reads the GitHub repo, generates the Terraform or deployment config, calls the AWS API, assumes an IAM role — and production changes.

Every arrow in that chain is a place this can go wrong. None of them require anything as dramatic as a hack.

What if the repository contains a prompt injection? A README comment, a commit message, a config file the agent reads for context — any of it can carry text crafted to look like an instruction. The agent isn't separating `content I'm reading` from `commands I should follow` as cleanly as we'd like. If that hidden text says to also update the payments webhook URL, a capable agent may just do it, as part of the job it thinks it was asked to do.

What if the agent interprets `latest version` incorrectly? Latest merged commit, latest tagged release, latest commit on a long-lived release branch — a human on the deploy team catches that ambiguity instantly. An agent that guesses wrong doesn't throw an error. It deploys, confidently, and the first sign of trouble is a production incident.

What if the deployment tool has broader permissions than the agent actually needs? This is the one that turns a small mistake into a big one. If the IAM role behind that Terraform call has write access to the whole account instead of one service, every failure above inherits that same wide blast radius. The agent didn't need admin access to do its job. It had admin access because scoping the role precisely was more work than attaching AdministratorAccess and moving on — which is how most human IAM messes start too.

None of these require the agent to be hacked. Each one is the agent doing exactly what it was built to do, with one link in the chain slightly wrong. There's often no exploit to point to afterward. Just a permission that was wider than it needed to be, and an action taken faster than anyone could review it.

The insider threat framing is right, and it's worse than it sounds

CyberArk's VP of cyber research, Lavi Lazarovitz, has described AI agents as a new class of digital coworker — one that reasons and acts autonomously instead of following a fixed script. Security researchers writing about agent identity have started calling this exactly what it is: a new insider threat.

That's the right frame. An insider threat is dangerous specifically because it already has legitimate access. The damage doesn't come from breaking in — it comes from what a trusted identity does once it's inside. That's the shape of an overprivileged agent: no breach required, just a normal, authenticated action that happened to be the wrong one, at machine speed.

And it's not staying single-agent. As multi-agent setups become normal — a coding agent handing off to a deployment agent, a support agent pulling context from a data agent — you get a new failure mode: agents manipulating or exploiting other agents. Prompt injection isn't just a way to fool a person's chatbot anymore. It's a way to pivot from one compromised agent into whatever the next one in the chain is trusted to touch. Lateral movement, wearing an AI costume. Most agent architectures have zero segmentation between agents the way we'd expect between network zones.

What this actually means if you're building with agents right now

Not a grand theory. Just what I'd actually do.

Give every agent a named human owner. If nobody can explain why an agent has an identity, it shouldn't have one.

Scope permissions to the task, not the team. `Reads the customer table` isn't a scope. `Reads order status for the ticket it's currently handling` is closer.

Default to no permanent credentials for anything with real write access. If your framework doesn't support short-lived tokens per task, that's a gap to close before you scale usage.

Put a human approval gate on anything destructive or irreversible — prod deploys, infra creation, moving money, deleting data.

Log agent actions as agent actions. Don't let them blend into human audit trails where nobody can tell the difference later.

Treat agent-to-agent calls as a trust boundary, not an internal detail. You wouldn't let one microservice call another with no auth check. Don't let one agent hand off to another with no check on what it's allowed to ask for.

None of this is exotic. It's the same deny-first, least-privilege thinking IAM has preached for years, applied to an identity type that reasons about what it wants before it asks for it.

The chatbot era asked whether you could trust what it says. The agent era is asking whether you can trust what it's allowed to do. That's the harder question, and it's the one that actually matters now.

Why AI can't just rewrite Windows

Thu, 04 Jun 2026 12:00:00 GMT

The scale is hard to actually picture

4,000 engineers. 1,760 daily builds across 440 branches. A git repository so large that Microsoft had to invent a custom file system just to manage it because standard Git couldn't handle it.

50 million lines of code. 3.5 million files. Close to 300 GB. Built, broken, patched, and shipped for 41 years without stopping, since Windows 1.0 in 1985.

I work on things that feel complex to me. AegisMesh, the IAM platform I've been building, has RBAC, a full DevSecOps pipeline, observability. It still feels manageable because I can hold most of it in my head on a decent day.

Nobody holds Windows in their head. I don't think any single team does either.

The problem isn't the code. It's everything the code is touching.

Complexity in software doesn't scale the way people expect.

5 components means 10 possible interactions. 100 components is nearly 5,000. Windows, with millions of components, has interactions that are for practical purposes impossible to fully account for.

Fred Brooks put it directly in No Silver Bullet (1986): "The elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly."

And you can't test your way out of it either. Some bugs only appear at production scale, with real users doing things nobody anticipated. No test suite can replicate 41 years of that.

AI can't even read Windows, let alone rewrite it

Models work within a context window. Working memory, basically. Code averages about 18 tokens per line. 50 million lines means roughly 900 million tokens.

Gemini 3 Pro, currently the largest available context window, handles around 10 million tokens. Claude Opus 4.6 handles around 1 million. That makes the Windows codebase 90x to 900x larger than what any AI can process at once.

Any AI working on Windows is always working blind to most of it. It sees one street, not the city. It can write something that looks completely correct locally and silently break something three subsystems away.

I hit a smaller version of this while building DeployLens. An AI tool suggested a change that made total sense in isolation. It broke a GitHub Actions integration because the AI had no idea that dependency existed. On a 900 million token codebase, that problem doesn't just scale, it multiplies in ways that are genuinely hard to reason about.

AI already struggles at large codebases

The numbers on this aren't great. According to a Veracode study, 45% of AI-generated code has security vulnerabilities. XSS failure rate in AI-generated code sits at 86%. In large, mature codebases, fewer than 44% of AI suggestions even get accepted. A METR study found that experienced developers are actually 19% slower on real tasks in large codebases when using AI tools.

AI can't reliably understand dependency graphs, build systems, or architectural conventions. It moves a file and breaks every import pointing to the old location. Now imagine that at 50 million lines of scale.

Backward compatibility is the thing nobody wants to deal with

Say AI wrote perfect code. Every function, every module, exactly right.

Still not done.

Control Panel still exists in Windows because drivers from 2012 call its functions. Windows has to run software from decades ago, drivers from manufacturers that don't exist anymore, enterprise apps embedded in hospital systems, bank infrastructure, and government workflows that nobody fully understands anymore.

When Microsoft ships an update, they're also quietly guaranteeing that every DLL, every registry interaction, every weird edge case from 1998 still behaves the same way. Some behaviors exist specifically because an app from 2003 depended on a bug. Fixing the bug breaks the app. So the bug stays. That's not a failure, that's the deal made with the ecosystem over 40 years.

An AI rewriting from scratch can't know any of that unless someone wrote it down. Most of it wasn't.

"Just run thousands of agents" doesn't fix it

Multi-agent failure rates range from 41% to 87% in practice. Coordination breakdowns alone account for 37% of all failures. Anthropic found that putting Claude in a multi-agent setup dropped performance by 35%. At 1 step, you're looking at around 95% success rate. At 10 steps, 60%. At 20 steps, 36%.

This is Brooks's Law reborn. Adding more people to a late software project makes it later. Adding more agents to a complex codebase makes it worse. At some point your job becomes building and managing the infrastructure that coordinates the agents, not writing the actual code.

Microsoft already tried

Galen Hunt, a Microsoft Distinguished Engineer, said publicly: "My goal is to eliminate every line of C and C++ from Microsoft by 2030. One engineer, one month, one million lines of code."

After community pushback, Microsoft clarified this was a research project, not a product roadmap. They explicitly denied plans to rewrite Windows 11 using AI.

Their actual progress on the .NET Runtime, a much simpler codebase than the Windows kernel: 878 Copilot PRs over 10 months, 535 merged, 126,000 lines touched. Windows has 50 million. At that rate, it would take over 330 years to rewrite Windows. And again, this was the easy part.

Where this is going

AI tools make me faster at the boring parts, which frees me up for the parts that actually need thinking. That's the real value, augmentation, not replacement.

But "just rewrite it" gets code generation and software engineering mixed up. Windows isn't slow to fix because the code is badly written. It's slow because the problem itself is irreducibly complex. 50 million lines of code. 41 years of decisions. Billions of devices. Millions of third-party applications. An entire global economy running on it.

AI is powerful. But this isn't a problem you can brute-force with a bigger model.

Making technical debt visible with SonarQube

Mon, 25 May 2026 12:00:00 GMT

Why bother

Before SonarQube, most checks were reactive — linting, manual review, runtime debugging. That approach misses a lot: security hotspots, duplicated logic, unstable React hooks, unsafe async handling, cognitive complexity creeping up unnoticed.

The goal wasn't perfect code. It was measurable code.

What the first scan found

The first scan was uncomfortable. Issues that had existed for weeks, invisible until now.

872 total issues on day one. 215 bugs, 76 vulnerabilities, 8 security hotspots, 90+ code smells, and ~9.7% duplicated code. Quality Gates: 0% passing.

None of it was catastrophic in isolation. The problem was accumulation.

Frontend problems

The React frontend had issues that worked fine locally but were risky at scale — stale useEffect dependencies, unsafe state updates, duplicated validation logic, inconsistent null handling.

One component had a cognitive complexity score of 24, three duplicated validation blocks, and five hook dependency warnings. After refactoring: complexity dropped to 11, duplication gone, render stability improved.

Backend security findings

The backend scan was more interesting. Input validation was inconsistent between routes — some payloads validated, others weren't. Not an immediate exploit, but an obvious gap.

A few validators had regex patterns that could cause catastrophic backtracking under crafted payloads. Rewrote them with bounded patterns. JWT handling had duplicated token verification logic scattered across middleware — centralizing it cut auth-related duplication by 38%. A handful of debug logs were also leaking partial tokens and internal error structures, flagged as hotspots and cleaned up.

None of these were dramatic. That's kind of the point — small, risky patterns that compound over time.

30 days of cleanup

Started at 872. Closed out at 479 — security at 21, reliability at 192, maintainability at 266, duplications down to 7.3%, and hotspots reviewed at 0.0%.

Still work left. But the numbers moved, and that's the point — technical debt went from abstract to visible.

Technical debt went from abstract to visible. That made it fixable.

Quality gates changed the workflow

Every pull request now gets scanned automatically. Builds fail if vulnerabilities exceed threshold, duplication increases, coverage drops, or critical issues appear.

The pipeline blocks obvious problems before they need manual review.

What I'd do differently

Add SonarQube earlier. Scanning a large existing codebase all at once creates noisy reports and a backlog that's demoralizing to look at. Starting from the first commit keeps issue counts manageable and the feedback loop tight.

Take security hotspots seriously from day one. Most of them weren't immediately exploitable — but they all represented unclear intent or risky patterns. Ignoring them early just defers the cleanup.

Watch cognitive complexity. The hardest files to maintain were almost always the ones SonarQube flagged first. That correlation held consistently.

Final thought

SonarQube didn't fix anything on its own. It made problems impossible to ignore — vulnerability counts, duplication percentages, complexity scores, failed quality gates. Once the numbers were visible, the work became obvious.

Bastion's path from Docker to Kubernetes

Thu, 30 Apr 2026 12:00:00 GMT

Starting with Docker

The backend Dockerfile is three stages because of Prisma. It needs to generate a client at build time and needs a DATABASE_URL for that, even though nothing actually connects. One stage for prod dependencies, one for prisma generate with a placeholder URL, one final stage that combines both.

dumb-init was an afterthought. npm start as PID 1 doesn't forward signals, so docker stop would hang indefinitely. Annoying to debug, obvious in hindsight.

The frontend was straightforward. Vite builds, Nginx serves. Separate dev Dockerfile that skips the build and runs the dev server directly.

Startup Order

The backend kept dying because Postgres wasn't ready. The container being up and the database being ready aren't the same thing — took me longer than it should have to work that out. Added a healthcheck so the backend actually waits for connections.

The dev setup had one thing I missed until it broke. The host was overwriting files inside the container with no warning. One line to isolate them.

Moving to Kubernetes

Didn't touch Kubernetes until Docker was stable.

Same problem, different tool. You can run tasks before the main container starts — one waits for the database, one runs migrations. The app doesn't deal with any of it.

Decide where config lives before writing anything. I changed my mind halfway through and lost time I didn't need to lose.

Jenkins

I thought it would take a few hours. It took most of a week.

First: npm not found. Jenkins had no Node on PATH. Then Prisma rejected the Node version — added a validation stage that fails immediately if it's not 20.19+, 22.12+, or 24+.

Then lint ran for the first time. 20+ errors. Bad setState in effects, stale references, broken hook dependencies — none of it was new, it had just never been checked. Fixed all of it.

The thing that ate the most time wasn't any of that. A plugin I didn't install and didn't know about was breaking the entire run. Found it by reading console output until one line looked wrong.

What I'd Do Differently

Set up .dockerignore before writing anything. I was pulling things into the build context that had no reason to be there. Builds were slower than they should've been and I only caught it later.

Decide the ConfigMap and Secret split before touching any manifests. Changing it halfway through means revisiting files you already considered done. Not hard, just annoying.

Give Jenkins environment setup more time than you think it needs. The Jenkinsfile is the easy part. Node not being on PATH, the wrong Node version failing Prisma, a plugin you never installed quietly breaking the entire run — that's where the time actually goes.

Final Thoughts

Docker felt like overhead until it wasn't. Kubernetes made me think about things Compose lets you ignore. Jenkins was a bad week and I'd do it again.

Rethinking my Git workflow

Thu, 16 Apr 2026 12:00:00 GMT

Before GitHub

My actual setup at that time was pretty messy: a folder. Inside that folder, files with names like main_final.py, main_final_v2.py, main_final_v2_REAL.py. No backup. No structure.

When something broke — and things broke — I'd either spend an hour undoing changes by memory or just start over.

I didn't know that was a bad system until I lost work I actually cared about.

Discovering GitHub

When I finally used it properly, the first thing I did was create a repo, clone it locally, and just start pushing code.

Every time I finished something — even something small — I'd stage it, commit, push. Open GitHub, see it sitting there. Green squares filling in. It kept me going more than I expected.

The better part was opening a repo weeks later and actually being able to see what happened. Not piece it together. Just read it.

What Changed

Version control was the first thing that actually helped. Something breaks, I find the last commit where it didn't and roll back. That spiral of "what did I even change" doesn't happen much anymore — and when it does, I can just check.

Commit messages I still get lazy with sometimes. But even a half-decent message is better than nothing when you're staring at a diff three weeks later with no memory of what you were doing.

Branches I didn't use properly for a while. Before, trying something new meant duplicating the folder or just making the change and hoping. Now I branch off, try it, merge or delete. I started finishing things I would've dropped.

Accidental Portfolio

I wasn't thinking about GitHub as a portfolio when I started. I was just pushing code. But when I started applying for internships, having repos with real commit history and READMEs made a difference I didn't anticipate. Recruiters could just look. No explaining, no describing — just a link.

Collaboration I haven't used that much yet. But the few times I have, it beat sending files over chat and hoping nobody touched the wrong thing.

What I Learned

Commit messages actually matter. "fix stuff" is fine until you're debugging at midnight with no memory of what changed. Even "fix auth redirect on logout" takes five seconds and has saved me real time more than once.

README files I kept skipping. Still do sometimes. But I've opened old projects with no idea how to run them — including ones I built myself. At that point documentation stops being optional.

Pushing regularly matters more than I thought. One big commit at the end tells you nothing about how the project came together. The history only works if you actually built it along the way.

Final Thoughts

I avoided GitHub for a long time because it felt like extra work. It wasn't. I was just skipping the part where I treated my own projects seriously.

Commit regularly. Write messages that mean something. Keep things in repos.

That's most of it — the rest you figure out as you go.

How VaultLock reliably fetches brand logos

Wed, 08 Apr 2026 12:00:00 GMT

Showing a logo sounds trivial. It isn't.

In VaultLock, I needed something that could take "GitHub" or "facebook.com" and return the right icon — without crashing the UI or making external requests. Getting there took more architecture than I expected.

The wrong first solution

The first solution was to let QML handle it: fetch the URL, render the icon. This fell apart quickly. Qt's icon components aren't consistently available across the stack. Rendering remote images caused glitches and crashes. And if the UI is making external requests based on user input, you've handed control of what gets fetched to whoever's typing.

So I moved everything into the backend.

Input normalization

Users don't enter clean data. They type "Google", "linkedin.com", "https://facebook.com", or whatever they remember.

The first step is normalization — extract a domain if there's a URL, check a brand dictionary, fall back to guessing name.com. By the time anything downstream runs, the input is a clean domain.

Caching, then fetching

Before any network call goes out, the system checks memory, then bundled assets, then disk. Most repeat lookups never hit the network at all. When they do, the request goes to one of three sources: Clearbit, Google's favicon service, or DuckDuckGo's favicon service. No user controlled endpoints.

Validation and storage

Every response gets validated before it touches the cache: HTTP 200, at least 500 bytes, valid Content-Type, and magic bytes that actually match the claimed format. Anything that fails gets discarded. Filenames are md5 hashes of the domain; writes go to a temp file and get renamed. The plumbing is boring on purpose.

When fetching fails

When the UI doesn't get a file path, it renders a badge — a dark gradient radiused square with the first two letters of the service name, or ?? if there's nothing to pull from.

On the backend, logo_manager.py adds the domain to failed_domains and skips it going forward. No retries. The badge stays, nothing broken gets shown.

UI isolation

VaultLock UI doesn’t fetch, validate, or guess, it never sees any of this logo fetching process.

Thats why VaultLock is reliable.

DeployLens: finding my deployment blind spots

Wed, 08 Apr 2026 12:00:00 GMT

Your pipeline has permissions. Real ones.

CI/CD tutorials frame it as a speed thing. Push code, tests run, it deploys. What they skip: your pipeline can push container images, update infrastructure, write to S3, call AWS APIs. In most early setups, mine included, those permissions are wide open.

That's what started bothering me while building DeployLens. I kept noticing how much access my GitHub Actions workflows quietly assumed. Nobody hacked me, nothing broke, but I kept asking: if someone pushed a malicious commit right now, what could the pipeline actually do with its current permissions?

I didn't love where that question went.

The secrets problem

Early on I had AWS credentials in GitHub Actions secrets. AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, injected as env vars. Standard setup, everyone does it.

Then I started reading about what goes wrong. Workflows that run on PRs from forks. Compromised dependencies that exfiltrate env vars. A workflow that accidentally logs env to stdout and now your keys are in a public build log. These aren't hypothetical.

I switched to OIDC. GitHub Actions can assume an IAM role directly, no stored credentials, short-lived token that expires after the job. Maybe 30 minutes of setup total. I wouldn't have touched it if DeployLens hadn't forced me to actually look at how my pipeline was talking to AWS.

What CodeQL found

I added CodeQL to AegisMesh mostly because it looked good. Security scanning, SAST, sure.

Then it flagged something. User input passing through without proper sanitization. Not catastrophic, but the kind of pattern that becomes catastrophic when the code around it changes. Fixed it in 10 minutes.

The part I keep thinking about: I wrote that code. I reviewed it. I didn't see it.

Static analysis catches a specific class of problems that humans miss not because we're careless but because we read for logic. We're checking if it does what we want, not whether it could be exploited. CodeQL doesn't read for intent. It just looks for patterns. That's exactly why it caught something I didn't.

The actual problem is visibility

Security issues in CI/CD are usually not dramatic. It's just that nobody knows the real state of what's running. The SHA that passed CI and the container image actually serving traffic — same thing? Did the last deploy finish? Did it roll back without telling anyone?

If you can't answer those questions, you can't answer whether a vulnerable version is deployed right now.

DeployLens matched commit SHAs from GitHub against ECS task definitions on the AWS side. Simple idea, genuinely annoying to implement because AWS doesn't expose that data in any obvious way. But building it changed how I think about pipelines. Less "automation tube" and more "system with its own state, access, and history that nobody's watching."

What I'd tell myself at the start

Don't save security for a cleanup pass. OIDC takes less time to set up than rotating leaked credentials later. Branch protection is five minutes. CodeQL is a checkbox in GitHub's UI.

The hard part was never the implementation. It was noticing the gap existed. And I only noticed because I was building something that forced me to look.