DEV Community: Ram Bikkina

Loop Engineering Explained Simply (With DIY Python Snippets)

Ram Bikkina — Sun, 21 Jun 2026 07:07:44 +0000

A few weeks ago, Peter Steinberger, the creator of OpenClaw who now works at OpenAI, made an observation that signals a massive structural shift in how we build software:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Shortly after, Boris Cherny, who leads Claude Code at Anthropic, described the exact same evolution in his own daily workflow:

"I don't prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops."

When two of the most prominent engineers shaping the frontier AI landscape independently reach the exact same conclusion, it is no longer a passing trend. It is a fundamental shift in computer science.

The era of manual, chat-based prompt engineering is officially dead. We have entered the age of Loop Engineering.

To understand why this is happening—and how to survive it—we have to look at the cybernetic theory of the loop, the raw economic physics making it possible, and the exact software blueprints required to build them.

Part 1: The Computer Science Theory of the Loop

When most people hear the word "Loop," they picture a basic while(true) statement in Python. But in the context of autonomous agents, "Looping" relies on three core concepts taken directly from Control Theory and Systems Cybernetics.

1. Open-Loop vs. Closed-Loop Cybernetics

For the last two years, we treated LLMs as Open-Loop Control Systems.

Think of a cheap kitchen toaster. You turn the dial to "4", push the lever down, and it applies heat for 120 seconds. If the bread was frozen, it comes out cold. If the bread was already toasted, it catches fire. The toaster has zero awareness of the bread's actual state; it just blindly executes a feedforward instruction. That is a prompt.

An Agent Loop is a Closed-Loop Control System (like a smart home thermostat). It measures the current room temperature, applies heat, measures the room again, calculates the delta (the error) between the current state and the target state, and adjusts itself. It uses feedback.

2. Probabilistic Cores inside Deterministic Shells

Large Language Models are fundamentally stochastic (probabilistic). If you ask an LLM the same complex coding question five times, you will get five slightly different variations of logic.

Trying to build reliable, enterprise-grade software out of purely stochastic prompts is like trying to build a skyscraper out of wet clay; the foundation constantly shifts.

Loop Engineering solves this by wrapping a non-deterministic engine inside a deterministic state machine. The LLM inside the loop is allowed to guess, hallucinate, and be creative. But the State Machine governing the loop holds the strict, binary pass/fail gates. The LLM supplies the raw cognitive horsepower; the Loop supplies the mathematical verification.

3. The Entropy Horizon (Why Loops Decay)

In information theory, systems degrade over time due to entropy.

When an AI agent runs through a loop 15 times trying to fix a bug, its context window fills up with past failed code snippets, messy stack traces, and its own redundant apologies ("Ah, I see my mistake!"). As the signal-to-noise ratio drops, the system hits an Entropy Horizon—it loses track of the original goal and starts hallucinating phantom bugs.

This theoretical limit is why state management and context pruning are the most difficult parts of loop design. A good loop actively throws away dead context to keep the model's entropy close to zero.

Part 2: The Economic Reality of Autonomy

If the theory of closed-loop systems is so obviously superior, why didn’t we build software this way in 2023?

Because of the API bill.

The dirty secret of autonomous loops is that they are token incinerators. While a manual prompt costs you a few hundred tokens, an automated loop pays a massive "token tax" for autonomy:

A Single-Agent Debugging Loop: Iterating 8 times to resolve a complex database migration easily burns 50,000 to 200,000 tokens.
A Multi-Agent Fleet: An orchestrator delegating sub-tasks to a Researcher, a Coder, and a QA agent across a 10-step plan can rapidly consume 500,000 to 2,000,000 tokens per run.
Scheduled CI/CD Loops: Pointing an autonomous loop at your GitHub repository every morning adds up to tens of millions of tokens per month.

When Peter Steinberger posted his advice, the immediate pushback from developers was: "Easy for you to say—you work at OpenAI and don't pay the token bill."

The Frontier Price Collapse

This financial blocker is precisely why Loop Engineering has suddenly gone mainstream. The arrival of ultra-low-cost, frontier-tier models—most notably DeepSeek V4—has fundamentally broken the token tax.

With massive 1M context windows and 384K maximum output limits priced at fractions of a cent per thousand tokens, the financial penalty for a loop failing 10 times in a row has dropped to near zero. You can finally afford to let a machine spend $0.40 worth of compute to autonomously solve a problem that would take a human engineer three hours of salary to fix.

Part 3: The 5 Stages of the Loop Lifecycle

Every production loop rotates through the exact same five distinct evolutionary phases. If your system architecture handles these handoffs cleanly, the loop becomes self-sustaining:

Discover: The agent reads its environment. It inspects directory structures, parses git diffs, or reads API documentation to establish a factual baseline.
Plan: The system generates a deterministic, step-by-step DAG (Directed Acyclic Graph) to map out the journey from the current state to the target state.
Execute: The agent performs the physical work—writing files, refactoring code, or calling external endpoints.
Verify: The most vital stage. The system runs an objective, non-AI quality gate. This must be a cold, hard test: a compiler check (tsc), a test runner (pytest), or a syntax linter.
Iterate: If the verification gate returns an exit code other than 0, the loop captures the raw terminal stderr output and routes it directly back into Stage 1, starting the loop over with the failure logs attached.

Part 4: The 6 Production Software Pillars

To move from an abstract flow diagram to a real-world engine that touches your codebases safely, your software needs six concrete architectural pillars:

1. Automations (The Heartbeat)

Automations replace the human finger pressing "Enter". You write background daemons that evaluate state triggers. For example: Watch /src; if a new file is added, trigger the RefactorLoop until unit test coverage is >= 90%.

2. Git Worktrees (Parallel Workspace Isolation)

When you run multiple agents simultaneously, they will eventually try to read and write to the same file at the exact same millisecond, causing catastrophic race conditions.

Using Git worktrees allows your orchestrator to check out the exact same repository branch into totally isolated, separate physical directories on your hard drive. Agent A can rewrite the backend in Worktree 1 while Agent B writes unit tests in Worktree 2. Zero file-locking collisions.

3. Skills (Compounding System Memory)

An agent shouldn't have to guess your architectural patterns every time it boots up. You drop a dedicated .agent/ configuration directory into your project root containing explicit guardrails.

DIY Snippet: Project Guardrails (`.agent/RULES.md`)

# Project Engineering Constraints

1. **Strict Typing:** All Python code MUST pass `mypy --strict`. Do not use `Any`.
2. **No Silent Failures:** Never use `except Exception: pass`. Catch explicit errors and log them.
3. **Immutability:** Favor `dataclasses` with `frozen=True`.
4. **Network Layer:** Use `httpx` for async calls. Strictly forbid the `requests` library.

4. Environmental Integrations (MCP Connectors)

An AI agent trapped inside its own chat window is useless. By adopting the Model Context Protocol (MCP), your loop connects securely to your local and cloud infrastructure. Instead of outputting a code block for you to copy, an MCP-enabled loop can query a PostgreSQL database, pull a ticket down from Jira, write the code, and submit a Pull Request to GitHub autonomously.

5. Separation of Concerns (The Maker-Checker Decoupling)

The Golden Rule of Looping: The model that writes the implementation must never be the one that validates it.

If you ask an LLM to review its own broken code, it will easily talk itself into believing its logic is brilliant. You must decouple your system: use a highly creative model for the Maker (Execution stage), and route the output to a completely separate, highly pedantic prompt profile—or a different model family entirely—for the Checker (Verification stage).

6. Persistent State (The Ledger)

Because models are stateless across separate API calls, your loop needs an external brain. You maintain a structured state ledger on disk to record the history of the loop's trajectory. This prevents the agent from getting stuck in an infinite loop, trying the exact same failed regex fix over and over again.

DIY Snippet: State Tracking Ledger (`.agent/state_ledger.json`)

{
  "session_id": "MIGRATION_LOOP_v4",
  "target_goal": "Migrate user_id column from INT to UUIDv4 in production DB",
  "max_allowed_attempts": 5,
  "current_attempt": 2,
  "execution_log": [
    {
      "attempt": 1,
      "action": "Generated ALTER TABLE script using default cast",
      "gate_status": "FAILED",
      "error_payload": "ERROR: default for column cannot be cast automatically"
    },
    {
      "attempt": 2,
      "action": "Added explicit USING gen_random_uuid() clause to statement",
      "gate_status": "PENDING_VERIFICATION"
    }
  ]
}

Part 5: Hands-On DIY — Building a Python Loop Engine

Here is a complete, dependency-free Python implementation of a Closed-Loop State Machine.

This engine accepts a high-level goal, asks an LLM to generate code, writes that code to disk, executes the system's Python compiler as an objective quality gate, and forces the LLM to autonomously consume its own syntax errors and fix them until the gate clears.

import subprocess
import os
import json

def simulate_llm_call(system_prompt: str, user_prompt: str) -> str:
    """
    Simulates an API call to a frontier LLM (e.g., DeepSeek / Anthropic / OpenAI).
    In production, replace this with your actual SDK invocation.
    """
    # For demonstration, we simulate an LLM returning broken code on Attempt 1, 
    # and fixed valid code on Attempt 2 after reading the error feedback.
    if "SyntaxError" in user_prompt:
        return "def calculate_fibonacci(n: int) -> list[int]:\n    fib = [0, 1]\n    for i in range(2, n):\n        fib.append(fib[-1] + fib[-2])\n    return fib[:n]"
    else:
        # Intentionally broken syntax (missing a colon) to trigger the feedback loop
        return "def calculate_fibonacci(n: int) -> list[int]\n    fib = [0, 1]\n    return fib"

def execute_compiler_gate(file_path: str) -> tuple[bool, str]:
    """Runs a strict, non-AI verification gate (the Python syntax compiler)."""
    try:
        subprocess.run(
            ["python", "-m", "py_compile", file_path],
            capture_output=True,
            text=True,
            check=True
        )
        return True, "Verification Gate Passed: Zero syntax errors."
    except subprocess.CalledProcessError as err:
        return False, f"Verification Gate Failed:\n{err.stderr}"

def autonomous_agent_loop(goal: str, output_file: str, max_loops: int = 4):
    """The deterministic state machine governing the stochastic LLM."""
    print(f"🚀 Initializing Loop Engine...\nGoal: '{goal}'\nTarget: {output_file}\n")

    # Load system skills (guardrails)
    rules = "Write pure Python code. Do not include markdown formatting or explanations."
    context_accumulator = f"Target Goal: {goal}"

    for attempt in range(1, max_loops + 1):
        print(f"──► [Loop Iteration {attempt}/{max_loops}]")

        # STAGE 1, 2 & 3: DISCOVER, PLAN, EXECUTE (Maker Phase)
        print("    ⚙️ Maker Agent generating implementation...")
        prompt_payload = f"{context_accumulator}\nFollow these rules strictly:\n{rules}"
        generated_code = simulate_llm_call("You are an expert Python coding agent.", prompt_payload)

        # Commit work to isolated workspace
        with open(output_file, "w") as file_pointer:
            file_pointer.write(generated_code)

        # STAGE 4: VERIFY (Checker Phase)
        print(f"    🛡️ Executing compiler gate against {output_file}...")
        gate_cleared, gate_logs = execute_compiler_gate(output_file)

        if gate_cleared:
            print(f"    ✅ Exit Code 0: Output verified successfully on loop {attempt}! Shipping.")
            break

        # STAGE 5: ITERATE (Feedback Loop)
        print(f"    ❌ Gate Failed. Capturing stderr and injecting back into state...")
        # Mutate the state accumulator so the LLM reads its own error on the next pass
        context_accumulator += f"\n\nOn Attempt {attempt}, your code failed with this exact error:\n{gate_logs}\nRewrite the code to fix this specific compiler error."
        print("    🔄 Re-routing back to Stage 1...\n")
    else:
        print(f"🛑 CRITICAL: Loop exhausted all {max_loops} attempts without clearing verification gate.")

if __name__ == "__main__":
    autonomous_agent_loop(
        goal="Write a valid Python function to calculate the Fibonacci sequence.",
        output_file="fibonacci_service.py",
        max_loops=3
    )

Part 6: The Professional Divide

We are watching the software engineering job market bifurcate in real time:

Engineering Dimension	The Prompt Engineer	The Loop Engineer
Core Paradigm	Conversational input/output	State machines & Systems cybernetics
Primary Artifact	Multi-paragraph English text blocks	Automated verification gates & DAG workflows
Human Role	Manually drives iterations; copies terminal errors	Architects system flows; manages error escalation
System Output	A single, isolated probabilistic generation	A repeating, self-correcting verified outcome
Financial Optimization	Minimizing cost per individual chat prompt	Minimizing total compute cost per verified feature

The Ultimate Point of Leverage

As this technology scales across the industry, an uncomfortable reality is becoming clear: two software engineers can write the exact same agent loop and achieve completely polar opposite results.

The first engineer uses the loop as a force multiplier, deploying it to navigate and refactor complex architectures they already understand deeply. The second engineer uses the loop as an escape hatch, deploying it to avoid learning how the underlying codebase works at all.

The loop itself does not know the difference—but your production infrastructure certainly will.

Boris Cherny and Peter Steinberger are not telling us that software engineering just got easier. They are warning us that the fundamental point of leverage has shifted higher up the stack. We are no longer manual laborers carefully instructing a machine on how to swing a hammer. We are factory architects designing the automated assembly lines that inspect, reject, and refine their own output until it is structurally flawless.

Build the loop. But build it with the rigorous, uncompromising mindset of someone who intends to remain the master engineer—not just the person who presses the start button.

Still learning. Still building. Still curious. — Ram Bikkina | bikkina.vercel.app

The Day a 5-Minute Video Scared Me

Ram Bikkina — Sat, 20 Jun 2026 04:54:59 +0000

Couple of Days back, I decided to brush up on my system design concepts. Like many engineers, I have a few YouTube channels that I trust whenever I want to revisit fundamentals or refresh topics that I haven't looked at in a while.

I picked a two-hour system design course, made myself a cup of chai, and sat down for what I expected would be a productive evening of learning. Since I wasn't learning the concepts for the first time, I thought watching at 1.25x or 1.5x speed would help me move through the content more efficiently.

The video started, and within a few minutes I found myself checking my phone. I brought my attention back to the video, only to start skipping ahead whenever an explanation felt too detailed. A few moments later, I had another tab open, then another, and before I realized it, my focus was scattered across multiple screens.

When I looked at the timestamp, only five minutes had passed. What surprised me was that I had probably paid full attention for only two or three of those minutes. The rest of the time, my mind was jumping between distractions.

I eventually closed the video and told myself that I would come back to it later. As I sat there with my chai, a thought crossed my mind that was far more concerning than not finishing the course.

A few years ago, during my master's degree and even in the early years of my career, I could easily spend an hour watching technical lectures, reading documentation, or studying new concepts without feeling distracted. Learning deeply felt natural and effortless.

Now, I was struggling to stay engaged with a topic I genuinely wanted to learn for more than a few minutes.

That realization bothered me more than the unfinished video.

Maybe It's Not Just Me

The more I thought about it, the more I noticed similar patterns showing up in everyday life.

Perhaps you've experienced some of these situations too.

You open YouTube to watch a tutorial and somehow end up browsing comments, checking notifications, and jumping between recommended videos before finishing the original one.

You pick up your phone to reply to a message and find yourself scrolling social media ten minutes later without remembering why you unlocked your phone in the first place.

You begin reading an article that genuinely interests you, but halfway through, you realize your eyes have been moving while your mind has been somewhere else entirely.

You start watching a movie at home and instinctively reach for your phone during slower scenes, even though the movie itself is enjoyable.

You join an online meeting and notice yourself switching tabs whenever the conversation doesn't directly involve you.

None of these moments seem particularly serious when viewed individually. However, when they start appearing repeatedly throughout the day, they raise an uncomfortable question.

Are we slowly losing our ability to stay focused on one thing for an extended period of time?

Two Simple Experiments

Most of us don't need a scientific study or a formal attention-span test to answer that question.

Our daily habits are already revealing more than we realize.

Experiment 1: The Commute Test

The next time you're traveling in a train, metro, bus, cab, or even waiting at an airport, try keeping your phone in your pocket for the entire journey.

Instead of scrolling through social media, observe the people around you, look outside the window, notice conversations, buildings, weather, and the small details that usually go unnoticed.

Pay attention to how long it takes before you feel the urge to reach for your phone.

If sitting with your own thoughts for ten or fifteen minutes feels uncomfortable, that observation itself might be more valuable than anything you find on your screen.

Experiment 2: The Meal Test

The next time you sit down for a meal, try eating without YouTube, Netflix, television, podcasts, social media, or work on your laptop.

Simply focus on the food, the flavors, and the experience of eating.

Notice how often your mind searches for additional stimulation.

Many of us have become so accustomed to consuming content while eating that a quiet meal can feel strangely incomplete.

The purpose of these experiments isn't to judge ourselves. It's simply to notice how dependent we may have become on constant stimulation.

What Changed?

I don't think the issue is a lack of intelligence or curiosity.

If anything, we have access to more information than any generation in history.

The challenge is that we now live in an environment specifically designed to compete for our attention.

Every notification, short video, recommendation algorithm, breaking news alert, and endless feed is fighting for a small piece of our focus.

Our brains are constantly rewarded for switching attention rather than sustaining it.

As a result, we become incredibly skilled at consuming information quickly, but we spend less time sitting with a single idea long enough to truly understand it.

The modern world rewards speed, novelty, and instant gratification, while deep learning requires patience, repetition, and uninterrupted attention.

Unfortunately, those two forces are often moving in opposite directions.

Why This Matters for the Future

At first glance, struggling to focus on a YouTube video might seem like a minor personal problem.

However, the implications become much larger when we look beyond ourselves.

Engineers build complex systems that require months of deep thinking and problem solving.

Doctors spend years studying subjects that cannot be learned through short summaries.

Scientists, researchers, writers, entrepreneurs, and creators all rely on sustained attention to produce meaningful work.

If future generations grow up in environments where constant distraction becomes normal, the challenge won't be access to knowledge.

The challenge will be developing the patience required to transform information into understanding.

A society that struggles to focus may still consume enormous amounts of content, but creating new ideas, solving difficult problems, and producing meaningful innovation becomes much harder.

In many ways, attention may become one of the most valuable skills of the next decade.

Not because people lack information, but because very few people will be able to stay focused long enough to extract real value from it.

A Personal Realization

That evening, I didn't finish the system design course.

However, I walked away with a realization that felt more important than the lesson I intended to learn.

My problem wasn't a lack of motivation.

It wasn't a lack of interest.

It wasn't even a lack of time.

The real challenge was that my ability to focus had quietly weakened over time, and I hadn't noticed it happening.

Once I recognized it in myself, I started seeing signs of the same struggle everywhere around me.

The battle for attention is no longer happening only between social media platforms, streaming services, and technology companies.

It is happening inside our own minds every day.

Conclusion

I don't claim to have solved this problem, and I'm certainly not writing from a position of mastery.

In fact, this article exists because I'm still trying to understand and improve my own relationship with attention and focus.

One thing I do know is that attention behaves a lot like a muscle. If we stop using it, it weakens gradually. If we train it consistently, it becomes stronger over time.

As I think about improving my own focus, I'd like to spend more time reading without distractions, watching long-form content without constantly checking my phone, and creating space for moments of boredom instead of immediately filling them with stimulation.

Perhaps the most important lesson is that most of us don't need a formal test to know whether our attention span has changed.

Our daily habits are already giving us the answer.

The real question is whether we're paying enough attention to notice it.

Still learning. Still building. Still curious. — Ram Bikkina | bikkina.vercel.app

GoLang Developers Need Therapy Too, Bro !!

Ram Bikkina — Mon, 15 Jun 2026 05:59:56 +0000

Coming from Python and learning Go feels less like learning a new programming language… and more like getting personally attacked by the compiler every 3 minutes, bruh.

In Python, life is peaceful.

You write:

name = "Ram"
print(name[0])

Python lovingly responds:

Beautiful. Simple. Civilized.

Then Go enters your life.

You write:

myString := "Ram"
fmt.Println(myString[0])

And Go proudly returns:

Bro what is 82?

I asked for “R”, not a WiFi password.

Then the tutorial guy calmly says:

“Actually strings are UTF-8 encoded byte slices ☺️”

Bruh.

I just wanted the first letter.

And before recovering from that emotional damage, Go hits you with:

cannot assign to myString[0]

Apparently strings are immutable.

Cool.

No problem.

So how to change one character?

Python:

name = "Ram"
name = "Sam"

Done. Move on with life.

Go tutorial:

var builder strings.Builder

Bro why am I constructing buildings just to update a string?

Then comes pointers.

Every Go tutorial says:

“Pointers store memory addresses.”

Okay.

But why do I need my variable’s home address, bro?

Am I sending courier to RAM?

Then after 2 hours of suffering, one experienced Go developer finally explains:

“Pointers avoid copying huge data and modify original objects efficiently.”

NOW it makes sense.

That’s the entire Go learning experience, honestly.

Nothing makes sense…

until suddenly it does.

And the funniest part?

Python has been secretly doing half these things behind the scenes all along.

Go just removes the magic filter and says:

“Here bro. This is what your computer is actually doing.”

Another emotional moment is error handling.

Python:

try:
    dangerous_function()
except:
    print("oops")

Go:

result, err := dangerousFunction()

if err != nil {
    return err
}

At first it feels repetitive as hell.

Then one day you debug a production issue and realize:

“Ohhh bruh… this is actually very predictable.”

That’s when Go starts slowly winning you over.

Also, Go developers are a different species.

Python developers:

“Look how smart and compact my code is 😎”

Go developers:

“My code looks boring and that’s why it works, bro.”

And honestly?

That mindset starts becoming attractive after working on large systems.

The biggest trap while learning Go is expecting “developer comfort.”

Go does not care about your comfort, bruh.

Go cares about:

speed
clarity
concurrency
predictable behavior
production stability

It’s basically the strict gym trainer of programming languages.

Python says:

“Don’t worry buddy, I’ll handle it ❤️”

Go says:

“Do it yourself bro. Builds character.”

But after the frustration phase, something interesting happens.

You stop fighting the language.

You stop trying to write “Python in Go.”

And slowly you begin appreciating things like:

structs
explicit errors
goroutines
channels
type safety
simple deployment
insanely fast APIs

Then one day you accidentally write good Go code…

…and suddenly the compiler stops shouting at you.

That’s when you realize:

“Damn bruh… I think I’m becoming a Go developer.”

I Misspelled One Word and My AI Bill Jumped 400% 😱

Ram Bikkina — Sat, 28 Mar 2026 05:45:18 +0000

Think LLMs "read" like we do? Think again. Here is why your typos (and your code formatting) are costing you real money.

So, there I was, scrolling through Instagram late at night—probably when I should’ve been sleeping—and I saw a weird trivia post.

It asked: "Hello world" is 2 tokens, but "helloworld" is more than 2. Why?

My brain went into "problem-solving mode." I thought, Okay, "Hello world" is just two common words. But "helloworld" isn't a real word, so the AI has to chop it up into smaller pieces. It sounded like a good guess, but "good guesses" aren't enough for me. I wanted to see the actual math.

I jumped onto my computer, opened Cursor, and built a quick tool using gradio and some common AI "tokenizers" (the stuff that chops up words). I wanted to see exactly where the "cuts" happen and—most importantly—how much they cost.

Here is what I found.

Level 1: The "Lego" Rule (Spaces and Caps)

First thing I learned? AI models are obsessed with patterns. If you break the pattern, you pay for it.

For us, "apple" and "aPpLe" mean the same thing. But to an AI? One is a common fruit it knows well. The other is a weird string of letters it has to piece together like a jigsaw puzzle.

Just by changing the capital letters, I tripled the "work" the AI had to do. It’s like trying to read a book where every third letter is capitalized—you can do it, but it’s way slower and more "expensive" for the brain.

Level 2: The "Typo Tax"

This is the part that actually surprised me. I tested a normal word like "environment" against my favorite typo, "envinorment." I always knew typos made me look a bit messy, but I didn't realize they were actually making my AI bill higher.

The word "environment" is so common that the AI sees it as one single unit. But as soon as I swapped two letters, the AI panicked. It couldn't find the whole word in its dictionary, so it had to use four different "bricks" to build it.

The result? A 400% jump in token usage for the exact same meaning. If you’re building an AI app and your users have bad spelling, you’re literally burning money on typos.

Level 3: Shortcuts That Backfire

I also tested how we talk in real life. We use "btw" instead of "by the way" to save time. But does it save money?

"By the way" = 3 tokens.
"btw" = 1 token.

Cool, slang works there! But then look at "knowledge" (1 token) vs. "knwldg" (4 tokens). Even though "knwldg" is shorter for us to type, it’s "noisier" for the AI because it’s not a common pattern. It ends up costing more!

The simple rule of thumb: 1 token is usually about 4 letters of normal English. But as soon as you add weird symbols, extra spaces, or code, that rule breaks.

Level 4: The "Senior" Reality Check (Code, Emojis, and Unicode)

As an engineer & backend dev, this is where things get really interesting. If you think a 400% jump is bad, wait until you see what happens when we step outside of standard English or start piping JSON data.

1. The JSON/Code Overhead

We love clean, readable code. But "pretty" JSON is an AI budget killer. Look at the difference:

{"key":"value"} — 5 tokens
{ "key" : "value" } — 9 tokens

By simply adding spaces inside those brackets for "readability," I doubled the cost of the payload. When you're sending thousands of API calls, those spaces aren't just whitespace; they're line items on your invoice.

2. The Unicode Trap (Telugu vs. English)

This is where the bias of modern AI really shows. Most tokenizers are based on UTF-8 but are heavily trained on Latin scripts.

English: "Hello" — 1 token
Telugu: "నమస్కారం" — ~8 tokens

Because a single Telugu character often requires multiple bytes to represent in Unicode, the tokenizer has to "sub-divide" the character multiple times. For Indian developers, this "token bloat" means building apps for local languages can be 6-10x more expensive than building for English.

3. The Emoji "Combo"

Think an emoji is just one character? Think again.

"😀" — 1 token
"🏳️‍🌈" — 4 tokens

The Pride flag isn't a single "brick." It’s a Zero Width Joiner (ZWJ) combo—it’s actually a Rainbow emoji + a special invisible character + a Flag emoji. The AI has to process the entire sequence to understand it's one symbol.

It’s fascinating to see how complex emojis "mutate" from simple ones. If you want to see the "DNA" of an emoji for yourself, run this quick Python script. It’s a fun way to see exactly how many hidden characters are hiding inside a single icon:

s = "🏳️‍🌈"
for c in s:
    print(c, hex(ord(c)))

When you run this, you'll see the Rainbow, the variation selector, the joiner, and the flag all listed out separately. To the AI, that's not one "vibe"—that's a whole sentence of data!

So, what did I learn?

Building this tool showed me that AI doesn't "read" words like we do. It looks for the easiest way to chop things up.

If you want to save money and get better results:

Clean your text. A simple spell-check before you send text to an AI can save you 400%.
Minify your JSON. If the AI is the only one reading the data, remove the spaces.
Be mindful of Unicode. If you're building for Indic languages, factor in the "token tax" during your budget planning.

I’m going to keep testing my tool to see what else I can break.

If you found this breakdown useful, feel free to stalk my profile for more deep dives into the weird world of AI engineering.

For the full picture of what I’m building, check out my portfolio at bikkina.vercel.app. Catch you in the next one! 🚀

The “Jurassic World” Rule is simple: Don’t try to outrun the raptor. Train it.

Ram Bikkina — Sat, 14 Mar 2026 05:16:29 +0000

In Jurassic World, there’s that iconic scene where Owen Grady (Chris Pratt) stands in a cage with three Velociraptors. He doesn’t run. He doesn’t try to punch them. He stands his ground, uses clear signals, and manages their instincts toward a goal.

The AI we have today is that raptor.

If you try to compete with it on raw speed, memory, or typing, you’re just another human running in the open field.

If you learn to control it, direct it, and monitor it, you suddenly become the person nobody can afford to lose.

Agentic AI + MLOps?
That’s your clicker.

1. AI is the raptor, not a calculator

Most people still think of AI as a “smart calculator that talks”. That was true for early chatbots. Now it’s way more. Agentic AI systems can:

plan tasks,
call tools and APIs,
read/write from databases,
loop, retry, and adapt based on feedback.

This is not just “give me an answer and stop”.

This is “here’s the goal, figure out the steps, go do things”.

So if your skill is only:

writing boilerplate code,
writing average content,
doing basic office tasks on a keyboard,

you are standing in front of a very hungry raptor.

You might survive a few scenes, but not the whole movie.

2. Walking blindly vs walking silently behind AI

Let’s break it into two types of people.

Walking blindly with AI

This is what most people are doing right now:

“I’ll just use ChatGPT/Copilot to code faster.”
“I’ll be a ‘prompt engineer’ and that’s my whole identity.”
“I don’t care how this thing is deployed, monitored, or controlled. It just works, right?”

On the surface, this feels smart. You’re productive. You’re fast.

But here’s the problem:

Hundreds of thousands of people can do this.
Tools are getting better every month.
Companies will simply need fewer people in this category.

You are competing with the raptor, in the same lane.

Walking silently behind AI

This is a smaller group. This is where you want to be.

These people say things like:

“I want to design how AI fits into the system, not just call the API.”
“I care about data pipelines, monitoring, guardrails, and failures.”
“I want to be the person who owns the whole AI workflow end‑to‑end.”

They are not trying to be “more AI than AI”.

They are the ones:

holding the clicker,
defining the fences,
deciding what the raptor can and cannot touch.

That’s Agentic AI + MLOps in one line:

You don’t try to beat AI.

You learn to orchestrate it and operate it.

3. What is Agentic AI (in human words)

Agentic AI is just AI that can act more like a doer than a typer.

Instead of:

“Here’s a prompt, give me one answer.”

It’s more like:

“Here’s a goal. Figure out what needs to be done, use these tools, and come back with a result.”

An agent can:

break a big goal into small steps,
choose which tool or API to call next,
loop until it’s done,
remember previous attempts and improve.

Examples:

A recruiting agent that reads resumes, checks ATS, books interviews, and emails candidates.
A support agent that reads tickets, looks up docs, drafts replies, and tags the right team.
A devops agent that watches logs, raises incidents, and opens Jira issues.

Your job with agentic AI is NOT just writing fancy prompts.

Your job is to:

decide the tools it can use,
design the flow (what comes first, what comes next),
add rules where humans must approve actions.

You’re basically training the raptor to hunt the right targets, in the right area, under your rules.

4. What is MLOps (your ops team for the raptor)

Now imagine you have a powerful agentic system running.

Without MLOps, it’s chaos.

MLOps is “DevOps + data + ML + common sense”.

It answers questions like:

Where does the data come from, and is it clean?
How do we train models again and again, and track which version works best?
How do we deploy models safely?
How do we monitor them in production?
How do we roll back when something breaks?

Core ideas in MLOps:

Data pipelines: repeatable ingestion, cleaning, and transformation.
Experiment tracking: log metrics, parameters, and model versions.
Model deployment: APIs, containers, scaling, rollouts.
Monitoring & alerts: watch performance, drift, errors, and user feedback.

If Agentic AI is the raptor,

MLOps is:

the cage,
the control room,
the CCTV,
and the emergency shutdown.

When you combine both, you don’t just “play with AI”.

You run AI.

5. Why this combo is hard to replace

Let’s be blunt.

AI will eat a lot of:

basic coding tasks,
generic content creation,
routine office workflows.

But it struggles badly with:

messy, real‑world systems,
responsibility and risk,
long‑term maintenance and trade‑offs.

Companies will always need humans who can:

understand the business problem,
design AI + data + infra around it,
manage cost, safety, and compliance,
debug and improve things when they break.

These are the roles that sit in the “safe, top 1%” zone:

AI / ML Platform Engineer
MLOps Engineer
AI Systems / Agent Orchestrator
Data + AI Engineer

These people:

don’t panic when a model changes,
don’t disappear when a new tool launches,
become more valuable as AI gets stronger.

Because the stronger the raptor, the more important the trainer.

6. So how do you skill up for this?

Here’s a simple path if you’re a newcomer or someone who wants a Plan B in the AI era.

Step 1: Get comfortable with LLMs (not obsessed)

Learn the basics of prompts, tools, and RAG (retrieval‑augmented generation).
Call at least one hosted API (OpenAI/Gemini) and one open model (Hugging Face).

Goal: you can explain where an LLM fits in a system, and where it doesn’t.

Step 2: Learn data and pipelines

Play with raw CSV/JSON and turn it into clean tables.
Learn what ETL/ELT is and use a simple scheduler (Cron/Airflow/Prefect).

Goal: you can build a small pipeline that runs every day, cleans data, and stores it.

Step 3: Learn MLOps basics

Understand the ML lifecycle: data → train → deploy → monitor.
Try:
- tracking experiments,
- saving model versions,
- deploying a model behind an API.

Goal: you can take a simple model and run it as a service with logs.

Step 4: Learn agentic patterns

Understand what makes an AI “agentic”: goals, planning, tools, memory.
Use an agent framework (like Crew or LangGraph) to:
- connect tools (APIs, DB, search),
- define workflows (step 1 → step 2 → step 3),
- add points where humans approve actions.

Goal: you can design a small agent flow on paper and then implement it.

Step 5: Build one small but real system

For example:

An AI support assistant that reads tickets, does RAG on docs, drafts replies, and logs everything.
Or an AI ops bot that watches logs, flags incidents, and opens issues.

Make sure your project includes:

data ingestion and cleaning,
at least one model (even a simple one),
an agent or tool‑using LLM,
deployment, logging, and basic monitoring.

Now you’re no longer “just another dev using AI”.

You’re the rooftop person with the clicker.

7. Final mindset: be the person holding the clicker

AI is not going away.

It’s getting faster, cheaper, and more capable.

So your choices are basically:

Stand in front of it and try to compete on speed → get outrun.
Or move slightly behind it, study it, and learn to direct it.

Agentic AI teaches you how to make AI act.

MLOps teaches you how to keep it safe, reliable, and useful.

Put those together, and you’re not food.

You’re the trainer.

You don’t need to be the loudest person in the AI hype.

Just walk silently behind the beast, run the systems, and let everyone else realize — a little late — that you’re the one who actually keeps the park running.

Why Simple is Winning Again.

Ram Bikkina — Sun, 22 Feb 2026 04:56:43 +0000

If you work in backend engineering, you know the drill. For the last ten years, the answer to every scaling problem was "Microservices."

The idea was seductive. Break your big, scary application into tiny, independent pieces. Each piece does one thing well. They talk to each other over the network. If the "Payments" service crashes, the "Browse" service keeps working.
It sounded like the perfect architecture. We all wanted to be like Netflix.

But recently, the industry woke up with a massive hangover. We realized that for many of us, microservices didn't solve our problems. They just replaced them with different, harder problems.

Now, the pendulum is swinging back. Not to the bad old days, but to something smarter.

The Old Enemy: The Spaghetti Monolith

To understand why we left monoliths in the first place, we have to remember what they used to look like.

Before microservices, we built what I call "Spaghetti Monoliths." This was one giant codebase where everything was tangled together.

The code for processing orders would directly reach into the database tables for user profiles. The shipping logic was mixed in with the billing logic.

It was a nightmare.

If you changed one line of code in the "User" section, you might accidentally break the "Checkout" flow. You couldn't be sure. Deployments were scary. You had to deploy the entire massive beast at once, crossed your fingers, and hoped nothing broke.

We ran away from this mess and embraced microservices.

The Turning Point: Amazon Prime Video

The moment everyone really started questioning microservices happened in 2023. The Amazon Prime Video engineering team published a blog post that shocked everyone.

They had a specific service used for monitoring audio and video quality. It was built using a modern, distributed microservices architecture (using AWS serverless functions). It was supposed to be scalable and cutting-edge.

Instead, it was expensive and slow.

Because the service was broken into so many tiny pieces, the components spent most of their time just talking to each other across the network. They were paying a fortune for data transfer between these small services.

So, they did the unthinkable. They merged all those microservices back into a single monolithic application.

The results were staggering. They reduced their infrastructure costs by 90%.

Because everything was now in one process, there was no network lag between components. It got faster. It got cheaper. It was easier to manage.

Amazon proved that sometimes, "modern" architecture is just over-engineering.

The New Hero: The Modular Monolith

So, are we going back to the Spaghetti Monolith? No way.

We are moving toward the Modular Monolith.

Think of it as the best of both worlds. You still have one single codebase. You deploy it as one unit. You have one database.

But inside that code, you draw strict lines.

You create distinct modules, like "Billing," "Inventory," and "Users."

Crucially, the "Billing" module is not allowed to directly touch the "Inventory" module's code or data tables. If "Billing" needs information from "Inventory," it must ask nicely through a clean, internal code interface.

It’s like having microservices, but instead of talking over a slow, expensive network connection, they talk via super-fast, in-memory function calls.

What It Looks Like in Code

Here is a very simplified example using Python (FastAPI).

In a spaghetti monolith, everything would be in one 5,000-line file.

In a modular monolith, your main file just acts as glue holding distinct, organized sections together.

You would have a folder structure like this:

/src
  /modules
    /users (contains router.py, service.py, models.py for users only)
    /payments (contains payment logic only)
    /products (contains product logic only)
  main.py

Here is how simple the main.py looks. It doesn't know how payments work; it just knows where the payment module lives.

from fastapi import FastAPI

# We import the routers from our distinct, separated modules.
# These modules do not directly touch each other's internal code.
from src.modules.users import user_router
from src.modules.payments import payment_router
from src.modules.products import product_router

app = FastAPI()

# The main app just mounts these pre-built modules.
# This is one single deployable application.

app.include_router(user_router.router, prefix="/users", tags=["Users"])
app.include_router(payment_router.router, prefix="/payments", tags=["Payments"])
app.include_router(product_router.router, prefix="/products", tags=["Products"])

@app.get("/")
async def root():
    return {"message": "The modular monolith is running smoothly."}

Why does this work?

If you need to debug a payment issue, you know exactly which folder to look in. If the "Payments" module gets too big in two years, it is already organized with clean boundaries. You can easily "snip" it out and turn just that one part into a microservice later.

Pros and Cons Quick View

Feature	Microservices	Modular Monolith
Complexity	High. Lots of moving parts.	Medium. Just needs discipline.
Performance	Slower due to network calls.	Very fast internal calls.
Cost	Higher infrastructure overhead.	Lower. You pay for compute, not chatter.
Debugging	Hard. Tracing requests across services is painful.	Easy. It's all in one place.
Team Scaling	Good for 500+ developers.	Good for small to mid-size teams.

When To Choose What

The industry has realized we were using microservices to solve organizational problems, not technical ones.

Choose a Modular Monolith if:

You are a startup building an MVP. Speed is everything.
You have a small to medium-sized engineering team (under 50-100 people).
Your domain is not yet fully defined. Monoliths are easier to refactor than distributed systems.

Choose Microservices if:

You are Google, Netflix, or Uber.
You have 50 distinct teams that keep stepping on each other's toes in the same codebase.
You have one specific feature (like video transcoding) that needs vastly different hardware resources than the rest of the app.

The Takeaway

Don't use microservices just because it's trendy. Complexity is the enemy of speed.

Start with a clean, well-organized modular monolith. It will serve you well for a long time. If you eventually hit massive scale, you’ll be ready to split it up. But don't pay the microservice tax until you actually need to.

Part of the journey is the end… until the next new chapter :::: Tathāstu.

I’m Ram Bikkina, and I turn complex backend trends into simple, layman-friendly guides. Stalk my profile for more articles.

Something Big Is Happening

Ram Bikkina — Thu, 12 Feb 2026 05:48:52 +0000

Note: This is a condensed and rewritten version of Matt Shumer's Something Big Is Happening.

The Calm Before the Global Reset

Do you remember early 2020? Life felt totally normal. We were planning summer vacations, complaining about the commute, and going to crowded concerts. Even though there was some news about a virus overseas, most of us just shrugged it off. Then, in just a few weeks, the world hit the "pause" button. Offices locked their doors, schools went virtual, and our entire way of living changed overnight.

I’m getting that same "quiet before the storm" feeling again. But this time, it’s not a virus. It’s Artificial Intelligence.

I’ve been working in the AI world for six years. I build these tools and invest in them. Usually, when people ask me what’s going on with AI, I give them the "polite" answer—that it’s a helpful assistant. But the truth is much more intense. We are currently in the middle of a massive shift that is going to change your job and your life much faster than you think.

Why February 5, 2026, Changed Everything

For a long time, AI was getting better in small, predictable steps. But recently, something broke open. On February 5, 2026, we saw the release of two massive models: GPT-5.3 Codex and Claude Opus 4.6.

These aren't just "smarter chatbots." They represent a jump from AI as a tool to AI as a worker.

Here is what that looks like in the real world:
Last year, if I wanted to build a web app, I would use AI to help me write specific functions or fix bugs. Now? I just tell the AI: "I want a subscription-based platform for dog trainers that handles scheduling and payments." Then, I walk away. I go grab lunch. While I’m gone, the AI:

Designs the entire user interface.
Writes thousands of lines of code.
Actually opens the app and clicks the buttons to see if they work.
Fixes its own mistakes without me saying a word.

When I come back, the product is finished. It’s not a "first draft"—it’s better than what a team of human developers would have built in a month.

The Feedback Loop: AI Building AI

The reason this is moving so fast is simple: AI is now helping us build the next version of AI.

OpenAI recently admitted that GPT-5.3 was used to debug its own training and manage its own deployment. This is what experts call an "intelligence explosion."

Step 1: We build a smart AI.
Step 2: That AI writes better code to make the next AI even smarter.
Step 3: The process repeats, but at a speed no human can match.

Is Your Job Safe? (The Brutal Truth)

If you work on a computer—if your job involves reading, writing, analyzing data, or making decisions—the ground is shifting under your feet.

We used to think AI would only do the "boring" stuff. We were wrong. The newest models are showing judgment and taste. They can understand nuance.

Let’s look at some examples:

Lawyers: Instead of just searching for cases, AI can now analyze a 100-page contract, find the hidden risks, and draft a counter-proposal that sounds exactly like a senior partner wrote it.
Accountants: It’s no longer just about filling out spreadsheets. AI can look at a company’s entire financial history and spot tax-saving strategies that a human might miss.
Marketers: AI can now create an entire brand identity—logos, social media copy, and ad strategies—that actually "feels" right for a specific audience.
Medical Staff: AI is already outperforming humans at reading complex MRI scans and suggesting rare diagnoses.

Dario Amodei (CEO of Anthropic) recently suggested that 50% of white-collar entry-level jobs could be automated in the next few years. This isn't a "maybe" anymore. The capability is already here.

How to Stay Ahead: A 3-Step Plan

I’m not telling you this to scare you. I’m telling you this so you can be the person who survives and thrives. The biggest advantage you can have right now is being early.

1. Stop Using the "Lite" Versions

If you are using the free version of ChatGPT, you are using "ancient" technology. It’s like trying to understand the internet while using a dial-up modem. Pay the $20 a month for the premium models (GPT-5.2/3 or Claude Opus 4.6). You need to see what the "ceiling" of this technology actually looks like.

2. The One-Hour Daily Habit

Spend 60 minutes every single day trying to break your job. Take the hardest, most complex task you have and see if the AI can do it. Don't just ask it a question; give it a 50-page PDF and ask it to find the contradictions. If it fails today, try again in three months. The person who knows how to "steer" the AI will be the most valuable person in the company.

3. Build Your Resilience

If your income depends entirely on a screen-based job, start thinking about a "Plan B."

Focus on Relationships: AI can't replace the deep trust you have with a client.
Lean into Accountability: AI can give advice, but a human still has to sign the legal documents and take responsibility.
Get Hands-On: Physical, real-world skills are much harder for AI to automate (for now).

The Big Picture

We are looking at a future where AI might cure cancer and solve aging within our lifetimes. But we are also looking at a world where the economy as we know it might break.

The "normal" world of 2025 is gone. You can either ignore what’s happening and hope for the best, or you can start learning these tools today.

The future isn't coming in a decade. It’s already here. It just hasn't reached your office yet.