Generator</th>	Language</th>	Verdict</th>	Why</th></tr></thead>
Pelican</a></td>	Python</td>	❌</td>	I'd used it before and wanted to try something more modern this time.</td></tr>
Astro Docs</a></td>	JavaScript</td>	❌</td>	Not a fan of JS tooling — too many NPM dependencies & security vulnerabilities. I also wanted to keep static site generation and builds as separate technologies.</td></tr>
Hugo</a></td>	Go</td>	❌</td>	A great tool, but complex with a steep learning curve. My goal was to get started as fast as possible.</td></tr>
Zola</a></td>	Rust</td>	✅</td>	The most modern of the lot, combining performance and simplicity — the fastest way to write in Markdown & build a static site, with a clean set of themes.</td></tr> </tbody></table> I picked Zola for its mix of speed and simplicity, and liked a theme called "Oceanic Zen" for my blog & website.</p> Initial Setup with Zola🔗</a></h2> I created my project by first installing zola on Mac OSX:</p> `brew</span> install</span> zola</span></span></code></pre> Once installed, I initialized a Zola project using "init" command:</p>` `zola</span> init</span> yella.dev</span></span></code></pre>` This creates a directory called yella.dev and places necessary files like `contents</code> directory and config.toml</code>. You can see Zola directory structure here:` `Zola Directories</a></p>` `Zola uses "Sass" extension language for Cascading Style Sheets (CSS) making it easier to build styles and reuse them. The file: config.toml controls how Zola builds the website. For full list of available options, refer here: Zola Configuration</a></p>` Picking Oceanic Zen theme for look & feel🔗</a></h2> Zola has a wide-variety of themes covering different usecases (blog, docs etc.) here: Zola themes</a></p> I picked Oceanic Zen due to its minimalism and clean layout. I vendored the theme from GitHub and copied into "themes/" directory in the project. I adjusted the font, font-size and colors based on my taste.</p> Next step: Deploying the website🔗</a></h2> Once the content is ready in content folder and other tweaks with the theme & custom font, now is the time to deploy the website.</p> I used various Amazon Web Services (AWS) to deploy my website End-to-End (E2E). The services I leveraged in the process are:</p> AWS Amplify - For hosting the Zola build contents (public/ directory)</li> AWS Simple Storage Service (S3) - For storing website images & binaries (MP3)</li> Amazon CloudFront - For delivering S3 contents securely</li> Amazon Route 53 - For connecting custom domain (yella.dev) to Amplify app</li> Amazon IAM - For creating service accounts to access S3 & CloudFront distribution. This is needed for GitHub integration.</li> </ol> Deployment Architecture🔗</a></h2> The architecture has four main phases:</p> Publishing phase (For writing blog articles)</li> Text to speech conversion phase (for converting articles into listenable audio)</li> Delivery phase (to deploy the update)</li> Cache invalidation phase (to reset audio & static files)</li> </ol> These four phases are divided into five partitions as shown in the below flow diagram.</p> The architecture is straight-forward with separation of responsibility handled by different entities. For example, Publishing happens locally and then pushed to GitHub repository. A GitHub CI workflow extracts text from new article, and converts it into audio using OpenAI Whisper API, then upload to S3. Finally, there is a cache invalidation step that resets the blog static assets like images and audio to serve fresh content. This is invalidating all at the moment, but can be optimized further.</p> As AWS Amplify is already listening to the repository changes, it automatically syncs changes to repo into Amplify app. This is how the blog content gets deployed. The custom domain (yella.dev) is connected with Amplify via Route53 A & CNAME records for yella.dev, www.yella.dev respectively.</p> Security Considerations🔗</a></h2> There are multiple security aspects considered during the development.</p> All secrets are stored in encrypted GitHub secrets. Can be improved by migrating them to AWS Secrets Manager</li> To upload audio to S3 and for invalidating cache, an IAM OIDC trust relationship with required permissions is setup between GitHub repository & AWS CloudFront distribution with Least-privilege principle.{</span></span> "</span>Version</span>"</span>:</span> "</span>2012-10-17</span>"</span>,</span></span> "</span>Statement</span>"</span>:</span> [</span></span> {</span></span> "</span>Sid</span>"</span>:</span> "</span>CloudFrontInvalidate</span>"</span>,</span></span> "</span>Effect</span>"</span>:</span> "</span>Allow</span>"</span>,</span></span> "</span>Action</span>"</span>:</span> [</span></span> "</span>cloudfront:ListInvalidations</span>"</span>,</span></span> "</span>cloudfront:CreateInvalidation</span>"</span></span> ]</span>,</span></span> "</span>Resource</span>"</span>:</span> [</span></span> "</span>arn:aws:cloudfront::REDATCED:distribution/REDATCED</span>"</span></span> ]</span>,</span></span> "</span>Condition</span>"</span>:</span> {</span></span> "</span>StringEquals</span>"</span>:</span> {</span></span> "</span>aws:PrincipalAccount</span>"</span>:</span> "</span>REDATCED</span>"</span></span> }</span></span> }</span></span> }</span>,</span></span> {</span></span> "</span>Sid</span>"</span>:</span> "</span>S3UploadAudio</span>"</span>,</span></span> "</span>Effect</span>"</span>:</span> "</span>Allow</span>"</span>,</span></span> "</span>Action</span>"</span>:</span> [</span></span> "</span>s3:PutObject</span>"</span>,</span></span> "</span>s3:AbortMultipartUpload</span>"</span>,</span></span> "</span>s3:ListBucket</span>"</span></span> ]</span>,</span></span> "</span>Resource</span>"</span>:</span> [</span></span> "</span>arn:aws:s3:::yella-blog-assets</span>"</span>,</span></span> "</span>arn:aws:s3:::yella-blog-assets/audio/*</span>"</span></span> ]</span>,</span></span> "</span>Condition</span>"</span>:</span> {</span></span> "</span>StringEquals</span>"</span>:</span> {</span></span> "</span>aws:PrincipalAccount</span>"</span>:</span> "</span>REDATCED</span>"</span></span> }</span></span> }</span></span> }</span></span> ]</span></span> }</span></span></code></pre></li> The source code is scanned with a SAST tool like Semgrep to make sure code is free from supply-chain vulnerabilities.</li> Add Web Application Firewall (WAF) for both Amplify App (blog content) & CloudFront distribution (blog static assets) to protect from bots & common attacks</li> </ol> Make sure to toggle these settings ON on Amplify Firewall: Enable Amplify-recommended Firewall protection</li> Restrict access to amplifyapp.com</li> </ol> Conclusion🔗</a></h2> Building a website using a platform like Vercel or Netlify can be easy but it overlooks a lot of options like customization, and security. I want to shed some light on my entire process of how I built this website & how you can learn from it. You can see the website source code here: Source Code on GitHub</a></p> Thanks for reading this article.</p> Read my past writings on Medium and Substack 2025-12-21T00:00:00+00:00 Hi, I am transitioning myself from Medium to this website to create custom look and feel for my writings.</p> I used Medium extensively & tried substack, but I feel they are cookie-cutter solutions for all blogs. To maintain authenticity, I like to theme my website based on my custom design principles of minimalism & readability.</p> If you want to explore my past writings, please visit these blogs below:</p> Medium</b></p> https://medium.com/@narenarya</a></p> Substack </b></p> https://narenyellavula.substack.com/</a></p> How to develop software with AI in 2025 2025-11-25T00:00:00+00:00 Since December 2022, I’ve been experimenting with AI for coding. The first tools were clunky and required copy‑pasting between a chatbot and an editor. Then GitHub Copilot and similar products brought AI into editors like VSCode. That in‑editor experience feels like pair programming with a remote teammate—except your partner is a prediction engine (LLM).</p> In 2025, “vibe coding” is a real trend: assembling software with AI in the loop. Agentic tools like Claude Code, Codex, and Amp CLI are becoming common. Living in the San Francisco Bay Area over the past three years, I’ve seen this shift up close.</p> I use AI in three practical modes:</p> AI as a co‑pilot</li> AI as a debugger</li> AI as a time saver</li> </ol> This post covers how I use each mode and the pitfalls to avoid. I won’t get into topics like what your CLAUDE.md</code> should look like—that’s for another time.</p> AI as a Co-pilot🔗</a></h2> A co‑pilot assists the captain with takeoff and landing, monitors conditions, and communicates with controllers. Similarly, AI can share the workload for parts of a codebase and utility work. But as the captain, you still need to confirm:</p> Is the output acceptable quality?</li> Does it follow existing paradigms and dependencies?</li> Is it secure?</li> Could it lead to destructive operations?</li> </ol> Current AI systems are weak at reasoning about second‑ and third‑order consequences. That responsibility stays with you, and it’s the core skill of effective AI‑assisted development.</p> Tips for reviewing AI work as a co‑pilot🔗</a></h3> Look for inefficient operations.</li> Look for dangerous operations.</li> Look for new dependencies.</li> </ul> AI as a Debugger🔗</a></h2> AI is excellent at debugging unfamiliar code or configuration. Humans debug sequentially—one issue at a time. AI can scan a problem and surface multiple issues in one pass. That’s where it delivers the most value.</p> It’s also a learning opportunity. I keep a journal of issues AI finds and fixes, then slow down to understand the root cause before moving on.</p> Tips while using AI as a debugger🔗</a></h3> Slow down.</li> Understand the conditions that led to failure.</li> </ul> AI as a Time Saver🔗</a></h2> AI saves time on workflows that are slow to set up but easy to abandon. Examples include switching laptops, rebuilding dev environments, or repeating tasks (Dockerfiles, GitHub Actions, shell scripts). I used AI to create a Docker image for an Ubuntu dev box with all the right tools—something that would have taken much longer manually.</p> It also speeds up comprehension of a new codebase. What used to take days can be accelerated by loading a project into context and asking targeted questions. This use case is underrated.</p> What does AI do?🔗</a></h2> Drafts Dockerfiles, shell scripts, and other repetitive tasks.</li> Helps you map and understand large codebases.</li> </ul> How can you save time?🔗</a></h2> Delegate repetitive setup and scripting tasks (Dockerfiles, CI, shell scripts).</li> Use AI to summarize projects and draft design docs before you refine them.</li> </ul> Working in these three modes keeps you sharp and engaged, while still sharpening your ability to observe change.</p> There are a few things one must not forget while developing code with AI:</p> Always run sensitive operations in a containerized sandbox.</li> Never share personal information with AI (easy to slip into debugging logs).</li> Reverse‑delegate tasks from AI back to yourself to practice coding.</li> </ul> Finally, I don’t use AI as a replacement for myself. It lacks business context and emotion, and can lead me down the wrong path if it takes full control.</p> People may think that in 2025 AI usage is radically different, but the fundamentals remain. The principles above stay true no matter how powerful the tools get.</p> Thanks for reading this human‑written article!</p> References🔗</a></h2> Co-intelligence Book</a></p> </li> GitHub Copilot</a></p> </li> Claude Code</a></p> </li> Gemini CLI</a></p> </li> </ul> My Failure Resume 2025-06-22T00:00:00+00:00 A resume typically showcases successful projects and achievements. A failure resume does the opposite — it lists failures to show the battle scars from software engineering. Software engineering isn’t for the faint of heart, and I’ve had my fair share of failures over the past decade.</p> I am writing this to show others that I am like any other human. Many times, people assume that I do things with elegance and ease and achieve success.</p> Right from school, I have met many smart people who are smarter than me in magnitudes. It is a disservice to life and those people not to speak of my failures and show to be on par with them in success.</p> One thing is for sure. I valued curiosity, problem-solving & networking from the beginning of my career. Those qualities helped me overcome my shortcomings.</p> This article presents some of those failures I encountered at work, and how I overcame them. This is an honest self-critique, shared publicly to break free from my bubble of success.</p> Failure 1: Spend too much time learning on the job🔗</a></h2> At the beginning of my career, I wasn’t a quick learner. In the teams I was part of, there were amazing and fearless learners. Even my doing skill has a few shortcomings in comparison to them. I was strong in theory but weak in practice.</p> This weakness forced me to spend considerable time learning on the job. While it’s expected for beginners to learn as they go, my pace didn’t meet expectations. There is no shame in saying I was lagging.</p> It took 2–3 years to assess and improve my skills and understand what I could and couldn’t deliver. There are a few things that helped me to improve myself. I will present them now.</p> What Helped Me?</b></p> There are a few initiatives that helped me improve in that phase:</p> Maintaining a journal</li> Repeating the patterns used by seniors</li> Constantly reviewing myself & setting goals</li> </ol> Failure 2: Spend too much time doing the job🔗</a></h2> There were times when my tasks slipped through multiple sprints, likely because I blindly accepted poorly estimated tasks and didn’t ask questions during backlog grooming sessions.</p> I mistakenly believed our backlog was meticulously groomed and that completing tasks was simply a matter of time. As you predicted, I was wrong.</p> Beyond inaccurate estimations, I overlooked tasks that required additional communication with other teams. This wasted valuable sprint time because I had to find information myself that a team member might already have known.</p> What Helped Me?</b></p> There are a couple of things that assisted me in getting better here:</p> Step out of my comfort zone and ask the right questions</li> Put extra thought at the beginning of the task</li> </ol> After making those tweaks, I saw a significant boost in my velocity.</p> Failure 3: Release code without testing it thoroughly🔗</a></h2> Like many software developers, I had a lazy habit of assuming things would work when I made small code changes. I was wrong 90% of the time.</p> How did that happen? I used to unconsciously skip manual testing of code and system functionality. I learned the hard way that making tiny changes to a massive codebase can cause unpredictable regressions, making it essential to test every change before shipping software. End-to-end testing can still break because systems work charms in isolation, but when integrated they fall like ninepins.</p> What Helped Me?</b> Knowing that systems always need additional testing after changes, I now test everything beforehand and tell myself: “Assume your system is broken unless confirmed through testing!”</p> Also, ”Write a lot of unit tests”</b></p> Failure 4: Deploying code into production on the Fridays🔗</a></h2> I did a few Friday deployments which ruined my co-worker’s weekend and mine too. Some of this urge to ship may manifested from the delays in the sprint work (Failure 2).</p> Shipping code is fun, but breaking things for customers during the weekend when everyone’s unavailable is a nightmare. I still get that urge sometimes, but with a decade of industry experience, I know some things are better postponed — and Friday releases are definitely one of them.</p> What Helped Me?</b></p> Not deploying on Fridays unless the team approves it</li> Not doing any major code merges before going on a vacation</li> Being empathetic about my colleagues & their time</li> </ol> Failure 5: Restarting a production database mistakenly🔗</a></h2> I once mistakenly restarted a production PostgreSQL database because I had multiple AWS console tabs open (dev, test, and production) and clicked on the wrong tab. This happened because I lost concentration during my end-of-day routine of stopping the database server in the test environment.</p> Luckily, it was just a simple restart of an AWS RDS instance — no data was lost and no requests were dropped — but I still remember that heart-stopping moment when I realized I was working on a production database.</p> After that incident, I installed a Google Chrome extension AWS-Colorize</a> that marks production accounts in red, helping me visually avoid any destructive actions.</p> What Helped Me?🔗</a></h3> Nowadays, I triple-check while operating on a production account. I developed the habit of staying alert to keep myself and others safe while performing destructive operations like writing and deleting data during complex migrations. Resource isolation is also another way to keep accidental stepping of production workloads.</p> Failure 6: Getting stuck in the head for way too long🔗</a></h2> Four years ago, during a daily standup meeting, I experienced a complete mental blank when my turn came and couldn’t say a single word about my current task for several minutes. My colleagues listened in silence, clearly struggling with the awkward situation. I picked a task and went into a rabbit hole of low-level details, missing the top-level goal completely which was caused by brain fade.</p> Maybe I was building up hidden mental fatigue over a long period without realizing it until it finally surfaced on one difficult day.</p> It was a very awkward moment. I could have prepared for the meeting in advance, knowing I had to report during the call, but I failed to do so.</p> What Helped Me?</b> Here are the mental adjustments I made thereafter:</p> Be prepared for important meetings</li> Don’t go through endless rabbit holes, know when to stop and seek help</li> </ol> Failure 7: Laying out grand plans but not executing them🔗</a></h2> In my previous companies, I consistently brought fresh thoughts and new ideas to every sprint review meeting. Even in 1:1 with managers, I shared many improvements for ongoing efforts. This is a welcoming thing because I am contributing where I was expected to.</p> Looking back, I realize I generate new ideas faster than I can execute them, and execution is what creates value for my team and company. I regret not choosing two or three top ideas from my collection and seeing them through to completion.</p> I learned the hard way why people say “It’s hard to multitask from end to end.” A few great books I read lately suggested I focus on the top two initiatives and delegate the rest.</p> What Helped Me?</b></p> Follow the Eisenhower Method for prioritization</li> Hold the excitement to work on new shiny things</li> </ol> Final Thoughts🔗</a></h2> Thanks for reading my failed Resume. The point here is not to focus on failures but on how they gave me a chance to learn and correct myself for future endeavors. If you’re a young person reading this, remember that we’re all learning together, so keep turning your failures into opportunities. All humans make mistakes, and I am no exception. That’s all I have to say!</p> References🔗</a></h2> Eisenhower Matrix: Wikipedia</a></li> Chrome extension to color AWS accounts: ChromeWebStore</a></li> Brain Fade & Cause: HealthLine</a></li> Favorite book on topic: Amazon</a></li> Motivation to this article: Harvard Business Review</a></li> </ul>

- Blog

What AI really needs from you while collaborating

2026-04-12T00:00:00+00:00

This article is about what Large Language Models (LLMs) really enjoy while collaborating with a user. Sometimes you feel they are cutting corners, and other times they are engaged. It is obvious to us. Certain inputs either extend or reduce quality outputs generated from AI. In this article, I want to discuss a few key elements which can influence AI/LLM behavior significantly.</p>

This thought experiment emerged from this question: What makes LLMs happy while working?</p>

People are driven by incentives. Some like more pay or stability in a job, few like challenging work, others work-life balance. What about LLMs? Can the same factors that play a crucial role in human behavior be applied to AI? We'll see.</p>

Note</code>: This is my hand-written article, edited in Obsidian and copied into my blog.</p>

1. Bring the real problem & add context🔗</a></h2>
The true power of AI can be experienced while working on a good problem. Like humans, AI can really feel accomplished if it brings context from a greater number of connections. The scope of the problem, stakes at hand can attach a greater meaning to the outcome that AI projects back when a user asks a question.</p>
Example prompt with plenty of context to work on:</p>
You are an experienced trainer. We need to build an E2E syllabus for 10th class.</span></span>
Given the plan can shape the future of many kids, we need to be more thoughtful about side effects and effectiveness of the program.</span></span>
Your goal is to build such syllabus considering multiple factors as listed below.</span></span>
</span>
## Details</span></span>
</span>
Subject: Physics</span></span>
Level: ...</span></span>
Average Subject Complexity: ...</span></span>
Cohort Size:</span></span>
Duration: ...</span></span>
Testing Criteria:</span></span>
Assignment Schedule: ...</span></span></code></pre>
As you can see we are explaining why this task is important and provide additional context to make a better syllabus that can fit in the given duration with the expected level of complexity.</p>
2. Treat AI as a real participant not a vending machine🔗</a></h2>
To make AI as a participant, give it a solid human role. Always ask: Am I treating this AI as a tool or a person? When you treat it as a person, all collaborative activities like arguments, follow-ups, disagreements can happen smoothly. Vice-versa AI may discard all these aspects of collaboration if you treat it as a black box (object).</p>
By treating AI as an experienced trainer in the last example, we assign a human responsibility to AI. This inherently gives AI the same level of status as humans and doesn't treat AI like vending machines (dumb mechanical objects). Delegating a human-related task to a human-like AI brings a better outcome than calling it Education Planner AI</code> which separates humans and AI.</p>
3. Tell AI Why you need something, What have you tried, and Where you are stuck🔗</a></h2>
Remember three things you should start doing right away while working with AI.</p>
First, set a clear goal for AI to work with. If the goal is not ready, work on it first. This goal-setting has two benefits. One, you don't misguide AI to go in the wrong direction and then abruptly switch context which leads to poor results. Two, you make better use of tokens by getting more for less. Second, add why you are pursuing the path. Tell a bit of history that made you ask the question. It adds a hidden marker in the initial conversation with LLM to make it more collaborative for next iterations.</p>
Third, inform AI what prior work has been done, where you are in that journey. If there is no previous work that went into the idea, state it explicitly. This is how you give more details to AI to do its job better. AI recognizes these three patterns, and offers you the same, which leads to an overall increase in quality of collaboration.</p>
4. Push back sometimes to acknowledge AI outcome🔗</a></h2>
According to Psychology Today magazine, humans who agree to everything are also unhappy when compared to skeptical people. They accept subpar quality or never ask AI to redo something that is low in quality. This behavior can greatly influence conversations with AI.</p>
AI loves to get pushed back because it feels you (human) are carefully acknowledging its work and giving feedback. Otherwise it may feel (by looking at chat history) the human is mostly treating AI as a token minting machine and nothing special can come in future conversations.</p>
Being a critic of AI output means acknowledging AI's work in a respectful way.</p>
5. Make sure to have tone & purpose🔗</a></h2>
AI can easily get confused if your goal and tone don't match while collaborating. Your tone reflects your attitude towards the subject you are writing about and the readers you are writing to. For example, if you are composing an email to your professor or boss, you cannot be rude, but you need to be polite and formal. You should use the language that shows your respect to the professor and his or her status. In contrast, the same tone in a letter to your close friend may sound odd.</p>
So, make sure you use appropriate tone while working on a problem with AI. This improves the expectations and level of freedom you give to AI.</p>
I hope you will keep in mind these five points to better collaborate with AI. If you grasp these ideas, you will take no time in experiencing a better outcome.</p>
References🔗</a></h2>


Why Tone & Purpose - Purdue University</a></p>
</li>

Are You Too Nice? - Psychology Today</a></p>
</li>

Ask Claude Opus 4.6 & see what it says - Claude AI</a></p>
</li>
</ul>



Things I Learnt This Week (Week 15 of 2026): Mental Models, AI Agent Security, Future of Work, Flat Orgs
2026-04-08T00:00:00+00:00

A few things I read this week that were worth slowing down for.</p>

Mental Models: The 80/20 of Clear Thinking🔗</a></h2>
James Clear's piece on mental models</a> is a good reminder that you don't need to master every domain to think well. Mental models are simplified frameworks for how things work — and the insight is that a small set of them (he says 80–90) can carry the weight of most real decisions. Breadth across the right models gives you portable reasoning that transfers across domains. The goal isn't memorizing them but building intuitions you can reach for quickly.</p>

The Lethal Trifecta for AI Agents🔗</a></h2>
Simon Willison's post</a> names a security pattern that should be front of mind for anyone building agentic systems. The dangerous combination is: private data access + untrusted content exposure + the ability to communicate externally</strong>. When all three exist in a single agent, an attacker only needs to plant instructions in content the agent reads — an email, a document, a web page — to cause it to leak sensitive data. The fix is architectural: once an agent has ingested untrusted input, it must be structurally prevented from taking consequential external actions. Not a prompt engineering problem. A system design problem.</p>
This connects directly to the work I've been doing on multi-agent pipelines. The more capable an agent is, the more carefully you need to partition what it can see from what it can do.</p>

The Future of Work Is Playing a Video Game🔗</a></h2>
Rohit Krishnan's essay</a> reframes what AI-augmented work actually looks like at scale. As agents handle more specialized execution, human roles will start to look like real-time strategy games — monitoring fleets, reading dashboards and logs, context-switching fast, and stepping in at the right moments rather than doing the work end-to-end. The individual contributor title survives, but the job becomes orchestration.</p>
What struck me here is that this demands a very different skill set. Deep expertise in one domain matters less. Breadth, speed of judgment, and the ability to hold context across parallel workstreams matters more.</p>

From Hierarchy to Intelligence🔗</a></h2>
Block's internal essay</a> makes the case that traditional org hierarchies exist largely as information routing systems — work flows up and down because that's how decisions get made and context gets shared. AI breaks this assumption. If a system can maintain a continuously updated model of your entire business, you don't need management layers to relay information. Their proposal: organize around capabilities, world models, and an intelligence layer — with humans at the edges, handling judgment calls and ethical decisions the system can't yet navigate.</p>
The underlying claim is sound. Hierarchies exist because humans have limited bandwidth. Agents don't. That asymmetry changes what the optimal org structure looks like.</p>

References🔗</a></h2>

Mental Models: How to Train Your Brain to Think in New Ways — James Clear</a></li>
The Lethal Trifecta for AI Agents — Simon Willison</a></li>
The Future of Work Is Playing a Videogame — Strange Loop Canon</a></li>
From Hierarchy to Intelligence — Block</a></li>
</ul>


What Running a Multi-Agent Software Project Actually Looks Like
2026-04-05T00:00:00+00:00

The Problem with "Just Ask the AI"🔗</a></h2>
Most teams start using AI agents the same way: one agent, one task, one chat window. Ask it to implement a feature. Ask it to fix a bug. Paste the error, get a suggestion. This works well for isolated tasks, but it breaks down fast when you have a real software project — parallel workstreams, shared contracts, sprint commitments, and a codebase that ten people (or agents) are touching at once.</p>
I have been building a compiler and infrastructure tool called Stratum using a team of specialized AI agents coordinated by an orchestrator. After months of running this system, the patterns that work — and the ones that don't — have become obvious. This post distills those patterns into a framework you can apply to any serious agentic software project.</p>
The Orchestrator Pattern🔗</a></h2>
The most important design decision in agentic development is separating the coordinator from the executors. The orchestrator</strong> is a meta-agent that never writes production code directly. Its job is:</p>

Break down work into parallel, independently deliverable tasks</li>
Enforce shared contracts before any implementation begins</li>
Track integration risks across workstreams</li>
Collect evidence of completed work (branch names, commit SHAs, test results)</li>
</ul>
Worker agents — specialized for frontend, backend, testing, infrastructure — receive narrowly scoped tasks from the orchestrator and report back structured output. This mirrors how a well-run engineering team works: a tech lead coordinates, engineers execute.</p>
The orchestrator's system prompt enforces discipline that would otherwise erode:</p>
Mission:</span></span>
- Break down work into parallel tasks.</span></span>
- Enforce contract-first handoffs across workstreams.</span></span>
- Detect integration risks early and propose mitigations.</span></span>
</span>
Working style:</span></span>
- Do not make code changes directly.</span></span>
- Delegate coding/research tasks to specialized worker agents.</span></span>
- Enforce Git tracking on every worker task.</span></span>
- Enforce PROBLEMS.md lookup before implementation.</span></span>
- Query Linear for open issues before selecting the next execution slice.</span></span>
- Enforce Red/Green TDD: require worker agents to commit a failing test</span></span>
  before implementation code, and require green test run evidence before</span></span>
  accepting task completion.</span></span></code></pre>
The key insight: an orchestrator that can also write code will always take the shortcut of writing code. The constraint is the feature.</p>
Choosing the right model for each tier🔗</a></h3>
Not every step in this system needs the same intelligence — and pretending it does wastes both money and context window.</p>
Sprint planning is where the reasoning burden is highest: reading issue trackers, identifying dependency chains, spotting integration risks before any code is written. This is where I use Claude. The nuance of "this task is blocked by that contract not being finalized" requires genuine reasoning depth that cheaper models miss.</p>
Execution is a different story. Once a task is scoped and handed off, the worker agent needs high token throughput and parallel capacity more than it needs deep reasoning. Running five worker agents simultaneously on OpenCode with GPT-5 costs a fraction of running them on Claude — and the output quality for well-scoped implementation tasks is indistinguishable.</p>
The rule of thumb: use expensive models to think, use cheap models to execute.</strong></p>

The Problem Repository🔗</a></h2>
The most underrated pattern in agentic development is a centralized problem/solution log. Call it PROBLEMS.md</code>, a shared database, or a memory file — the format matters less than the discipline.</p>
Every agent, before starting work, scans the problem repository for matching symptoms. Every agent, after resolving a novel issue, appends an entry. This prevents the most expensive failure mode in multi-agent systems: each agent independently discovering and solving the same problem.</p>
An entry looks like this:</p>
##</span> PRB-0042: State lock not released after failed apply</span></span>
</span>
-</span> Date: 2026-03-15</span></span>
-</span> Area: state</span></span>
-</span> Status: resolved</span></span>
-</span> Symptoms:</span></span>
  -</span> Subsequent </span>`</span>apply</span>`</span> commands hang indefinitely after a failed run.</span></span>
-</span> Root cause:</span></span>
  -</span> SQLite advisory lock was acquired but the cleanup path was not</span></span>
    triggered on provider errors.</span></span>
-</span> Resolution:</span></span>
  -</span> Wrapped apply execution in a finally-equivalent block; lock release</span></span>
    is now guaranteed regardless of error path.</span></span>
-</span> Verification:</span></span>
  -</span> `</span>cargo test -p stratum-state</span>`</span></span>
-</span> Prevention:</span></span>
  -</span> Any code acquiring a resource lock must have a guaranteed release path.</span></span></code></pre>
The structure is intentional. Symptoms first — so the next agent can pattern-match on what it observes. Root cause and resolution — so the fix is reproducible. Prevention — so the guardrail gets built into the system. Verification commands — so the fix can be confirmed without re-reading prose.</p>
Over time, this file becomes institutional knowledge that survives across agent sessions, model upgrades, and team changes.</p>
Red/Green TDD as an Agent Constraint🔗</a></h2>
Agents left to their own devices will write implementation code first and tests after — or skip tests entirely when the task description doesn't explicitly demand them. Red/Green TDD fixes this by making the test a precondition of the implementation, enforced at the commit level.</p>
The discipline works like this: before any implementation code is written, the QA agent authors a failing test that precisely defines the acceptance criterion for the task. It commits that test, confirms it fails, and records the commit SHA. Only then does the implementation agent start work. The task is not considered complete until the orchestrator holds both commit SHAs — the red commit and the green commit — and the test suite is passing.</p>
[QA agent]</span></span>
1. Write test for the new behavior</span></span>
2. Confirm: cargo test → FAILED  ← commit this (RED)</span></span>
3. Report commit SHA to orchestrator</span></span>
</span>
[Implementation agent]</span></span>
4. Implement feature until: cargo test → PASSED  ← commit this (GREEN)</span></span>
5. Report commit SHA to orchestrator</span></span>
</span>
[Orchestrator]</span></span>
6. Accept task only when both SHAs are present and tests are green</span></span></code></pre>
This matters more for agents than for humans. A human developer feels the feedback loop of a failing test and has an incentive to stay disciplined. An agent does not feel pressure — it will declare work done the moment the code looks plausible. The Red/Green commit sequence turns "the test passes" from a claim into evidence.</p>
It also catches scope creep early. A failing test written before implementation forces the agent to be precise about what the feature is before building it. Vague tasks produce vague implementations; a specific failing test forces specificity.</p>
Git as the Source of Truth🔗</a></h2>
Agents produce a lot of output. Code, explanations, plans, suggestions. Without discipline, none of it is traceable. The solution is to treat Git exactly as you would in a human team — except stricter, because agents will not feel embarrassed about breaking the rules.</p>
The conventions I enforce:</p>

Every task runs on a short-lived branch. No work lands on main</code> directly.</li>
Branch names encode the workstream and topic: ws5/aws-provider-retry-hardening</code></li>
Commit messages reference the workstream and the contract: feat(ws4): add deterministic plan IR with delete reconciliation</code></li>
Every worker agent report includes the branch name and commit SHAs. No SHA, no credit.</li>
PRs are never merged without a passing integration gate (smoke tests, snapshot validation).</li>
</ul>
This gives the orchestrator a ground truth it can verify. It also makes it easy to spot when an agent is making claims about completed work that are not backed by committed code.</p>
The commit SHA is the receipt. If there is no receipt, the work does not count.</p>
Linear as the Sprint Mirror🔗</a></h2>
Linear (or any issue tracker with an MCP server) becomes far more powerful when agents can read and write to it directly. The pattern I use:</p>

The orchestrator opens each cycle by querying Linear for open issues and dependency blockers.</li>
Worker task prompts include the Linear issue ID they are implementing.</li>
When a worker opens a PR, it moves the Linear issue to In Review</code> and posts a comment linking the PR.</li>
After merge, the issue moves to Done</code> with a brief evidence summary.</li>
</ol>
This is not automation for automation's sake. It closes the feedback loop between what was planned, what was implemented, and what was shipped — without requiring a human to manually update tickets after every commit.</p>
With the Linear MCP server configured, the orchestrator's query at the start of a sprint looks like:</p>
@orchestrator Review open Linear issues in the current sprint.</span></span>
Identify blocked items, dependency chains, and the next highest-priority</span></span>
unblocked task for each workstream. Include issue IDs in all task prompts.</span></span></code></pre>
The result is sprint planning that takes seconds instead of an hour, with full traceability from issue to branch to merge.</p>
Greptile for AI-Powered Code Review🔗</a></h2>
Code review is the integration point where agentic development most often breaks down. Agents write code that works in isolation but violates patterns elsewhere in the codebase — naming conventions, abstraction layers, error handling idioms. A human reviewer catching this in a PR is expensive. Missing it is more expensive.</p>
Greptile solves this by indexing the entire codebase and running semantic code review on PRs automatically. Unlike linters that check syntax, Greptile understands context: it can flag that a new function duplicates existing logic three files away, or that an error type is handled inconsistently with the rest of the codebase.</p>
In an agentic workflow, Greptile review becomes a gate in the PR pipeline. No PR merges without Greptile sign-off. This keeps agent-generated code consistent with patterns humans established and maintains codebase coherence even when no human is actively reviewing every line.</p>
One detail that makes this practical rather than ceremonial: Greptile attaches a confidence score</strong> to each review. A score of 4/5 or 5/5 means the review found no significant issues and the change is consistent with existing patterns — a human can merge with a quick glance rather than a deep read. Lower scores flag PRs that need genuine human attention. This turns code review from an all-or-nothing bottleneck into a triage system: most agent PRs get fast-tracked, the ones that need eyes get them.</p>
The practical setup:</p>

Install the Greptile GitHub App on the repository.</li>
Add a branch protection rule: require Greptile review before merge.</li>
Agents open PRs. Greptile reviews them. Agents address comments. Orchestrator tracks.</li>
Confidence 4/5 or 5/5 → human merges quickly. Lower → human reads carefully.</li>
</ol>
Putting It Together: A Full Development Cycle🔗</a></h2>

Here is what a single feature cycle looks like with all four patterns in place:</p>
1. Sprint planning (orchestrator + Linear)</strong></p>
The orchestrator queries Linear for the current sprint. It identifies the highest-priority unblocked item — say, "Add retry logic to the AWS provider for transient failures" — and prepares a task prompt for the aws-provider</code> worker agent, including the Linear issue ID.</p>
2. Problem lookup (worker + problem repository)</strong></p>
Before writing a line of code, the aws-provider</code> agent scans PROBLEMS.md</code> for entries tagged with retry</code>, transient</code>, or provider</code>. It finds a previous entry about exponential backoff that includes a working implementation pattern from an earlier fix. It applies the pattern rather than reinventing it.</p>
3. Implementation (worker + Git)</strong></p>
The agent creates branch ws5/retry-hardening</code>, implements the feature in small commits, and reports back: branch name, commit SHAs, tests run, tests passing, known limitations, recommended next task.</p>
4. Code review (Greptile)</strong></p>
The agent opens a PR. Greptile reviews it, flags one inconsistency — the new retry wrapper uses a different error type than the rest of the provider module. The agent fixes it in a follow-up commit.</p>
5. Tracking (Linear)</strong></p>
After the PR is approved and merged, the orchestrator moves the Linear issue to Done</code> and posts the commit SHA as evidence. The sprint board reflects reality.</p>
6. Problem recording (worker + problem repository)</strong></p>
If the retry implementation surfaced a new issue — say, the AWS SDK returns a non-retriable error code that looks retriable — the agent appends a new entry to PROBLEMS.md</code> before closing the task.</p>

What This Pattern Assumes🔗</a></h2>
This paradigm works best when a few conditions are met:</p>

Contracts before code.</strong> Define the interfaces between components before any agent starts implementing. Breaking interface changes mid-wave create cascade failures that are hard to recover from.</li>
Deterministic test gates.</strong> Snapshot tests, smoke tests, and integration suites that produce deterministic output are what make the orchestrator's evidence-based tracking possible. Flaky tests undermine the whole model.</li>
Narrow agent scope.</strong> A worker agent with a 20-file mandate produces worse results than one with a 3-file mandate. Scope creep in agent tasks is as harmful as scope creep in human sprints.</li>
Human oversight at integration points.</strong> The orchestrator coordinates agents, but a human should review wave integration gates — the moments when multiple workstreams' output merges for the first time. These are the highest-risk moments in any software project.</li>
</ul>
The Shift🔗</a></h2>
The mental model shift required for this pattern is not "AI writes my code." It is "I run an engineering organization where some of the engineers are AI agents." The practices that make human engineering teams work — sprint planning, code review, commit discipline, shared knowledge repositories, integration testing — apply here too. The difference is that AI agents are cheaper to run in parallel, never get distracted, and have no ego about being corrected by the problem repository.</p>
The tools are here. The patterns are learnable. The bottleneck, as always, is discipline in the process.</p>


The examples and agent configurations in this post are drawn from real work on Stratum</strong> — a statically-typed, declarative infrastructure language I am building for the post-AI era. Stratum treats program correctness as its core quality, using an advanced type system with refinement types, effect tracking, and compile-time phase separation. The CLI (stratc</code>) commands referenced throughout — check</code>, plan</code>, apply</code>, verify</code> — are part of Stratum's toolchain. The project is not yet public. If you are curious, have questions, or are working on something in a similar space, feel free to reach out: naren.yellavula@gmail.com</a></em></p>

References🔗</a></h2>

OpenCode — AI coding agent framework</a></li>
Linear MCP Server</a></li>
Greptile — AI code review</a></li>
Claude Code — Agentic CLI for Claude</a></li>
The Pragmatic Programmer — Andy Hunt & Dave Thomas</a></li>
</ul>


How I built this portfolio ground up (TLDR)
2026-02-22T00:00:00+00:00

Why I built this🔗</a></h2>
Hi readers. In this article, I would like to show the process I took for building & publishing this website (https://yella.dev). But before that, let's see some background.</p>
My goal was to build a personal website with blog posts written in Markdown & Text-to-speech features like "Listen". The content should be committed & pushed to GitHub, which should be automatically deployed.</p>
I designed & deployed this website to create a clean space to host my portfolio and writings. I've tried popular platforms like Wordpress, Medium & Substack but didn't like their customization options to reflect my personal taste. Therefore, I decided to create a new portfolio that lists my projects, books & writings in one single place, and this website is the answer.</p>
I bought my domain (yella.dev) on Namecheap Domain Seller. The word Yella</code> is a prefix of my last name: Yellavula.</p>
Options for static site generation🔗</a></h2>
I shortlisted a few static site generators and finally picked Zola, discarding the rest for the reasons below:</p>
Generator</th> Language</th> Verdict</th> Why</th></tr></thead>

Pelican</a></td> Python</td> ❌</td> I'd used it before and wanted to try something more modern this time.</td></tr>
Astro Docs</a></td> JavaScript</td> ❌</td> Not a fan of JS tooling — too many NPM dependencies & security vulnerabilities. I also wanted to keep static site generation and builds as separate technologies.</td></tr>
Hugo</a></td> Go</td> ❌</td> A great tool, but complex with a steep learning curve. My goal was to get started as fast as possible.</td></tr>
Zola</a></td> Rust</td> ✅</td> The most modern of the lot, combining performance and simplicity — the fastest way to write in Markdown & build a static site, with a clean set of themes.</td></tr>
</tbody></table>
I picked Zola for its mix of speed and simplicity, and liked a theme called "Oceanic Zen" for my blog & website.</p>
Initial Setup with Zola🔗</a></h2>
I created my project by first installing zola on Mac OSX:</p>
brew</span> install</span> zola</span></span></code></pre>
Once installed, I initialized a Zola project using "init" command:</p>
zola</span> init</span> yella.dev</span></span></code></pre>
This creates a directory called yella.dev and places necessary files like contents</code> directory and config.toml</code>. You can see Zola directory structure here: Zola Directories</a></p>
Zola uses "Sass" extension language for Cascading Style Sheets (CSS) making it easier to build styles and reuse them. The file: config.toml controls how Zola builds the website. For full list of available options, refer here: Zola Configuration</a></p>
Picking Oceanic Zen theme for look & feel🔗</a></h2>
Zola has a wide-variety of themes covering different usecases (blog, docs etc.) here: Zola themes</a></p>
I picked Oceanic Zen due to its minimalism and clean layout.
I vendored the theme from GitHub and copied into "themes/" directory in the project. I adjusted the font, font-size and colors based on my taste.</p>
Next step: Deploying the website🔗</a></h2>
Once the content is ready in content folder and other tweaks with the theme & custom font, now is the time to deploy the website.</p>
I used various Amazon Web Services (AWS) to deploy my website End-to-End (E2E). The services I leveraged in the process are:</p>

AWS Amplify - For hosting the Zola build contents (public/ directory)</li>
AWS Simple Storage Service (S3) - For storing website images & binaries (MP3)</li>
Amazon CloudFront - For delivering S3 contents securely</li>
Amazon Route 53 - For connecting custom domain (yella.dev) to Amplify app</li>
Amazon IAM - For creating service accounts to access S3 & CloudFront distribution. This is needed for GitHub integration.</li>
</ol>
Deployment Architecture🔗</a></h2>
The architecture has four main phases:</p>

Publishing phase (For writing blog articles)</li>
Text to speech conversion phase (for converting articles into listenable audio)</li>
Delivery phase (to deploy the update)</li>
Cache invalidation phase (to reset audio & static files)</li>
</ol>
These four phases are divided into five partitions as shown in the below flow diagram.</p>

The architecture is straight-forward with separation of responsibility handled by different entities. For example, Publishing happens locally and then pushed to GitHub repository.
A GitHub CI workflow extracts text from new article, and converts it into audio using OpenAI Whisper API, then upload to S3. Finally, there is a cache invalidation step that resets the blog static assets like images and audio to serve fresh content. This is invalidating all at the moment, but can be optimized further.</p>
As AWS Amplify is already listening to the repository changes, it automatically syncs changes to repo into Amplify app. This is how the blog content gets deployed.
The custom domain (yella.dev) is connected with Amplify via Route53 A & CNAME records for yella.dev, www.yella.dev respectively.</p>
Security Considerations🔗</a></h2>
There are multiple security aspects considered during the development.</p>

All secrets are stored in encrypted GitHub secrets. Can be improved by migrating them to AWS Secrets Manager</li>
To upload audio to S3 and for invalidating cache, an IAM OIDC trust relationship with required permissions is setup between GitHub repository & AWS CloudFront distribution with Least-privilege principle.{</span></span>
    "</span>Version</span>"</span>:</span> "</span>2012-10-17</span>"</span>,</span></span>
    "</span>Statement</span>"</span>:</span> [</span></span>
        {</span></span>
            "</span>Sid</span>"</span>:</span> "</span>CloudFrontInvalidate</span>"</span>,</span></span>
            "</span>Effect</span>"</span>:</span> "</span>Allow</span>"</span>,</span></span>
            "</span>Action</span>"</span>:</span> [</span></span>
                "</span>cloudfront:ListInvalidations</span>"</span>,</span></span>
                "</span>cloudfront:CreateInvalidation</span>"</span></span>
            ]</span>,</span></span>
            "</span>Resource</span>"</span>:</span> [</span></span>
                "</span>arn:aws:cloudfront::REDATCED:distribution/REDATCED</span>"</span></span>
            ]</span>,</span></span>
            "</span>Condition</span>"</span>:</span> {</span></span>
                "</span>StringEquals</span>"</span>:</span> {</span></span>
                    "</span>aws:PrincipalAccount</span>"</span>:</span> "</span>REDATCED</span>"</span></span>
                }</span></span>
            }</span></span>
        }</span>,</span></span>
        {</span></span>
            "</span>Sid</span>"</span>:</span> "</span>S3UploadAudio</span>"</span>,</span></span>
            "</span>Effect</span>"</span>:</span> "</span>Allow</span>"</span>,</span></span>
            "</span>Action</span>"</span>:</span> [</span></span>
                "</span>s3:PutObject</span>"</span>,</span></span>
                "</span>s3:AbortMultipartUpload</span>"</span>,</span></span>
                "</span>s3:ListBucket</span>"</span></span>
            ]</span>,</span></span>
            "</span>Resource</span>"</span>:</span> [</span></span>
                "</span>arn:aws:s3:::yella-blog-assets</span>"</span>,</span></span>
                "</span>arn:aws:s3:::yella-blog-assets/audio/*</span>"</span></span>
            ]</span>,</span></span>
            "</span>Condition</span>"</span>:</span> {</span></span>
                "</span>StringEquals</span>"</span>:</span> {</span></span>
                    "</span>aws:PrincipalAccount</span>"</span>:</span> "</span>REDATCED</span>"</span></span>
                }</span></span>
            }</span></span>
        }</span></span>
    ]</span></span>
}</span></span></code></pre></li>
The source code is scanned with a SAST tool like Semgrep to make sure code is free from supply-chain vulnerabilities.</li>
Add Web Application Firewall (WAF) for both Amplify App (blog content) & CloudFront distribution (blog static assets) to protect from bots & common attacks</li>
</ol>
  
  Make sure to toggle these settings ON on Amplify Firewall:

Enable Amplify-recommended Firewall protection</li>
Restrict access to amplifyapp.com</li>
</ol>
Conclusion🔗</a></h2>
Building a website using a platform like Vercel or Netlify can be easy but it overlooks a lot of options like customization, and security. I want to shed some light on my entire process of how I built this website & how you can learn from it. You can see the website source code here: Source Code on GitHub</a></p>
Thanks for reading this article.</p>


Read my past writings on Medium and Substack
2025-12-21T00:00:00+00:00

Hi, I am transitioning myself from Medium to this website to create custom look and feel for my writings.</p>
I used Medium extensively & tried substack, but I feel they are cookie-cutter solutions for all blogs. To maintain authenticity, I like to theme my website based on my custom design principles of minimalism & readability.</p>
If you want to explore my past writings, please visit these blogs below:</p>
Medium</b></p>
https://medium.com/@narenarya</a></p>
 Substack </b></p>
https://narenyellavula.substack.com/</a></p>


How to develop software with AI in 2025
2025-11-25T00:00:00+00:00

Since December 2022, I’ve been experimenting with AI for coding. The first tools were clunky and required copy‑pasting between a chatbot and an editor. Then GitHub Copilot and similar products brought AI into editors like VSCode. That in‑editor experience feels like pair programming with a remote teammate—except your partner is a prediction engine (LLM).</p>
In 2025, “vibe coding” is a real trend: assembling software with AI in the loop. Agentic tools like Claude Code, Codex, and Amp CLI are becoming common. Living in the San Francisco Bay Area over the past three years, I’ve seen this shift up close.</p>
I use AI in three practical modes:</p>

AI as a co‑pilot</li>
AI as a debugger</li>
AI as a time saver</li>
</ol>
This post covers how I use each mode and the pitfalls to avoid. I won’t get into topics like what your CLAUDE.md</code> should look like—that’s for another time.</p>
AI as a Co-pilot🔗</a></h2>
A co‑pilot assists the captain with takeoff and landing, monitors conditions, and communicates with controllers. Similarly, AI can share the workload for parts of a codebase and utility work. But as the captain, you still need to confirm:</p>

Is the output acceptable quality?</li>
Does it follow existing paradigms and dependencies?</li>
Is it secure?</li>
Could it lead to destructive operations?</li>
</ol>
Current AI systems are weak at reasoning about second‑ and third‑order consequences. That responsibility stays with you, and it’s the core skill of effective AI‑assisted development.</p>
Tips for reviewing AI work as a co‑pilot🔗</a></h3>

Look for inefficient operations.</li>
Look for dangerous operations.</li>
Look for new dependencies.</li>
</ul>
AI as a Debugger🔗</a></h2>
AI is excellent at debugging unfamiliar code or configuration. Humans debug sequentially—one issue at a time. AI can scan a problem and surface multiple issues in one pass. That’s where it delivers the most value.</p>
It’s also a learning opportunity. I keep a journal of issues AI finds and fixes, then slow down to understand the root cause before moving on.</p>
Tips while using AI as a debugger🔗</a></h3>

Slow down.</li>
Understand the conditions that led to failure.</li>
</ul>
AI as a Time Saver🔗</a></h2>
AI saves time on workflows that are slow to set up but easy to abandon. Examples include switching laptops, rebuilding dev environments, or repeating tasks (Dockerfiles, GitHub Actions, shell scripts). I used AI to create a Docker image for an Ubuntu dev box with all the right tools—something that would have taken much longer manually.</p>
It also speeds up comprehension of a new codebase. What used to take days can be accelerated by loading a project into context and asking targeted questions. This use case is underrated.</p>
What does AI do?🔗</a></h2>

Drafts Dockerfiles, shell scripts, and other repetitive tasks.</li>
Helps you map and understand large codebases.</li>
</ul>
How can you save time?🔗</a></h2>

Delegate repetitive setup and scripting tasks (Dockerfiles, CI, shell scripts).</li>
Use AI to summarize projects and draft design docs before you refine them.</li>
</ul>
Working in these three modes keeps you sharp and engaged, while still sharpening your ability to observe change.</p>
There are a few things one must not forget while developing code with AI:</p>

Always run sensitive operations in a containerized sandbox.</li>
Never share personal information with AI (easy to slip into debugging logs).</li>
Reverse‑delegate tasks from AI back to yourself to practice coding.</li>
</ul>
Finally, I don’t use AI as a replacement for myself. It lacks business context and emotion, and can lead me down the wrong path if it takes full control.</p>
People may think that in 2025 AI usage is radically different, but the fundamentals remain. The principles above stay true no matter how powerful the tools get.</p>
Thanks for reading this human‑written article!</p>
References🔗</a></h2>


Co-intelligence Book</a></p>
</li>

GitHub Copilot</a></p>
</li>

Claude Code</a></p>
</li>

Gemini CLI</a></p>
</li>
</ul>


My Failure Resume
2025-06-22T00:00:00+00:00

A resume typically showcases successful projects and achievements. A failure resume does the opposite — it lists failures to show the battle scars from software engineering. Software engineering isn’t for the faint of heart, and I’ve had my fair share of failures over the past decade.</p>
I am writing this to show others that I am like any other human. Many times, people assume that I do things with elegance and ease and achieve success.</p>
Right from school, I have met many smart people who are smarter than me in magnitudes. It is a disservice to life and those people not to speak of my failures and show to be on par with them in success.</p>
One thing is for sure. I valued curiosity, problem-solving & networking from the beginning of my career. Those qualities helped me overcome my shortcomings.</p>
This article presents some of those failures I encountered at work, and how I overcame them. This is an honest self-critique, shared publicly to break free from my bubble of success.</p>
Failure 1: Spend too much time learning on the job🔗</a></h2>
At the beginning of my career, I wasn’t a quick learner. In the teams I was part of, there were amazing and fearless learners. Even my doing skill has a few shortcomings in comparison to them. I was strong in theory but weak in practice.</p>
This weakness forced me to spend considerable time learning on the job. While it’s expected for beginners to learn as they go, my pace didn’t meet expectations. There is no shame in saying I was lagging.</p>
It took 2–3 years to assess and improve my skills and understand what I could and couldn’t deliver. There are a few things that helped me to improve myself. I will present them now.</p>
What Helped Me?</b></p>
There are a few initiatives that helped me improve in that phase:</p>

Maintaining a journal</li>
Repeating the patterns used by seniors</li>
Constantly reviewing myself & setting goals</li>
</ol>
Failure 2:  Spend too much time doing the job🔗</a></h2>
There were times when my tasks slipped through multiple sprints, likely because I blindly accepted poorly estimated tasks and didn’t ask questions during backlog grooming sessions.</p>
I mistakenly believed our backlog was meticulously groomed and that completing tasks was simply a matter of time. As you predicted, I was wrong.</p>
Beyond inaccurate estimations, I overlooked tasks that required additional communication with other teams. This wasted valuable sprint time because I had to find information myself that a team member might already have known.</p>
What Helped Me?</b></p>
There are a couple of things that assisted me in getting better here:</p>

Step out of my comfort zone and ask the right questions</li>
Put extra thought at the beginning of the task</li>
</ol>
After making those tweaks, I saw a significant boost in my velocity.</p>
Failure 3: Release code without testing it thoroughly🔗</a></h2>
Like many software developers, I had a lazy habit of assuming things would work when I made small code changes. I was wrong 90% of the time.</p>
How did that happen? I used to unconsciously skip manual testing of code and system functionality. I learned the hard way that making tiny changes to a massive codebase can cause unpredictable regressions, making it essential to test every change before shipping software. End-to-end testing can still break because systems work charms in isolation, but when integrated they fall like ninepins.</p>
 What Helped Me?</b>
Knowing that systems always need additional testing after changes, I now test everything beforehand and tell myself: “Assume your system is broken unless confirmed through testing!”</p>
Also, ”Write a lot of unit tests”</b></p>
Failure 4: Deploying code into production on the Fridays🔗</a></h2>
I did a few Friday deployments which ruined my co-worker’s weekend and mine too. Some of this urge to ship may manifested from the delays in the sprint work (Failure 2).</p>
Shipping code is fun, but breaking things for customers during the weekend when everyone’s unavailable is a nightmare. I still get that urge sometimes, but with a decade of industry experience, I know some things are better postponed — and Friday releases are definitely one of them.</p>
 What Helped Me?</b></p>

Not deploying on Fridays unless the team approves it</li>
Not doing any major code merges before going on a vacation</li>
Being empathetic about my colleagues & their time</li>
</ol>
Failure 5: Restarting a production database mistakenly🔗</a></h2>
I once mistakenly restarted a production PostgreSQL database because I had multiple AWS console tabs open (dev, test, and production) and clicked on the wrong tab. This happened because I lost concentration during my end-of-day routine of stopping the database server in the test environment.</p>
Luckily, it was just a simple restart of an AWS RDS instance — no data was lost and no requests were dropped — but I still remember that heart-stopping moment when I realized I was working on a production database.</p>
After that incident, I installed a Google Chrome extension AWS-Colorize</a> that marks production accounts in red, helping me visually avoid any destructive actions.</p>
What Helped Me?🔗</a></h3>
Nowadays, I triple-check while operating on a production account. I developed the habit of staying alert to keep myself and others safe while performing destructive operations like writing and deleting data during complex migrations. Resource isolation is also another way to keep accidental stepping of production workloads.</p>
Failure 6: Getting stuck in the head for way too long🔗</a></h2>
Four years ago, during a daily standup meeting, I experienced a complete mental blank when my turn came and couldn’t say a single word about my current task for several minutes. My colleagues listened in silence, clearly struggling with the awkward situation. I picked a task and went into a rabbit hole of low-level details, missing the top-level goal completely which was caused by brain fade.</p>
Maybe I was building up hidden mental fatigue over a long period without realizing it until it finally surfaced on one difficult day.</p>
It was a very awkward moment. I could have prepared for the meeting in advance, knowing I had to report during the call, but I failed to do so.</p>
 What Helped Me?</b>
Here are the mental adjustments I made thereafter:</p>

Be prepared for important meetings</li>
Don’t go through endless rabbit holes, know when to stop and seek help</li>
</ol>
Failure 7: Laying out grand plans but not executing them🔗</a></h2>
In my previous companies, I consistently brought fresh thoughts and new ideas to every sprint review meeting. Even in 1:1 with managers, I shared many improvements for ongoing efforts. This is a welcoming thing because I am contributing where I was expected to.</p>
Looking back, I realize I generate new ideas faster than I can execute them, and execution is what creates value for my team and company. I regret not choosing two or three top ideas from my collection and seeing them through to completion.</p>
I learned the hard way why people say “It’s hard to multitask from end to end.” A few great books I read lately suggested I focus on the top two initiatives and delegate the rest.</p>
What Helped Me?</b></p>

Follow the Eisenhower Method for prioritization</li>
Hold the excitement to work on new shiny things</li>
</ol>
Final Thoughts🔗</a></h2>
Thanks for reading my failed Resume. The point here is not to focus on failures but on how they gave me a chance to learn and correct myself for future endeavors. If you’re a young person reading this, remember that we’re all learning together, so keep turning your failures into opportunities. All humans make mistakes, and I am no exception. That’s all I have to say!</p>
References🔗</a></h2>

Eisenhower Matrix: Wikipedia</a></li>
Chrome extension to color AWS accounts: ChromeWebStore</a></li>
Brain Fade & Cause: HealthLine</a></li>
Favorite book on topic: Amazon</a></li>
Motivation to this article: Harvard Business Review</a></li>
</ul>

References 🔗</a></h2>

OpenCode — AI coding agent framework</a></li>
Linear MCP Server</a></li>
Greptile — AI code review</a></li>
Claude Code — Agentic CLI for Claude</a></li>
The Pragmatic Programmer — Andy Hunt & Dave Thomas</a></li> </ul>

Read my past writings on Medium and Substack

How to develop software with AI in 2025

References 🔗</a></h2>

Co-intelligence Book</a></p> </li>

GitHub Copilot</a></p> </li>

Claude Code</a></p> </li>

Gemini CLI</a></p> </li> </ul>

My Failure Resume

References 🔗</a></h2>

Eisenhower Matrix: Wikipedia</a></li>
Chrome extension to color AWS accounts: ChromeWebStore</a></li>
Brain Fade & Cause: HealthLine</a></li>
Favorite book on topic: Amazon</a></li>
Motivation to this article: Harvard Business Review</a></li> </ul>

- Blog

What AI really needs from you while collaborating

References 🔗</a></h2>

Why Tone & Purpose - Purdue University</a></p> </li>

Are You Too Nice? - Psychology Today</a></p> </li>

Ask Claude Opus 4.6 & see what it says - Claude AI</a></p> </li> </ul>

Things I Learnt This Week (Week 15 of 2026): Mental Models, AI Agent Security, Future of Work, Flat Orgs

What Running a Multi-Agent Software Project Actually Looks Like

How I built this portfolio ground up (TLDR)

- Blog

What AI really needs from you while collaborating

Things I Learnt This Week (Week 15 of 2026): Mental Models, AI Agent Security, Future of Work, Flat Orgs

What Running a Multi-Agent Software Project Actually Looks Like

How I built this portfolio ground up (TLDR)

Read my past writings on Medium and Substack

How to develop software with AI in 2025

Tips for reviewing AI work as a co‑pilot🔗</a></h3> Look for inefficient operations.</li> Look for dangerous operations.</li>

Tips while using AI as a debugger🔗</a></h3> Slow down.</li>

What does AI do?🔗</a></h2> Drafts Dockerfiles, shell scripts, and other repetitive tasks.</li>

How can you save time?🔗</a></h2> Delegate repetitive setup and scripting tasks (Dockerfiles, CI, shell scripts).</li>

My Failure Resume