DEV Community: Shrijith Venkatramana

Understanding AI Code Fast: A 60-Second Habit for Institutional Memory

Shrijith Venkatramana — Thu, 21 May 2026 09:45:03 +0000

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

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

Introduction

We are all participating in the agent era. New methodologies, ideas, experiments, and approaches are being discovered by engineers, professionals, and enthusiasts all over the world.

So many new things are happening in AI, and I am particularly interested in software engineering and its future, not the way it exists today, but the way it is evolving.

This article explores that question through the lens of Understanding AI Code Fast: A 60-Second Habit for Institutional Memory.

Many people think the details do not matter. Many others think they do. There is a lot of debate around this, so I want to present my perspective and a few approaches that teams may be able to adopt and benefit from.

Do We Need to Read AI-Generated Code?

The foundational question is simple: does one need to read AI-generated code or not?

Right now, many people claim that you may not need to read it at all. A common comparison is assembly language: once C arrived, most developers no longer needed to read assembly for everyday work.

But that comparison is tricky. We prompt LLM agents, and LLM agents produce code. Yet from the code alone, I cannot derive the prompts that generated it.

I may use a one-line prompt or a ten-line prompt, and they may generate different things. The same model may also generate different things across different invocations.

Production Systems and Responsibility

For anything that has a running production version and many users depending on it, uptime matters.

It could be school software, marketing software, ERP software, or anything else. That makes this a serious question: what happens if something is wrong, who takes responsibility, and how do we recover?

Agents may help us solve these issues as well, but what if the issue is slightly bigger?

What if the agent makes a wrong architectural decision?

What if it uses a reward hacking mechanism to solve the issue rather than solving it correctly?

What if a shallow approach was taken to implement a new feature?

Those questions naturally follow.

The Two Failure Modes of AI-Assisted Programming

In my opinion, there are two major failure modes here, and I call them the common traps of absolutes in AI-assisted programming.

Before getting into the details, it is worth mentioning something from Sunny Mishra.

In a public post, he proposed an interesting idea. He has been an engineering manager for nearly a decade.

Why not have a bot that checks engineers' Git commits, creates daily and weekly reports, identifies where help is needed, and provides automatic updates?

In other words, get an agent to read all this information and report it back to the team.

The loop being proposed looks like this:

Prompt → Code → Summary → Back to the team.

I call this an awareness loop.

He recognized that large amounts of code are being generated and many things are happening very quickly, so people need help understanding how things are getting implemented.

Awareness is required.

He did not say, “Read every line.” He said awareness is required.

Reading Every Line vs Reading Nothing

My view is that reading every line of code is no longer necessary in many situations because LLMs are genuinely good at many things.

They are trustworthy for a large number of products that we typically deal with, and that is great.

Suppose there is some UI code. Why should I check every detail if a button click simply triggers a modal? The agent can handle that. The same applies to tasks like configuring logs.

As long as the prompt is written properly, the agent can do many of these tasks effectively.

So I do not think reading everything is required anymore.

But there are also people arguing the opposite extreme: “Do not read anything.” Stay entirely at the abstraction layer. Never go down into the implementation details.

I think that is also dangerous.

The Amazon “Dive Deep” Principle

This is where an Amazon principle is useful.

Amazon is famous for its leadership principles, and one of them is Dive Deep.

At Amazon, leadership principles apply to everyone, from a new joiner to a senior executive.

The principle says:

Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdotes differ. No task is beneath them.

You could be a VP managing hundreds of people, and you are still expected to understand what is happening underneath.

You may operate at a high abstraction layer most of the time, but you still go down regularly, audit systems, inspect details, and remain skeptical.

I believe this principle exists because polished dashboards are often insufficient.

Right now, with tools like Claude Code, people are generating HTML reports and summaries automatically.

But is the report sufficient? What is happening underneath? Should we not check occasionally and develop some intuitive understanding of the systems we depend on?

Awareness Culture vs Slumber Culture

At the end of the day, I think organizations fall into two broad categories: an awareness culture or a slumber culture.

Do you want your people to stay alert and proactive, or do you want them to ignore the details completely?

And remember: code review is not really about code alone.

When a team performs code review, it is building institutional memory.

The team is gradually understanding how the system works. It is extremely important that at least a few people understand what a subsystem is doing.

If nobody understands how anything works, then what happens when things go wrong and the agents are not capable enough to solve the issue?

Auditing and intuitive understanding must evolve alongside agentic development.

Both should progress together.

Understanding should grow while automation also grows.

That way, responsibility can be taken, risk can be signed off, and somebody knows enough about the system to deal with failures when they occur.

And failures always occur.

Outages happen.

Customers get impacted.

Architectural mistakes happen. Security problems happen. Performance issues happen.

This is serious work.

At the end of the day, all of this understanding is about maintaining a grip on the system and, therefore, on your future.

Without that grip, your future becomes uncertain.

That is the essence of the Amazon principle: dive deep, audit frequently, and keep checking.

A dashboard may look good, but does it actually match reality underneath?

You have to verify that continuously.

Git-lrc and the 60-Second Review Habit

This brings me to a tool I am working on.

It provides a deck-style summary system called git-lrc.

When you do a Git commit, it generates a slide-style review.

It takes roughly 30 to 40 seconds to go through and inspect the code.

So after git add and git commit, this summary appears locally.

It gives a concise explanation of what is happening in the codebase, along with the actual code itself.

The code is not hidden.

The issues in the code are not hidden either.

An engineer may do this five or ten times a day, and over a month they may perform hundreds of these micro-reviews.

This allows people to stay connected to what is happening underneath the system without having to read every line manually.

git-lrc highlights what is relevant, what may be important, and what deserves attention.

It provides a very fast summary, so there is minimal time waste while still giving assurance and confidence that nothing strange is happening.

It also reduces the burden on senior engineers because reviews happen incrementally, commit by commit.

As a result, institutional memory gets built continuously.

Understanding accumulates over time.

People can vouch for their own changes more confidently.

You move quickly while still remaining relatively safe.

That is the system we are building.

We believe this roughly 60-second review habit can help reduce outages while improving institutional memory.

Closing

That is the core idea I wanted to highlight.

I recommend checking out hexmos.com/git-lrc and trying it out.

Installation instructions are available, and there is also a free version.

So give it a try.

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

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro 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

Dependent Types for Programmers: A Practical Introduction Using Lean 4

Shrijith Venkatramana — Tue, 19 May 2026 16:52:47 +0000

If you are learning Lean 4, sooner or later you encounter something like this:

Vec : Type → Nat → Type

And suddenly the tutorials start talking about:

proofs,
propositions,
type theory,
dependent types,
Curry–Howard correspondence.

For many programmers, this is where things become foggy.

The strange thing is that the underlying idea is actually very practical.

Dependent types are fundamentally about this:

making more program assumptions visible to the compiler.

This article builds the idea gradually from an ordinary programmer’s mental model.

The Normal Way We Think About Types

In most languages, we think of types like categories.

42 : Int
"hello" : String

A type tells us what kind of value something is.

For example:

List<Int>

means:

“a list of integers.”

But notice what the type does not tell us:

how many integers,
whether the list is empty,
whether it is sorted,
whether it has been validated,
whether authentication has happened,
whether certain invariants hold.

Those become:

comments,
runtime checks,
tests,
conventions,
assumptions.

The Core Idea of Dependent Types

Dependent types change one thing:

types are allowed to depend on values.

That is why they are called dependent types.

Normally:

values belong to types

With dependent types:

values can also appear inside types

That sounds abstract initially, but the examples make it much clearer.

Understanding `Vec Nat 3`

Suppose you see:

Vec Nat 3

This means:

“a vector containing exactly 3 natural numbers.”

Break it apart:

Vec → vector type constructor
Nat → element type
3 → required length

The important part is this:

the length is part of the type itself

So these are different types:

Vec Nat 3
Vec Nat 5

The compiler can distinguish them.

That is the conceptual shift.

“But C Arrays Already Have Sizes”

Good observation.

C already gets somewhat close:

int arr[3];

So what makes dependent typing different?

The difference is that the values become usable inside the type system itself.

For example:

append : Vec α n → Vec α m → Vec α (n + m)

This means:

appending a vector of size n
to a vector of size m
produces a vector of size n + m

The type system is now reasoning symbolically about values.

That is much more expressive than ordinary static typing.

Why This Matters

Most software bugs are really violations of assumptions.

Consider matrix multiplication.

You might write:

matrixMultiply(a, b)

But there is an implicit rule:

a.columns == b.rows

Normally:

you document this,
test this,
or check it at runtime.

With dependent types, you can encode the relationship structurally:

Matrix m n
Matrix n p

Now invalid multiplication does not typecheck.

The compiler understands the invariant itself.

That is the real promise of dependent typing:

move important assumptions from comments into machine-checked structure.

Non-Empty Lists

Here is another example.

In ordinary programming:

def head(xs):
    return xs[0]

Potential issue:

What if xs is empty?

Usually this becomes:

a runtime exception,
a defensive check,
or a convention.

In Lean-like systems:

head : Vec α (n + 1) → α

This says:

head only accepts non-empty vectors.

Why?

Because:

n + 1

can never be zero.

The impossible case disappears from the program structure entirely.

“But Real Programs Use Dynamic User Input”

This is one of the most common misunderstandings.

People often assume dependent typing only helps when everything is known at compile time.

But in practice, the workflow is usually:

dynamic validation
        ↓
static guarantee afterward

Suppose a user uploads some JSON.

Initially, the data may effectively have a type like:

UntrustedInput

Then validation happens.

After validation, the type changes:

AuthenticatedUser
ValidConfig
NonEmptyList
Vec Nat 3

The important idea is this:

once something has been checked, the type system remembers the fact.

That is incredibly useful.

Real-World Intuition

Many systems already rely on informal “refined” types.

For example, programmers mentally distinguish between:

raw string
validated email
escaped SQL
sanitized HTML
authenticated user

But in many languages, all of them are still just:

String

Dependent typing allows those distinctions to become explicit and enforceable.

What Lean Is Really Exploring

Lean is often presented as:

a theorem prover,
a mathematical tool,
or a proof assistant.

But from a programmer’s perspective, a more useful framing is:

Lean explores what happens when program invariants become part of the language itself.

Not:

comments + conventions + hope

but:

proof + enforcement

That is the deeper shift.

Final Thoughts

When programmers first encounter dependent types, the syntax can look intimidating:

Vec : Type → Nat → Type

But the underlying idea is surprisingly concrete.

Dependent types are about expressing richer facts directly in the type system:

sizes,
protocol states,
validation status,
permissions,
invariants,
safety guarantees.

And once those facts become part of the type system, entire classes of bugs become much harder to represent.

That is why languages like Lean are interesting even beyond theorem proving.

They are exploring a different model of software correctness itself.

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

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro 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

From Logic to Code: Understanding the Curry–Howard Correspondence in Lean

Shrijith Venkatramana — Mon, 18 May 2026 18:38:04 +0000

For many programmers, precise mathematical logic and general programming feel like different worlds.

Logic is about proving theorems.
Programming is about making systems behave correctly.
Proofs belong to mathematicians.
Functions belong to engineers.

But in systems like Lean, those boundaries start collapsing.

One of the deepest ideas behind this is the Curry–Howard correspondence -- the observation that:

logical propositions correspond to types
proofs correspond to programs
proof checking corresponds to type checking

At first, this sounds abstract, philosophical, or even like category theory mysticism.

But once you see it expressed concretely in Lean, it becomes quite mechanical.

This article walks through that transition step by step:

from logic,
to functions,
to proof goals,
to types carrying specifications,
to a sorting function that literally contains its own correctness proof.

The Core Idea: Propositions Behave Like Types

Let us start with a tiny logical statement:

P ∧ Q → P

Read logically, this means:

“If P and Q are both true, then P is true.”

Very obvious.

Now let us reinterpret it computationally.

Logical Interpretation

To prove:

P ∧ Q

you must provide:

a proof of P
and a proof of Q

That structure is identical to a pair:

(p, q)

Similarly, to prove:

P → Q

you must provide:

a method that transforms evidence of P
into evidence of Q

That is exactly what a function does.

So under Curry–Howard:

Logic	Programming
proposition	type
proof	value/program
implication	function
conjunction (`P ∧ Q`)	pair
proof checking	type checking

This is not metaphorical in Lean.

It is literal.

A Tiny Theorem Is Also a Program

Here is a theorem in Lean:

theorem fst : P ∧ Q → P := by
  intro h
  exact h.left

Let us read this slowly.

The Goal

Initially Lean shows:

⊢ P ∧ Q → P

Everything after ⊢ is the current proof goal.

You can think of it as:

“Construct something of this type.”

Step 1: `intro h`

intro h

This assumes:

h : P ∧ Q

and changes the goal to:

⊢ P

So now we have evidence that:

P is true
Q is true

bundled inside h.

Step 2: Extract the Left Side

exact h.left

This extracts the proof of P.

Done.

Now look at the exact same theorem computationally.

The theorem is equivalent to:

fun h => h.left

This is just:

take a pair
return the first element

The same object is simultaneously:

a proof,
and a program.

That is Curry–Howard.

Lean Proof Goals Are Requests for Evidence

A useful way to think about Lean is:

Lean is constantly asking you for evidence.

Suppose Lean shows:

⊢ Sorted ys

This is not a boolean check.

Lean is not asking:

“Is this true?”

It is asking:

“Can you construct evidence that this is true?”

That distinction matters enormously.

In ordinary programming:

correctness is often informal,
hidden in comments,
or validated through testing.

In Lean:

correctness becomes part of the type system itself.

Types Can Express Specifications, Not Just Data Shapes

Most programmers are used to types like:

sort : List Nat -> List Nat

This only says:

input: list
output: list

Nothing about correctness.

The function could:

reverse the list,
shuffle the list,
return garbage,
or always return [].

The type would still accept it.

Now look at this:

sort :
  (xs : List Nat) ->
  { ys : List Nat //
      Sorted ys ∧ Permutation xs ys }

This changes everything.

The function is now required to produce:

an output list ys
a proof that ys is sorted
a proof that ys contains exactly the same elements as xs

The type stopped describing shape and started describing truth.

“Sorted” Becomes a Logical Object

But where does Sorted come from?

It must itself be formally defined.

Here is a simplified version:

inductive Sorted : List Nat -> Prop
| nil :
    Sorted []

| single (x : Nat) :
    Sorted [x]

| cons (x y : Nat) (xs : List Nat) :
    x ≤ y ->
    Sorted (y :: xs) ->
    Sorted (x :: y :: xs)

This says:

empty lists are sorted
single-element lists are sorted
larger lists are sorted if:
- the first element is ≤ the second
- and the tail is sorted

Now suppose your implementation returns:

[1,2,3]

Lean must construct evidence for:

Sorted [1,2,3]

That proof is itself a structured object.

Roughly:

1 ≤ 2
2 ≤ 3
tail sorted

all recursively assembled together.

What Happens When the Function Is Wrong?

Suppose the implementation returns:

[3,1,2]

Lean now tries to construct:

Sorted [3,1,2]

But according to the definition of Sorted, this eventually requires:

proof(3 ≤ 1)

Impossible.

So the program is rejected.

Notice what happened here.

We did not:

run tests,
inspect runtime output,
fuzz inputs,
or hope for good behavior.

Instead:

the implementation failed to inhabit the required type.

The proof could not be constructed.

So the program was invalid.

The Deep Shift: Correctness Became Construction

This is the conceptual leap Curry–Howard enabled.

Traditionally:

programs were operational artifacts,
proofs were human reasoning artifacts.

Curry–Howard showed they share the same structure.

That insight led to:

proof assistants,
dependently typed programming,
formally verified kernels,
verified compilers,
machine-checked mathematics,
cryptographic verification systems.

The key shift is this:

A proof is not merely an argument.

It is a concrete computational object.

And in Lean:

writing a program
and proving it correct

can become the same act.

Closing Thoughts

When people first hear:

“propositions are types”

“proofs are programs”

it often sounds like abstract mathematical poetry.

But Lean makes the idea concrete.

A theorem becomes a type.
A proof becomes a value.
A function becomes logical implication.
And type checking becomes proof verification.

The result is a system where correctness is not merely documented or tested after the fact.

It becomes part of what the program is.

That is the real significance of the Curry–Howard correspondence:

not philosophy for its own sake,
but a bridge between logic and executable systems.

And once you see it inside Lean, it becomes difficult to unsee.

Designing Reliable Permission Models with Lean 4

Shrijith Venkatramana — Sun, 17 May 2026 18:15:22 +0000

Most authorization systems begin simple.

Then reality happens.

Over time:

more roles get added,
exceptions accumulate,
workflows become stateful,
permissions become inherited,
AI assistants start generating handlers and refactors,
and eventually nobody is fully certain what combinations are actually possible anymore.

This is where many discussions around “AI-generated code safety” become unsatisfying.

People often talk about:

better prompts,
more tests,
stronger reviews,
static analysis,
or safer languages.

Those help.

But there is another direction worth exploring:

What if some critical invariants were not merely tested, but mathematically enforced?

Not:

“the code probably works,”
or “the tests passed,”

but:

“certain invalid states are mechanically impossible.”

That is the interesting promise behind Lean.

And permission systems are one of the best places to start because:

humans understand them intuitively,
they are security-critical,
and they become surprisingly difficult to reason about once complexity grows.

This tutorial walks through:

installing Lean 4,
understanding the core mathematical ideas,
building a permission model,
proving security invariants,
intentionally breaking them,
and seeing how Lean prevents unsafe changes.

The goal is not academic theorem proving.

The goal is:

designing systems where important security assumptions become hard to accidentally violate.

1. Installing Lean 4

Lean 4 is unusual because it is simultaneously:

a programming language,
a compiler,
and a theorem prover.

Install it using elan.

Linux/macOS

curl https://raw.githubusercontent.com/leanprover/elan/master/elan-init.sh -sSf | sh

Verify installation:

lean --version
lake --version

2. Install the VSCode Extension

Install:

“Lean 4”

from the VSCode marketplace.

This gives:

live proof checking,
inline errors,
theorem goals,
and interactive feedback.

This interactivity matters a lot.

Lean is less like:

writing static code,

and more like:

continuously negotiating with a mathematical verifier.

3. Create a Lean Project

Create a project with Mathlib support:

lake new VerifiedPermissions math
cd VerifiedPermissions
code .

Open:

VerifiedPermissions/Basic.lean

This file will contain both:

executable programs,
and mathematical proofs about those programs.

That duality is the central idea behind Lean.

4. First Lean Program

Replace the file contents with:

def greet (name : String) : String :=
  s!"Hello, {name}"

#eval greet "world"

Let’s unpack this carefully.

`def`

def greet

def means:

define a function or value.

This is ordinary programming.

`(name : String)`

(name : String)

This means:

the function accepts a parameter called name,
whose type is String.

Lean is statically typed.

But unlike many languages:

types in Lean are deeply connected to logic itself.

That becomes important later.

`: String`

: String

This declares:

the function returns a string.

So mathematically:

greet : String → String

Meaning:

greet maps one string into another string.

Functions in Lean are treated very mathematically.

`:=`

:=

Means:

is defined as.

`#eval`

#eval greet "world"

Actually runs the program.

This is important because Lean is not just:

a proof notation system,
or symbolic logic language.

It is executable.

5. A Small Verified Function

Now replace the file with:

def increment (x : Nat) : Nat :=
  x + 1

theorem increment_is_larger (x : Nat) :
  increment x > x := by
  exact Nat.lt_succ_self x

This is where things become interesting.

You are no longer just writing code.

You are writing:

code,
and mathematical claims about the code.

6. Understanding the Mathematics Line by Line

`Nat`

Nat

Means:

natural numbers.

So:

0, 1, 2, 3…

Lean treats mathematics as native objects.

`increment`

def increment (x : Nat) : Nat :=
  x + 1

This is an executable function.

Nothing unusual yet.

`theorem`

theorem increment_is_larger

This changes everything conceptually.

You are no longer saying:

“I hope this property holds.”

You are saying:

“This property must be proven.”

And Lean will refuse to continue unless the proof is valid.

`(x : Nat)`

The theorem applies universally.

Meaning:

For every natural number x

not:

“for tested examples,”
not “for likely inputs,”
but literally all possible values.

This is one of the biggest conceptual differences from testing.

Tests are existential:

These cases worked.

Proofs are universal:

All valid inputs satisfy this property.

`increment x > x`

increment x > x

This is the claim being proven.

Meaning:

increment always returns a larger number.

`:= by`

:= by

This begins a proof block.

You are now constructing evidence that the statement is true.

`exact`

exact Nat.lt_succ_self x

This says:

use an existing theorem directly.

Nat.lt_succ_self is a theorem already known to Lean:

x < x + 1

So Lean verifies:

your theorem,
by reducing it to already-proven mathematics.

7. Breaking the Proof Intentionally

Now change:

increment x > x

to:

increment x < x

You now claim:

increment makes numbers smaller.

Lean immediately rejects this.

This is the first important moment.

The theorem is not:

documentation,
comments,
or developer intent.

It is mechanically enforced logic.

8. Building a Permission Model

Now we move toward authorization systems.

Replace the file with:

inductive Role
| Guest
| User
| Admin

9. Understanding `inductive`

This line introduces a very important mathematical idea.

inductive Role

This defines a finite set of possible values.

Mathematically:

Role ∈ {Guest, User, Admin}

This is powerful because:

impossible states cannot exist,
invalid roles cannot appear accidentally,
and all cases must be handled explicitly.

This already improves reliability substantially.

10. Defining Permissions

Now add:

def canDelete : Role → Bool
| Role.Guest => false
| Role.User => false
| Role.Admin => true

This means:

canDelete maps a Role into a boolean

or mathematically:

Role → Bool

Meaning:

every role deterministically maps to a permission decision.

11. Why This Is Safer Than It Looks

Notice something subtle.

Lean forces all role cases to be handled.

If you later add:

| Moderator

Lean immediately complains that:

canDelete is incomplete.

This is extremely valuable operationally.

In many production systems:

new authorization states get introduced,
old logic silently becomes incomplete,
edge cases appear months later.

Lean forces exhaustive handling.

That alone prevents many categories of policy drift.

12. Adding Security Invariants

Now add:

theorem guests_cannot_delete :
  canDelete Role.Guest = false := by
  rfl

theorem users_cannot_delete :
  canDelete Role.User = false := by
  rfl

13. Understanding `rfl`

rfl

means:

this is true by direct reduction.

Lean computes:

canDelete Role.User
→ false

So the theorem becomes:

false = false

which is trivially true.

14. Introducing a Security Bug

Now simulate a future refactor.

Change:

| Role.User => false

to:

| Role.User => true

Immediately:

users_cannot_delete

fails.

This is where the practical value starts appearing.

The proof acts like:

a permanently active security assertion.

Not:

documentation,
not review guidelines,
not tribal knowledge.

An enforced invariant.

15. Why This Matters More with AI-Generated Code

The interesting part is not tiny examples like this.

The interesting part is what happens later when:

AI assistants generate handlers,
rewrite permission logic,
refactor workflows,
or modify state transitions.

The problem is no longer:

“Will the code compile?”

The problem becomes:

“Did the generated system preserve critical invariants?”

Formal models become interesting because:

implementations can change repeatedly,
while the invariants remain fixed and machine-checked.

16. What Lean Is Actually Buying

Lean does not magically create bug-free software.

What it can realistically provide is:

machine-checked invariants,
exhaustive handling of states,
prevention of silent policy drift,
stronger guarantees around transitions,
and continuous enforcement of critical assumptions.

That is a narrower claim than:

“formally verified applications.”

But it is also much more practical.

And for authorization-heavy systems, even small mechanically enforced guarantees can become surprisingly valuable over time.

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

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro 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

Rust and Zig Solve the Same Problems Very Differently

Shrijith Venkatramana — Sat, 16 May 2026 17:12:12 +0000

Here are six small examples that reveal two completely different language philosophies.

With the recent Bun port to Rust (from Zig) with LLM assistance is setting the interwebs ablaze, I felt going a bit deeper into how Rust and Zig differ in their approaches to solving concrete problems.

Most discussions about Rust and Zig become philosophical quickly.

But the philosophy itself is just the starting point.

A deeper understanding can come from how each philosophy shapes day to day engineering tasks such as:

allocating memory
handling errors
sharing state
building binaries
interfacing with C
structuring dependencies

I'll walk you through a a few examples, after which, the two languages may start feeling fundamentally different.

If one were to summarize, Rust keeps asking:

“How can the compiler make this difficult to misuse?”

Zig keeps asking:

“How can the programmer see exactly what is happening?”

Let's go through a few examples.

Example 1: Creating a Dynamic Array

Let’s start with something boring.

A growable list of integers.

Rust

fn main() {
    let mut numbers = Vec::new();

    numbers.push(1);
    numbers.push(2);
    numbers.push(3);
}

Very little ceremony.

You do not think about allocation yet.

You do not think about cleanup.

You do not think about allocator strategy.

Rust intentionally compresses those concerns away unless you need them.

Zig

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();

    const allocator = gpa.allocator();

    var numbers = std.ArrayList(i32).init(allocator);
    defer numbers.deinit();

    try numbers.append(1);
    try numbers.append(2);
    try numbers.append(3);
}

The first reaction many engineers have:

“Why so explicit?”

But after a while, the important thing becomes obvious:

allocator choice is visible
allocation lifetime is visible
cleanup is visible
failure is visible

The language forces resource awareness into the code itself.

That changes how systems evolve.

In Rust, memory management becomes something the compiler heavily assists with.

In Zig, memory management remains part of the engineering model.

That difference shows up everywhere later.

Example 2: Invalid References

This example makes Rust’s philosophy impossible to miss.

Rust

fn main() {
    let mut values = vec![1, 2, 3];

    let first = &values[0];

    values.push(4);

    println!("{}", first);
}

Rust rejects this.

Because push() may reallocate the vector internally, invalidating the reference.

The interesting part is not the compiler error.

The interesting part is what Rust optimizes for.

This category of bug is historically painful:

crashes under load
intermittent corruption
impossible‑to‑reproduce failures
security vulnerabilities

Rust treats these as unacceptable failure classes.

So the compiler intervenes aggressively.

Zig

Zig allows the same pattern.

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    var values = std.ArrayList(i32).init(allocator);
    defer values.deinit();

    try values.append(1);
    try values.append(2);
    try values.append(3);

    const first = &values.items[0]; // reference to first element

    try values.append(4); // may reallocate, invalidating 'first'

    std.debug.print("{}\n", .{first.*});
}

This code compiles and runs – but the reference first may become dangling after the second append. The program can crash or read garbage.

Zig’s philosophy differs.

Zig assumes:

The programmer should understand when memory relocation is possible.

That sounds dangerous.

And sometimes it is.

But there is another side.

Rust scales correctness mechanically.

Zig scales understanding culturally.

That is a very different engineering assumption.

Example 3: Error Handling

The two languages start feeling stylistically similar while still revealing very different priorities.

Rust

use std::fs;

fn read_file() -> Result<String, std::io::Error> {
    let content = fs::read_to_string("config.json")?;
    Ok(content)
}

The ? operator keeps propagation concise.

Errors stay explicit.

Control flow remains visible.

This is one of Rust’s best design choices.

Zig

const std = @import("std");

fn readFile(allocator: std.mem.Allocator) ![]u8 {
    const file = try std.fs.cwd().openFile("config.json", .{});
    defer file.close();

    return try file.readToEndAlloc(allocator, 1024 * 1024);
}

The important difference is subtle.

Zig keeps allocation visible even during convenience APIs.

That becomes surprisingly important in large systems.

Many production issues are really resource issues in disguise:

allocation spikes
hidden copies
unexpected buffering
allocator fragmentation
ownership confusion

Zig keeps reminding you those things exist.

Rust tries harder to abstract them safely.

Example 4: Shared State Across Threads

This is where Rust becomes genuinely impressive.

Rust

use std::sync::{Arc, Mutex};
use std::thread;

fn main() {
    let counter = Arc::new(Mutex::new(0));

    let mut handles = vec![];

    for _ in 0..10 {
        let counter = Arc::clone(&counter);
        handles.push(thread::spawn(move || {
            let mut num = counter.lock().unwrap();
            *num += 1;
        }));
    }

    for handle in handles {
        handle.join().unwrap();
    }
}

There is ceremony here.

But Rust does something powerful:

ownership is tracked
mutation is controlled
thread safety is enforced
races become much harder accidentally

Rust’s concurrency story is restrictive because unrestricted concurrency has historically been catastrophic.

The language deeply distrusts shared mutable state.

For good reason.

Zig

Zig provides the same primitives with less ceremony.

const std = @import("std");

var counter: i32 = 0;
var mutex = std.Thread.Mutex{};

fn worker() void {
    mutex.lock();
    defer mutex.unlock();
    counter += 1;
}

pub fn main() !void {
    var threads: [10]std.Thread = undefined;
    for (&threads) |*t| {
        t.* = try std.Thread.spawn(.{}, worker, .{});
    }
    for (threads) |t| {
        t.join();
    }
    std.debug.print("counter: {}\n", .{counter});
}

Zig’s approach feels much closer to C.

The primitives are straightforward.

The language trusts you more.

That simplicity appeals – especially when debugging.

But correctness depends more directly on engineer discipline.

Rust tries to make dangerous concurrency difficult.

Zig tries to make concurrency understandable.

Example 5: Interfacing With C

This is one of Zig’s most interesting strengths.

Zig

const c = @cImport({
    @cInclude("sqlite3.h");
});

That is basically it.

Zig’s C interoperability story feels unusually direct because the language positions itself close to C semantics.

Many systems engineers notice this immediately.

Teams with large existing C codebases find incremental migration realistic.

Rust

Rust has strong FFI support.

But it usually looks more like:

use std::ffi::{c_int, c_void};

extern "C" {
    fn sqlite3_open(filename: *const i8, ppDb: *mut *mut c_void) -> c_int;
}

Or it involves:

bindgen
unsafe blocks
wrapper layers
ownership translation

Rust tries to preserve safety guarantees across language boundaries.

Zig optimises for minimal friction.

Again:

Rust prioritises correctness constraints
Zig prioritises mechanical transparency

The same pattern keeps reappearing.

Example 6: Building a Static Binary

This example seems operationally boring until you have maintained deployment pipelines long enough.

Zig

zig build -Dtarget=x86_64-linux-musl

Done.

The first time many infra engineers try this, the reaction is:

“Wait, seriously?”

Zig’s toolchain story feels aggressively practical.

Almost as if someone tired of fighting build environments designed it.

Rust

Rust’s tooling is excellent.

Cargo is excellent.

But static cross‑compilation in Rust often introduces real‑world friction:

linker configuration
musl edge cases
OpenSSL issues
Dockerised builders
target setup
CI complexity

None of this is impossible.

But operationally, Zig often feels mechanically lighter.

That matters more than people think – especially for small infrastructure teams.

One Thing That Becomes Obvious After These Examples

Rust and Zig do not compete on syntax.

They compete on where engineering responsibility should live.

Rust says:

“The compiler should aggressively constrain dangerous behaviour.”

Zig says:

“The programmer should see the dangerous behaviour directly.”

That difference affects:

APIs
tooling
concurrency
debugging
deployment
dependency culture
architecture style

Even the ecosystems reflect it.

Rust’s ecosystem is rich, abstracted, and ambitious.

Zig’s ecosystem is smaller, simpler, and operationally direct.

The Interesting Part Is How These Philosophies Fail

Rust failure mode:

“The system became architecturally complicated because the compiler demanded precision.”

Zig failure mode:

“The system stayed understandable, but correctness depended heavily on engineer discipline.”

Both are real costs.

Both become more visible as systems and teams grow.

What I Would Personally Optimise For

If multiple teams will maintain critical infrastructure for years:

I would strongly lean Rust.

The compile‑time guarantees compound in value organisationally.

If a small systems team deeply values operational simplicity and explicit control:

Zig becomes extremely attractive.

Especially for:

tooling
infrastructure utilities
embedded systems
lightweight services
C migration layers

The deeper insight is this:

Rust optimises for preventing mistakes. Zig optimises for exposing reality.

Depending on the system, either property can be more valuable.

Practical Checklist

Before choosing either language, ask:

Will many engineers touch this code?
Is deployment simplicity a major concern?
Is memory corruption a serious business risk?
Is debugging or correctness the bigger pain today?
Does the team already understand systems programming deeply?
Will this system survive for many years?
Is operational complexity already growing too quickly?
Are hidden abstractions becoming a problem?

Most teams answer these emotionally.

The operational consequences arrive later.

Final Takeaway

After enough examples, the philosophical split becomes very hard to unsee.

Rust keeps moving complexity toward the compiler.

Zig keeps moving complexity toward the engineer.

Both choices carry costs.

The real question is:

“Which failure mode does this system tolerate better?”

Over to you...

If you have built serious systems in either language:

Which part became the actual long‑term cost?

What became painful once the codebase, deployment surface, and team started growing?

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

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro 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

A New Method for Stable Software: Micro Code Reviews for the AI Era

Shrijith Venkatramana — Tue, 12 May 2026 15:33:36 +0000

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

Why This AI Moment Changes How We Build Software

I have been into software for almost a decade now. I grew up with software, using software, building software, being enthusiastic about software. I thought it was the most magical thing. I still do.

When I was in college, I read The Society of Mind by Marvin Minsky. It was a very famous book, at least in some research circles. I was enthralled by it. I loved that book and reread it many times.

So this AI revolution is nothing unexpected to someone like me. I’m absolutely for it.

But in terms of practical details, Minsky wasn’t exactly right. He initially did a lot to popularize neural networks, but later he moved toward other approaches and felt neural networks were not workable. With hindsight, we can now say neural networks were probably a very good idea, because modern deep learning is fundamentally based on neural models. And today, compute is what is making things happen for us.

We have Rich Sutton’s “Bitter Lesson,” where he argued that what matters most is computation, not handcrafted methods. For 70 years, the biggest advances have come from leveraging computation. That idea has clearly played out in practice.

So this is a wonderful time to do software in a different way.

At Hexmos, we call ourselves builders of semi-autonomous agents. In a way, we are building agents that help build other agents. That is our focus.

If AI Writes More Code, What Becomes the Human Job?

Practically speaking, most of us are using tools like GitHub Copilot, Cursor, Claude Code, OpenCode, or similar systems. We are all generating large amounts of code now, and that means we are constantly dealing with code we do not fully understand ourselves.

There is simply too much being generated for manual checking.

So more and more of software development is going to revolve around two pillars.

Originally, we had three pillars:

Envisioning goals and specifying requirements
Building software
Deploying software, observing feedback from the world, tests, and production systems, and then improving the system

Now with AI, the middle part — the actual implementation work — is becoming increasingly automated.

So envisioning and specification are still largely human responsibilities. And I think we want to keep it that way. As people like Herb Simon have argued, we want to design environments the way humans want them, not the way machines want them. We are building these systems for ourselves.

And then there is verification.

Specifying goals and checking whether things were done correctly is increasingly becoming the human responsibility.

Historically, verification in software engineering has mainly been based on relatively lightweight techniques:

Code review
Documentation
Testing
CI/CD
Fuzzing
Property-based testing
Formal verification

src: What works and doesn't selling formal methods

The cheapest and most common method has been code review. You simply ask a senior engineer to look at the code.

But now the volume has exploded because machines are generating code continuously. You may generate thousands of lines of code in a single day.

Why Traditional Code Review Breaks When Code Volume Explodes

So how do you verify all of that?

We need more review, and we need better methods for doing it.

To solve this, I came up with what I believe is a comparatively new technique: git-lrc.

The idea is micro code reviews.

The Core Idea: Review Code at the Exact Moment It Matters Most

What do I mean by “micro”?

All of us already use git commit. Whether you are using Copilot, Cursor, Claude Code, OpenCode, or something else, eventually you are storing code somewhere and creating commits.

That is a universal workflow shared by tens of millions of developers.

So I thought: why not place the review step exactly there?

Committing is already the point where you are ready to create a snapshot. So why not review the snapshot before it gets finalized?

That became the core insight.

And now we are able to execute it properly.

Another important aspect is understanding what the machine is generating. Sometimes AI systems make terrible architectural decisions. Sometimes they introduce ugly patterns, expensive cloud operations, sensitive data leaks, behavioral regressions, or security issues.

They may:

Introduce expensive infrastructure operations
Expose sensitive data
Change behavior unintentionally
Corrupt important logic
Leak credentials

So bad things can happen.

That is why we want lightweight review systems that help produce more stable software while reducing bugs and operational issues.

Of course, there are more rigorous techniques like formal specification and formal verification. But most software does not require that level of rigor.

Often, we simply want a fast and cheap way to sanity-check generated code.

That is what micro review is about.

It is an extremely cheap verification method that catches issues early.

Another important aspect is comprehension. As you commit changes, the system helps you understand what is happening.

What the Workflow Feels Like in Practice

Here is what that looks like in practice.

Imagine I intentionally add some obviously bad code to a small Go program. I stage the change the normal way and start a commit. Instead of letting the commit go through immediately, git-lrc opens a review window and begins analyzing the staged diff in real time. The important point is that the review happens at the exact moment I am about to preserve the change, so I do not need to remember a separate workflow or open a different tool.

Within roughly 13 seconds, the first result appears. The system flags part of the change as suspicious and says that the lines look random and likely not intended for production use. That kind of feedback matters because it catches the sort of low-quality AI output that is easy to miss when you are moving quickly. Rather than forcing me to inspect every line from scratch, the review immediately tells me where to focus my attention.

The interface then generates short visual summaries of the change and walks through them step by step. As I move through the review, it explains that a new Go package called main has been introduced, that standard boilerplate was added, and that some of the comments look like placeholders or unfinished experimental code. It also points me directly to the affected file, main.go, so I can jump straight from the review into the source.

What makes this useful is that the tool does not stop at description. It also explains why the change may be risky. In this example, the review highlights that unfinished code can reduce stability and can create refactoring work later. So the system is doing two jobs at once: it is identifying a possible defect, and it is helping me understand the nature and impact of the change I just made.

From there, I have a clear next step. I can let the tool attempt an automatic fix in the background, or I can pass the issue to another coding assistant such as Copilot or Claude and ask it to repair the specific problem. In the demo, Copilot recognizes the placeholder text and removes it.

That is the core value proposition. In less than a minute, I get a review, a concise explanation of what changed, a warning about what might go wrong, and a straightforward path to fixing the issue.

In practice, the system acts as both:

A lightweight verification layer
A comprehension aid for AI-generated code

That is the essence of the micro review methodology.

Why This Tiny Review Step Can Improve Reliability and Revenue

And I believe this can significantly improve code quality across engineering teams.

Code quality directly impacts:

Reliability
Uptime
Customer experience
Revenue retention
Operational stability

Does the software stay available at night while engineers are asleep?

Does it behave as expected?

Does it annoy users?

Does it create churn or revenue loss?

Generated code must be checked, and we need cheap ways to do it continuously.

This gives companies a way to improve engineering standards with very little effort.

The overhead is tiny — often less than a minute per commit — but the quality gains can be substantial.

So hopefully this has been useful.

If this sounds interesting, go to Hexmos git-lrc.

From there, you can install it and try it out.

Why the Pricing Is Meant to Stay Predictable

Let me also briefly explain the pricing.

We charge based on lines of code scanned.

You can have unlimited users and unlimited team members, but usage is priced predictably based on scanning volume.

For example:

$32 for 100,000 lines
$64 for 200,000 lines
$128 for 400,000 lines
$256 for 800,000 lines

Both price and volume scale proportionally.

The important point is that there are no surprise bills.

AI usage is included in the pricing, so you do not need to separately pay for models.

You can onboard your entire team — whether you are a startup, small business, or larger company.

We also offer enterprise plans for organizations that need custom deployments or integrations.

But generally, most teams can simply start with the standard paid plans.

There is also a free tier with around 30,000 lines of code included, so you can try it out before committing.

So give it a try, explore it, and see whether this style of lightweight review improves your workflow.

FastMCP: Build Production-Ready MCP Servers in Python with Minimal Boilerplate

Shrijith Venkatramana — Sun, 10 May 2026 16:57:02 +0000

Imagine you want your AI coding assistant or agent to actually do useful things in your world—read the latest database records, run calculations against your data, update tickets, or even show an interactive dashboard—without you writing pages of glue code, managing JSON schemas by hand, or worrying about credential leaks every time you expose a capability.

FastMCP is the Python framework that makes this straightforward. It turns ordinary Python functions, classes, and data sources into fully compliant Model Context Protocol (MCP) servers that any compatible AI host (Claude Desktop, Cursor, custom agents, etc.) can discover and use safely.

What Problem Does MCP (and FastMCP) Actually Solve?

Traditional tool-calling approaches have friction:

Raw function calling often requires manual schema definitions.
CLI "skills" can expose too much (credentials, full shell access).
Custom HTTP endpoints mean reinventing discovery, validation, auth, and state management.
Connecting interactive UIs back to your backend is painful.

MCP standardizes how LLMs discover and call tools, read dynamic resources, and use prompt templates. FastMCP implements that standard with Pythonic decorators and sensible defaults so you stay focused on business logic.

Installation and Your First Working Server (5 Minutes)

Use uv (recommended) or pip:

uv pip install fastmcp
# or
pip install fastmcp

Create server.py:

from fastmcp import FastMCP

mcp = FastMCP("demo")  # Human-friendly name for the server

@mcp.tool
def add(a: int, b: int) -> int:
    """Add two numbers. Useful for any math the agent needs to perform accurately."""
    return a + b

@mcp.tool
def greet(name: str, formal: bool = False) -> str:
    """Generate a greeting message."""
    title = "Mr. " if formal else ""
    return f"Hello, {title}{name}!"

if __name__ == "__main__":
    mcp.run()  # Defaults to Streamable HTTP transport

Run it:

python server.py

The server starts on http://localhost:8000 (configurable). You now have a live MCP endpoint with automatic schema generation from type hints and docstrings.

Exploring Your Server: Tools, Resources, and Prompts

FastMCP supports three core primitives.

Tools — Executable functions the LLM can call.

Resources — Readable data (static or dynamic) the LLM can fetch.

Prompts — Reusable prompt templates with parameters.

Add these to the same file:

from typing import List, Dict
import datetime

# Dynamic resource example
@mcp.resource("resource://time/now")
def current_time() -> str:
    """Return current UTC time as ISO string."""
    return datetime.datetime.now(datetime.timezone.utc).isoformat()

# List resource
@mcp.resource("resource://users")
def list_users() -> List[Dict]:
    """Return a list of sample users. In production, query your DB here."""
    return [
        {"id": 1, "name": "Alice", "role": "engineer"},
        {"id": 2, "name": "Bob", "role": "designer"}
    ]

# Prompt template
@mcp.prompt
def research_topic(topic: str, depth: str = "medium") -> str:
    """Generate a structured research prompt."""
    return f"""
    Research {topic} at {depth} depth.
    1. Use available tools to gather latest information.
    2. Summarize key findings.
    3. List open questions.
    """

These are automatically discoverable. Resources are great for live data (JIRA tickets, GitHub issues, database views) without forcing the LLM to call a tool every time.

Connecting Clients and Testing Locally

FastMCP includes a rich client library. Create client.py:

import asyncio
from fastmcp import Client

async def main():
    async with Client("http://localhost:8000") as client:  # Adjust URL/port
        # List capabilities
        tools = await client.list_tools()
        print("Available tools:", [t.name for t in tools])

        # Call a tool
        result = await client.call_tool("add", {"a": 15, "b": 27})
        print("15 + 27 =", result)

        # Read a resource
        time_data = await client.read_resource("resource://time/now")
        print("Current time:", time_data)

asyncio.run(main())

For local development with interactive UIs, use the built-in dev server (more on that below).

Building Interactive Apps Inside the Conversation

One of FastMCP’s most powerful features is Apps — tools that return rich, interactive UIs rendered directly in the host’s conversation.

Mark a tool with app=True and return Prefab components (or custom HTML).

Example dashboard.py:

from fastmcp import FastMCP
from prefab import Column, Header, Chart, DataTable, Button, CallTool  # Prefab components

mcp = FastMCP("sales-demo")

def fetch_sales_data(region: str):
    # Simulate or query real data
    return [
        {"month": "Jan", "revenue": 12000},
        {"month": "Feb", "revenue": 15000},
        # ...
    ]

@mcp.tool(app=True)
def sales_dashboard(region: str = "Global"):
    """Interactive sales dashboard for the selected region."""
    data = fetch_sales_data(region)

    return Column([
        Header(f"Sales Dashboard - {region}"),
        Chart(data, type="bar", title="Monthly Revenue"),
        DataTable(data, searchable=True),
        Button(
            "Export CSV",
            on_click=CallTool("export_sales", {"region": region})
        )
    ])

# Backend tool used by the UI (hidden from LLM by default)
@mcp.tool
def export_sales(region: str):
    # Generate and return file or link
    return {"status": "success", "message": f"CSV for {region} ready"}

Run with fastmcp dev apps dashboard.py to preview locally. The dev UI gives you a picker, auto-generated forms, live rendering, and an MCP inspector showing all traffic. Changes hot-reload.

Advanced Patterns and Production Considerations

Server Composition & Namespacing

from fastmcp import FastMCP, Provider

main_mcp = FastMCP("main")

# Mount another server under a prefix
github_provider = ...  # or another FastMCP instance
main_mcp.mount(github_provider, prefix="github")

Authentication & Security

FastMCP supports multiple auth methods. You keep credentials server-side; the LLM only sees tool results. This is a major advantage over exposing raw API keys or full shell access.

Deployment

Run locally or on any VPS with mcp.run().
For production, Prefect Horizon offers managed hosting, GitHub-based deploys, branch previews, SSO, RBAC, audit logs, etc.
Containerize easily with Docker for self-hosting.

Debugging Tips

Use fastmcp dev apps for UI tools.
Append .md to any docs URL on gofastmcp.com for markdown.
The server at https://gofastmcp.com/mcp lets you query the docs via MCP itself.

Common Real-World Use Cases

Internal Tools: Expose company DB queries, ticket systems, or monitoring data safely.
Personal Agents: Connect to your calendar, email summaries, or note-taking app.
Data Analysis: Dynamic resources for CSVs, live API feeds, or vector search results.
Workflow Automation: Tools that trigger Prefect flows or other orchestration.
E-commerce / CRM Demos: As seen in community examples with order management and dashboards.

Next Steps and Resources

Read the official quickstart and tutorials at gofastmcp.com.
Explore example apps in the FastMCP GitHub repo.
Try connecting your server to Claude Desktop or other MCP hosts.
Experiment with fastmcp dev apps—it’s the fastest way to iterate on interactive tools.

FastMCP removes most of the repetitive work so you can focus on what the AI should actually do with access to your systems. The code you write looks like normal Python, but suddenly becomes powerful, discoverable, and interactive capabilities for any MCP-compatible agent.

Start small with a couple of tools today. You’ll quickly see how natural it feels to give your AI real work to do. What domain or dataset will you connect first?

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

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro 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

State of Linux Terminal Emulators in 2026

Shrijith Venkatramana — Sat, 09 May 2026 17:19:33 +0000

The Linux terminal emulator landscape has evolved into a rich ecosystem of powerful, modern tools that sometimes go overlooked.

While many people are happy with their distribution's default, the last few years have brought some incredible improvements that can genuinely change your command-line workflow.

This article dives into the state of terminal emulators in 2026, comparing 10 of the most popular options.

It's not about declaring a single "best" terminal, but about understanding the trade-offs, the new capabilities, and finding the right tool for how you work.

⚡ A Tale of Two Terminals: The Great 2026 Divide

The once-unified world of terminal emulators has undergone a dramatic split.

On one side, we have the GPU-accelerated powerhouses (like kitty, WezTerm, and Ghostty), which have turned the terminal into a fast, feature-rich "CLI platform".

On the other, the mature, desktop-integrated classics (like GNOME Terminal and Konsole) remain the rock-solid defaults for millions, but are they still relevant?

This division is being driven by three forces in the Linux world:

Wayland's Dominance: With Wayland as the default on major desktops like GNOME and Ubuntu‘s latest LTS, the era of X11 workarounds is over. Terminals must now be Wayland-native or have robust Wayland backends to perform well.
The GPU Render Transformation: Offloading text rendering to your graphics card isn't just a gimmick. Applications like Alacritty, kitty, and Ghostty use OpenGL to achieve incredibly low latency and smooth scrolling, even under heavy log output. The CPU-rendered "old guard" has had to fight back with heavy optimization.
Containers, Tabs, and Inline Media: The terminal of 2026 is no longer just a black box for commands. The best emulators now offer built-in container integration (like distrobox), native tabs and splits (eliminating the need for tmux for many), and even inline image and graphics protocol support.

🧩 The Top 10 Terminal Emulators of 2026

Here's a breakdown of the most important terminal emulators in 2026, categorized by their philosophy and user types.

The New Guard (GPU-Accelerated & Feature-Rich)

These are the terminals pushing the boundaries of what's possible.

1. 🐈 kitty: The Feature-Rich Platform

kitty is a GPU-accelerated terminal that feels more like a complete platform than a simple emulator. It's built for power users who want deep customization and advanced features baked right in.

Key Features: Built-in tiling window management, a custom graphics protocol (for viewing images in the terminal with icat), and a unique "kitten" system for extensible command-line tools.
Performance: Written in C and Python, kitty is incredibly fast. Version 0.33 introduced SIMD-parallel parsing, dramatically improving throughput in real-world workloads.
Configuration: Uses a simple, human-readable config file. Powerful, but there's no GUI for settings.
Verdict: The ultimate choice if you want a single, highly-capable terminal to replace your need for separate multiplexers like tmux.

Where to get it: sudo apt install kitty (Ubuntu/Debian) or sudo pacman -S kitty (Arch). For more, see the official website.

2. 🦀 WezTerm: The Programmable Powerhouse

WezTerm is a cross-platform Rust terminal with a superpower: a built-in multiplexer that works seamlessly across local and remote hosts.

Key Features: Its entire configuration is done in Lua, making it infinitely customizable. It supports panes, tabs, and windows that can span different machines while preserving state.
Performance: Extremely competitive with other GPU-accelerated terminals, though some users note a slightly higher memory footprint due to its rich feature set.
Configuration: Everything is configured in Lua. It has a steep learning curve, but the flexibility is unmatched for developers who want complete control.
Verdict: The best pick for developers who live in a mix of local and remote environments and want to script every aspect of their terminal.

Where to get it: Available via most package managers. Check the official website for installation instructions.

3. 👻 Ghostty: The New Native Kid on the Block

Created by Mitchell Hashimoto (founder of HashiCorp), Ghostty has quickly gained a massive following for its speed and native approach.

Key Features: Uses platform-native UI toolkits, including GTK4 on Linux. It's GPU-accelerated and supports modern features like tabs, splits, and multiple graphics protocols (Kitty, Sixel, iTerm2) out of the box.
Performance: Early benchmarks place it squarely in the top tier for speed. It's designed to feel "snappy" even with dozens of tabs and splits.
Adoption: In a very short time, Ghostty has gathered over 45k GitHub stars and is even packaged as a snap and in the Ubuntu 26.04 LTS repositories.
Verdict: A promising, rapidly maturing terminal that is already a great daily driver for anyone who wants a modern, fast, and well-integrated experience.

Where to get it: sudo snap install ghostty or sudo apt install ghostty (on Ubuntu 26.04). Visit the GitHub page to build from source.

4. ⚡ Alacritty: The Speed Minimalist

Alacritty set the standard for the modern, GPU-accelerated terminal. Its philosophy is laser-focused: be the fastest terminal emulator, and nothing else.

Key Features: It deliberately lacks built-in tabs or splits. The authors believe these features are better handled by a separate multiplexer like tmux or zellij, adhering to the Unix philosophy of one tool doing one job well.
Performance: Unmatched raw speed. Its idle memory usage is incredibly low (around 20-35 MB), and input latency is among the best in the business, especially with recent Wayland improvements.
Configuration: Configured via a straightforward YAML or TOML file. No GUI, no bloat.
Verdict: The perfect choice for users who love tmux and want a terminal that is ruthlessly efficient and gets out of their way.

Where to get it: sudo apt install alacritty or sudo pacman -S alacritty. Find more at Alacritty's GitHub.

The Trusted Workhorses (Desktop-Integrated & Stable)

These are the terminals you probably already have installed. They've been improving quietly and are more capable than ever.

5. 💠 Konsole: The KDE Power User's Dream

If you're on KDE Plasma, Konsole is a natural extension of your desktop environment. It‘s feature-rich, deeply integrated, and highly performant for what it does.

Key Features: Offers native splits, tabs, bookmarks (for directories and SSH sessions), and profiles. It integrates seamlessly with Dolphin (F4 opens a terminal in the current directory) and other KDE components.
Performance: Not GPU-accelerated, but it’s highly optimized for typical workloads and supports modern features like true color and font ligatures.
Configuration: Has a full-featured GUI preferences dialog, making it very user-friendly for customization.
Verdict: Hands down the best terminal for anyone who uses KDE Plasma as their daily driver.

Where to get it: Already installed on KDE Plasma. For others, sudo apt install konsole.

6. 🐧 GNOME Terminal: The Unkillable Classic

GNOME Terminal is the default for millions of Linux users. While GNOME has been pushing its simpler "Console" app, GNOME Terminal remains the heavy lifter for serious work.

Key Features: It offers profiles, tabs (though GNOME 40+ removed the tab bar by default), transparency, and customization via dconf.
Performance: The critical update here is the VTE (the terminal widget library) overhaul in GNOME 46. This brought substantial latency reductions, bringing GNOME Terminal's responsiveness much closer to GPU-accelerated competitors.
Configuration: The dconf-based configuration system is powerful but can be clunky.
Verdict: A safe, stable, and now surprisingly fast default that is more than enough for most users. It really has come a long way.

Where to get it: sudo apt install gnome-terminal or use your distribution's package manager.

Specialists & Niche Picks

These terminals serve very specific needs with unique approaches.

7. ⚙️ Foot: The Wayland-First Minimalist

If you're using a Wayland-based tiling window manager like Sway or Hyprland, Foot is a must-try. It's built from the ground up for Wayland and prioritizes minimalism and efficiency above all else.

Key Features: It's CPU-rendered but incredibly lean. Despite its small size, it supports true color, Sixel images, and even scrollback search.
Performance: Incredibly low memory usage and fast startup. Its design philosophy trades feature bloat for pure, predictable performance. It's a perfect complement to a highly scripted, tmux-driven workflow.
Configuration: Simple, file-based configuration.
Verdict: The ultimate terminal for users of tiling window managers who want a simple, rock-solid, and fast Wayland-native experience.

Where to get it: sudo pacman -S foot (Arch) or build from its Git repository.

8. 📐 Tilix & Terminator: The Classic Tilers

Before tiling became mainstream in terminals like kitty, tilix and terminator were the go-to options for splitting a single window into multiple panes.

Features: Both are VTE-based and allow you to divide a window into a grid of terminals. They can save and restore sessions, making them great for setting up a reproducible dev environment.
Maintenance: This is the main concern. Tilix's development has slowed significantly (the project has explicitly sought maintainers), and Terminator has a similar, though slightly better, maintenance status.
Performance: As VTE clients, they get the latency benefits of the GNOME 46 VTE improvements.
Verdict: Still functional and in most distro repos, but for new users, a more actively maintained solution like kitty, WezTerm, or Konsole is likely a better long-term choice.

9. 📟 xterm: The Eternal Fallback

We should never forget xterm. It is the reference implementation and is as stable as bedrock. It's the "canary in the coal mine" for terminal compatibility.

Features: It‘s the most standards-compliant terminal you can find. It’s highly configurable via X resources, but it lacks modern niceties like tabs, decent theming, or Wayland support (without XWayland).
Verdict: Every Linux user should have it installed. When your fancy GPU terminal breaks in the most arcane way possible, xterm will still be there for you.

Where to get it: It's probably already installed. If not, sudo apt install xterm.

🧠 A Framework for Your Terminal Choice

With so many options, choosing a terminal can feel overwhelming. Here's a structured way to think about the decision.

Use Case: I Use a Desktop Environment (GNOME, KDE)

Your Best Bet: Konsole (for KDE) / GNOME Terminal (for GNOME).
Why? These terminals offer the best integration with your desktop's theming, shortcuts, and workflow. They are stable, well-supported, and get regular improvements (the recent VTE performance boost in GNOME Terminal is a great example).
Action: Give your default terminal another try. You might be surprised at how good it's become. Explore its settings.

Use Case: I’m a Terminal Junkie / `tmux` Addict

Your Best Bet: Alacritty or Foot.
Why? You want a terminal that is a flawless canvas for your real workflow: tmux, neovim, and custom scripts. You don‘t need or want your terminal emulator to also be a window manager. Alacritty is the speed king, while Foot is the Waylord’s choice.
Action: Set up Alacritty with your favorite tmux config. You'll likely never look back.

Use Case: I Want One Terminal to Rule Them All

Your Best Bet: kitty or WezTerm.
Why? You find tmux powerful but a bit of a layer on top. You want native tabs, splits, inline images, and deep scripting ability built directly into your terminal. kitty offers a battle-hardened "platform" with its kittens, while WezTerm offers infinite customizability with Lua.
Action: Install both and spend a day configuring each. See which one "clicks" with your mental model.

Use Case: I’m a Wayland Tiling WM User (Sway, Hyprland)

Your Best Bet: Foot.
Why? It‘s made for you. It’s native, lightweight, and doesn't try to reinvent the tiling wheel (your WM handles that). It‘s a perfect match for the philosophy of a tiling environment.
Action: sudo pacman -S foot and set it as your primary terminal in your Sway/Hyprland config.

❓ The Final Command Line: Which One is for You?

This guide covers the major players, but the real answer is, as always in Linux, “it depends”. Here's a summary to help you decide:

Want the most features in a box? → Go with kitty.
Need ultimate programmability and remote multiplexing? → Try WezTerm.
Want a modern, fast, native terminal? → Check out Ghostty.
Value pure, raw speed and minimalism? → Pick Alacritty.
Love KDE and want deep integration? → Stick with Konsole.
Use a distro with GNOME and want a solid, improved default? → GNOME Terminal.
Live in a Wayland tiling window manager? → Try Foot.
Need a rock-solid standard for debugging? → Keep xterm handy.

Your terminal is your home in the Linux world. It's worth the investment to find one that feels just right. For me, the improvements in speed and features over the last few years have been genuinely transformative. Whether it's a GPU-rendered giant or a newly optimized classic, the terminal of 2026 is a tool that any power user can get genuinely excited about. Give a new one a spin this weekend. You might be surprised by what you find.

*What's your daily driver terminal? Let me know in the comments!

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

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro 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

The Subsidy Era Is Over: A Reality Check on AI-Powered Dev Tool Pricing

Shrijith Venkatramana — Fri, 08 May 2026 18:02:21 +0000

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

You have all been using different kinds of AI tools, be it Claude, GitHub Copilot, anti-gravity, Google Gemini, or Cursor. These tools started with very generous pricing, so it felt like you could get a lot done for very little. Many people were getting things done using the free tier itself, but it seems like things are changing. In this video, I will walk through a few of these limitations.

The Subsidy Era Is Ending

This discussion was prompted by a post by Kamil Krauspe, a VP of Engineering and Managing Director at a reputed AI company. Based on some interesting evidence, his conclusion is that, on the surface, it looks like nothing has changed, but in many of these providers, the amount of AI included per plan has reduced. Essentially, the subsidy is ending.

He points to evidence across providers:

Claude has reduced subsidies.
Copilot has reduced subsidies.
OpenAI has reduced subsidies for Codex.
Google has tightened anti-gravity.

There is also a nuance with Claude. Recently, there was news that Claude had increased its limits, or doubled them. But what actually happened is that the five-hour limit increased while the weekly and monthly limits remained the same. So the overall volume has not increased; only the hourly limit has.

One reason for this, according to the argument, is that in a typical SaaS product there is an extreme user profile: someone who pays $10 and maybe, in the worst case, consumes $100 worth of value. But with agents, that multiple can become 100,000x. Cost also has multiple layers:

Model cost
Tool builder cost
User behavior cost

All in all, because the subsidies are ending, it is very important for people to make cost-conscious decisions. The core point is that all the major providers are tightening plans and tightening steps.

Think in Workloads, Not Models

The practical conclusion is that companies and individuals have to think more from a workload angle, not from a model angle. Earlier, the view was simple: there is a task, you complete the task, and you pay a particular amount. Now pricing is becoming much more granular, often at the token level.

That means the workload matters far more. For example, you might be doing:

Autocomplete
A single question or query
Interactive file editing
An autonomous agent run
Multi-agent orchestration

The token usage profiles and the costs are totally different across these workloads. Token usage might be less than 1,000, or it could go up to a billion. The cost might be less than $0.01, or it could be $500 or more for a single task.

This is a massive difference. For example, in a Claude subscription someone may pay $200, while heavy use may consume up to $4,400. On average, maybe it is $1,000. So who is paying for the 5x or even 50x cost? Right now, companies are absorbing it, but how long can they keep doing that?

Pricing Models in AI Code Review

In my own area, where I am building a portfolio, what I am seeing is that many products still use an older, seat-based pricing idea.

For example:

Code Rabbit charges $30 per month per user. If you are a startup with 10 engineers, that is $300 per month and $3,000 or more annually for the basic plan.
The premium plan may be double that: $60 per user, or $6,000 per year.
Code-ant is also charging similarly.
Greptile is also charging similarly.
Usage-based pricing, like Claude, is unbounded. It could be any number. You have no control over what the final monthly amount is going to be.

With pure usage pricing, a review could cost $15 or $25. If you are doing 10 reviews, that can become a large number in a single month, even for one user. So in the market, we are seeing a mix of pure usage pricing and seat-based pricing.

The Approach Behind git-lrc and LiveReview

I have a tool called git-lrc and LiveReview, and we have taken a different approach. We have merged usage-based pricing with upper-limit, slab-based pricing. The reason is simple: we want usage anchoring and slab-level pricing at the same time, so you get predictability at the end.

What does that mean?

We charge by how many lines of code you scan.
We do not care how many engineers you have.
We are not charging by token.

So if you are a startup with 10 engineers, you can start with just $32, as long as you are scanning only 100,000 lines. The slabs are straightforward:

$32 for 100,000 LOC
$64 for 200,000 LOC
$128 for 400,000 LOC

This is what I mean by slab-based pricing. We are not charging artificially. We are trying to charge in a fair, transparent, and predictable way. In my opinion, none of the other solutions in the market, whether Claude, Code Rabbit, or Greptile, offer this kind of sensible pricing.

I think this is a major strength of our model: predictability plus usage anchoring. People do not want unbounded charges from pure token-based pricing, and they do not want seat-based pricing where they may end up paying unnecessarily because they have 10 engineers but many of them may not use the tool that actively. You end up paying for unused capacity, and that is not a good idea.

So this is the pricing model we have innovated: slab-based pricing tied to usage. That is where you get predictability, simplicity, and value for money. There is no misuse of money happening. Your money goes to actual usage. I hope this subsidy discussion gives you that reality check, and I hope you check out the tool I have built.

A Quick Introduction to git-lrc

I want to take two minutes of your time to introduce git-lrc. git-lrc is a free micro AI code review tool that runs on git commit as you develop software with agents.

As you know, AI can write a lot of code, but your team still owns the outcome. With AI, code generation is not the problem; consequence management is. Who has to answer for outages, security incidents, broken promises, and customer complaints? It is still the engineer, the engineering team, and engineering management. You may delegate execution to AI a little bit, but you cannot delegate responsibility.

git-lrc provides micro AI code reviews on git commit. This improves production stability, security, and performance while reducing bugs, latency, and cost, and it does all this while demanding very little engineering effort.

A Quick Demo

Here is a quick demo of git-lrc:

You open Git as usual.
You run git status and see there are changes.
You trigger a review with git commit.
The updates appear in real time.
You quickly get a summary of what the change is about.
You get that summary in a very clear viewer web UI.
The issues are categorized by severity, such as warning and critical.
You can also see cost bugs, security bugs, and other issues.

You can go to GitHub and read the entire source at github.com/HexmosTech/git-lrc.

For teams, the pricing is extremely affordable. You can get started at $32 and scan 100,000 lines of code per month. We do not have any headcount-based pricing, and we do not charge per engineer. The pricing is extremely simple.

You can get started with $32 per month for any number of users and unlimited team members, and you get all the features for review, PR threads, GitHub, GitLab, bucket integration, AI credits, micro reviews, the VS Code extension, and other features. Everything is included in this.

So for $32, this is one of the best value-for-money options you can get on the market in terms of code review. You can increase the tier if you wish. Go to github.com/HexmosTech/git-lrc and see it for yourself.

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:

OpenAPI standardized "how humans and programs understand APIs."

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:

A standardized protocol that lets agents discover and invoke tools dynamically.

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

OpenAPI was designed so humans could generate clients.
MCP is designed so models can generate behavior.

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:

Responsibility is a unique concept. It can only reside and inhere in a single individual.

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.

The relation of program to environment opens up an exceedingly important role for computer simulation as a tool for achieving a deeper understanding of human behavior.

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

For it is the organization of components and not their physical properties that largely determine behavior. And if computers are organized somewhat in the image of man, then the computer becomes an obvious device for exploring the consequences of alternative organizational assumptions for human behavior.

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

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 habit,…

View on GitHub

DEV Community: Shrijith Venkatramana

Understanding AI Code Fast: A 60-Second Habit for Institutional Memory

Introduction

Do We Need to Read AI-Generated Code?

Production Systems and Responsibility

The Two Failure Modes of AI-Assisted Programming

Reading Every Line vs Reading Nothing

The Amazon “Dive Deep” Principle

Awareness Culture vs Slumber Culture

Git-lrc and the 60-Second Review Habit

Closing

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

Dependent Types for Programmers: A Practical Introduction Using Lean 4

The Normal Way We Think About Types

The Core Idea of Dependent Types

Understanding Vec Nat 3

“But C Arrays Already Have Sizes”

Why This Matters

Non-Empty Lists

“But Real Programs Use Dynamic User Input”

Real-World Intuition

What Lean Is Really Exploring

Final Thoughts

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Free, Micro AI Code Reviews That Run on Commit

See It In Action

Why

From Logic to Code: Understanding the Curry–Howard Correspondence in Lean

The Core Idea: Propositions Behave Like Types

Logical Interpretation

A Tiny Theorem Is Also a Program

The Goal

Step 1: intro h

Step 2: Extract the Left Side

Lean Proof Goals Are Requests for Evidence

Types Can Express Specifications, Not Just Data Shapes

“Sorted” Becomes a Logical Object

What Happens When the Function Is Wrong?

The Deep Shift: Correctness Became Construction

Closing Thoughts

Designing Reliable Permission Models with Lean 4

1. Installing Lean 4

Linux/macOS

2. Install the VSCode Extension

3. Create a Lean Project

4. First Lean Program

def

(name : String)

: String

:=

#eval

5. A Small Verified Function

6. Understanding the Mathematics Line by Line

Nat

increment

theorem

(x : Nat)

increment x > x

:= by

exact

7. Breaking the Proof Intentionally

8. Building a Permission Model

9. Understanding inductive

10. Defining Permissions

11. Why This Is Safer Than It Looks

12. Adding Security Invariants

13. Understanding rfl

14. Introducing a Security Bug

15. Why This Matters More with AI-Generated Code

16. What Lean Is Actually Buying

HexmosTech / git-lrc

Free, Micro AI Code Reviews That Run on Commit

git-lrc

Understanding `Vec Nat 3`

Step 1: `intro h`

`def`

`(name : String)`

`: String`

`:=`

`#eval`

`Nat`

`increment`

`theorem`

`(x : Nat)`

`increment x > x`

`:= by`

`exact`

9. Understanding `inductive`

13. Understanding `rfl`