Originally published on nvarma.com
These are my personal thoughts, experiences, and opinions, and they do not reflect the views of the company I work for.
Recently, I was reading a Hacker News thread about a blog post called "We might all be AI engineers now". The comments were really honest and very much the kind that makes HN light up with the most raw takes on almost anything that is posted.
"Not a day goes by that a fellow engineer doesn't text me a screenshot of something stupid an AI did in their codebase. But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write."
"The code it generates is locally ok, but globally kind of bad...LLMs will always get worse as your codebase grows."
"All I'm saying is you're gonna have to figure out how to do this with an agent."
Between that thread and my own X & LinkedIn feeds, the terms keep piling up. Forward Deployment Engineering. Agentic Engineering. Token Cost Optimization. Context Engineering. AI Safety Engineering. A few years ago, I'd have dismissed any of those terms as science fiction.
I'm reflecting on this strange sense of deja vu. In 2001, I was a student in India living through the dot-com bubble burst from across the ocean. In 2007, I was an early-career software engineer in India's IT services industry, on the receiving end of the follow-the-sun model, watching global delivery models get stitched together in real time. By 2010, I was a grad student in the US just about to enter the workforce when the mobile app boom had everyone convinced that if you didn't have an app, you didn't have a business. By 2014, as a tech lead on a team, I witnessed every company was scrambling to get their infrastructure "into the cloud." At every inflection point, the vocabulary changed. However, the anxiety as we went through this shift was real and very humbling to experience. One of my observations is that the people who came out ahead weren't the ones who predicted what was coming next. They were the ones who'd seen the pattern before and prepared well for what came ahead.
I wrote about this feeling of acceleration back in January in AI Saturation and touched on it again in Software Engineering as a Craft. So three months later, I'm still processing the pace when I notice small things that keep adding up. I keep coming back to a realization that the playbook for leading through AI isn't actually new. It's been written before by leaders who navigated transitions much before my time as an engineering leader.
The Internet: When it was cool to be on the "Web"
I remember the late '90s as a teenager growing up in the emerging world of software services in India. You could see how everyone was joining Engineering colleges that sprung all over India, especially across South India. You had students scoring the top ranks all choosing Electronics and Communication Engineering (ECE) or Computer Science and Engineering (CSE) at the same pace as someone taking up Medicine. The more "core subject" student chose something like Electrical and Electronics Engineering (EEE) or more niche area like Chemical Engineering, Textile Engineering and so on. However, the Y2K problem had sent demand for computer-literate workers through the roof in India, and suddenly everyone was enrolling in NIIT evening classes the same way the generation before had lined up for typewriting classes. Over in the US, every business needed a website, a "web strategy," and a "webmaster" (remember that title?). Entire consulting practices sprang up overnight to help brick-and-mortar businesses figure out HTML. Pretty much everyone who I studied with in school pursuing a non-CS college degree still pivoted to an IT job in the software factories using labor arbitrage to their advantage. Well, we've come a long way since then in retrospect.
Most of those web companies in the dot-com era failed. This was not because the technology was bad, but because they'd confused having a website with having a business. The ones that survived, for example Amazon selling books, Google organizing information for people to discover data, Yahoo providing email and news solved a real problem for real people. The technology was the enabler but not the product in and of itself. The leaders I admired by observing their meteoric rise during that time and those who led through changing times shared a common trait: they asked "why are we building this" or "what problem does this solve?" before they asked "how does this technology work?" The ones closer to home who were benefiting from the Y2K moment were paying attention to the new tools to learn how to support other businesses through transformation. Smart leaders leading businesses refused to let the tools drive the strategy, solving a business problem leveraging them made them stand out.
Global Delivery: When your work spanned Time Zones
The global delivery model (aka offshore development centers) wave of the mid-2000s was different because it wasn't really about technology at all. It was about operating models, about economies of scale, tapping into the economics of labor arbitrage and global financial macroeconomics. Your team wasn't down the hall anymore. They were in Dublin or Bangalore or Hyderabad or Manila, and depending on which time zone got priority, your meetings were either at 7 AM or 9 PM.
I have lived this from both sides, which gives me a perspective I don't think everyone has. If you did not realize it by now in this post, I was a student during India's IT boom of mid-90s to mid-2000s. I watched relatives and family friends build careers in IT services companies that were scaling people at breakneck speed. As an early career Engineer, I entered the workforce in a services firm whose employee number is currently at ~353,500. I was #71,000 about 20 years ago. Later I moved to the US for grad school and experienced the other side of it, working on teams that were figuring out how to collaborate across 12-hour time zone gaps. The fear of missing out on both sides was something else. I still remember one of my first global projects where I got a ping from a client in Atlanta at 7:30am their time, when I was closing out my day at 5pm after my evening tea. People in the US focused on getting the project completed with the same quality as what they would have done in-house. People in India worried about being treated as interchangeable if this project did not go well, or if cost-overruns threatened future contracts. And managers everywhere were dealing with communication overhead, quality concerns, and the famous "follow the sun" model that sounded brilliant in a boardroom but was complicated in practice.
The good leaders I worked with during that time understood something important. They invested in communication infrastructure before they invested in headcount. Shared documentation, clear ownership, regular face time even if it meant someone was on a video call at an unreasonable hour. They built distributed teams into their organization design, not as a cost optimization. My experience of seeing companies who treated offshore DCs purely as a cost-cutting exercise got exactly what they paid for. The ones who saw it as a way to access global talent and build something more resilient? Those organizations are still thriving. It is funny that the age of AI takes us back to the same principles. I still remember in my new hire training, an off-the-cuff remark made by a trainer about "document everything, so if you get hit by a bus, the project continues". That's not what a starry eyed new college grad wants to hear, but it was the reality of operating a world where humans are replaceable cogs in a larger system that chases the bottom line.
Mobile Apps: Adjusting to a whole new era of smartphone apps
Apple launched the iPhone in 2007 and the App Store in 2008, which triggered the smartphone app wave. It felt like the dot-com boom all over again but in your pocket. Every business needed a mobile app. It didn't matter if you were a restaurant, a dry cleaner, or a bank. "There's an app for that" became the mantra and entire companies were built around the idea that mobile was going to eat everything.
I remember the explosion of new titles here too. "Mobile Developer" became its own specialization overnight. You had iOS developers, Android developers, and then cross-platform developers arguing about whether PhoneGap or Titanium or later React Native was the right way to build. App marketplaces created a whole new distribution model that startups could ride without needing a sales team. And the gold rush of apps, most of which were terrible, reminded me of all those dot-com websites that existed just to exist. I still remember seeing my favorite Snake game in Nokia get replaced by Tic Tac Toe or Chess as the default game to play. The concept of games never went away, but the mode of delivery and interactivity birthed a new frontier for businesses wanting in on action.
What struck me most was how the best companies during that era didn't just build an app and call it done. They rethought their product for the new form factor. The ones who just shrunk their website into an app got mediocre results. The ones who understood that mobile was a different context, different attention span, different interaction and data model, they built things that actually worked. Every country did not have access to these devices nor did the internet penetration really go so quickly, so you had to adapt to tracking metrics differently and build for your audience. It's a lesson I keep coming back to now, because a lot of what I see with AI integration today feels like the "just shrink the website into an app" phase.
Cloud Migration: When "Just move it to AWS" was the popular answer
The cloud migration wave of the mid-2010s is the one I experienced most directly, first as a hands-on engineer and then as a team leader working on K-12 compliance software. "Lift and shift." "Cloud-native." "Serverless." Customers were wary of the move to the cloud, it meant a loss of control or maybe a doubt around trusting a third party with their most important data. Eventually, they came back to the same question: "Why isn't this in the cloud yet?". When an industry deals with transformations in technology, the first reaction is to not trust the thing. Eventually, the new normal is to expect everything to follow the new pattern of work.
That era had its own explosion of new titles. Centralized DevOps teams popped up everywhere. "DevOps Engineer" became a real job title that hadn't existed a few years prior. AWS certifications became the new resume standard. Companies were hiring cloud architects before they'd even decided what to migrate. I remember a specific conversation with a VP of Engineering, "We need to provision AWS accounts as soon as possible and move everything to it". I was sceptical about the team's experience with cloud infrastructure. It was marketed as an opportunity to learn. It reminded me of when you buy a brand new Mercedes-Benz for your first behind-the-wheel driving lesson. Or in my case, it reminded me of when I bought a $100 guitar to learn how to play (P.S: I've probably tried learning it with a start/stop cycle of 50 times).
Coming back to that cloud migration story, I moved on before I could see how that particular story ended. I recall every company was playing whack-a-mole with massive on-prem to cloud migrations. Meanwhile, cloud-native companies entered the fray without any legacy baggage, and acquisitions and mergers drove a lot of the strategy for incumbents. Cloud data centers continued to be built for the day when the great on-prem migration would come. Entire data center industries came up where companies operate private clouds by renting out server space. It became an inflection point where build vs. buy conversations started driving capital expenditure in ways they hadn't before.
This feels like the same story in a different decade. Cloud computing really was better for most workloads, but the genuine shift got distorted by urgency and hype into a mandate without a plan. The leaders who got it right treated migration as a multi-step transformational journey, not one quarter's OKR. They ran experiments, picked the right workloads first, invested in training before migration tooling, and were okay with some things staying on-prem. However, doing nothing and sticking to old ways led to eventual disintegration as the industry moved to newer frontiers. You were discussing and debating strategy when the market transformed around you.
AI in 2026: Where we are now
I'm looking at my feeds right now and it's a fire hose. AI Safety Engineering. Local LLMs you can run on a Mac Mini (I've been doing this myself). Cloud API providers for every conceivable AI service. Token cost optimization as an emerging discipline. Agentic use case prioritization frameworks. Agentic engineering as a job family. Forward Deployment Engineers who sit between the AI model and the customer. Every week there's a new infrastructure, a new framework, a new model release, a new attempt at trying to pivot cloud offerings into the AI era. My LinkedIn feed looks like a word cloud of terms. The irony is Generative AI in itself has caused so much AI saturation hitting LinkedIn, X, Medium and so many other places. I'm surprised by how much AI saturation there is, the abundance of information is indeed something that provides a great opportunity to filter the signal from the noise.
This feels familiar because the pattern is always the same. A real technological shift creates genuine new capabilities, which creates a gold rush of new companies and job titles, which creates the FOMO feeling about falling behind, which creates pressure to adopt everything at once. In my opinion, the leaders who navigate this well are the ones who resist that last part.
Thoughts on navigating a new era
I don't have it all figured out. I didn't live through the pre-Internet computing world, so that may offer lessons for students of history and is something I'd like to read up on (comments welcome on any reading material!). But having watched four of these cycles play out in my career, I'm thinking of a few things to keep me and the people around me grounded.
I'm treating AI in my daily workflows as a strategy, and baking in evals at every step of the way. This is the same idea as distributed teams being a strategy with clear contracts, or cloud infrastructure being one with metrics around costs of ownership & operations driving architecture decisions. The question I keep coming back to is "what problem are we solving, and does AI actually help us solve it better?". Sometimes the answer is yes. Sometimes being clear about what you want to build into the spec or finding an off-the-shelf library gets you further.
I'm advocating for experimentation time for my team, I try to keep inspiring them into trying things out and blocking dedicated time for self-learning. One of the biggest mistakes I saw leaders make during the cloud migration era was not giving their teams time to learn before expecting them to deliver. I'm trying not to repeat that but it is hard as the days go by. Sometimes sounding the alarm seems too heavy-handed, but I recognize that lifelong learning is a skill by itself. I wrote about this in my post on the craft of engineering, I really like the idea that everyone starts at zero. Only by getting your hands dirty would you actually see that the learning sticks.
On the topic of taking risks, I'm being deliberate about which ones to take but I've always believed in thinking differently. During the cloud migration wave, companies that did not pay attention to their core user base but pivoted a 100% to the new technology ended up doing badly at both. I'm wary of applying that same thinking. Deterministic outcomes in certain industries matter more than probabilistic outcomes. Moving with a sense of urgency is good, and I'm thriving in a world where the constraint is no longer the ability to produce something, but making it really useful is an interesting challenge to live through. Building with people who care passionately about the problem we are solving as much as the technology used to solve it is an added bonus.
I keep watching for what I think of as the naive "follow the sun" trap. Follow the sun is a legitimate operating model. Many global companies run it successfully today. The early versions assumed you could hand work off across time zones without losing context often leading to things breaking. The companies that made it work invested heavily in documentation, handoff rituals, shared tooling. The ones that just split epics across time zones and hoped for the best ended up slower with more bugs. I see some interesting parallels with how teams are choosing between traditional software delivery and pivoting to embed agents into workflows. As of today, human in the loop tasks requiring judgment, context, or institutional knowledge are being revisited to see how they should evolve. The companies that invest in the scaffolding around this with agent harnesses, clear specs, guardrails, human review loops where needed, will get the value. The ones that skip that work to jump on the "trending this week" train will be in the same predicament around how the cloud migration occurred.
The dust always settles
In January, I wrote that I thought we had about two years before the dust settles in this evolution around our software engineering craft. I still believe the world has changed for better, and we're discovering new ways of working, while the two years seem very far away. Every quarter seems more exciting than the past one. Every major industry shift I've lived through followed a similar pattern. There's an explosion of activity followed by a period where things consolidate with winners and losers in technology, processes and patterns. Eventually a new steady state where the real value becomes clear and the noise fades.
The pioneers of new technology often displaced some of the old players, some adapted to survive in the new world. The shift of the landscape though was permanent. The path from "everything is changing" to "here's how we actually work now" did not take days. It took months, if not years, and the breakneck pace of innovation took a solid 12 months to become structured with formalized set of learnings.
I don't know what the steady state looks like for AI as it transforms the world. Nobody does, and I'm skeptical of anyone who claims to. But I do know the playbook for getting there: filter the noise, invest in your people, manage your risks deliberately, and give yourself permission to not adopt everything at once.
We've been here before, we are living through it again now and I'm pretty clear that we'll be here again in the future. The specific technologies change but the leadership challenge stays remarkably consistent: stay curious enough to learn, disciplined enough to focus, and patient enough to let the dust settle.
If you're an engineering leader feeling overwhelmed by the pace of change right now, give yourself time to take a breath. I did. This moment feels similar to what leaders went through in 1999, 2007, 2010, and 2014. It means something real is happening. It also means the most important thing you can do right now is think clearly to navigate through a changing landscape. I was a practitioner in the past transformational shifts, I'm a leader of people and technical strategy in this one. The path forward is bright for those who see light in the possibilities. How you see the world and how you can navigate change may define how you lead your teams. What an exciting time to be building!
This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.
