Forem: Shrijith Venkatramana

MCP is APIs for Agents

Shrijith Venkatramana — Thu, 07 May 2026 18:30:01 +0000

REST APIs gave humans (and the code they wrote) a standardized way to access software over the network.

MCP is trying to do the same thing for agents.

That simple framing clears up a lot of confusion.

For nearly 20 years we built systems assuming the caller was a human developer writing code against APIs. Now the caller is increasingly an LLM-driven agent. MCP changes the interface layer accordingly.

The REST Era: APIs Designed for Humans

With REST + OpenAPI, the typical flow looked like this:

Human Developer
    ↓
SDK / HTTP Client
    ↓
REST API
    ↓
Service

A human would read the docs, inspect the OpenAPI spec, figure out auth, pick the right endpoints, map parameters, handle retries and errors, and manually compose workflows.

OpenAPI became the universal machine-readable description of the API. It captured endpoints, request/response schemas, authentication, parameters, types, and examples. This enabled Swagger UI, SDK generators, Postman collections, API gateways, client codegen, and testing tools.

In short:

But agents aren't humans. And that changes everything.

Why REST APIs Are Awkward for Agents

An LLM can call REST APIs directly — technically there's nothing stopping it. But raw REST has some serious friction when the consumer is an agent.

1. REST assumes deterministic callers
REST expects the caller to already know which endpoint to hit, which parameters matter, the right sequencing, and how to handle failures. Agents don't work that way. They reason step-by-step and make decisions dynamically.

2. OpenAPI is optimized for developers, not reasoning systems
Humans are great at inferring intent from sparse or messy docs. Agents struggle with ambiguous operation names, missing descriptions, inconsistent schemas, and undocumented behavior.

Multiple OpenAPI→MCP articles have pointed out the same thing: the quality of the MCP experience depends heavily on the semantic quality of the underlying OpenAPI spec.

3. REST exposes transport details too directly
Agents don't care about HTTP verbs, query params vs body, pagination formats, or JSON quirks. They care about capabilities.

Instead of thinking:

POST /api/v3/issues
Content-Type: application/json

They want to think:

"Create a Jira ticket"

MCP pulls the interface up to the level of tools and capabilities.

MCP: APIs for Agents

The Model Context Protocol (MCP) is essentially:

Anthropic has called it something like "USB-C for AI integrations."

The new flow usually looks like:

User
  ↓
LLM Host (Claude, Cursor, VSCode, etc)
  ↓
MCP Client
  ↓
MCP Server
  ↓
REST APIs / Databases / Tools / Systems

The crucial mental model shift:

REST = interface for programmers
MCP = interface for agents

What MCP Actually Exposes

An MCP server exposes tools, resources, prompts, and capabilities. The star of the show is usually the tool.

Here's a simplified example:

{
  "name": "create_github_issue",
  "description": "Create a GitHub issue in a repository",
  "inputSchema": {
    ...
  }
}

Notice everything that disappeared: HTTP verbs, endpoint URLs, transport details. The agent now reasons at the capability level.

REST vs MCP

REST/OpenAPI	MCP
Designed for developers	Designed for agents
Endpoint-centric	Capability-centric
HTTP-first	Tool-first
Human docs	LLM-readable semantics
Explicit orchestration	Dynamic reasoning
SDKs	Tool registries
Request/response focus	Intent/action focus

So Where Does OpenAPI Fit?

This is where things got exciting fast.

We already have massive amounts of structured API metadata sitting in OpenAPI specs. So instead of hand-writing MCP servers, the ecosystem started generating them automatically.

Tools like:

are basically doing OpenAPI → MCP tools.

The Core Conversion Idea

Take a REST endpoint:

POST /tickets

with OpenAPI metadata:

operationId: createTicket
summary: Create support ticket

An MCP generator turns it into a clean tool definition. Under the hood the MCP server still makes the HTTP call, but the agent sees a high-level capability.

Why This Works Surprisingly Well

OpenAPI already gives us schemas, parameters, descriptions, auth definitions, and operation names. A lot of REST APIs were already "halfway to MCP."

That's why OpenAPI-to-MCP tooling exploded so quickly.

But Conversion Is Not Enough

Here's where many early takes fall short.

A naive 1:1 mapping from REST endpoint to MCP tool is often... mediocre. MCP isn't just a protocol translation — it's an interface redesign for agents. Production teams figured this out quickly. (Example)

The Semantic Problem

Humans tolerate ugly APIs. Agents don't.

Bad naming (POST /v2/createTaskEx), weak descriptions (summary: Get task), or ambiguous parameters become painfully obvious when an agent tries to use them.

The Real Insight

OpenAPI→MCP isn't mere translation. It's transforming developer-oriented APIs into agent-oriented capabilities. That's a deeper change.

Good MCP Design Often Adds Abstractions

The best implementations go beyond CRUD. Instead of exposing createIssue, assignIssue, addLabel, they might offer manage_incident_ticket — a higher-level tool that orchestrates multiple calls behind the scenes.

Composite tools help agents reason much better with semantically meaningful operations.

MCP Servers Are Becoming API Gateways for Agents

Historically API gateways served humans and services. Now MCP servers are emerging as the gateway for agents — acting as capability registry, semantic adapter, auth broker, orchestration layer, safety boundary, and context provider.

Local vs Remote MCP

Local MCP (stdio) — perfect for Cursor, filesystem tools, IDE automation, desktop workflows.
Remote MCP (HTTP/SSE) — ideal for SaaS platforms, cloud APIs, enterprise systems. A lot of momentum is heading here. (Reference)

What Happens to SDKs?

SDKs aren't going away, but they're no longer the primary interface for AI-native systems.

The pattern is shifting from Human → SDK → API to Agent → MCP → API. The SDK often still lives inside the MCP server.

The Bigger Shift

Era	Primary Consumer
Web era	Humans
API era	Programs
MCP/Agent era	Reasoning systems

REST standardized service access. MCP standardizes agent access.

The Most Important Architectural Change

Software used to expose data. Now it's exposing capabilities.

Agents don't just retrieve information — they act. This demands semantic discoverability, richer intent descriptions, tool safety, permission boundaries, and composable workflows.

MCP is the protocol built for exactly that transition.

One Way To Think About It

That's why it feels qualitatively different even when it's still calling REST APIs underneath.

Practical Architecture Today

Modern AI-native systems increasingly look like:

Frontend Agent
    ↓
MCP Client
    ↓
MCP Server
    ↓
REST/gRPC/DB/internal services

And many companies are realizing they already own thousands of APIs — MCP is simply the new interaction layer sitting on top of them. (Example)

The agent era is here, and the interface layer is evolving with it.

What do you think — is MCP going to be as big a shift as REST was? Drop your thoughts below.

Now, a quick introduction to git-lrc.

git-lrc is a free micro AI code review tool that runs on Git commits as you develop software with AI agents.

AI can generate large amounts of code, but your team still owns the outcome. You cannot delegate responsibility—only execution.

git-lrc provides lightweight code reviews at commit time. It improves stability, security, and performance while reducing bugs and costs.

You run Git as usual. When you commit, a review is triggered. You receive a summary of changes and categorized issues—warnings, critical issues, performance problems, and security concerns.

The tool includes a web UI for reviewing results.

It is open source and available at github.com/HexmosTech/git-lrc.

For teams, pricing starts at $32 per month. It supports unlimited users and includes integrations with GitHub, GitLab, and Bitbucket, along with AI credits.

You can learn more at hexmos.com/git-lrc

Why Agentic Engineering Must Replace Vibe Coding

Shrijith Venkatramana — Wed, 06 May 2026 12:56:02 +0000

If you prefer watching a video version of this article, check out:

Here, we are going to look into a phenomenon that is happening across social media. “Vibe coding” is all the rage—for good reasons, and also for some bad ones.

We will examine this phenomenon, look at its strengths and weaknesses, and discuss my position on it as the author of git-lrc and as someone working in this space of tools that help build things quickly—AI-assisted coding and so on. I am interested not just in the technology, but in what it means for software engineering, its users, customers, the public at large, and civilization.

Why Does Vibe Coding Sound So Inevitable?

I have a screenshot here. The person doesn’t matter, but it captures a general opinion many people have: if you are not vibe coding, you are essentially writing today’s version of COBOL—it works, but it’s no longer how things are meant to be built.

That is a strong and very clear claim about the present and the future.

I don’t like absolute statements. I prefer to assess things in more detail.

What Changes When You Translate Intent Instead of Code?

Previously, we had assembly programming. Then came B at Bell Labs with Ken Thompson, then C, and later languages like Python and Java. These transitions are related. Moving from C to assembly is a conversion from one formal language to another.

What is a formal language? The meaning is precise. A print statement in C has a corresponding, predictable meaning in assembly. There is no uncertainty. A for loop in C becomes a loop structure in assembly. The mapping is clear and deterministic.

But when you prompt an AI agent and it produces Python or C, that is a different kind of process. It is a conversion from a natural language to a formal language.

Your prompt might be two lines or ten lines. It might be structured. But the output can vary widely. Even the same model can produce different outputs across runs. We don’t know exactly what it will produce.

Also consider the reverse direction. Given code, can you reconstruct the original problem? Not reliably. This is not a one-to-one mapping. It is one-to-many.

In contrast, C to assembly is close to one-to-one. From assembly, you can reconstruct C-like code. You might lose variable names, but the structure remains intact.

So with vibe coding, we must remain vigilant. The system is producing meaning on the fly. It adds, removes, and modifies intent. It generates its interpretation of your input.

This is a key differentiator when dealing with natural language input.

Why Abstractions Stop Protecting You at the Worst Time

There is also the concept of leaky abstractions. Even with traditional abstractions, you need to understand layers beneath them to produce good results.

Consider why Elon Musk needs to understand how rockets work. He could hire people and delegate everything, but he still engages deeply with engineering details.

When you build something serious, you need understanding across multiple abstraction layers. Depth matters.

Similarly, we teach computer architecture concepts—memory, CPU, etc.—even if students later write Java. Why? Because abstractions break. They work most of the time, but not always. You need to understand what is happening underneath.

What Breaks When Software Gets Trusted Too Easily?

Now consider a few questions about vibe coding.

You might think this is exaggerated. Let’s look at history—examples of software failures.

The Therac-25 accidents led to six deaths due to software malfunction.
Toyota had unintended acceleration issues—89 deaths and thousands of complaints.
The Patriot missile failure caused 28 deaths due to a numerical error.
The Mariner 2 failure involved costly software-related issues.
Another spacecraft failure was caused by an integer overflow.
The Mars Climate Orbiter was lost due to a unit mismatch.
Boeing crashes caused hundreds of deaths due to sensor-related software issues.
Financial systems like Capital One and Citibank experienced major erroneous transactions.
The Fujitsu Horizon scandal led to wrongful prosecutions due to software errors.
The CrowdStrike outage affected millions of systems, disrupting flights, healthcare, and payments.

These are failures in professionally engineered systems.

So the question is: am I exaggerating?

In serious contexts—from personal tools to critical infrastructure—you cannot blindly trust software.

The problem with vibe coding is that its advocates promote it, but would they trust systems built using it?

At a deeper level, trust is the bedrock of civilization. Engineering exists to build reliable and secure systems that others can depend on.

An engineer’s responsibility is not personal convenience, but public safety and reliability. Bridges must stand. Planes must land safely. Medical systems must work when needed.

So What Should Replace Vibe Coding?

Vibe coding, by itself, cannot support this level of responsibility. It may be useful for prototyping, exploration, or internal tools. But it cannot be the foundation for serious systems without additional rigor.

That is why I discourage the term “vibe coding” and instead advocate “agentic engineering.”

Agentic engineering emphasizes respect for reality, feedback loops, testing, criticism, and verification. Not blind trust—verification.

We must not rely solely on intuition or “it seems to work.” Systems can fail in critical ways.

We have a responsibility to promote methods that uphold engineering values.

Interestingly, Andrej Karpathy popularized the term “vibe coding,” and by 2026 he is also advocating a shift toward agentic engineering.

We want to preserve engineering values: reliability, correctness, efficiency, performance, and security. These are what build civilizations.

Agentic engineering aligns with that.

As part of this, I built a tool called git-lrc. It provides micro AI code reviews on commit. Every time you commit, it encourages you to review what was generated, identify issues early, and maintain quality.

We should not pass problems downstream to customers. We should take responsibility upfront.

That is the core message: promote agentic engineering over vibe coding.

Want a Practical Way to Apply This?

Now, a quick introduction to git-lrc.

git-lrc is a free micro AI code review tool that runs on Git commits as you develop software with AI agents.

AI can generate large amounts of code, but your team still owns the outcome. You cannot delegate responsibility—only execution.

git-lrc provides lightweight code reviews at commit time. It improves stability, security, and performance while reducing bugs and costs.

You run Git as usual. When you commit, a review is triggered. You receive a summary of changes and categorized issues—warnings, critical issues, performance problems, and security concerns.

The tool includes a web UI for reviewing results.

It is open source and available at github.com/HexmosTech/git-lrc.

For teams, pricing starts at $32 per month. It supports unlimited users and includes integrations with GitHub, GitLab, and Bitbucket, along with AI credits.

You can learn more at hexmos.com/git-lrc

Responsible Design: Shaping Large-Scale Consequences by Organizing Agents

Shrijith Venkatramana — Tue, 05 May 2026 10:39:41 +0000

You can watch the video version of the post as well if you prefer that:

Recently on LinkedIn, I saw a comment that I thought was really thought-provoking and interesting.

This comment was made by Mr. Meheryar Tata. He's a CTO and also has a financial background. I think he was a CA as well.

So, let's get into it.

What he said is that AI, by itself, cannot have accountability structurally because it has nothing to lose. Only humans and corporations can be accountable because a broken promise has economic consequences. In the long term, this means that the only remaining job will be risk underwriting. You will receive a premium to be held accountable when things go south. Basically, insurance.

This is an extremely thought-provoking comment, in my opinion.

Because what he's essentially saying is that semi-autonomous systems will do most of the jobs of the future.

Driving a car? AI will do it. Balancing the books? AI will do it. Teaching? AI will do it. Surgery? AI will do it. Arguing for justice? AI will do it. Everything — AI will do it.

So, what does the human do?

Well, a human or a corporation guarantees something, and if things go wrong, someone must be held accountable so that bad consequences have an equal and proportionate response.

As progress happens, I think we also increasingly wish for security guarantees across all kinds of human activity.

That was his view.

Now let's go a little further. I don't know whether all of you know what this is about, but this is a picture of Hammurabi.

You know Hammurabi's code. Hammurabi was a famous Babylonian king historically, and he came up with some of the very first laws.

Most of these were essentially "if this, then that" kinds of laws. Even in India, we had people like Chanakya. In China, people like Han Fei. Different civilizations were developing legal systems. The whole idea was that things go wrong in society all the time, and the question becomes: how do we deal with it?

For example, he had laws dealing with structural failure. If a house collapses and kills the owner, then the builder must be executed. The builder therefore has a reason to be careful and design things properly.

Or if there is damage to the owner's son, then the builder's son is also executed.

These kinds of systems were about compensation, damage prevention, deterrence, and quality standards.

There are several components to this, and I think it's a very interesting perspective.

So this is where Mr. Meheryar is coming from. This is the underlying view: how do you deter dangerous activities in society?

Now we'll move forward in history and look at another way of thinking about this.

There was someone called Admiral Rickover. He was the person who introduced the idea of nuclear submarines and made them practical.

During his time, this was almost seen as impossible because the Manhattan Project was going on, and atomic energy was associated almost entirely with bombs. So it was considered a very tricky thing to even imagine converting atomic energy into productive use.

He was taking it into national defense through nuclear submarines, and he made it safe. He made an extremely dangerous and new technology safe.

How did he do that?

His primary concept was responsibility.

Here is his quote on responsibility.

What he said is:

Look at the wording here.

Mr. Meheryar said that accountability can reside in a human or a corporation.

But Rickover is even harsher. He's saying only the individual can truly bear the consequence because, even inside an organization, someone must ultimately be held responsible.

People like Elon Musk insist that there must be an actual person's name behind every requirement.

You cannot hide behind an organization because, at the end of the day, one person is responsible for a particular thing.

You may share responsibility with others, but your own responsibility is not diminished.

It's a wonderful quote.

You can say ten people are on your team and that they contributed to a bad outcome, but the point is that all ten of you are still responsible.

That is the idea of responsibility he brings forward. Each person is responsible for the whole. You may delegate execution, but responsibility still remains with you.

Delegation means someone else may execute, but you are still accountable.

You may disclaim responsibility, but you cannot divest yourself of it. You cannot escape it.

You cannot divide it, pass the buck, or say "I didn't know."

You are responsible.

So when something goes wrong, there has to be one person.

And as they say, if everyone is responsible, then probably no one is.

So this is another perspective on responsibility.

From the AI angle, this is something we have to think deeply about.

How do we make people responsible for systems they do not even understand?

We cannot fully predict what AI systems will do.

Even at the societal level, we cannot predict what every individual will do, and yet governments still say they will provide justice.

That is the whole idea of the state. Even in highly complex situations, where taking responsibility seems impossible, we still try to figure out a way to take responsibility.

This is another person: Herbert Simon.

Herbert Simon wrote a very important book called The Sciences of the Artificial.

I think this is also extremely important.

What he said is that engineering, medicine, business, architecture, painting, and many other fields are concerned not with the necessary, but with the contingent — not with how things are, but with how they might be. In short, they are concerned with design.

This whole book, The Sciences of the Artificial, is essentially another way of talking about the science of design.

Most modern disciplines are fundamentally about design. Engineering is about design. Medicine is about design. Business is about design. Architecture is about design.

It is all about shaping outcomes using intelligence, resources, capabilities, creativity, focus, and scholarship.

Using everything available to shape consequences to the best of our ability.

Making things happen the way we want them to happen.

That is what design is about.

And what Simon said is that most modern jobs are fundamentally about design.

Design is a first-class intellectual discipline. It is not decoration. It is about taking existing situations and transforming them into preferred outcomes.

This applies to architecture, policy, organizations, UI, economics — everything.

It is fundamentally about consequences.

And again, Simon brings in this perspective of complexity.

Back then, we could not understand humans at a very micro level. This was before AI.

Essentially, what he is saying is that each AI agent is a component, and now we are going to organize these agents into coherent systems.

We must organize them in such a way that harm does not befall humanity.

We already do this with potentially dangerous systems. For example, we have armies, but armies are placed under civilian control. Even if there is a coup attempt, there are mechanisms to restore order.

The idea is that we use intelligent organizational structures to keep dangerous power under control in the way we want.

The entire system is designed so that outcomes align with our intentions.

That is what Simon is saying.

So how does all this relate back to Mr. Meheryar?

Insurance is one thing. Deterrence is one thing.

But in the modern view, we must take responsibility for the outcomes of complex systems.

And how do we do that?

We do it through design.

We have to design systems carefully. We have to think about new organizational structures. We have to put things together in sensible ways so that harm is minimized and benefits are maximized.

That, I hope, gives you an idea of how I think about AI and how to shape the future with AI.

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

AI Micro Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a habit,…

View on GitHub

We Built a Free AI Code Review That Runs on Every Commit

Shrijith Venkatramana — Sat, 21 Feb 2026 10:23:47 +0000

Hello, I'm Shrijith. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

The Moment We Realized Something Was Off

In our team, AI tools like Copilot and Cursor clearly increased velocity. Features moved faster. Refactors felt cheaper. Boilerplate disappeared.

But careful inspection of code quietly declined.

AI would generate large diffs. They looked reasonable. They compiled. Tests passed. So they landed.

Only later would we discover subtle issues:

A validation check removed.
A constraint relaxed.
An edge case dropped.
An expensive cloud call introduced.
Sensitive material leaking into logs.

Nothing dramatic. Just small, silent shifts.

And those are the ones that cost hours in production debugging.

We had given ourselves a race car.

We forgot the brakes.

Why We Didn’t Build Another Dashboard

The obvious solution would’ve been another SaaS review tool or another CI gate.

I didn’t want that.

Responsibility in software engineering has a natural anchor point: git commit.

Every editor, every IDE, every AI agent eventually hits Git.

Committing is mandatory. It’s the moment a developer says:

“I stand behind this change.”

So we built git-lrc to live exactly there.

It hooks into git commit and reviews every staged diff before it lands.

When you commit:

A GitHub-style diff opens in your browser.
Inline AI comments appear at the exact lines that matter.
Issues are tagged with severity.
A high-level summary explains what changed.
You can copy flagged issues back into your AI agent.
Lines added/removed per file are shown for quick scope awareness.

No dashboards. No external process.

Just a structural nudge at the right moment.

Review, Vouch, or Skip — Your Choice

git-lrc is engineer-centric by design.

You can:

Review — run AI analysis on the diff.
Vouch — skip AI and explicitly take responsibility.
Skip — commit without review.

Every commit records what happened directly in git log, for example:

LiveReview Pre-Commit Check: ran (iter:3, coverage:85%)

iter shows how many review cycles you ran.
coverage shows how much of the final diff was AI-reviewed.

Your team can see exactly which commits were reviewed, vouched, or skipped — without any external reporting tool.

Review becomes part of authorship, not an afterthought.

Designed for AI Workflows

A typical cycle looks like this:

Generate code with your AI agent.
git add .
git lrc review
AI flags issues inline.
Copy issues back to your agent.
Fix.
Review again.
git lrc review --vouch
Commit.

Each review is tracked as an iteration.

You move fast — but deliberately.

60 Seconds to Set Up. Completely Free.

Install:

curl -fsSL https://hexmos.com/lrc-install.sh | sudo bash

Then:

git lrc setup

You bring your own Gemini API key (free tier).

There’s no billing layer. Unlimited reviews.

Only the staged diff is analyzed.

No full repository upload.

Diffs are not stored after review.

The mission is simple:

Make AI code review engineer-centric, free, and accessible to developers everywhere.

The more devDevelopers review AI-generated code early, the fewer subtle bugs make it to production

Make AI code review engineer-centric, free, and accessible to developers everywhere.

AI-assisted coding is becoming the default.

The real question isn’t whether we use AI.

It’s whether we stay responsible while using it.

If you care about shipping fast without silently degrading quality, I’d appreciate your support.

👉 Upvote git-lrc on Product Hunt:

https://www.producthunt.com/products/git-lrc

The more developers review AI-generated code early, the fewer subtle bugs make it to production.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

The future belongs to those who can refute AI, not just generate with AI

Shrijith Venkatramana — Thu, 19 Feb 2026 13:36:54 +0000

The assumption in software engineering circles has been that if AI lets us write code faster, we will build more things and move faster.

That assumption misses a step.

Writing code is not the same as integrating it, maintaining it, or trusting it.

We are starting to discover that verification does not scale the way generation does.

I argue that the engineer who thrives in this environment will not be the one who can prompt the largest code output. It will be the one who can look at what comes out and reliably decide what survives.

This post is about why that skill — of refutation — is about to become central, and what it means for how we build software.

1. Volume is no longer a signal of value.

We are in the middle of a real GenAI explosion.

Code, images, video, documents — all of it can now be generated at a cost that is rapidly approaching zero compared to the historical human-labor baseline.

In software engineering especially, the ability to write a lot of code has traditionally been associated with productivity and even creativity.

That association is now breaking down.

We can generate more than ever before, faster than ever before.

Volume by itself has lost meaning.

2. Knowledge is what survives attack.

To understand what is changing, it helps to step back and borrow from epistemology.

Epistemology is the branch of philosophy that separates knowledge from what is not knowledge.

Merely having experience with something is not knowledge.

Repeating what supposed authorities have propounded is not knowledge.

Making statements based on experience is not knowledge either.

Statements become candidates for knowledge only when they are internally consistent, publicly testable, and able to survive adversarial scrutiny.

3. Value is revealed under attack, not in the design lab

A useful analogy is military hardware.

The worth of a battle tank is not established in the design lab or by marketing brochures.

Its worth is demonstrated by how it withstands attack in actual battle. Until it has faced stress, resistance, and hostile conditions, we cannot make serious claims about its efficacy.

The same applies to ideas, designs, and code. Their value is revealed under attack.

4. The source of an idea does not matter; only its survival matters.

Karl Popper made this explicit: the source cannot be trusted.

It does not matter whether a claim comes from a famous scientist, a senior engineer, or a large language model.

What matters is whether the claim survives attempts to falsify it.

Knowledge grows through conjecture and refutation, not through confident assertion.

Popper was writing about the demarcation of science from non-science, but the pattern applies more broadly: without the possibility of being shown wrong, we cannot claim to have learned anything.

5. GenAI is a conjecture engine; everything it produces is provisional.

GenAI, at its core, is a conjecture engine.

Every piece of generated code is a proposed theory about how a system should behave.

Every generated explanation is a proposed interpretation.

All of it must be treated as provisional.

Everything AI generates should be considered a proposed theory and then subjected to severe testing and criticism to see if it survives.

6. We already had systems for adversarial scrutiny (CI/CD, code review).

This was already true in the pre-AI world.

That is why we invented code review, linters, and continuous integration in the first place. We recognized that humans make mistakes, that first drafts are often wrong, and that structured criticism improves outcomes.

CI/CD pipelines, unit tests, and integration tests are all mechanisms for subjecting code to adversarial scrutiny.

In that sense, applied Popperian epistemology has been embedded in our workflows for years.

7. Historical software growth: about 20% per year.

What changes now is scale.

In 2016, Professor Hatton and his team published The Long-Term Growth Rate of Evolving Software.

They studied how software codebases grew over time, long before GenAI was in the picture.

Their finding was strikingly consistent: historically, software projects grew at about a 20% compound annual growth rate (CAGR).

At that rate, a codebase roughly doubles in size in about four years.

It is important to note that this paper describes how codebases actually grew, not a theoretical maximum. It is a historical baseline, not a physical law.

8. Monster codebases are a plausible outcome of AI-driven productivity.

Now consider what happens if AI meaningfully boosts developer productivity.

If productivity doubles and CAGR moves toward 40%, doubling time shrinks to roughly two years.

If productivity increases fivefold and we approach 100% CAGR, a codebase doubles every year.

Over a decade, that compounding is explosive. A 5× productivity boost sustained over ten years could translate into a roughly 165× increase in code volume.

A medium-sized 100,000 LOC codebase could plausibly turn into 100 million LOC.

For context, the Linux kernel reached around 40 million LOC after three decades of evolution.

We are potentially heading toward “monster codebases.”

9. But isn’t growth bounded by complexity? Yes, but significant growth is still likely

This projection invites immediate objections.

First, the 20% CAGR comes from a pre-LLM world; using it to predict a post-LLM world is logically tension-ridden.

The historical trend gives us a baseline against which to measure disruption.

If the trend holds, nothing changes.

If it breaks, we need to understand the new environment.

Second, software growth is bounded by complexity, not just typing speed.

A 100 million LOC codebase might be unbuildable or unmaintainable regardless of how fast we can write code, because integration complexity grows faster than linearly.

If we generate code faster than we can manage its integration complexity, we build systems that collapse under their own weight.

The question is whether our verification systems scale with it.

10. The old equilibrium between writing and reviewing code breaks at scale.

Historically, review processes could grow alongside codebases.

If code grew 20% per year, human review capacity could roughly keep pace.

But if code volume grows by multiples, not percentages, the old equilibrium breaks.

We move from incremental growth to bulk production of code.

How will refutation grow with generation?

11. AI must help with verification, or human review collapses.

At that point, attention becomes the scarce resource.

As generated output increases, value shifts from production to selection.

The key problem becomes: how do we direct limited human attention to the most important risks inside an ocean of machine-generated diffs?

How do we build higher-level representations that compress massive change into manageable insight?

There is no realistic path forward without using AI to verify as well.

Human-only review cannot keep up with machine-scale generation.

AI must help draw attention to useful things, highlight potential constraint violations, detect behavioral drift, and reduce the burden of review.

Verification must become partially automated, or it simply collapses.

12. But if AI is flawed, can AI review be trusted? (The infinite regress problem).

This is where the most obvious objection arises: if the AI that generates code is flawed and produces hallucinations, why would an AI that reviews code be any less flawed?

Would this not simply compound errors rather than catch them? This is sometimes called the infinite regress problem — if we need an AI to check the AI, who checks the checker?

13. Specialized review AI is different from general generation AI.

The answer lies in specialization.

A review AI does not need to be a general intelligence.

It needs to be a focused tool for checking specific properties: type correctness, conformance to project style, violation of defined architectural boundaries, or behavioral drift captured by property-based tests.

The model used for review can be different from the one used for generation — smaller, more conservative.

Review AI is not asked to have an opinion about whether code is “good.”

It is asked to surface anomalies to a human.

It acts as a tireless, fast, but ultimately fallible junior reviewer whose job is to flag anything unusual and let the senior engineer make the final call.

The goal is not to eliminate human judgment, but to focus it.

14. Guardrails belong in verification, not just generation.

This is also where guardrails belong.

Guardrails should primarily sit on the verification layer, not the generation layer.

Trying to constrain generation alone is like trying to prevent all bad tank designs at the drawing board.

A more robust approach is to subject every design to rigorous criticism and stress testing.

Instead of focusing on censoring models as the main control mechanism, we should upgrade our verification methods.

There is room for debate here: some harms occur at the moment of generation, not execution, and generation-layer guardrails address those.

But for engineering reliability, verification is where the leverage lies.

15. Perhaps we’ll write less, more leveraged code. But verification shifts, it doesn’t disappear.

A different kind of objection comes from economics.

Perhaps the future is not monster codebases but minimal, highly leveraged ones.

If code becomes cheap, the incentive to write efficient, reusable abstractions increases.

Why generate a thousand lines of boilerplate when a ten-line configuration file powered by AI does the same thing?

This is possible.

But even minimal codebases require verification of their minimal parts, and the leverage increases the blast radius of any mistake.

Whether code volume expands or contracts, the verification load shifts rather than disappears.

The scarce resource remains human attention directed at the right places.

If GenAI scales conjecture, ReviewAI must scale refutation.

16. Market saturation might limit growth, but problem space is far from exhausted.

Another objection is that growth in code volume will eventually hit market saturation.

We do not have an infinite number of meaningful problems to solve. After a point, generating more code just creates noise and technical debt.

But this assumes that the problem surface is close to saturated. It is not.

Consider countries like India. Large-scale infrastructure gaps, pollution management, logistics inefficiencies, healthcare access, education quality, urban planning, agricultural optimization — these are not marginal problems.

They are system-level challenges that require coordination, monitoring, simulation, automation, and optimization at scale. All of these increasingly rely on software.

Even in developed economies, software penetration into physical systems is still incomplete: energy grids, water systems, public transport, manufacturing, climate modeling, robotics, biotech.

As capability expands, software does not merely fill existing markets; it enables new domains of intervention.

Historically, when production capacity increases, demand tends to expand into areas previously considered infeasible.

The limiting factor has rarely been a shortage of problems. It has been cost and coordination.

17. Engineering must adapt, because norms evolve too slowly.

Engineering as a field needs to internalize this shift.

The discipline has always depended on separating what works from what merely appears to work.

Having experience building something does not make it reliable.

Having it survive adversarial testing does.

With code volume potentially compounding at unprecedented rates, we do not have the luxury of slowly evolving norms.

We need accessible, cost-effective verification tools that integrate directly into development workflows.

18. A concrete direction: automated review on every git commit.

In my own work on AI-assisted code review, I have been building tooling that triggers review automatically when diffs are committed to git repositories.

The idea is straightforward: treat every change as a hypothesis and subject it to systematic attack.

In a sense, this is applied Popperian epistemology embedded in CI/CD. The goal is not to slow down generation, but to make criticism abundant.

I do not claim this solves every problem.

The tools are early, the approaches are experimental, and the infinite regress concern is real.

But it’s time we started taking our ReviewAI stack more seriously.

19. The future belongs to those who can refute, not just generate.

GenAI has made conjecture cheap.

The risks of compounding error are real.

If we do not make refutation equally powerful and widely available, we risk drowning in our own output.

The future of engineering in the AI era will not be decided by how much we can generate, but by how rigorously we decide what survives.

And that decision of what survives, in the end, remains a human responsibility.

And I for one hope that Refutation as an idea gets taken as seriously as the idea of generation in the industry.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

AI Is Stress-Testing Software Engineering as a Profession

Shrijith Venkatramana — Fri, 06 Feb 2026 15:20:06 +0000

The arrival of large-scale AI systems has triggered two predictably disappointing reactions among a large swath of software engineers: hype and fear.

One group greets AI with unrestrained excitement, extrapolating demos into destiny. This position is usually held by the less experienced or by those with commercial interests tied to the narrative

Another treats it as an existential threat, assuming wholesale displacement and professional irrelevance. This reaction often comes from more experienced engineers who have grown comfortable in a particular context and are primarily focused on protecting their existing paycheck.

Both responses, in my view, are mistakes. They share a common flaw: neither is a professional response.

Professions are defined not by the tools they use, but by the responsibilities they accept.

Medicine as a field of practice did not go extinct when diagnostic machines improved.

Civil engineering did not dissolve when materials science advanced.

In each case, the profession adapted by elevating standards of judgment, verification, and accountability.

Software engineering is now being asked to do the same.

This moment is not about defending status or losing one’s bearings due to excessive exuberance. AI is an opportunity for the field of Software Engineering to grow up.

The Failure of Hype and Fear

Hype is a failure of epistemic, mental and professional discipline.

It treats impressive behavior under controlled conditions as proof of general reliability.

It confuses surface fluency with understanding and mistakenly assumes that systems somehow work out OK on their own.

Engineers who have never owned production systems are especially vulnerable to this error, because they have not yet internalized how often “working” systems fail in unexpected ways.

Fear is a different failure, but a failure nonetheless.

It assumes that because a tool can perform a task, it can absorb responsibility for that task.

This is a category error.

Tools do not bear accountability. People do.

When engineers retreat into narratives of irrelevance under the banner of realism - they are in practice abandoning professional duty.

Neither posture helps society.

Neither deserves trust.

What a Professional Response Looks Like

A professional response begins with responsibility.

Engineers remain responsible for the behavior of systems they design, deploy, and maintain, regardless of how much automation is involved.

“The model did it” is not an explanation; it is an abdication.

If a system cannot be explained, evaluated, or bounded, it should not be deployed in contexts where failure matters.

Professionals are also defined by epistemic discipline.

They distinguish what is known from what is uncertain, what has been validated from what merely appears to work.

They resist both excitement and panic because both distort judgment.

Calm assessment under uncertainty is not optional; it is the core professional skill.

Verification becomes more important, not less.

As generative systems make production cheaper, review, checking, auditing, and adversarial testing become the scarce skills.

Creation can be automated. Validation cannot be outsourced to systems that do not understand consequences.

Only those who understands the dynamics and history of a system end-to-end can vouch for it competently.

Authority, when exercised, must be tied to truth rather than status.

Professionals do not claim legitimacy by insisting on uniqueness, nor do they forfeit it by denying their value.

They earn authority by explaining limits clearly, correcting errors publicly, and refusing to overstate confidence.

Credibility comes from accuracy, not bravado.

Finally, a professional response is system-level.

Engineers must reason about sociotechnical systems: incentives, organizations, feedback loops, and long-term maintenance.

They ask uncomfortable questions, such as who pays when the system fails and how errors propagate beyond the technical boundary.

This is the difference between building artifacts and practicing engineering.

The Training That Produces Professionals

Professional judgment does not emerge from tool fluency or short courses alone.

It is cultivated through specific forms of training and experience.

The first is production responsibility.

There is no substitute for owning systems that can fail, being paged when they do, and living with the consequences of design decisions.

This experience teaches restraint, humility, and realism.

It is why experienced engineers react differently to AI hype than those who have only shipped prototypes.

Second is rigorous reasoning.

Training in logic, probability, statistics, and failure analysis and many other topics, including the liberal arts - produces a human being capable of taking on real responsibility.

Professionals must train their thought, emotion, speech and actions to serve with competence.

Professionals ask what assumptions are being made, how brittle those assumptions are, and what evidence would falsify their beliefs.

Without this discipline, AI becomes a baseless confidence amplifier rather than a tool.

Third, writing must be treated as a core technical skill.

Design documents, postmortems, risk analyses, and model evaluations are not administrative overhead; they are how thinking is made inspectable.

Writing forces clarity and exposes gaps in understanding.

Managing AI systems is largely a writing problem: constraints, evaluations, prompts, and decision rationales are textual artifacts.

Fourth, professionals study failure.

Engineering history is rich with disasters caused not by a lack of intelligence, but by overconfidence, normalized deviance, and misaligned incentives.

These patterns repeat.

Engineers who do not study them are condemned to reenact them with more powerful tools.

Fifth, training must include organizational, political and human factors.

Most large failures are not purely technical.

They arise from communication breakdowns, incentive misalignment, mismanagement of various resources, and diffusion of responsibility.

Engineers who ignore these factors are operating with an awfully inaccurate model of reality.

Finally, professional formation requires an ethos rather than a mere “We’re special” identity.

The question is not whether engineers are special.

The question is whether they are worthy of trust in important and complex matters at hand.

Trust is earned through clarity, restraint, and accountability over time, not through novelty or self-assertion.

The Task Before Us

AI does not eliminate software engineering as a profession, although it demands introspection, reforms, evolution in it.

It merely removes the comfort of immaturity.

It makes excuses harder to sustain and sloppy thinking more visible.

In exchange, it raises the ceiling for those willing to accept responsibility and exercise judgment.

Software will still be required in the world - but the way it gets created and handled may change drastically in the upcoming months and years.

Growing up will not feel glamorous. It will involve less excitement, less fear, more verification, and more uncelebrated work.

But that is the price of being a profession rather than a trade, and of being trusted rather than merely used. A “coder” is a tradesman (output-focused). An “engineer” is a professional (outcome-focused, risk-bearing). AI may automate the trade, but it stresses the profession.

This is the test. How software engineering responds will determine whether it matures— or forfeits its claim to authority altogether.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Story of a TCP Packet: An Intuitive Entrypoint To Linux Networking

Shrijith Venkatramana — Sun, 26 Oct 2025 16:00:32 +0000

Ever wondered what eth0, iptables, nat, or FORWARD actually mean in Linux networking? As engineers, we use these terms, but these terms—interfaces, iptables tables and chains, the networking stack—often feel like a black box. What are interfaces, are they hardware or software? Do they always need an IP? What’s the deal with iptables’ tables versus chains? How does a packet even flow through all this?

This post follows a TCP packet from your browser to a server running nginx, into a Docker container with a Python app, and back. We’ll use an analogy to ease in, a real-world example for context, plain English to clarify, and technical details to satisfy your curiosity. By the end, you’ll understand how Linux networking fits together and why it matters for debugging and building systems.

A Building Analogy: Interfaces as Doors, iptables as Gatekeepers

Picture your server’s network as a busy office building:

Interfaces are doors or hallways. The front entrance (eth0) welcomes external packets, while internal paths (docker0, lo) connect departments. Some doors are physical (like Ethernet ports); others are virtual (software-only).
iptables is the security team, with rulebooks (tables) for different tasks—filter for blocking or allowing, nat for rewriting addresses. Each rulebook has checkpoints (chains) like reception desks or mailrooms.
The networking stack is the building’s delivery system, ensuring letters (packets) reach the right desk through doors and guards.

From outside, it’s just sending a letter and getting a reply. Inside, a complex system makes it happen.

This shows interfaces can be hardware or software, and not all need IPs—some just pass traffic. iptables handles both security and routing (and property modification/mangling, but that's less important for now), and the stack ties it all together.

The Setup: From Browser to Dockerized Python App

Here, we will get a high level view of an interaction - which will form the basis of the rest of the post.

Imagine you visit https://example.com. Here’s the server setup:

nginx listens on the server’s public IP 203.0.113.10:443 via interface eth0.
nginx proxies requests to a Python app inside a Docker container at 172.17.0.2:8000, connected through a bridge interface docker0.

The packet’s journey:

Browser → Internet → Server (eth0, nginx) → docker0 → Container → Python app → Back.

This mirrors real-world web app setups. Let’s break it down in plain English from a slighly different angle.

Plain English: How Packets Enter and Move

When your browser sends a request, the packet arrives at eth0, a network interface. Interfaces are where packets enter or leave. Some are tied to physical hardware (like an Ethernet card for eth0), while others, like docker0 or lo (loopback), are software-based, existing only in the kernel. Not every interface needs an IP— althoug in practice bridges like docker0 often have one and help with forward packets from the server to the containers and back (act as gateways).

The kernel decides: deliver locally (to nginx on port 443) or forward (to a container)? Before that, iptables steps in. It’s the kernel’s tool for managing packets, handling both security (via the filter table to allow/deny) and routing (via the nat table to rewrite addresses). Tables are the big categories; chains are specific checkpoints within them, like INPUT for local delivery or FORWARD for routing. Each chain holds rules, like “allow TCP port 443.”

To see interfaces on your system:

#!/bin/bash
# List network interfaces and IPs
ip addr show
# Example output (shortened):
# 1: lo: <LOOPBACK> inet 127.0.0.1/8
# 2: eth0: <BROADCAST> inet 203.0.113.10/24
# 3: docker0: <BROADCAST> inet 172.17.0.1/16

iptables Explained: Tables, Chains, and Their Roles

iptables is the kernel’s packet-processing engine, controlling both security and routing, among other things. Tables are the top-level categories, each with a purpose:

filter: Decides to accept or drop packets (security).
nat: Rewrites source/destination addresses (routing).
mangle: Modifies packet headers (less common).

Chains are checkpoints within tables, like steps in a process:

PREROUTING: First stop for incoming packets, before routing decisions.
INPUT: For packets destined locally (e.g., to nginx).
FORWARD: For packets passing through to another destination (e.g., container).
OUTPUT: For packets leaving the host.
POSTROUTING: Final step before packets exit.

Tables are bigger than chains—each table contains multiple chains, and chains hold specific rules, like “accept TCP to port 443.”

Here’s the structure:

Concept	Purpose	Examples
Table	Groups tasks	filter (security), nat (routing)
Chain	Checkpoint in table	PREROUTING, INPUT, FORWARD
Rule	Action to take	Accept port 443, rewrite to 172.17.0.2

To add a rule allowing HTTPS:

#!/bin/bash
# Add INPUT rule for HTTPS (run as root)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
# No output; verify with:
# iptables -L INPUT -v -n
# Example: Chain INPUT ... ACCEPT tcp dpt:443

Note that we only reference the INPUT chain here; the table is implicit. The default table is filter, so the rule above is shorthand for:

iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

For iptables details, see netfilter documentation.

Step 1: Packet Hits eth0 and PREROUTING

The packet arrives at eth0:

Source: 192.168.1.10:50500 (browser)
Destination: 203.0.113.10:443 (server)

The kernel sees the destination IP matches eth0 (local delivery).

First stop: nat:PREROUTING for potential Destination NAT (DNAT), rewriting the destination. Here, nginx is on the host, so no rewrite occurs. In Docker setups with -p 443:8000, DNAT would change the destination to the container’s IP.

Capture the packet:

#!/bin/bash
# Capture HTTPS traffic on eth0 (run as root)
tcpdump -i eth0 tcp port 443 -c 1 -nn
# Example: IP 192.168.1.10.50500 > 203.0.113.10.443: Flags [S]...

Step 2: filter:INPUT Delivers to nginx

Next, the filter:INPUT chain checks if the packet can reach nginx. A rule like above (--dport 443 -j ACCEPT) allows it. This is also where tools like ufw (Uncomplicated Firewall) add their rules—ufw is a user-friendly frontend for iptables that primarily manages the filter table to block or allow traffic.

nginx processes the request and opens a new connection to the container:

Source: 172.17.0.1:random (docker0 on host)
Destination: 172.17.0.2:8000 (container)

iptables acts before apps—it filters or rewrites packets before nginx sees them.

Step 3: Routing Through docker0 to the Container

The kernel routes the new packet via docker0, a software bridge interface (no IP, just forwards). Containers use virtual Ethernet (veth) pairs: one end (vethXXXX) on the host, the other (eth0) in the container.

Path: nginx → docker0 → vethXXXX → container’s eth0.

Check the bridge:

#!/bin/bash
# Show Docker bridge (needs bridge-utils)
brctl show docker0
# Example: docker0 ... interfaces: veth1234

Docker networking: Docker bridge docs.

Step 4: Container App and Return Trip

In the container, the packet hits its eth0 (the one inside the container, this one is virtual) and reaches the Python app on port 8000. The app responds, and the packet reverses:

Container eth0 → vethXXXX → docker0 → nginx → eth0 → browser.

On return, filter:FORWARD ensures forwarding is allowed, and nat:POSTROUTING applies Source NAT (SNAT), rewriting the source from 172.17.0.2 to 203.0.113.10.

Add SNAT:

#!/bin/bash
# Add SNAT for outbound traffic (run as root)
iptables -t nat -A POSTROUTING -s 172.17.0.0/16 -o eth0 -j MASQUERADE
# Verify: iptables -t nat -L POSTROUTING -v -n

Simple Python app:

# app.py - Run: python app.py
from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"Hello from container!")

server = HTTPServer(('0.0.0.0', 8000), Handler)
server.serve_forever()
# Run; test with: curl localhost:8000
# Output: Hello from container!

Save and run with python app.py.

Why This MaThe Linux networking stack is the kernel’s machinery: interfaces receive packets, iptables’ tables (`filter` for security, `nat` for routing) and chains (`INPUT`, `FORWARD`) process them, and routing delivers them. It’s what powers every `curl` or server.

Understanding this helps you:

Debug with ip addr, iptables -L, or tcpdump.
Secure systems by crafting precise iptables rules.
Design networks, like Docker setups, with confidence.

Next time you see veth1234 or a cryptic iptables rule, you’ll know its place in the packet’s journey—and how to control it.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

A Deep Dive Into How Go Modules Work

Shrijith Venkatramana — Sun, 28 Sep 2025 19:25:02 +0000

Go modules are the standard way to manage dependencies in Go projects since Go 1.11. They help organize code, handle versions, and make builds reproducible. This article breaks down how modules function, with practical examples to get you up to speed.

Understanding the Basics of Go Modules

Go modules provide a system for versioning and dependency management. Before modules, Go used GOPATH, which often led to version conflicts. Modules solve this by defining a module as a collection of packages with a unique path and version.

A module is identified by its module path, like github.com/user/project. Each module has a go.mod file that lists dependencies and their versions.

To enable modules, set the GO111MODULE environment variable to auto or on, but in recent Go versions, it's on by default outside GOPATH.

Here's a simple example to create a module:

// main.go
package main

import "fmt"

func main() {
    fmt.Println("Hello, Modules!")
}

Run go mod init example.com/mymodule in the directory with main.go. This creates a go.mod file:

module example.com/mymodule

go 1.21

Build and run with go build and ./mymodule (or mymodule.exe on Windows). Output: Hello, Modules!

For more on module basics, check the official Go documentation: Modules Overview.

Creating Your First Go Module Step by Step

Start with an empty directory. Create a file greet.go:

// greet.go
package greet

import "fmt"

func Greet(name string) {
    fmt.Printf("Hello, %s!\n", name)
}

Then main.go:

// main.go
package main

import "example.com/mymodule/greet"

func main() {
    greet.Greet("Developer")
}

Initialize the module: go mod init example.com/mymodule.

The go.mod now exists. To tidy dependencies (though none yet), run go mod tidy.

Build: go build. Run: ./mymodule. Output: Hello, Developer!

This setup shows how packages within a module import each other using the module path.

Inside the go.mod File: Key Elements Explained

The go.mod file is the heart of a module. It declares the module path, Go version, dependencies, and more.

Key directives:

module: Defines the module path.
go: Specifies the minimum Go version.
require: Lists direct dependencies with versions.
replace: Overrides a dependency's path or version.
exclude: Skips specific versions.
retract: Marks versions as retracted.

Example go.mod after adding a dependency:

module example.com/mymodule

go 1.21

require github.com/google/uuid v1.3.0

Run go mod edit -require=github.com/google/uuid@v1.3.0 to add it manually, or use go get.

To understand directives better, see go.mod Reference.

Adding and Updating Dependencies Effectively

Use go get to add dependencies. It updates go.mod and downloads modules.

Example: Add github.com/google/uuid.

In main.go:

// main.go
package main

import (
    "fmt"
    "github.com/google/uuid"
)

func main() {
    id := uuid.New()
    fmt.Println(id)
}

Run go get github.com/google/uuid. This adds to go.mod and creates go.sum for checksums.

To update: go get github.com/google/uuid@latest.

go.sum ensures integrity; it lists hashes for modules.

For a table of common commands:

Command	Purpose
`go get pkg`	Add or update dependency
`go mod tidy`	Remove unused, add missing deps
`go mod why pkg`	Explain why a package is needed
`go list -m all`	List all modules and versions

How Versioning and Semantic Versioning Fit In

Go uses semantic versioning (SemVer) like v1.2.3. Modules support major versions via suffixes: v2+ in the path, like example.com/mymodule/v2.

When requiring, specify versions: require example.com/other v1.0.0.

Go resolves versions using minimal version selection (MVS): Picks the highest version that satisfies all requirements.

Example: If one dep requires v1.2.0 and another v1.3.0, it chooses v1.3.0 if compatible.

To tag a version: git tag v1.0.0 and push.

Pseudo-versions like v0.0.0-20230929123456-abcdef123456 are used for untagged commits.

For details on versioning: Module Versions.

Working with Multiple Modules in Workspaces

Workspaces allow editing multiple modules together, useful for monorepos.

Create go.work with go work init.

Add modules: go work use ./mod1 ./mod2.

Example structure:

workspace/
- mod1/
- go.mod
- main.go
- mod2/
- go.mod
- lib.go
- go.work

go.work:

go 1.21

use (
    ./mod1
    ./mod2
)

In mod1's main.go, import mod2 using its path.

This overrides go.mod replaces for local development.

Troubleshooting Common Module Issues

Common problems include proxy issues, checksum mismatches, or invalid paths.

For checksum errors: Run go mod verify.

If behind a proxy, set GOPROXY=https://proxy.golang.org,direct.

Invalid module path: Ensure it starts with a domain like example.com.

Example fix for a bad import:

If import fails, check go.mod for correct require.

Table of errors:

Error Type	Fix
Checksum mismatch	`go mod download` or delete cache
Module not found	Check network or GOPROXY
Version conflict	Use `go mod graph` to inspect

For proxy setup: GOPROXY Environment.

Advanced Techniques for Module Management

Use replace in go.mod for local forks: replace github.com/other/mod => ../local/mod.

Vendoring: go mod vendor copies deps to vendor/ for offline builds.

Minimal modules: Keep go.mod clean with go mod tidy.

For private modules, set GOPRIVATE=example.com/private.

Example with replace:

Add to go.mod: replace github.com/google/uuid => ./local/uuid.

This points to a local directory.

Go modules evolve with each release, so check release notes for updates. Mastering them ensures reliable, scalable projects. Experiment with these examples in your setup to solidify your understanding.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Try These Under The Radar Golang Features to Do More With Less

Shrijith Venkatramana — Fri, 26 Sep 2025 19:21:38 +0000

Go's simplicity is one of its biggest strengths, but it packs some under-the-radar features that can shave hours off your development time. In this post, we'll explore capabilities like build constraints, object pooling, and advanced error handling. These aren't always front-and-center in tutorials, but they solve real-world problems efficiently. Whether you're optimizing performance or streamlining workflows, these tools can make your code cleaner and faster. Let's get into the details.

Customize Builds with Constraints for Platform-Specific Code

Build constraints let you include or exclude code based on conditions like OS, architecture, or custom tags. This keeps your codebase clean without runtime checks, which is great for cross-platform apps.

For example, you might have platform-specific implementations. Add a comment like //go:build darwin at the top of a file to make it compile only on macOS.

Here's a complete example. Create two files: hello_darwin.go and hello_linux.go, plus a main file.

hello_darwin.go:

//go:build darwin

package main

import "fmt"

func main() {
    fmt.Println("Hello from macOS!")
}

No, that's not right. Build constraints apply to files, and main should be separate.

Better:

main.go:

package main

import "fmt"

func main() {
    greet()
}

darwin.go:

//go:build darwin

package main

func greet() {
    fmt.Println("Hello from macOS!")
}

No, package main in both? Actually, for same package.

Correct way: files in same package.

Let's do:

main.go:

package main

import "fmt"

func main() {
    fmt.Println(getMessage())
}

message_darwin.go:

//go:build darwin

package main

func getMessage() string {
    return "Hello from macOS!"
}

message_linux.go:

//go:build linux

package main

func getMessage() string {
    return "Hello from Linux!"
}

To compile: go build on respective OS.

Output on macOS: // Hello from macOS!

On Linux: // Hello from Linux!

You can also use custom tags like //go:build prod and compile with go build -tags prod.

This avoids if-else bloat in code. For more on syntax, check the official build constraints doc.

Key points:

Reduces binary size by excluding unused code.
Improves readability without conditional logic.
Works with modules seamlessly.

Reuse Objects Efficiently Using sync.Pool

sync.Pool provides a way to reuse temporary objects, reducing garbage collection pressure in high-throughput apps like servers.

It's ideal for allocating buffers or structs that are created and discarded frequently. The pool manages a cache of objects, and you can put/get them as needed.

Example: In a web server, reuse byte slices for responses.

Complete code:

package main

import (
    "fmt"
    "sync"
)

func main() {
    var pool = sync.Pool{
        New: func() any {
            return make([]byte, 1024)
        },
    }

    // Get from pool
    buf := pool.Get().([]byte)
    copy(buf, "Hello, World!")
    fmt.Println(string(buf[:13])) // Output: Hello, World!

    // Put back
    pool.Put(buf)

    // Get again, should reuse
    buf2 := pool.Get().([]byte)
    fmt.Println(len(buf2)) // Output: 1024 (reused)
}

This runs without errors. The New func creates objects on miss.

Pools are goroutine-safe but cleared during GC, so use for short-lived objects.

Key points:

Cuts allocation overhead in loops or handlers.
Thread-safe by design.
Avoid storing stateful objects.

For benchmarks showing gains, see Go's sync package docs.

Handle Timeouts and Cancellations with Context

The context package lets you propagate cancellation signals, deadlines, and values across API boundaries, preventing resource leaks in concurrent code.

Use it for HTTP requests, database queries, or goroutines that might outlive their usefulness.

Example: A function that simulates work with timeout.

Complete code:

package main

import (
    "context"
    "fmt"
    "time"
)

func doWork(ctx context.Context) error {
    select {
    case <-time.After(2 * time.Second):
        fmt.Println("Work completed")
        return nil
    case <-ctx.Done():
        return ctx.Err()
    }
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel()

    err := doWork(ctx)
    if err != nil {
        fmt.Println(err) // Output: context deadline exceeded
    }
}

Here, the timeout triggers cancellation.

You can nest contexts or pass values like user IDs.

Key points:

Prevents goroutine leaks by signaling done.
Composable with WithValue, WithDeadline.
Standard in libraries like net/http.

Improve Error Handling with errors.Is and errors.As

The errors package offers Is and As for checking wrapped errors, making it easier to handle specific error types without string matching.

This is useful in layered apps where errors get wrapped with context.

Example: Wrap an error and check it later.

Complete code:

package main

import (
    "errors"
    "fmt"
)

var ErrNotFound = errors.New("not found")

func findItem() error {
    return fmt.Errorf("failed to find: %w", ErrNotFound)
}

func main() {
    err := findItem()
    if errors.Is(err, ErrNotFound) {
        fmt.Println("Item not found") // Output: Item not found
    }

    var target *os.PathError // Assuming import "os"
    if errors.As(err, &target) {
        // Would work if wrapped error is PathError
    }
}

Wait, in this example, it's not PathError, but shows As usage.

Import "os" for PathError.

But to keep simple, the Is works.

Key points:

Chainable with %w in fmt.Errorf.
Type-safe checks with As.
Reduces brittle string comparisons.

See errors package docs for unwrap details.

Speed Up Tests with Parallel Execution

In testing, t.Parallel() lets tests run concurrently, cutting down suite time on multi-core machines.

Mark independent tests to run in parallel, while setup can stay serial.

Example: Two tests that can run together.

Complete code (save as example_test.go):

package main

import (
    "testing"
    "time"
)

func TestSlowOne(t *testing.T) {
    t.Parallel()
    time.Sleep(1 * time.Second)
    // Assert something
}

func TestSlowTwo(t *testing.T) {
    t.Parallel()
    time.Sleep(1 * time.Second)
    // Assert something
}

func TestMain(m *testing.M) {
    // Run tests
    m.Run()
}

Run with go test -v. Without parallel, ~2s; with, ~1s.

Key points:

Boosts CI/CD speed for large suites.
Safe for independent tests; avoid shared state.
Use with -parallel flag for control.

Embed Files Directly into Binaries

The embed package (Go 1.16+) lets you include files like templates or assets in your binary, simplifying deployment.

No need for separate assets folders in production.

Example: Embed a text file and read it.

Complete code:

package main

import (
    "embed"
    "fmt"
)

//go:embed hello.txt
var content embed.FS

func main() {
    data, err := content.ReadFile("hello.txt")
    if err != nil {
        panic(err)
    }
    fmt.Println(string(data)) // Output: assuming hello.txt contains "Hello, Embedded!"
}

Create hello.txt with "Hello, Embedded!".

Build and run; file is inside binary.

You can embed directories too.

Key points:

Single-file deploys for CLIs or servers.
Read-only access via embed.FS.
Works with http.FileServer.

Check embed package docs for patterns.

Achieve Lock-Free Updates with Atomic Operations

The sync/atomic package provides functions for atomic reads/writes, avoiding mutexes for simple concurrent updates.

Useful for counters or flags in high-concurrency scenarios.

Example: Atomic counter in goroutines.

Complete code:

package main

import (
    "fmt"
    "sync"
    "sync/atomic"
)

func main() {
    var counter int64
    var wg sync.WaitGroup

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            atomic.AddInt64(&counter, 1)
            wg.Done()
        }()
    }

    wg.Wait()
    fmt.Println(counter) // Output: 1000
}

Without atomic, race conditions possible.

Key points:

Faster than mutexes for primitives.
Operations like Load, Store, CompareAndSwap.
Detect races with -race flag.

Tailor JSON Handling with Custom Marshaling

Implement json.Marshaler/Unmarshaler for custom JSON logic, like formatting dates or validating fields.

This keeps structs clean while handling edge cases.

Example: Custom time format.

Complete code:

package main

import (
    "encoding/json"
    "fmt"
    "time"
)

type CustomTime struct {
    time.Time
}

func (ct CustomTime) MarshalJSON() ([]byte, error) {
    return json.Marshal(ct.Format("2006-01-02"))
}

type Event struct {
    When CustomTime `json:"when"`
}

func main() {
    e := Event{When: CustomTime{time.Now()}}
    data, _ := json.Marshal(e)
    fmt.Println(string(data)) // Output: {"when":"2025-09-27"} (approx, based on date)
}

This overrides default time format.

Key points:

Flexible serialization without extracode.
Pairs with struct tags for field names.
Use for enums or computed fields.

Incorporating these features into your daily Go work can lead to more efficient codebases and quicker iterations. Start with one or two in your next project—build constraints for multi-platform tweaks or sync.Pool for performance hotspots—and measure the impact. Over time, they'll become go-to tools in your toolkit, helping you focus on logic rather than boilerplate.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Gatsby or Astro: Picking the Right Tool for Content-Heavy Websites

Shrijith Venkatramana — Wed, 24 Sep 2025 17:57:31 +0000

When building websites focused on content like blogs,documentation sites, or portfolios, Gatsby and Astro stand out as popular choices. Both frameworks help developers create fast, modern sites, but they differ in architecture, performance, and flexibility. This post breaks down their key aspects to help you decide which fits your project.

Inside Gatsby: Static Sites with React Power

Gatsby is a static site generator built on React. It pulls in data from various sources during build time and generates HTML files. This means your site loads quickly since everything is pre-rendered.

Key features include:

GraphQL for data querying: Gatsby uses GraphQL to fetch content from Markdown, APIs, or CMS like Contentful.
Plugin ecosystem: Thousands of plugins for SEO, image optimization, and more.
React components: Build dynamic UIs while keeping the site static.

For a simple blog setup in Gatsby, start by installing it globally:

npm install -g gatsby-cli
gatsby new my-gatsby-blog https://github.com/gatsbyjs/gatsby-starter-blog
cd my-gatsby-blog
gatsby develop
# Output: Server starts at http://localhost:8000

In src/pages/index.js, you can query posts:

import React from "react"
import { graphql } from "gatsby"

export default function Home({ data }) {
  return (
    <div>
      <h1>Blog Posts</h1>
      {data.allMarkdownRemark.nodes.map(node => (
        <div key={node.id}>
          <h2>{node.frontmatter.title}</h2>
          <p>{node.excerpt}</p>
        </div>
      ))}
    </div>
  )
}

export const query = graphql`
  query {
    allMarkdownRemark {
      nodes {
        id
        frontmatter {
          title
        }
        excerpt
      }
    }
  }
`
# Output: Renders a list of blog posts from Markdown files in content/blog

Gatsby handles routing automatically and optimizes images via plugins like gatsby-image. Check the official docs for more on data sourcing: Gatsby Data Layer.

Astro's Core: Islands of Interactivity

Astro focuses on shipping less JavaScript by default. It renders pages to HTML at build time but allows "islands" of interactive components from frameworks like React or Vue.

Standout points:

Framework-agnostic: Mix components from different libraries without lock-in.
Partial hydration: Only hydrate interactive parts, keeping the rest static.
Content collections: Built-in support for Markdown and MDX with schema validation.

To set up a basic Astro site:

npm create astro@latest my-astro-blog --template blog
cd my-astro-blog
npm run dev
# Output: Server runs at http://localhost:4321

For displaying content, use collections in src/content/config.ts:

import { z, defineCollection } from 'astro:content';

const blogCollection = defineCollection({
  schema: z.object({
    title: z.string(),
    date: z.date(),
  }),
});

export const collections = {
  blog: blogCollection,
};
# Output: Defines schema for blog posts in src/content/blog

Then, in src/pages/index.astro:

---
import { getCollection } from 'astro:content';

const posts = await getCollection('blog');
---
<html lang="en">
  <head>
    <title>Blog</title>
  </head>
  <body>
    <h1>Posts</h1>
    <ul>
      {posts.map(post => (
        <li>
          <a href={`/blog/${post.slug}`}>{post.data.title}</a>
        </li>
      ))}
    </ul>
  </body>
</html>
# Output: Generates a static index page listing blog posts

Astro's syntax mixes HTML with JavaScript expressions. For deeper dives, see Astro Content Collections.

Speed and Performance: Where They Differ

Performance is crucial for content sites with images and text. Gatsby pre-builds everything, leading to fast initial loads but longer build times for large sites. Astro often builds faster since it avoids bundling unused JS.

In benchmarks, Astro sites can load 20-50% faster due to minimal client-side code. Gatsby shines with its image processing, reducing file sizes automatically.

Here's a quick comparison table:

Aspect	Gatsby	Astro
Build Time	Supports Incremental Builds	No real incremental builds
Render Time	Slower for big sites (full React bundle)	Faster, selective rendering
Page Load Speed	Excellent with pre-rendering	Superior with zero-JS default
Bundle Size	Larger if interactive	Smaller, islands only

Test your own site with tools like Lighthouse. For Gatsby optimizations, refer to Gatsby Performance Guide.

Managing Content Sources Effectively

Both handle content from Markdown, but Gatsby integrates deeply with CMS via plugins. Astro uses file-based routing and collections for simplicity.

In Gatsby, connect to a headless CMS like Sanity:

Install plugin: npm install gatsby-source-sanity

Add to gatsby-config.js:

module.exports = {
  plugins: [
    {
      resolve: `gatsby-source-sanity`,
      options: {
        projectId: 'your-project-id',
        dataset: 'production',
      },
    },
  ],
}
// Output: Pulls Sanity data into GraphQL layer for querying

Query in pages as before.

Astro fetches external data at build time or via endpoints. For Markdown, it's native—no plugins needed.

Bold tip: If your site grows to hundreds of pages, Astro's content collections prevent schema errors early.

Setup and Daily Workflow Comparison

Gatsby requires Node.js and familiarity with React. Setup involves configuring plugins in gatsby-config.js.

Astro's CLI is straightforward, with less boilerplate. You edit .astro files directly, which feels like enhanced HTML.

Developer pain points:

Gatsby: Debugging GraphQL can be tricky for beginners.
Astro: Learning islands if you need interactivity.

Both support hot module replacement for fast dev servers. Astro often feels lighter for quick iterations.

Built-in SEO and Accessibility Tools

SEO is baked into both. Gatsby generates sitemaps and meta tags via plugins like gatsby-plugin-sitemap.

Astro handles SEO with frontmatter in pages:

---
title: 'My Post'
description: 'A description here'
---

Key difference: Gatsby's React base makes dynamic meta tags easier for personalized content.

For accessibility, both encourage semantic HTML, but Astro's static focus reduces JS-related issues.

Explore Astro's SEO features: Astro SEO Guide.

Ecosystem Strength: Plugins and Community

Gatsby boasts over 2,500 plugins, covering themes to e-commerce. Its community is mature, with many starters.

Astro's ecosystem is growing fast, with integrations for major frameworks. It has fewer plugins but emphasizes composability.

If you're in the React world, Gatsby feels like home. Astro appeals for multi-framework projects.

Community forums: Gatsby has active Slack; Astro uses Discord.

Making the Choice Based on Your Needs

Consider your project's scale. For highly interactive content sites with heavy data integration, Gatsby provides robust tools through its GraphQL layer and plugins—ideal if you're already using React.

Opt for Astro if you prioritize speed and minimal JS, especially for mostly static conTent with spots of interactivity. It's great for migrating from older static generators or starting fresh with flexibility.

Test both with a prototype: Spin up a small blog in each and measure build times, load speeds, and ease of adding features. Your team's skills matter too—React devs lean Gatsby, while HTML/JS purists prefer Astro.

Ultimately, both deliver excellent content-driven sites, so align with your performance goals and workflow preferences.

*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

git-lrc-intro-60s.mp4

Why

🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
🔁 Build a…

View on GitHub

Unpacking Git's Branching: A Look at the Internals

Shrijith Venkatramana — Tue, 23 Sep 2025 19:43:26 +0000

Git branching lets developers work on features or fixes without disrupting the main codebase. At its core, branches are lightweight pointers to commits, making them efficient for managing parallel development. This article breaks down how branching operates inside Git, with examples to show the mechanics in action.

Branches as Simple Pointers

In Git, a branch isn't a full copy of the code—it's a reference to a specific commit. Stored in the .git/refs/heads/ directory, each branch file contains the SHA-1 hash of the commit it points to. This design keeps branching fast and cheap.

Key point: Branches move forward with new commits, updating their reference automatically.

For example, start with a fresh repository:

# Initialize a new Git repository
git init my-repo
cd my-repo

# Create and commit a file
echo "Initial content" > file.txt
git add file.txt
git commit -m "Initial commit"
# Output: [master (root-commit) abc123] Initial commit

# Check the branch reference
cat .git/refs/heads/master
# Output: abc1234567890abcdef1234567890abcdef1234 (example SHA)

Here, master points to the commit hash. Adding another commit shifts this pointer.

Git documentation on branches: git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

HEAD: Git's Current Position Marker

HEAD is a special reference that tracks where you are in the repository. It usually points to a branch, like refs/heads/main, but can detach to point directly at a commit. This controls what git status and commits affect.

Key point: When HEAD points to a branch, commits update that branch's pointer.

View HEAD in action:

# After initial setup from previous example
git checkout -b feature
# Output: Switched to a new branch 'feature'

# Inspect HEAD
cat .git/HEAD
# Output: ref: refs/heads/feature

# Commit something new
echo "Feature addition" >> file.txt
git add file.txt
git commit -m "Add feature"
# Output: [feature def456] Add feature

HEAD now references the feature branch, which points to the new commit.

Creating Branches: Instant and Low-Cost

Git creates a branch by writing a new file in .git/refs/heads/ with the current commit's hash. No files are copied—it's just a 41-byte file (40 for the hash plus a newline).

Key point: Branches start from the current HEAD, inheriting the commit history.

Try creating one:

# Continuing from previous
git branch bugfix
# No output, but creates the branch

# List branches
git branch
# Output:
#   bugfix
# * feature
#   master

# Check the new branch reference
cat .git/refs/heads/bugfix
# Output: def4567890abcdef1234567890abcdef1234567 (matches feature's current commit)

This shows bugfix points to the same commit as feature at creation time.

Switching Branches with Checkout

Checkout updates the working directory to match the target branch's commit. Git swaps files in the index and worktree, using the tree-ish (commit) the branch references.

Key point: If conflicts arise, Git aborts; otherwise, HEAD updates to the new branch.

Example of switching:

# From feature branch
echo "Bug fix content" > bug.txt
git add bug.txt
git commit -m "Fix bug on bugfix"  # But wait, we're on feature—switch first

git checkout bugfix
# Output: Switched to branch 'bugfix'

# Now commit on bugfix
echo "Bug fix content" > bug.txt
git add bug.txt
git commit -m "Fix bug"
# Output: [bugfix ghi789] Fix bug

# Switch back
git checkout feature
# Output: Switched to branch 'feature'
# Note: bug.txt is gone from worktree

The worktree reflects the branch's state after checkout.

Merging: Combining Branch Histories

Merging integrates changes from one branch into another. Git finds the common ancestor and applies differences. Fast-forward merges just move the pointer if no divergence; otherwise, it creates a merge commit.

Merge Type	Description	When It Happens
Fast-Forward	Moves target branch to source commit	No new commits on target
Three-Way Merge	Creates new commit with two parents	Divergent histories

Key point: Use --no-ff to force a merge commit even for fast-forwards.

Merge example:

# From previous setup, on master (assuming initial commit)
git checkout master
# Output: Switched to branch 'master'

git merge feature
# Output: Fast-forward (if no divergence)
# Or: Merge made by the 'recursive' strategy. (if three-way)

# For three-way, assume divergence
# First, commit on master
echo "Master update" >> file.txt
git add file.txt
git commit -m "Update on master"
# Output: [master jkl012] Update on master

# Now merge
git merge bugfix
# Output: Auto-merging file.txt (if conflicts, resolve manually)
# Merge commit created if successful

After merge, the target branch includes the source's changes.

Git merge internals: git-scm.com/docs/git-merge

Rebasing: Linearizing Branch Commits

Rebasing replays commits from one branch onto another, rewriting history for a cleaner timeline. It moves the branch base, potentially causing conflicts per commit.

Key point: Avoid rebasing shared branches to prevent history mismatches for collaborators.

Rebase demo:

# Setup: Assume feature diverged from master
git checkout feature
# Output: Switched to branch 'feature'

git rebase master
# Output: Successfully rebased and updated refs/heads/feature.
# Or: Conflicts if changes overlap—resolve and git rebase --continue

# Before rebase, log might show:
git log --oneline --graph
# Output:
# * def456 (feature) Add feature
# * abc123 (master) Initial commit

# After, feature commits sit atop master's latest

This keeps history linear but changes commit hashes.

Detached HEAD: Working Without a Branch

In detached HEAD, HEAD points directly to a commit, not a branch. Commits here aren't referenced by any branch unless you create one.

Key point: Use this for temporary experiments; lost commits can be recovered via reflog if needed.

Example:

# Detach to a commit
git checkout abc123  # Initial commit hash
# Output: Note: switching to 'abc123'.
# You are in 'detached HEAD' state.

# Commit in detached state
echo "Experimental change" >> file.txt
git add file.txt
git commit -m "Experiment"
# Output: [detached HEAD mno345] Experiment

# To save, create branch
git checkout -b experiment
# Output: Switched to a new branch 'experiment'

# Check log
git log --oneline
# Output:
# mno345 (HEAD -> experiment) Experiment
# abc123 Initial commit

Without branching, the commit risks garbage collection.

Remote Branches: Tracking Upstream Changes

Remote branches are read-only references to branches in remote repositories, prefixed like origin/main. They update on fetch; local branches track them for push/pull.

Key point: Set upstream with git branch --set-upstream-to for easier operations.

Remote example:

# Add a remote (assume a cloned repo for simplicity)
# In a new repo:
git remote add origin https://github.com/user/repo.git

# Fetch remotes
git fetch origin
# Output: Fetching updates remote refs

# List remote branches
git branch -r
# Output:
#   origin/master
#   origin/feature

# Track a remote branch locally
git checkout -b local-feature origin/feature
# Output: Branch 'local-feature' set up to track remote branch 'feature' from 'origin'.
# Switched to a new branch 'local-feature'

This syncs local work with remote states.

Understanding these internals helps debug issues like merge conflicts or lost commits. Experiment in a test repo to see how pointers shift—tools like git log --graph visualize the structure. For deeper dives, explore Git's object database where commits and trees store the actual data.




 [![git-lrc](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yzvpkxm9mga1pweneahx.png)](https://github.com/HexmosTech/git-lrc) 
 *AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production. 

 git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.* 


 Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use. 

 ⭐ Star it on GitHub: 
 
  
    
      
      
        HexmosTech
       / 
        git-lrc
      
    
    
      Free, Unlimited AI Code Reviews That Run on Commit
    
  
  
    


| 🇩🇰 Dansk | 🇪🇸 Español | 🇮🇷 Farsi | 🇫🇮 Suomi | 🇯🇵 日本語 | 🇳🇴 Norsk | 🇵🇹 Português | 🇷🇺 Русский | 🇦🇱 Shqip | 🇨🇳 中文 |








git-lrc



Free, Unlimited AI Code Reviews That Run on Commit





 




     













AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.


See It In Action



See git-lrc catch serious security issues such as leaked credentials, expensive cloud
operations, and sensitive material in log statements



  
    
    

    git-lrc-intro-60s.mp4
    
  

  

  



Why






🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.

🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.

🔁 Build a…





  


  View on GitHub

Building a Row Echelon Form Checker in Python and Go with Tests

Shrijith Venkatramana — Mon, 22 Sep 2025 17:36:11 +0000

Row echelon form is a key concept in linear algebra for simplifying matrices during operations like Gaussian elimination. This post walks through creating a checker function to verify if a matrix is in row echelon form, following specific rules. We'll implement it in Python and Go, add test cases, and explore details with examples. The checker focuses on two main rules: all-zero rows must be at the bottom, and pivot positions must shift rightward in successive rows.

Understanding Row Echelon Form Basics

Row echelon form (REF) structures a matrix so each row starts with zeros followed by a non-zero pivot (if present), and pivots are staggered. This form helps in solving systems of equations by making back-substitution straightforward.

A matrix in REF looks like this:

[ 1, 2, 3 ]
[ 0, 1, 4 ]
[ 0, 0, 1 ]

Here, pivots are in columns 1, 2, and 3. Not all REF matrices have pivots starting at 1; they can be any non-zero value, but often normalized to 1 in reduced REF (which we're not enforcing here).

For more on the formal definition, check the Wikipedia page on Row Echelon Form.

Key Rules for Our REF Checker

Our checker enforces these rules:

All-zero rows at the bottom: Any row with all zeros must appear after all non-zero rows.
Rightward pivot progression: The first non-zero element (pivot) in each row must be to the right of the pivot in the row above it.

We ignore whether pivots are 1 or if entries above pivots are zero—that's for reduced REF. Our focus is strict REF.

Consider this invalid example due to a misplaced all-zero row:

Row	Elements
1	[0, 0, 0]
2	[0, 1, 2]
3	[0, 0, 3]

This fails the first rule. A valid version would move all-zero to bottom and then swap rows 1 and 2.

Implementing the Checker in Python

In Python, represent matrices as lists of lists. The function iterates through rows, tracks the last pivot column, and checks for all-zero rows out of place.

Here's the complete function:

def is_row_echelon_form(matrix):
    if not matrix or not matrix[0]:
        return True  # Empty matrix is trivially in REF

    rows = len(matrix)
    cols = len(matrix[0])

    # Ensure all rows have same number of columns
    for row in matrix:
        if len(row) != cols:
            return False

    last_pivot_col = -1
    seen_zero_row = False

    for i in range(rows):
        # Find the pivot position in this row
        pivot_col = -1
        for j in range(cols):
            if matrix[i][j] != 0:
                pivot_col = j
                break

        if pivot_col == -1:  # All-zero row
            seen_zero_row = True
            continue  # All-zero rows are okay if at bottom, checked later implicitly

        if seen_zero_row:
            return False  # Non-zero row after zero row

        if pivot_col <= last_pivot_col:
            return False  # Pivot not to the right

        last_pivot_col = pivot_col

    return True

# Example usage:
# matrix = [[1, 2, 3], [0, 1, 4], [0, 0, 1]]
# print(is_row_echelon_form(matrix))  # Output: True

This code handles empty matrices and ensures uniform row lengths. It tracks last_pivot_col to enforce the pivot rule and seen_zero_row for zero placement.

Testing the Python Implementation

Test cases cover valid REF, invalid pivot positions, misplaced zeros, and edge cases like single-row or empty matrices.

Use Python's unittest for structured tests. Here's a complete test script:

import unittest

class TestRowEchelonForm(unittest.TestCase):
    def test_valid_ref(self):
        matrix = [[1, 2, 3], [0, 1, 4], [0, 0, 1]]
        self.assertTrue(is_row_echelon_form(matrix))

    def test_invalid_pivot_position(self):
        matrix = [[1, 2, 3], [1, 1, 4], [0, 0, 1]]  # Second row pivot not rightward
        self.assertFalse(is_row_echelon_form(matrix))

    def test_misplaced_zero_row(self):
        matrix = [[0, 0, 0], [0, 1, 2], [0, 0, 3]]
        self.assertFalse(is_row_echelon_form(matrix))

    def test_all_zero_rows(self):
        matrix = [[0, 0], [0, 0]]
        self.assertTrue(is_row_echelon_form(matrix))

    def test_empty_matrix(self):
        matrix = []
        self.assertTrue(is_row_echelon_form(matrix))

    def test_single_row(self):
        matrix = [[1, 2, 3]]
        self.assertTrue(is_row_echelon_form(matrix))

    def test_uneven_rows(self):
        matrix = [[1, 2], [0, 1, 3]]  # Uneven lengths
        self.assertFalse(is_row_echelon_form(matrix))

if __name__ == '__main__':
    unittest.main()

# When run, all tests should pass except the invalid ones, which correctly fail.

These tests ensure the function behaves as expected. Run this script to verify—expect 7 tests, with no failures if implemented correctly.

For Python testing docs, see unittest in Python docs.

Porting the Checker to Go

Go uses slices of slices for matrices. The logic mirrors Python but with Go's type system and error handling for uneven rows.

Here's the full function in a main package:

package main

import "fmt"

func isRowEchelonForm(matrix [][]int) bool {
    if len(matrix) == 0 || len(matrix[0]) == 0 {
        return true // Empty matrix is in REF
    }

    rows := len(matrix)
    cols := len(matrix[0])

    // Check all rows have same columns
    for _, row := range matrix {
        if len(row) != cols {
            return false
        }
    }

    lastPivotCol := -1
    seenZeroRow := false

    for i := 0; i < rows; i++ {
        // Find pivot column
        pivotCol := -1
        for j := 0; j < cols; j++ {
            if matrix[i][j] != 0 {
                pivotCol = j
                break
            }
        }

        if pivotCol == -1 { // All-zero row
            seenZeroRow = true
            continue
        }

        if seenZeroRow {
            return false // Non-zero after zero
        }

        if pivotCol <= lastPivotCol {
            return false // Not rightward
        }

        lastPivotCol = pivotCol
    }

    return true
}

func main() {
    matrix := [][]int{{1, 2, 3}, {0, 1, 4}, {0, 0, 1}}
    fmt.Println(isRowEchelonForm(matrix)) // Output: true
}

This version uses integers for simplicity; adjust to floats if needed for real matrices. Compile and run with go run main.go.

Testing the Go Implementation

Go's testing package handles tests. We'll mirror Python's cases.

Create a main_test.go file:

package main

import "testing"

func TestIsRowEchelonForm(t *testing.T) {
    tests := []struct {
        name    string
        matrix  [][]int
        want    bool
    }{
        {"valid_ref", [][]int{{1, 2, 3}, {0, 1, 4}, {0, 0, 1}}, true},
        {"invalid_pivot", [][]int{{1, 2, 3}, {1, 1, 4}, {0, 0, 1}}, false},
        {"misplaced_zero", [][]int{{0, 0, 0}, {0, 1, 2}, {0, 0, 3}}, false},
        {"all_zeros", [][]int{{0, 0}, {0, 0}}, true},
        {"empty", [][]int{}, true},
        {"single_row", [][]int{{1, 2, 3}}, true},
        {"uneven_rows", [][]int{{1, 2}, {0, 1, 3}}, false},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            if got := isRowEchelonForm(tt.matrix); got != tt.want {
                t.Errorf("isRowEchelonForm() = %v, want %v", got, tt.want)
            }
        })
    }
}

// Run with 'go test' - expect all tests to pass.

This table-driven test approach makes adding cases easy. Use go test to execute—look for "ok" output.

See Go's testing package in the official docs.

Comparing Python and Go Approaches

Python's dynamic typing simplifies matrix handling, but Go requires explicit checks for slice lengths. Both use similar loops, but Go's performance shines for large matrices due to compilation.

Aspect	Python	Go
Matrix Rep	List of lists	Slice of slices
Type Handling	Flexible (int/float)	Fixed (int here; use float64)
Error Check	Runtime length check	Runtime length check
Testing	unittest class-based	Table-driven with t.Run

Python feels quicker for prototyping, while Go suits production with stricter types.

Handling Edge Cases in Both Languages

Edge cases include non-square matrices, like [1,0],[0,0],[0,0] or [0,1],[1,0].

In code, our implementations handle these: non-square works as long as rows uniform. For floats, modify comparisons (e.g., use epsilon for zero).

Test addition: A matrix with leading zeros in rows but correct pivots, like [[0,1,2],[0,0,3]]—valid, pivot cols 1 and 2.

Both languages' codes pass this without changes. For large matrices, consider efficiency; our O(rows * cols) is fine for most uses.

Building this checker reinforces linear algebra basics and cross-language skills. Adapt it for reduced REF by adding checks for pivot=1 and upper zeros. Test thoroughly in your projects to catch matrix issues early.