DEV Community: Abhijay Mitra

AGI is Coming — Cultivate Mental Models

Abhijay Mitra — Sun, 26 Apr 2026 19:31:05 +0000

Today, 75% of all new code at Google is now AI-generated and approved by engineers.

— Sundar Pichai, CEO of Alphabet/Google (April 2026)

A note before I begin. I do not personally believe complete AGI is coming anytime soon. I think the gap between "impressive model" and "genuinely general intelligence" is wider than the current narrative makes it sound, and most of the loudest predictions are, in my opinion, priced for marketing rather than reality.

This post is not a prediction. It is a thought exercise — if AGI does arrive, in whatever form and on whatever timeline, this is how I think things will play out for those of us working in tech, and this is what I think the only sane response looks like.

For most of my career, I treated AGI the way most working engineers did — as a someday problem. A sci-fi footnote. Something to argue about over coffee, not something to plan around.

I still think complete AGI is far. But I no longer think the shape of the disruption is far.

The AI tools already at my disposal have scaled up what "productivity" to a company means, and that is enough to take the rest of this argument seriously — even as a hypothetical.

Andy Grove, in Only the Paranoid Survive, gave me the vocabulary for what I am watching:

A strategic inflection point is a time in the life of a business when its fundamentals are about to change. That change can mean an opportunity to rise to new heights. But it may just as likely signal the beginning of the end.

— Andrew S. Grove, Only the Paranoid Survive

AGI is a strategic inflection point — not just for a business, but for an entire profession.

And the assumption that "this will take decades" is probably the single most expensive belief one can hold right now.

It's all about the game, and how you play it.

Why do I think AGI is actually coming?

I have never been persuaded by hype cycles or Twitter arguments. What changed my mind was watching several independent curves bend in the same direction at the same time.

Capability per dollar is doubling faster than Moore's Law ever did. Models that cost millions to train two years ago now run on a laptop.
Context windows have moved from 4K to multi-million tokens. That is not a feature upgrade — that is a phase change in what a model can reason over.
Agentic tool use has stopped being a demo and started being a product. ChatGPT processes 1+ billion queries daily, today. The gap between answering a question and doing the job has collapsed.

I remember this one personally — back in 2021, during my Salesforce internship, I was building a prototype of a live voice application where a patient could interact with an AI over a voice call, and it felt like a Sci-Fi Project.

Cut to today: HDFC Bank has a voice agent. Swiggy has a voice agent. What was a research prototype four years ago is now increasing my credit card limit.

Self-improvement pipelines — models training, evaluating, and writing the code for the next generation of models — are now standard infrastructure, not research curiosities.

None of these, in isolation, prove anything. But they are independent vectors pointing the same way, and they are reinforcing each other.

When three or four exponentials braid together, the outcome is not linear — it is a cliff.

But it still hallucinates, does it not?

It does. And five years ago it could not write a coherent paragraph.

The argument "it cannot do X today" has been wrong about every X on the list so far.

The more honest question is not whether the current generation can replace me — it is whether the generation two years out can do the median task in my job.

For most tasks in most tech roles, my honest answer is yes.

So what does this mean for a working engineer?

The lazy reading is "I will be obsolete".

A lot of what is your job today might be.

The more unsettling reading is this: the thing that used to make me valuable — knowing how to do the task — is being commoditised in real time.

Writing a CRUD endpoint, wiring up an auth flow, translating a spec into code, debugging a stack trace — these were the atomic units of the job. They are becoming the atomic units of a prompt.

This essentially means AI is already doing the job today.

A pathetic joke I keep telling myself: the only skill an engineer really needs now is writing a good skills.md for Claude.

So the question I keep returning to is: what is left? What cannot be commoditised?

What cannot be commoditised?

Judgement. Taste.

Knowing which of ten plausible solutions is actually right for this system, this team, this customer, this decade.

Naval Ravikant makes this point more sharply than I can:

Learn to sell, learn to build; if you can do both, you will be unstoppable. But more importantly, specific knowledge, accountability, leverage, and judgement — that is what pays.

— Naval Ravikant, The Almanack of Naval Ravikant

Of that list, the first three are already being amplified — and in some cases replaced — by AI tooling. Judgement is the one that is not.

And judgement, when I look at it carefully, is downstream of exactly one thing — mental models.

It's all about control, and if you can take it.

What is a mental model, exactly?

A mental model is a compressed, reusable representation of how some part of the world works.

If you are a KGPian, you already know this by another name — it is just a "funda", the kind a wise old senior drops on you over chai at the hall canteen, the kind that stays with you long after you have forgotten the syllabus it came wrapped in.

Shane Parrish has spent the better part of a decade formalising this on Farnam Street, and his working definition is the cleanest I have come across:

A mental model is simply a representation of how something works. We cannot keep all of the details of the world in our brains, so we use models to simplify the complex into understandable and organisable chunks.

— Shane Parrish, The Great Mental Models, Volume 1

A good mental model is a portable sword. You carry it with you and consult it when the winter comes.

A few that live rent-free in my head, that I use all the:

Naval Ravikant — the harder path. "When you have two paths that seem equally good, pick the one with the most short-term pain." The easy path is usually easy because someone has already extracted most of the value from it. The hard path compounds.
Chesterton's fence. Before removing a rule, a process, or a piece of code, know why it was put there. Most "legacy" code is legacy because it survived something you didn't see.

They are lenses. One does not use them — one thinks through them.

The best way to collect mental models is to read books, and wisdom.

Here is the part I think most people miss. LLMs are extraordinary at facts and syntax, and surprisingly poor at picking the right lens. They will happily generate a technically correct answer to the wrong question. They will optimise the metric they were asked for and ignore the metric that actually mattered. They will solve the puzzle in front of them without noticing it is the wrong puzzle.

That gap — the gap between a correct answer and the right answer — is where humans still live. And it is made almost entirely of mental models.

Here is the part worth being honest about. AI can do mechanical work blindingly fast — it can write the boilerplate, stub the tests, refactor the module, translate the spec — and it can do all of this at a speed no human can match. What it cannot do, at least not yet, is innovate. It cannot look at a problem and decide the problem itself is wrong. It cannot take a leap that is not already implicit in its training data. That act — the act of originating — is still a human job.

Steve Jobs said it cleanly:

Innovation distinguishes between a leader and a follower.

— Steve Jobs

The machine is an extraordinary follower. The leader still has to be you.

And the leading — the seeing, the choosing, the originating — is done with mental models. This, I think, is the actual way out of the AI revolution. Not outrunning the machine on its own track, but stacking lenses until one can look at the same data and see a different problem.

Charlie Munger put it bluntly, and it has stayed with me:

You must know the big ideas in the big disciplines and use them routinely — all of them, not just a few. The man with a hammer sees every problem as a nail.

— Charlie Munger

The way out is to not to always choose the hammer. Cultivate enough fundas that one can reach for the right tool, the right lens at the right time.

It's all about the debt, and how you pay it.

Honestly, AI-driven global warming might kill us first

The datacentres behind every frontier model drink water and electricity at a scale most people have not internalised. Cooling that pulls from municipal water supplies already running dry. Ice caps melting a little faster every quarter. Sea levels creeping up on coastlines that were already on borrowed time. Bangalore — once famous for its weather — now feels like Kolkata in peak summer, and AI is not the only reason, but it is squarely one of them. We are burning a staggering slice of the planet to get machines marginally closer to our own benchmarks.

This brings in the other point of no return, apart from AGI, we are missing over here is global warming. AI-driven global warming might genuinely kill us before AGI ever arrives. The climate curve is also an exponential. It is also reinforcing. And unlike the capability curves, it is not one any of us can opt out of. And countries need to cooperate with each other in other to make AGI or the progress towards it ethical.

It's all about the pain, and who's gonna make it.

What I have concluded

AGI is not the end of the career. It is the end of the kind of career where knowing how to do, or what to do was enough. The question why something needs to be done is seemingly more difficult for AI to answer, and is precisely where I feel, human interference shall remain crucial.

Is it all the most important today, to ride with the AI wave, to understand the impact it will generate on day-to-day life, and to use it as the tool it was meant to be, to start depending on it for time-consuming labor.

While it might still be time before complete AGI arrives, only those will survive AGI, who are able to ride the wave, and not swim away from the tide.

Now since AGI is the Game — a game none of us are really in control of — I will leave you with a verse that has been echoing in my head the whole time I was writing this:

It's time to play the game.

Time to play the game.

It's all about the game, and how you play it.

It's all about control, and if you can take it.

It's all about the debt, and how you pay it.

It's all about the pain, and who's gonna make it.

— Motörhead, "The Game" (Triple H's entrance theme)

‎The Game (Triple H) - Song by Motörhead - Apple Music

Song · 2002 · Duration 3:28

music.apple.com

My Review of 'Zero To One'

Abhijay Mitra — Wed, 01 Dec 2021 08:05:02 +0000

Apart from being a guy who reads and writes code, I am also an avid reader of books and manga. You can find about my likes and recommendations from my Goodreads profile.

I recently finished the book 'Zero To One' by Peter Thiel and thought of noting stuff down somewhere for my future use.

Cover of Zero to One (source: Wikipedia)

Why are monopolies so successful?

Tolstoy opens Anna Karenina by observing:

All happy families are alike: each unhappy family is unhappy in its own way.

Thiel argues business is the opposite:
- All happy companies are different: each one earns a monopoly by solving a unique problem.
- All failed companies are the same: they failed to escape competition
Restaurants vs Tech Companies.

Restaurants: successful ones might collect healthy amounts today, but their cash flows will probably dwindle over the next few years when customers move on to newer and trendier alternatives.

Technology Companies: often lose money for the first few years. It takes time to build valuable things, and that means delayed revenue. Most of a tech company's value will come at least 10 to 15 years in the future.

Thiel skillfully points out quite opposing patterns of success.
What to consider when starting tech companies?

If one focuses on near-term growth above all else, one misses the most important question: Will this business still be around a decade from now?

Numbers alone won't tell one the answer. Instead one must think critically about the qualitative characteristics of ones own business.
How good should the proprietary tech be?

Thiel says that a good rule of thumb is that proprietary technology must be at least 10 times better than its closest substitute in some important dimension to lead to a real monopolistic advantage.

Anything less than an order of magnitude better will probably be perceived as a marginal improvement and will be hard to sell, especially in an already crowded market.
How does sales work?

Like acting, sales works best when hidden.

This explains why almost everyone whose job involves distribution whether they're in sales, marketing, or advertising has a job title that has nothing to do with those things.
- People who sell advertising are "account executives".
- People who sell customers are "business development".
- People who sell companies are "investment bankers".
- People who sell themselves are called "politicians".
Thiel emphasises the reason being, none of us wants to be reminded when we're being sold.
Are engineers skilled enough to sell tech?

The engineer's grail is a product great enough that "it sells itself". But anyone who would actually say this about a real product must be lying: either he's delusional (lying to himself) or he's selling something (and thereby contradicting himself).

The polar opposite business cliché warns that "the best product doesn't always win".

Economists attribute this to "path dependence": specific historical circumstances independent of objective quality can determine which products enjoy widespread adoption.

Thiel brings a conclusion to this dilemma by stating: It's better to think of distribution as something essential to the design of your product. If you've invented something new but you haven't invented an effective way to sell it, you have a bad business no matter how good the product.
Which problems / projects are the best?
- Doing something different is what's truly good for society and it's also what allows a business to profit by monopolizing a new market.
- The best projects are likely to be overlooked, not trumpeted by a crowd.
- The best problems to work on are often the ones nobody else even tries to solve.

Updates in Ubuntu 21.10

Abhijay Mitra — Wed, 01 Dec 2021 07:27:12 +0000

In this blog, we shall be discussing the updates and improvements in Ubuntu 21.10. Please note that this version is NOT an LTS (Long-term support) version.

Finally installed Ubuntu 21.10 after the long wait!

The Horizontal Workspaces:

The most iconic one being the introduction of horizontal workspaces!

A new Gnome Version:

Ubuntu 21.10 comes with a customized Gnome 40 desktop instead of Gnome 36 (default on Ubuntu 21.04).

Gestures:

Multitouch gestures have been improved over the last few releases.

Ubuntu Dock:

A lot of people have been using Dash to Dock extension instead of the standard Gnome Ubuntu Dock.

Gnome 40 has really improved the default Gnome Ubuntu Dock and added separators between favourite and running applications.

Software Updates:

Alongside the new additions to the OS, Ubuntu 21.10 is obviously shipped with loads of software updates.

Languages of the Future

Abhijay Mitra — Wed, 01 Dec 2021 07:23:00 +0000

Some languages which I don't see going out of demand (until 2030 hopefully) are definitely:

Java:

Most companies in tech use Java to build their backend applications. Java is very fast as a language, is mainly based on OOPS (which makes code modular and clean to read), and most importantly is independent of platform (all you need to run it is the JVM - Java Virtual Machine). One of the best features I love about Java is its efficient exception handling and precise (compared to C++) error messages. Since Android is so popular these days, the only language that may replace Java would be Kotlin.
Swift:

Well who doesn't love Apple? Even Apple haters seem to love its clean and snappy UI. Though I don't have personal experience with Swift till now, its memory management is of high repute. As long as Apple is the world's most valuable company, Swift isn't going anywhere. Swift's ease of coding UI stuff will keep it in demand.
Javascript:

Though Javascript may be annoying at times, there's no denying of the fact that it is one of the select few languages that are extensively used in backend and frontend, server side and client side, and has extensive well designed libraries and frameworks for most industrial use cases. An application written in Javascript is almost certainly faster than a "similar" one in Python. Also, Node JS (written partly in C++) is super fast and its asynchronous multi-threaded I/O model improve the performance even more. Javascript is definitely going to stay for time in the future.
C++:

A great place to learn about this amazing language would be from the author of C++ himself. Whenever a developer looks for speed in backend, C++ is generally the way to go. C++ is blazingly fast, supports OOPS, and also is under constant development. I have spent most of my programming journey in C++.
Python:

One of the reasons Python is so popular despite being much slower compared to the others in this list must be the huge ocean of libraries and frameworks available for it. Also, code in Python looks more like pseudo code than most other languages. That makes Python code very easy to understand. Also, the learning curve in Python is much easier for newcomers in the world of software.

My Internship at Salesforce

Abhijay Mitra — Wed, 01 Dec 2021 07:05:44 +0000

This blog is about my internship experience at Salesforce India. This was a (remote - due to Covid-19) Software Engineering Internship I took in Summer 2021.

Me coding while interning at Salesforce!!! 😎

Why did you choose the company?

Salesforce is famous for its amazing work culture. I loved the way Salesforce was revolutionising modern workflow even during the unprecedented Covid-19 times.

How many rounds and what rounds?

There were a total of 5 rounds. 1 initial shortlisting coding test followed by 3 Technical Interview Rounds and 1 HR Round on the interview day.

How many rounds and the degree of difficulty? How much expertise do you need to clear the round?

There were 3 problems in the shortlisting test. One of them (3rd one) was difficult for me. The other two was of medium difficulty. I would say, being rated >= "expert" on Codeforces would be good enough to be able to solve 2 problems full. I was also able to solve the 3rd problem partially.

How important was your CV? Would you advise adding things which are not completely true in CV?

The interviewer asked about my CV in the 2nd Tech round on the interview day. All of the questions about my CV were from my past internship. I would definitely advice against writing any false pieces of information on your CV.

Duration of intern?

8 weeks

Your point of contact during your internship?

My manager was a KGP alumni himself, from my department. He always boosted my confidence and guided me throughout the internship. Also, my mentor was extremely helpful and he spoke to me on a regular basis. I did enjoy every moment with the team.

Main project or objective during your intern?

I worked at Salesforce's Health Cloud. My project was to build an application that aimed to recognize, analyse and store data automatically, directly from medical voice conversations. During the internship, I developed a prototype app for healthcare registrars that mitigated their role in registering, updating or fetching patient details, using the NLP domain of automating storage of patient interactions. I can't provide details to my work as it is confidential.

How was the work culture in the company?

Salesforce has one the best work cultures in the world. It is currently (2021) the 2nd best company in the world to work for according to Fortune. I worked for about 5 hours a day on average. They provided everything I needed for the internship, along with awesome gifts and swags on regular intervals. The employees are always happy, motivated and ready to clear all your doubts and everyone in the company was just a ping on Slack away.

Were important tasks given to you or any input you gave to your project manager which proved to be useful?

My project was a prototype of one of the breakthroughs Salesforce India's Health Cloud was planning for some time. The healthcare industry is moving towards ensuring easier access and exchange of medical information. My project was to create a very small MVP for the bigger picture application. We made key decisions while working on the project and I feel proud to have been a part of this mission.

Anything you had to learn before the start of intern?

I often had conversations about the tech being used in the project with the team and had suggested some ways at some junctures. The team was always appreciative of my suggestions and provided valuable alternatives in case I was wrong.