Previously published on LinkedIn Newsletter - Hivel Pulse.
I still remember a day from my past role as CTO.
I was in discussion with one junior and one senior developer from our product team.
The latter guy had an interesting question: How do we ensure this implementation won’t become a bottleneck when we scale in six months?
And the former guy had a weird but legit question: If the feature works and the tests pass, why should I bother optimizing it further or refactoring it right now?
To help them leave the cabin with clarity only, I preferred answering them from a book (Thinking, Fast and Slow) I was then reading.
“We have two cognitive systems. System 1 is all about fast, subconscious, automatic, everyday decisions and is error-prone. Whereas, System 2 is slow, conscious, effortless, and reliable. Being a developer is neither a job of mastering System 1 nor System 2. It is about finding the balance between these two and switching between them as the situation demands.”
.jpg)
I seized the moment. Both left the cabin with clarity and a little knowledge into how a developer’s mind works, or rather, should work!
Fast forward to 2025, when AI is shaping new engineering practices and coding habits, I thought of revisiting the mental models of developers. Since that conversation with the junior and senior developers, I’ve had the opportunity to work with hundreds of similar minds navigating System 1 and System 2 - sometimes in isolation, sometimes in harmony.
The goal with this blog is not just helping leadership teams with crafting L&D Programs or SOPs around the use of AI in engineering, but also to help developers understand how their minds could trick them into using AI against them.
Inside the Brain of Junior Dev - Quick Wins, Deep Fall
Junior developers are driven by Selective Attention
In 1999, psychologists Christopher Chabris and Daniel Simons conducted an experiment called ‘The Invisible Gorilla’.
The experiment aimed to demonstrate the concept of Selective Attention.
In that experiment, the volunteers were asked to watch a video of a basketball game and count how many passes were made.
When volunteers were busy counting it, a man dressed in a gorilla suit walked right through the scene, stopped, and beat his chest. This move was a part of the experiment.
Despite the prominent movement happening just before their very eyes, the majority of volunteers missed the man in a gorilla suit.
Reason? They were focused on counting passes.
This phenomenon is known as Selective Attention, where you fail to notice the obvious object, movement, or signals while you concentrate on one task or goal.
The majority of developers in their early career stage are driven by Selective Attention. They focus more on quick wins and short-term goals and thus end up overlooking the larger, more critical aspects of software development.
For example, when they use AI to write code, they unknowingly wire their minds to consider getting workable code after a messy prompt as a big success.
And when it finally happens, they miss the important details around logic, edge cases, clean code practices, fault-tolerance, performance bottleneck, and long-term maintainability. These crucial things act as a man in a gorilla suit for them.
Junior developers are often stuck within a cycle of quick validation and cognitive shortcuts
For junior developers, especially those coding with AI, System 1 thinking dominates. Their thinking is intuitive, fast-paced, and often driven by immediate feedback.
The happiness of seeing code compiling successfully or getting a feature to work quickly creates a cycle of quick validation and cognitive shortcuts. Here is what it looks like in action.
- AI Suggests > Code Works > Feels Rewarded
The developer feels accomplished because something just worked.
- Reward Reinforces Shortcut Thinking
The brain starts favouring shortcuts (AI prompt or minimal understanding) just because it works.
- Reduced Critical Thinking
Over time, the brain starts to bypass slower, analytical System 2 processes in favor of faster System 1, because it feels easier and offers rewards with minimal effort.
- Formation of Cognitive Shortcuts
After a few quick wins, the brain prefers to take shorter routes. It starts believing things like If it works, it’s good enough, or AI gave this, so I’ll use it.
The aftermath of getting stuck in this cycle of quick validation and cognitive shortcuts is quite visible in their approach to engineering.
They focus on,
- Delivering fast, functional code.
- Trusting AI outputs without questioning, verifying, or critically analyzing them.
- Using frameworks and templates with minimal questioning.
- Avoiding complex design considerations early on
The trap of Confirmation Bias is very real for junior developers
Confirmation bias is where people tend to favor information that confirms their existing beliefs while ignoring anything that challenges them.
It is considered the brain’s way to reduce cognitive load. Instead of challenging, it looks for patterns that support what it already thinks.
Here is how it impacts junior developers.
A junior developer is tasked with writing a feature that formats and sends email reminders.
So, the developer types the prompt Write a function to send reminders based on user preferences.
The AI returns working code - it compiles, sends test emails, and even logs the success.
But without understanding real whys and whats, the developer is likely to miss,
- What happens if a user has no preferences set?
- Are time zones being handled?
- Is the email queue being rate-limited?
But since the code works perfectly fine in a controlled environment, the brain says, It worked - no need to overthink.
This is how confirmation bias quietly guides the mindset of junior developers toward a more chaotic condition.
Inside the Brain of Senior Dev: Cognitive Offloading and Occam's Razor for AI-Enhanced Code Reviews
Cognitive Offloading is senior developers’ prime strategy
Cognitive offloading refers to the act of relying on external systems, tools, or aids to handle some of the mental processes.
For a senior developer, this could mean using an AI tool to automatically detect bugs, highlight inefficiencies, or identify anti-patterns in code.
By offloading these tasks to AI, senior developers create time for them to focus on higher-level decision-making, architectural considerations, and refining the overall design of the software.
And due to their AI hygiene practices, they tend to use AI code writing and review tools to empower their learnt habits and practices, rather than replacing those practices with new fully AI-fied code review and writing habits and shortcuts.
Here is an example for better clarity.
Consider a senior developer reviewing a feature update that a junior developer has implemented. Without AI, this process could eat up several hours.
So, he offloads his cognitive load to an AI code review tool. The tool flags common errors and highlights areas that violate coding standards.
However, the senior developer acknowledges the boundary between artificial and human intelligence. He does not let the AI review tool violate it.
In other words, AI remains a secondary layer of analysis, whereas developers’ judgment continues to drive the primary review process.
It’s all about augmenting, not replacing!
Senior developers chase simplicity with Occam's Razor Principle
According to Occam’s Razor Principle, the best solution is often the one with the simplest explanation. It encourages minimizing unnecessary assumptions or complexities.
In code review, senior developers don’t just look for what works, but they also prefer to pursue it for clarity into why it works.
For example, when AI tools flood the suggestions of multiple refactorings, patterns, or optimizations, the senior developer applies a mental filter: Are we solving the problem or just covering it up with layers?
Instead of blindly accepting all AI-suggested improvements into the code, they assess,
- Signal vs Noise: Is it solving the real issue or just making things look smarter?
- Cognitive Load: Will this be understandable for someone revisiting this code in six months?
- Failure Surface: Does this suggested improvement reduce potential edge-case failures?
Conclusion (Velocity or Quality OR Velocity and Quality?)
With AI assisting in writing, rewriting, and reviewing the code, the real differentiator isn’t just technical skill - it's cognitive adaptability.
Junior developers, already operating with System 1, achieve more speed due to AI. But it often leads to a false sense of progress.
Whereas, Senior developers who use AI not as a crutch, but only as a cognitive offload, might struggle with speed. So, they would need to switch their System 2 into System 1 in some cases.
Ultimately, the true engineering skills lie not in choosing between System 1 (velocity) and System 2 (quality), but finding a perfect balance and switching between them as the situation demands.
Also, read: AI Code Review Tools - Can it Make Code Reviews More Human?
