Akshay Deshpande

In the previous post, Two Layers, One Mental Model: How I Stopped Fighting My AI Tools, I wrote about a simple way to reason about AI tooling: Context — what the agent knows when it wakes up. Capability — what the agent can do. Hybrid constructs — reusable units that combine procedural knowledge with invocation. That post was mostly about vocabulary. I wanted a mental model that made constructs like CLAUDE.md, AGENTS.md, rules, skills, subagents, hooks, and MCPs less confusing. ...

The mess that triggered this A few months ago, my AI tool usage looked like most engineers’ AI usage. I was exploring several AI coding assistants — IDE-integrated ones, terminal agents, chat-based models — often more than one at a time. There was no system, no structure, no baseline. Which meant five things, all bad: Every session started from zero. I re-explained the project to the AI on every new chat — what the repo does, how the stack is wired, what the deployment model looks like. Same task, different answers. The same question in two different tools got different and often contradictory output, because the prompts and pre-loaded context were different. No reuse. Whatever prompt finally worked died in my local history. No guardrails. The AI happily edited files it had no business touching, because nothing told it not to. The tools’ actual capabilities — skills, memory, rules, hooks, subagents — were unused. I had powerful agents and was using them as fancy autocomplete. Underneath all five was a vocabulary problem. CLAUDE.md, AGENTS.md, skills, workflows, workpacks, rules, agents, subagents, hooks, MCPs, plugins. Read any one piece of documentation and you walk away with a useful but isolated definition. Read all of them and the definitions blur into each other. Is a skill just a small workflow? Is a rule just a CLAUDE.md fragment? When do I reach for a subagent versus a skill? Where do MCPs fit? ...

This writeup talks about different metric type that an application can emit as telemetry. It intends to cover the case of when to use which metric types and the usecase for them. Metrics is one of the oldest forms of telemetry. There are many APM solutions, whose billing model runs on the number of metrics you send to them. But it is often not clear to app devs on what kind of metrics to emit from applications. Infact, the types of metrics can be confusing sometimes. ...

This note is a mental model for how Prometheus discovers and scrapes metrics in Kubernetes. The lens I want to keep throughout is: Where will the scrape config file sit? (Prometheus repo vs application repo) In which namespace will the serviceMonitor sit? (and how Prometheus finds it) At a high level there are two ways to tell Prometheus about a /metrics endpoint: Static via in the Prometheus config file. Dynamic via (CRD from Prometheus Operator) with label‑based discovery. ...

In most of distributed datastore systems, there are a lot of techical terms to describe the behavior of the system. While these terms, like, “Leader”, “Follower”, “Replication”, “Consistency”, etc., are widely used and helpful, what I feel missing are the details about internal relationship between these terms. Analogically, while the map of the field is great, it is also important to understand how the soil, water, and sunlight interact to help the plants grow. ...

When studying Chapter 4 of Designing Data-Intensive Applications (Encoding and Evolution), I quickly encounters a level of granularity that seems mechanical: binary formats, schema evolution, and serialization techniques. Yet behind this technical scaffolding lies something conceptually deeper. Encoding is not merely a process of serialization; it is the very grammar through which distributed systems express and interpret meaning. It is the act that allows a system’s internal thoughts — the data in memory — to be externalized into a communicable form. Without it, a database, an API, or a Kafka stream would be nothing but incomprehensible noise. ...

I attended Kubecon India 2025 held in Hyderabad this year. I mainly focused and attended talks related to Observability and Scalable designs. Now that the sessions are uploaded to Youtube, linking the ones which I really enjoyed. Observability at Scale With Monitoring as Code: Grafana, Prometheus, & Tempo - Vipin GopalaKrishnapillai & Saiabhinay Bommakanti, Amway Global - link Predictable auto scaling with keda - link Observability - tenant centric metrics - link Building observability platform for Edge compute nodes - link ...

I enjoy philosophy. Stoic philosophy in particular. Philosophy, I think, helps us revalidate our purpose. It acts as a yard stick and makes sure that we are not moving away from our First-Principles. Applying the same to Software Engineering, in my opinion, every team should have a “Design Philosophy”. What is that one yard stick which teams can use for making better decisions. Infact, it is done in some forms in a few cases. Some call it Guiding-Principles. Some call it MVPs. I call it “Design Philosophy”. ...

The intention of this page is to put together the Observability Signal Guidelines which will provide the required visibility into the systems without hurting the cost aspect of the solution. Three basic observability signals that any application emits are: Metrics, Traces and Logs The general question is - When to emit what signal? The answer lies in the intent behind the signal being emitted. What do you intend to measure with the Observability signal that you are emitting? ...

I recently did a brush up course on Networking/Protocols 101’s. Making my notes public. Networking Basics / Protocols: Mental model to think about all protocols: A few notes about different Protocols: Network layer protocol: Transport layer protocol: TCP: UDP: Other Protocols: HTTP: SMTP: XMPP: MQTT: AWS Networking: Local Zone: Edge location: Understanding IPv4, IPv6 IPv4 IPv6 Classes IPv4 How to read CIDR noation: AWS VPC: Interacting with VPC: Internet Gateway (IGW) Subnet: Route table NACL: Networking Basics / Protocols: There are 7 layers of communications as defined in OSI (Open systems Interconnection) model ...