› Ashutosh Singh Rawat

Hi. I’m Ashutosh. Some people also know me as Ash.

World’s #1 procrastinator, self proclaimed coolest dad, innovation & product enthusiast, creator, tech+design fanatic, foodie, amateur percussionist, Ping pong player, and lol gamer.


If you’ve been feeling like something “snapped” in late 2024 and 2025—that your work still looks the same on the surface, but under the hood it’s suddenly… different—you’re not alone. The tickets, the stand‑ups, the sprints are all still here, but what it means to be a software engineer is quietly changing in front of us.

I have a strong hunch that when we look back a few years from now, we’ll say: 2025 was the last normal year for SWE. Not “the year all the jobs vanished,” but the last year where it still made sense to think in terms of big IT headcounts, pyramids of junior devs grinding through mundane work, and “coding” as the primary way individual engineers create value.

Because if AI agents can now take on hours of serious work in one shot—and are on track to handle days or weeks worth of it soon—then a lot of the industry logic we grew up with simply stops making sense.


One of the reasons I feel this so strongly is my own experience “vibe coding” since the end of 2024. At first, it’s playful: you toss half‑baked ideas at the model, it spits out working code, and you get this slight guilty rush—like you’re cheating on an exam and somehow getting away with it. But very quickly, that feeling changes. You realise that for a huge chunk of the work that used to occupy junior and mid‑level developers—CRUD boilerplate, glue code, small refactors, tests, migrations—the model isn’t just helping you. It’s doing the first 70–80% almost completely on its own, and you’re mostly editing and steering.

Now, zoom out from one developer to a typical IT services pyramid. For decades, these companies were basically arbitraging human time. Lots of juniors at the bottom, a thinner middle of project managers and tech leads, and a tiny layer at the top that actually understood business value and systems end‑to‑end. The model worked because you needed a ton of human “processing power” to move requirements to production: manual testing, hand‑rolled integrations, low‑risk features churned out sprint after sprint.

AI breaks that pyramid in the most boring, inevitable way possible: it chews through the bottom and middle. Not all at once, and not perfectly, but relentlessly.

Another reason 2025 feels like an inflection point is the quantitative side of this story. Benchmarks have quietly shifted from “can this model answer trivia and write leetcode solutions?” to “how many hours of a competent human’s work can this system realistically shoulder on a messy, multi‑step task?” That’s a fundamentally different question. And the answer has gone from “minutes” to “several hours” frighteningly fast, with credible people arguing that we’re on a curve where those “time horizons” might double every few months.

What that means in plain language is: the kind of task that used to keep a junior dev busy for an afternoon—a small feature, a non‑trivial refactor, a migration with some edge cases—is exactly the kind of task that an agent can now take a serious swing at, end‑to‑end, while you go for a walk and come back to review the pull request. Today that still feels magical; in a couple of years, it’s going to feel normal.

Now, I know some of you may be thinking: “Isn’t this just hype? We’ve seen automation waves before. Don’t these tools always look great in demos and then crumble on real‑world codebases?”

You’re right to be skeptical. Anyone who has actually tried to plug an “AI agent” into a non‑toy repo knows how quickly they can hallucinate, get lost in the file tree, or generate confident nonsense. The key difference this time is that we’re not talking about little autocomplete tricks in isolation. We’re talking about full workflows where the model can read large swathes of context, plan multi‑step changes, call tools (tests, linters, CI, APIs), and iterate on its own output. The failures are very real—but so is the slope of the curve.

Another objection you might have is: “Won’t this just create more demand for engineers? Every productivity increase in tech so far led to more software, not less.”

That’s partly true, and it will stay true for the engineers who adapt. There will absolutely be more software, more experiments, more agents, more systems to design and supervise. But the structure of that demand changes.

Think about the classic outsourcing story: a client has a big backlog of mundane work. A services firm promises to do it cheaper by hiring lots of juniors. Margins are thin, quality is variable, but the model “works” because you’re trading money for human attention at scale. Now imagine the same client in 2028. Do they really need a hundred juniors doing mundane work if ten strong engineers with good agentic tools can deliver the same output—or better—by orchestrating a small army of AI workers? It’s hard to see how the old pyramid survives that math.

So where does that leave you, the individual developer reading this?

One of the most important shifts is identity. If you still think of yourself primarily as “the person who writes code,” you’re going to feel this decade as a constant threat. Every new capability will feel like it’s eating your lunch. On the other hand, if you start to think of yourself as “the person who designs and owns systems of humans and AI agents to deliver business outcomes,” the same curve suddenly looks like your biggest ally.

Instead of panicking every time an agent can do another slice of your work, you start asking:

  • How do I scope work so that an agent can own it for a few hours or days?
  • How do I break down a week‑long project into phases that a model can handle, while I only step in at key review checkpoints?
  • How do I wire up my tools, repos, tests, and infra so that agents can do real work safely, not just churn out cute demos?

At that point, what you’re doing day to day is less “coding” and more “directing”. You’re specifying problems, setting constraints, deciding what “good” looks like, and then delegating execution to a mix of humans and agents. Your leverage comes from taste, architecture, product sense, and your ability to communicate with these systems—just like a good manager’s leverage comes from how they lead people, not how many lines of code they personally write.

Now, I know another fear lurking here is: “Does this mean only the ’top 1%’ of engineers have a place in the future? What about everyone else who’s just… solid?”

All that being said, I’m not saying “only geniuses survive”. What changes is the shape of “solid”. Being the person who quietly ships tickets on time but never really owns problems is going to be harder and harder to justify, because a well‑configured agent can look a lot like that person on paper. But being the person who can take a fuzzy business goal, turn it into a clear plan, orchestrate agents and tools to execute most of it, and then refine the result into something users actually love—that’s going to be extraordinarily valuable, and not just at FAANG‑style companies.

In fact, one of the more optimistic possibilities here is that individuals and very small teams get “agency” (pun intended) that used to be reserved for huge organisations. When a solo engineer with good agentic tooling can do the work of a small team, the barrier to trying new things drops. You don’t have to beg for headcount to run an experiment; you spin up some agents, point them at your code and data, and supervise. The constraint shifts from “how many people can I hire?” to “how many good ideas and how much taste can I bring to the table?”

At the end of the day, when I say “2025 was the last normal year for SWE”, I’m not saying that 2026 is the year everyone gets fired and the machines take over. I’m saying that 2025 will probably look, in hindsight, like the last year where you could reasonably plan a career around the old assumptions: big pyramids of human time, slow linear progression from junior to senior doing mostly similar work with more responsibility, and a clear boundary between “tools” and “teammates”.

What’s coming next is messier and more interesting: a world where you’re expected to work through agents, not just with them, where your ability to delegate, specify, and judge becomes as important as your ability to implement. If you lean into that now—if you treat today’s “vibe coding” as the training ground for serious AI delegation—you’re not just safe, you’re early. And in a world where capabilities are compounding this fast, being early is everything.

Hey there web designers! Are you tired of seeing the same minimalist, clean designs everywhere you look? Well, get ready for a change because I believe that neo-brutalism is going to be everywhere in 2023.

But wait, you might be thinking, “Neo-brutalism? Isn’t that the rough, raw, and unrefined architectural style from the 1950s and 60s?” And you’re right, that is the original definition of brutalism. But in the world of web design, neo-brutalism refers to a style that embraces raw, unpolished elements like bold typography, rough textures, and limited color palettes.

One of the reasons I believe we’ll be seeing more neo-brutalism in 2023 is the rise of nostalgia in design. As we move further into the digital age, there’s a growing desire to reconnect with the past and to embrace the tactile and imperfect. Neo-brutalism taps into this nostalgia by harkening back to a time when design was less about perfection and more about raw expression.

Another reason is the desire for authenticity in design. In a world where everything is curated and filtered, people are craving designs that feel real and genuine. Neo-brutalism embraces this authenticity by embracing the imperfections and embracing the roughness of the design. It’s a style that doesn’t try to hide its flaws, but instead embraces them as part of its charm.

But let’s not forget about the practical side of things. Neo-brutalism is a style that is easy to replicate and highly customizable. It’s a style that can be adapted to a wide range of designs and can be used in a variety of ways, from bold and powerful to simple and understated.

Now, I know that some of you might be thinking, “But what about accessibility? Won’t neo-brutalism make it harder for people with disabilities to use my website?” And you’re right, it’s important to consider accessibility in all of our designs. But neo-brutalism doesn’t have to be inaccessible. By choosing appropriate color contrasts and typography, and ensuring that all functionality is still operable via keyboard, we can create neo-brutalist designs that are accessible to all users.

All that being said, I’m not saying that every website in 2023 will be neo-brutalist, but I do believe that we’ll start to see more and more of it. Neo-brutalism is a style that taps into our nostalgia and desire for authenticity, and it’s a style that is easy to replicate and highly customizable. So, let’s embrace the imperfections and the raw elements, and see how we can incorporate neo-brutalism into our designs in 2023.

Hey there fellow developers! If you’re like me, you’re always on the lookout for the latest and greatest technologies and trends in web development. And one trend that I’ve been seeing more and more of lately (well, a few years now..) is the use of server-side rendering (SSR) for web applications.

Now, I know that some of you may be thinking, “But wait, I’ve been using single-page applications (SPAs) for years and they’ve worked just fine!” And you’re right, SPAs have been a popular choice for web development for a while now. But as technology and user needs have evolved, I think it’s time for us to start thinking about SSR as the default for web applications.

« Older posts Newer posts »