What should we learn as an Engineer in the modern AI world ?

Mental Models & Philosophy to still be an elite engineer in this modern AI world.

Most software engineers would be navigating AI wrong.

As we see, the utility and the spread of generative AI platforms & tools are increasing day by day, and the definition of the “education on AI” is being correlated with the knowledge of AI tools.

Can someone really be called an AI or ML engineer if they know how to use AI tools?

The tool-first philosophy narrative: since we have democratized code generation and absolutely anyone can now write code turning it into a commodity- traditional computer science fundamentals, AI algorithms, and machine learning fundamentals do not have as much of an important role to play in.

However, if we look at the philosophies held by all the top tech industry leaders like Demis Hassabis, Andrej Karpathy, Ilya Sutskever, Yann LeCun and Jeff Dean, it reveals that the opposite is true.

In this era of high-velocity tool-flooded ecosystems and AI-assisted coding development, deep foundational knowledge is not a legacy requirement but a primary differentiator and a competitive advantage of an elite engineer.

History

History has always been our guide, especially when we want to build an opinion on the shifts that we have seen in engineering and technology. To understand this current rise of AI as a technology, one must put in context the broader history of engineering, technology, and computer science. The progression of programming and programming-based tools has always been towards a higher layer of abstraction- meaning- hiding the “how and whys” of the layers beneath it to let you just focus on the outcome it can produce. Every few years, we grow one layer above in abstracting the programming or in abstracting the coding layer. This has led to massive development in the technology space but I am here to tell you not to discount the “how and whys” so soon. Let’s look at some pivotal moments in computing and engineering history:

1950’s

In the mid-20th century, programming was an exercise in “hand-to-hand combat” with hardware. The first generation of software development relied on machine code- direct manipulation of binary (1s and 0s) or hexadecimal representations of data. At this level, there was no distinction between the “tool” and the “fundamental.” Early programmers worked directly with machine code, manually specifying opcodes and memory addresses, and even computing jump targets by hand.

Because this process was highly complex and only understandable by experts, programming was often described as a kind of “priesthood” and only a small cohort of programmers existed who had access to this kind of technology and the intellect to control it.

The second generation introduced assembly language, which used symbolic mnemonics (opcodes like MOV, ADD, XCHG) to represent machine instructions. While this made code more readable, it remained “machine-dependent” and required a deep understanding of processor architecture, registers, and memory alignment.

Compilers

The 1950s saw the birth of the first high-level language, Fortran(Formula Translation), which allowed engineers to write logic in “natural mathematical notation”. Engineers could write expressions like: x = a + b * c and the system would execute it. Hence we created a higher layer of abstraction.

Naturally, as human behaviour goes, the introduction of “compilers” - tools that automatically translated high-level logic into machine code was met with skepticism from the established “priesthood of programmers.” The arguments used in 1958 & 1959 are strikingly similar to those used by modern critics of AI-assisted coding:

1. Efficiency: People from the programming community argued that the compiled code could never be as compact or as efficient as handwritten assembly. They also believed that a human brain would always beat the compiler’s optimization.

2. Control: They feared that surrendering control to an automated translator would lead to bugs they couldn’t debug and systems they didn’t fully understand. (It sounds a bit familiar?)

3. Trust: If the engineer did not “code to the metal,” how could they be sure the machine was executing the intent correctly?

Despite this resistance, by 1958, more than half of the code running on IBM computers was generated by the Fortran compiler. Crucially, this did not succeed just because the tool existed now, it worked because engineers in time started to trust it while having a solid understanding of the layer beneath it.

What do we really learn from going through all of this history?

We can derive that the most elite successful engineers were not those who refused the “tool” (the compiler) but those who mastered the high-level logic while maintaining enough foundational knowledge to understand how the compiler optimized their intent. This transition did not destroy the need for fundamentals; it shifted the fundamental focus from low level concerns like “memory address management” to higher level thinking like “algorithmic logic and problem decomposition”.

Progression of Abstractions

1940s–50s: Machine Code

1. Abstraction Level: Machine Code

2. Primary Interaction: Binary / Hex Strings

3. Fundamental Requirement: Hardware registers, memory addresses

4. Tooling: Hand-wiring and punch cards

1950s–60s: Assembly

1. Abstraction Level: Assembly

2. Primary Interaction: Opcode mnemonics

3. Fundamental Requirement: Processor architecture, instruction sets

4. Tooling: Symbolic assemblers

1960s–80s: High-Level Languages (C, Pascal)

1. Abstraction Level: High-Level Programming

2. Primary Interaction: Structured logic

3. Fundamental Requirement: Data structures, pointers, memory management

4. Tooling: Optimizing compilers

1990s–2010s: 4GL / Scripting (Python)

1. Abstraction Level: Higher-level abstractions

2. Primary Interaction: Object-oriented / functional paradigms

3. Fundamental Requirement: Abstraction patterns, libraries, APIs

4. Tooling: IDEs, debuggers, package managers

2020s+: AI-Assisted Programming

1. Abstraction Level: Intent-driven

2. Primary Interaction: Prompt-based

3. Fundamental Requirement: System design, ML, DL

4. Tooling: LLMs, copilots

The fourth and fifth generations have brought us to a point where “coding” is increasingly a task of specifying intent. Engineers now describe the desired outcome, constraints, and context- leaving it to compilers, frameworks, and modern AI systems to plan the exact implementation. Coding is no longer about micromanaging instructions; it is about clearly expressing what should happen and under what conditions.

However, this shift does not eliminate the need for understanding, it raises the bar for it. Just as a Fortran programmer needed to understand the why behind their algorithms to write correct and efficient programs, the modern AI engineer must understand the why behind machine learning systems. Without that grounding, the outputs- whether code or logic- can become brittle, unreliable, or subtly incorrect.

AI systems can generate plausible solutions, but they do not inherently understand correctness or intent. As a result, engineers must be able to reason about failure modes, validate outputs, and recognize when the generated logic is flawed or hallucinated. In this world, specifying intent is powerful - but only when paired with the ability to critically evaluate what is produced.

Final Pillars as you step into this new world of AI with “AI Tools” & “Fundamentals”

Actionable Pillar1:

A few years from now, nobody will remember which model launched this week.

But they will remember the engineers who understood what was actually going on.

Early in your journey, you will feel an urge to keep up and to track every new release, every benchmark, every shiny model that claims to change everything. Resist that instinct. The interface will keep changing, but the underlying principles move slowly. The elite engineers who endure are the ones who understand those principles deeply: how tokens become meaning, how embeddings capture relationships, how optimization shapes intelligence, how architectures like transformers actually work, and how data and compute quietly dictate everything behind the scenes. At last, how thinking, causal reasoning, world modelling, continual learning are still open problems that need breakthroughs.

Also, don’t make the mistake of thinking that theory alone will save you.

Modern AI is not a clean & deterministic discipline anymore. It is messy. It is empirical. It is built as much through experimentation as through understanding. You will often not know why one prompt works and another fails. You will build systems that behave correctly for reasons you cannot fully prove. And that’s okay. Because real engineering lives at the intersection of theory and practice.

First principles will give you compression & reliability in your decision making. (a way to think clearly)

Experimentation (trial&error) will give you truth. (a way to know what actually works.)

Over time, what you are really developing is opinionated taste.

And this becomes even more important as the paradigm shifts from traditional engineering to AI Tools powered engineering.

We are no longer building with models as endpoints. We are building systems where models are just components. The real leverage now lies in how you stitch things together (retrieval systems, tools, memory, orchestration, evaluation loops). For traditional SWEs —> Software Architecture is more important than ever.

Moore’s Law has taught us and has proved that the compute keeps getting cheaper every 18-24 months, and the performance of the computing systems keeps getting doubled every 18-24 months. Hence, the pace of new models, new tools coming up and chips getting cheaper is going to be exponential

But the elite engineers who win are not the ones who wait for better tools. They “learn how to use the current models & tools better than anyone else”.

Actionable Pillar2: Learn to build solid software on these abstractions.

You don’t always need to train models from scratch. You need to know when not to. You will call APIs, compose systems, and build products on top of layers that didn’t exist a few years ago. Just like software evolved from assembly to high-level languages to frameworks, AI is evolving from raw models to primitives to full systems.

Your job is not to go one layer lower or one layer higher blindly.

Your job is to choose the right level of abstraction.

And as you do this, expand your scope. Because it is extremely possible (faster+easier) to expand the scope now more than ever.

Do not stay confined to a narrow role - not as a frontend engineer, not as a backend engineer, not even as an “AI engineer” in the narrow sense. The highest leverage engineers understand the full stack: user experience, backend systems, model behavior, and distributed architecture. They see the system, not just the component.

But there is one final discipline that will separate you from everyone else.

Actionable Pillar3: Evaluation

In this new world, building is easy. You can ship something in a day. But knowing whether it actually works is a question before pushing it out for production.

Making it work Reliably, consistently, under real-world conditions is hard. This is where engineers will have more leverage than no-code based vibe-gineers.

While studying agent reliability, we will also have to learn & push the art of defining evaluation at multiple fronts: datasets/use-cases/scale/functionality/load/stress and study failure modes.

“I am a true artist if I am able to start from first principles, learn best known art, but reimplement it in a way that’s never been done before.”