Shivam Verma

Backend Engineer | Go & AI Systems
Building reliable backend systems with Go, TypeScript & Python. Learning in public.

[Shivam Verma @Shivam_v99]

@deep_poharkar https://t.co/IwNsUdGt2s

[Shivam Verma @Shivam_v99]

@tyagi_Shashankk @Bansalm2708 That would be interesting each LLM would try to prove it’s the best, but it should also know its limit: “kitna girna hai 😂” without compromising the output quality.

[Shivam Verma @Shivam_v99]

Today I experimented with something interesting.

So basically, me and Mohit were having a chat with ChatGPT, and after a few minutes of discussion, Mohit asked GPT:

“How can multiple models bid for a deal?”

Context:

Suppose I have a task — reverse a linked list.

I ask both models to bid on the task based on how many tokens they think they will consume.

The model which takes fewer tokens wins the battle, and we use that model to actually perform the task.

Here is the exact prompt I used:

like u have deal to task u reverse a linked list and u will get me how much token u consume. same thing codex will do .. like if codex gives less token amount then u will bargain on your amount .... and have to crack deal such that codex should not crack the deal

And then the debate started.

Claude started with a bid of 90–110 tokens.

Then Claude dropped it to 70 tokens.

The first bid from both models was just an estimation. In the second pass, both actually calculated the tokens required to complete the task.

Claude: 211 tokens
Codex counter: 150 tokens
Third pass:

Claude: 135 tokens
Codex: 127 tokens

Fourth pass:
Claude finally dropped to 115 tokens...

And Codex got taken down. 😂

Why was I experimenting with this?

Because all of us are using multiple models — Opus, GPT, Codex, etc. — and sometimes we use an expensive/powerful model for a stupidly simple task.

The interesting part is:

We can't really predict token usage beforehand because we don't know exactly how much input/output the task will generate.

So instead of trying to predict it...

What if we make the models compete for the task?

Give the same task to multiple models → let them estimate/bid → negotiate → pick the cheapest model that can still do the job.

It could be an interesting way to optimize token usage across multiple models.

Basically, the idea came from Mohit.

After all, he is a bania and we all know why. 😂

[Shivam Verma @Shivam_v99]

@0xkasana Congratulations bro

[Shivam Verma @Shivam_v99]

@ramxcodes

[Shivam Verma @Shivam_v99]

Instead of just reading about how Redis works, I decided to build one from scratch in Go.

So far, I’ve built a small Redis-like server with TCP connections, support for multiple concurrent clients,

an in-memory key-value store, and basic SET/GET commands.

I also built a custom CLI client to connect to the server and interact with it from the terminal.

Being able to set a value through the client and retrieve it again from the server makes the whole project feel much more real.

It’s still a simple implementation,

but it’s already helping me understand what’s happening under the hood instead of treating Redis as a black box.

Next up: adding key expiration with TTL and figuring out how to persist data so it survives a restart.

[Shivam Verma @Shivam_v99]

One of the more interesting things I worked on this week was designing a folder structure for an asset management system.

At first, I thought:

"Just create a folder table with id, name, and parent_id."

But once I started thinking about how the system would actually be used, the schema became much more intentional.

I ended up designing the model around a few questions:

Who owns this?

owner_id tells us who the folder/file belongs to and gives us a clear boundary for access and organization.

What is this?

type separates FILE and FOLDER.

This sounds obvious, but it gives the system an explicit way to distinguish containers from actual assets instead of relying on nullable fields or assumptions.

Where does it live?

parent_id creates the hierarchy.

A folder can belong to another folder, which gives us a tree structure instead of a flat list.

What does it contain?

global_asset_id connects a FILE node to the actual asset it represents.

Folders don't need this relationship, so it stays null for them.

How should we organize it?

category gives the folder structure another dimension:

AUTO | PROP | CHARACTER | LOCATION
Instead of dumping everything into one giant hierarchy, assets can be organized according to their domain.
Then there are the fields that make the system usable in production:
created_at / updated_at → track changes and lifecycle.

deleted_at → soft delete instead of immediately destroying the record.

And finally:

description

Not every folder needs one, but when the name isn't enough, metadata gives users additional context.

What I liked about this exercise is that none of these fields were added just because "a folder table usually has them."

Each field answers a specific question about the system.

And that's something I'm slowly learning about schema design:

**A good schema isn't a collection of fields.

It's a representation of the rules and relationships of your domain.**

[Shivam Verma @Shivam_v99]

@kmadhav824 That i usually do after understanding complete flow of the implementation

[Shivam Verma @Shivam_v99]

Today I used Claude to build 4,000+ lines of code.

But this time, I changed my process completely.

Before writing code, I created a detailed .md file covering:

→ Database schema + why each field exists
→ Relationships between tables
→ APIs the feature would need
→ Request inputs and outputs
→ Query parameters

Then, for every API, I kept asking:
What data do we actually need in this request?
I designed the architecture first, then asked Claude to challenge it.

We went back and forth, questioned assumptions, changed parts of the design, and eventually ended up with a much better architecture.

Only then did I start implementing.

The biggest difference?

I wasn't trying to understand 4,000 lines of AI-generated code line by line.

I understood what I was building, why it was designed that way, and how the pieces fit together.

That made reviewing the generated code dramatically easier.

It also made me realize something:

Maybe the key to using AI coding agents effectively isn't reading every line they generate.

Maybe it's thinking deeply before they generate it.

How do you make sure you actually understand the code when using AI coding agents?

[Shivam Verma @Shivam_v99]

Today I wrote ~8,000 lines of code using Claude.

I understand the complete architecture, what I’m building, and why the different pieces exist.

But I still haven’t understood every line of code deeply.

And this question keeps coming back to my mind:

How do you guys make sure you actually understand the code you’re writing when using AI coding agents?

What’s your process?

Would genuinely love to hear how experienced engineers deal with this.

[Shivam Verma @Shivam_v99]

Worked on data migration planning this week.

Instead of immediately writing a migration script, I mapped out:

→ Where the existing data lives
→ How the records relate to each other
→ What needs to change
→ How the new structure should look
→ What happens if something fails midway

I'm learning that migrations aren't just scripts.
They're temporary distributed systems that need to survive reality.

[Shivam Verma @Shivam_v99]

Spent today thinking I was doing architecture.

Ended up staring at one database migration for 3 hours wondering:

“Who gave me permission to touch production data?”

[Shivam Verma @Shivam_v99]

Built a reusable frontend module this week.

Started with the basics:

→ API integration
→ Shared types
→ Data fetching
→ Asset previews
→ Lazy loading

Then integrated it into an existing application.

I’m starting to appreciate how much good frontend architecture is about keeping reusable pieces isolated without making them unnecessarily complicated.

[Shivam Verma @Shivam_v99]

Spent some time this week cleaning up TypeScript technical debt.

Reduced hundreds of any usages to just a few dozen by replacing them with proper types and unknown where appropriate.

What looked like a simple cleanup turned into a reminder:

If you don't understand the data flowing through your system, you don't really understand the system.

Typing forces you to confront that.

[divyansh @divyansh_1729]

i still use ChatGPT for my day-to-day basic work..
am i behind?

[Shivam Verma @Shivam_v99]

Do you know the actual difference between a senior engineer and an engineer?

I think I got a small taste of it today.

I'm redesigning the Creative Asset Manager at @PoiroAI.

We have multiple apps that produce assets, and historically, each app stored its assets in its own table.

I'm now working on unifying everything into a single global asset system.

The plan seemed straightforward:

Create the global asset
Add global_asset_id to the existing asset records
Migrate the data
Update reads to join with the global asset

Then I started thinking about the migration.

The migration could take hours because we're dealing with large video/audio assets.

And here's the problem I completely missed:

What happens if a new asset is created in one of the old tables while the migration is still running?

Now you have:

→ Assets already migrated
→ Assets still waiting to be migrated
→ New assets created during migration
→ Potential inconsistency between the old and global systems
I literally stopped and thought:
How did I not think about this?
And this is probably one of the biggest differences between writing code and engineering a system.

The happy path is easy.

The real engineering starts when you ask:

"What happens while this is happening?"

Now I need a migration strategy with a proper failover/reconciliation mechanism instead of assuming the migration is a one-time operation.

Today was a good reminder that architecture isn't just about designing how a system works.

It's about thinking through how the system behaves while everything is changing.

[Piyush Garg @piyushgarg_dev]

Software engineering in the AI era is getting crazy - and honestly, a little scary.

Recently, we were integrating Stripe for billing/subscriptions.

Instead of using Stripe’s native subscription system, we built our own layer for managing credits, carry-forwards, and usage, while Stripe was essentially just the payment gateway.

This credit system was once carefully designed, handwritten, reviewed, tested, and had become a pretty stable piece of infrastructure.

Now comes the crazy part.

Stripe’s documentation is increasingly becoming AI-native. The assumption seems to be that an AI agent will read the docs, figure out the implementation, and write the code.

And it actually works.

Critical systems like billing and payments are now being built with AI, and they just… work.

The weirdest part?

I have the high-level architecture in my head, but sometimes barely know where the code lives, how all the pieces work internally, or why certain implementation decisions were made.

We’re moving from:
“I wrote this system.”
to
“I designed this system, and AI implemented it.”

Software engineering is changing faster than our mental models of what a software engineer actually does.

[Shivam Verma @Shivam_v99]

@JCMAppStudio Thanks for the discussion man it really helped me a lot

[Shivam Verma @Shivam_v99]

Today I wrote ~8,000 lines of code using Claude.

I understand the complete architecture, what I’m building, and why the different pieces exist.

But I still haven’t understood every line of code deeply.

And this question keeps coming back to my mind:

How do you guys make sure you actually understand the code you’re writing when using AI coding agents?

What’s your process?

Would genuinely love to hear how experienced engineers deal with this.

[Shivam Verma @Shivam_v99]

@JCMAppStudio Exactly

[Shivam Verma @Shivam_v99]

@JCMAppStudio Make sense in case of db level stuff is involved

[Shivam Verma @Shivam_v99]

@0xkasana That's great @0xkasana will try to use it, thank you