How I found my "why" again

2nd October, 2026

An account on how I found my purpose in this new era of AI

---

This is the first time in a very long time that I'm writing without AI. So this might sound unrefined. This writeup is mostly for me, to collect my thoughts and to deliberate carefully. This is about how I lost my purpose, and how I found it again. You may not agree with me on these accounts, and that is totally fine. So let's get to it.

The new developments in AI have made a profound impact in the world. Its most popular use case is with software engineering, where most manual parts of the SDLC can now be automated. Programmers are born to automate. That's what we do. So that's where AI has currently found its home, even though its impact propagates to almost any industry. AI has enabled engineers to ship features faster than ever, and some good ones build exceptionally great things. LLMs grew at an exponential pace, and some argue it still does. In this status quo, it's easy for beginners like us to lose our purpose; lose why we exist, as what we do, learn, and know can sometimes be just done with AI.

How and What I lost

In terms of software engineering and architecting, I have a long way to go, and I have just started my career as a software engineer. Even before I finished with my undergrad studies, ChatGPT came out, and it took the industry by storm. When I was building a three-tiered application for the first time, GitHub Copilot was already out. Those days, I didn't even have the adequate knowledge and experience to even understand why people found it useful. It overwhelmed me, because it seemed to decide even before I was done thinking what I wanted. Not until towards the end of our second year project did I understand its real use. By the time I completed second year, ChatGPT was already out, and the same cycle continued.

It didn't seem convincing at first, but slowly and increasingly, it felt like what we are doing, and what we are studying, is becoming pointless. I almost do not code by hand. I spend most of the time reviewing code written by AI. At first it felt exhausting and overwhelming, and most importantly, it felt like AI took away a part of the work I loved the most.

I love coding. I love waiting anxiously while the hot reload kicked in with my changes to go check my page layout change the way I want, or finally figure out the perfect padding and border radius to get perfect rounded corners in a card element, or see the backend business logic play out the way I exactly wanted it to. That sense of satisfaction was everything. I love how the keys feel on my fingers while I typed. I literally use MonkeyType for therapy. It felt like AI is taking those away.

We don't really have to write code by hand anymore. No more hot reloading. Just hop on to a planning session with an agent. Once done, ask it to write up another prompt for an implementer agent, and paste that right back to another new chat to get it done. It does the job often better than you could have done the first try. What we have to do is the least fun part. Review it. We now are left with the thinking and problem solving, the hardest part of software engineering. Don't get me wrong. It's not that I hate it; in fact I love it, but it feels exhausting, overwhelming to do it all the time, and above all, it felt like reviewing is actually useless since the amount of human review it requires is becoming increasingly low. We really might come to a point where AI will be the new age of compilers.

How I found my "why" again

I have a knack of refusing to adopt something just because it's the new trend in the industry. I let it sit for a while. I learn about it. Learn why and how it's useful for us, and how it can be used to make our life easier. It has become increasingly apparent to me that that slow deliberation has paid off profoundly for me.

I have actually grown to love the new SDLC. While what I said about planning with the agent and asking the same agent to implement sounds really simple and shallow, I have come to understand that it's way more deeper than that.

I had the opportunity to work on a completely new microservice at work. I had the freedom to propose my own design, plan it out with Claude, and implement. I enjoyed every little part of the process. I first laid out the underlying structure by hand, and asked Claude for its own recommendations. I learned everything it said in depth, assessed the options, and went ahead. Once I got the hang of it, I slowly started offloading more of the work to Claude. I spent an entire week pretty much creating the initial structure of the code.

I started to ask Claude to generate instruction files such as CLAUDE.md, Architecture Decision Records (ADRs), etc. I learned to find value in the grill-me skill. After every change made by the agent, I carefully reviewed it, understood every single line and why it was there, and made changes when necessary. I noticed that the instruction documents became bloated over time, and the agent would choke on its own instructions. So periodically, I had to plan out and segregate those documents in to smaller digestible chunks for the agent. Just like for a human.

At the same time, I also worked on a personal pet project called Ideate. I didn't review any of the code. I wasn't careful with the prompting, because it was just a pet project after all. It came to a point where Claude started to use ~15% of the session with just a single message asking it to change the padding of something. The more features I asked it to add, the more complex the changes became, and the more time it took, and slower the app became. The CLAUDE.md was humongous. I realized the contrast between the two projects, and I came to a realization as to what caused it. This might seem obvious for anyone reading, but for me it was just an abstraction. I felt the weight of it once I experienced it myself.

AI needs grounding

Let me digress a bit. Up until 1971, the value of the US Dollar was tied to gold. So the official price of gold was constant. This was called the Gold Standard. However, it was abolished in 1971. Ever since then, USD has lost its value steadily.

ColdFusion visualized this by cutting the tether that keeps a balloon from drifting away.

Just like that, if we cut the tether grounding the solution to the human and let the agent do whatever it wants, it messes everything up. The code will get bloated, it will start suffocating on its own code and instructions, start solving the wrong problems, and often create new ones. It quickly becomes a nightmare to maintain. This is due to architectural erosion. Gradual changes to the code cause the system's architecture to weaken over time, if not done carefully.

I learned that satisfaction can be gained through solving problems. It feels satisfying to get the output you want. It feels satisfying to draft a design knowing that you addressed most of the pitfalls. Figuring out the right architecture, having the sense that you are in control, knowing how every feature is wired, gives a sense that you drove it. It feels like a higher order pleasure, but that doesn't mean I stopped enjoying coding all of a sudden, after all.

Code is a great way to represent behavior and state. We can now encode that information in to a prompt. We have just learned a new way to compress information, encode meaning, but it very much requires human touch. Compilers didn't replace programmers. Programmers just started solving bigger problems. So I strongly believe that we as humankind will continue to achieve even higher levels of abstractions and that we will always be there, solving bigger problems than we ever could.

I had these sentiments for a while, but an article by Cameron Balahan and Richard Seroter from Google articulated them really well.

Fundamentals matter more than ever

I'm really glad I didn't take any shortcuts and tried to understand everything end to end before I moved forward with any concept, and I feel really fortunate to be placed in a culture that promotes learning and self growth. When I joined the industry after graduation, it took me considerable time to get used to the speed at which we ship features. Everyday, I learned something new, and on the same day I had to apply it to solve a problem. I learned enterprise architectural patterns, enterprise use cases, how production code bases are maintained, and to use AI effectively. I spent time learning, unlearning, and relearning the fundamentals, and ways to solve problems. One such example is the clean repository pattern and layered architecture. I don't want to pretend that I get it fully yet, but I visualize it as a clean set of networking cables plugged cleanly in to a switch. That's how dependency injection feels to me.

Knowing what you do, and fundamentals we learn during our studies, matter more than ever. That's what determines adaptability and our own resilience. Just like AI needs grounding, we need to ground ourselves in fundamentals and experience. In the last diagram, if the human themself wasn't grounded in the fundamentals and was just free floating on vibes, there's no point. A solution tethered to a human who lacks knowledge, experience, and purpose is still slop. So I'm of the strong opinion that any refactor the AI recommends doing to your codebase, every line of code it writes, you have to have a good idea of what it's doing, and you need to have the ability to evaluate it. I spent several weekends and nights on the Ideate app to refactor the slop. It's miles better now, but there's a lot needed to improve.

I'm really glad I was able to find my "why" again, and I'm sure I will have to keep finding it over and over again in this fast changing world. And I hope I'll always find it.