I was invited to take an hour long session to the engineering leadership at Razorpay. I work as the "AI Builder" profile where I am basically brains and extra fingers for my boss Shashank (SHK). Armed with unlimited tokens of the strategy team, we play with frontier ideas that are not yet mature to be handed to Eng + Product teams.

In less than 3 months I've delivered over 3 projects and this tells you about the speed at which the company operates. A single project can be over 50 agents, 1 Billion tokens, 500+ test cases. And with all the token burning I've come to understand a few things that work well. Here's my story that maybe helps in getting you up to speed on the agentic development.

"When predicting future, it's easier if you know things which will not change." - Jeff Bezos

If you are completely new to this then start with handrolling your own agentic loop to understand new fundamentals like caching, tool call loops, structured generation, event hooks, CLIs vs. SDK. Feel free to use claude to build something on top of open weight models from OpenRouter and understand how the tool you use every day actually works.

First let me tell you about my setup. I use Claude code (20x) which is my daily driver, OpenAI codex (20x) and toroid-kernel. Preferred models are opus (planning + general chat), gpt-5.6-sol (coding) and kimi/glm/haiku (workflows). I am not an AI maximalist, the only multiagent setup I use is offloading tasks from claude to codex using the /codex skill from gstack. I use python for scripting and Go + HTMX for backend.

So here goes the learnings and I'll spend a minute explaining all of them.

Lesson 1: Write your own README

The easiest thing is to pick a md file that only you write, not an AI. This is not the CLAUDE.md file which is a pointer file for your agent. Your md file contains the goals you want with the project. Not 40 APIs, the 12 that actually matter. Inside Razorpay we use our internal documentation system called aidocs to generate detailed HTML documents (why limit yourself to markdown). This md file contains the pointers so that important things like deferred ideas, open questions are always present for you to read. At some point you have to write your own thoughts.

Lesson 2: AI maxxing actually works

Claude 20x and Codex 20x plans give you enough tokens. According to SemiAnalysis spending $400 (exc. taxes) you get about $22,000 of API tokens. This is enough for you to make your biggest projects come to life. And I don't mean start ultracode and see 100s of subagents, but some care can take you places. Open weight models like glm-5p2 have replaced sonnet because of cheaper but effective token quality.

Lesson 3: Go the extra mile, use AI for craftsmanship

Talking about care, in general SDEs are not empaths, they are given a task from the roadmap and they deliver it. AI is a bias amplifier, and biases are not always wrong. In one of the projects I worked on, we wanted to capture more information about a profile. We go beyond just a simple search, we read their code, marketing blogs, founders thoughts, etc. Some companies and people are bad at communication, so look at their work. This resulted in surfacing profiles that were easily missed before. With AI there is no longer an excuse to not deliver good software.

Lesson 4: Don't ship shitty software

Talking about no more excuses. With agents it is so easy to push slop. But that still doesn't justify why SDEs push software that does not work. For one of the projects we had to simulate network traffic and I did not want to configure locust. Claude was able to create test accounts, understand traffic pattern from real world logs, mock clients and finally clean up artifacts in the DB & S3. Agents are connected to CI/CD, automatically deploy on dev and do blue/green till all the tests are passing.

Lesson 5: Source of truths and autoloops

I said before that writing is the most important thing you can do. With kubectl you apply the final state that you want, and the system figures out how to reach that state. Working with AI agents is pretty much the same. Except now your state resides in detailed tech and product specs. You work (with your team) to make your destination clear, what kind of governance modules are required, what does the queue architecture look like. As people deploy bigger applications, system design is more important than ever.

Once you get to a spec you are happy with, setup loops to achieve that goal. Tell AI not to stop till it reaches that, keep pushing it to do adversarial review using another LLM + harness and refine the approach.

Truth is LLMs already contain the intelligence, it is about figuring out how to get it out. Karpathy's Autoresearch is a good hello world into how to build loops. Based on how you frame it, it can be used in software, marketing, supply chain, etc. Here's the setup in brief:

1. Define a surface area (e.g. pkg/, internal/)
2. validation (e.g. tests/, training script)
3. metric to go up (e.g. test coverage) or down (e.g. latency, loss).

Lesson 6: Run things overnight, your agent does not need to sleep

Autoloops might look nice, but they are the only approach that work over super long time horizons. Eventually any task can be framed as such. Ask yourself the question: "What is the hardest problem I can solve that no one else would have tried to solve". "How would I know with confidence that a direction is good?". These are not easy questions to answer and soon you'll understand you are limited by your vision.

Lesson 7: Skills that evolve with needs better than forced structure

"If all you have is a hammer, then everything looks like a nail".

Not everything you read on X is perfect. If your problem is not loops, don't use them. If you don't use multiagents, then don't. If you don't have large budget, then don't use Opus. Your situation is unique and your automation depends on your needs. Practices that evolve out of needs have a better utilization rate than forced principles. Find your own path.

Lesson 8: Everyone is a developer

Back in the day (6 months ago :P) non-developers would not touch code because "it was too hard to understand". This is now an excuse, if SDEs are guilty of shipping bad software, non-SDEs are guilty of not learning software. Inside Razorpay we use Slash for over 50% of our coding tasks. People use it to do:

• minor changes ("button looks out of place, please fix")
• first drafts ("Take a look at this paper, can you raise a PR to use this algorithm")
• operations ("Add this IP address to this AWS LB")
• learning ("How did Slash implement model routing?")

There is no more a reason to not understand things. It is borderline criminal for people to not use AI in some shape or form to understand computing itself.

And this brings me to the conclusion. These are my learnings which will not translate 1:1 with everyone else. Pick what you like from these.