Posts

The previous write-up ended with the output from the embedding lookup (1 and 2 below). The previous write-up showed that the output from the embedding layer gives the numerical representation for the token IDs, but these embeddings themselves are not yet contextual. Details are in this section of the previous write-up: https://akshayd.dev/posts/how-llms-work-tokenization-and-embeddings/#initial-embeddings-are-not-yet-contextual This write-up covers the Transformer block (Attention module / MLP) and the Output layer. These take the embedding vectors produced by the embedding layer and add the contextual layer for the LLM magic. ...

When a new model is announced, we often see a description like this: Llama 2 7B: 4096 dimensions, 32 attention heads, 32 Transformer blocks What do those numbers mean? And when you send a prompt like this: The cat sat on the mat what actually happens under the hood? Those questions sent me down the rabbit hole of trying to understand the internals of large language models. This post is my attempt to explain the first part of that journey in plain language. ...

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”. ...