Relearning Software Architecture in the Age of AI

I am bad, really bad at coming up with a name for the blog before actually writing about it.
We will go on to what we learnt today and then get an appropriate title on this thing.
I’m pretty sure that otherwise there is no way that I am actually gonna write anything and keep going in circles about what to write and dropping any good or bad idea that comes to my head. SO here goes.

Thinking deeply — really deeply — about software architecture is where the world is heading now(?). We are in the age of LLMs, sure, but I’m sure there are people out there who want to read and understand things on their own. Who want to be the PUNKS in this world. Haha. Well anyway, it is fun, yeah? We are all learning out here, and writing is one of the best ways to learn, of course.

It’s been nearly 2 years now for me at my job. I have gone through two different full stack applications — one on React, Alfresco, Node, Redis, SQL, and another on Angular, Python, LiteLLM, and Mongo. I also work on Kubernetes quite regularly and have done AWS deployment for apps in both Kubernetes and non-Kubernetes ways. Other than that, some prompt-engineering — getting some agents to work together in a way I want. Out of all of these, the agent orchestration absolutely burnt me out, because of course, that takes a different part of your head. More R&D than actual development. But yeah, that was fun too.

In all this time of doing all these things, I’ve realised that I usually just sit down and figure things out to make things work. As I’m approaching the 2-year mark of my job, I’ve realised that this is not enough. We have discovered a bunch of issues that came out because we didn’t spend enough time in the ideation process.

Right now, I am focusing more and more on that process. Taking more reviews and doing more reviews of my own code. Currently, in the process of revamping our entire application from scratch, we’ve found glaring issues and the importance of monitoring tools and the need to follow them. Software development always intrigued me, but I was at a place where I just wanted to solve things as fast as I could — not at a place where I sat down to think as an engineer. Anyone can be a coder, but being an engineer requires design, thought, reviews, and discussion — things we were missing out on.

Our main goal is to talk as much as we can, be modest and open with our flaws in thought: How do we make this better? How do we optimise that so we don’t have to write something all over again? All classic dev questions — and all of it always leads to the age-old design patterns with OOPs. It is indeed the holy grail. And somewhere along the way, with the advent of ChatGPT and it not having enough context for what we were trying to solve, we lost our way. We are in the process of re-learning everything and hoping to leave our codebase in a better state than when we started.

This is especially important since, with the increasing advent of AI and tools like Cursor, better-written and better-designed code will lead to easier and more efficient development. So it is indeed always a two-way effort. Even though there are clear indications of us being overtaken with time, the absolute novelty in thinking and designing something with tried-and-true concepts gives me a feeling that is much, much more fulfilling than all the times I developed things without much thought, using prompts that were not thoughtful enough.

Either way, stay tuned!