Lately, I’ve been reflecting on something:
The question for most developers is no longer "Are you using AI?", but rather "How and why are you using AI?".
I’ve noticed AI tooling becoming increasingly embedded in my daily workflow. At this time last year, my usage of AI was limited to code autocomplete suggestions in my IDE that I would manually validate. Now I am using coding assistants to help ideate, prototype, and refactor my projects.
In just one year, my workflow has changed dramatically.
It's hard for me to now imagine coding without AI tooling as it has been making me more productive. It's the same feeling I got when I got my first smartphone.
AI increasingly feels like my first smartphone: transformative, incredibly useful, and powerful enough that I need intentional habits to avoid overdependence. For example, keeping it outside of my bedroom when I go to sleep and occasionally going on walks without it, just to be alone with my thoughts.
This is the kind of awareness I’m now trying to build around my AI usage: understanding how it shapes my thinking, where it helps, and where it may quietly erode it.
AI isn’t just changing how fast we build. It is also impacting how we think.
Because not all AI usage is equal. Each usage can be mapped to a certain cognitive cost.
Sometimes AI helps us think more clearly and move faster.
But sometimes it quietly replaces parts of our reasoning before we even notice.
I realized that sometimes I wasn’t using AI because I needed leverage, I was using it because I wanted to avoid friction.
That realization pushed me to start thinking less about AI usage in general, and more about AI modes.
Each AI mode carries a cognitive cost
I distinguish 3 groups: Supportive, Mixed, Risky.
Supportive modes:
- Explaining unfamiliar code or architecture
- Exploring tradeoffs
- Critiquing a plan
- Testing assumptions
- Clarifying concepts
These modes use AI to expand your thinking and have a low cognitive cost.
Mixed modes:
- Boilerplate generation
- Refactoring suggestions
- Drafting documentation
These modes use AI to save time but can also compress understanding if used carelessly. These modes have a sizeable cognitive cost.
Risky modes:
- Blindly accepting generated solutions
- Delegating core architecture too early
- Letting AI define implementation before you’ve thought deeply
- Heavy debugging delegation without understanding the root cause
These can feel productive on the surface, but these AI modes can weaken long-term comprehension if used frequently and have a high cognitive cost.
Hands-on reflective practices also affect your total score
When shipping code I also keep a set of reflective exercises that I can make use of at different stages of my workflow. These can reinforce healthy behavior that alleviate some of the cognitive cost from AI modes.
Before:
- Did I attempt this myself first?
- Am I using AI to expand my thinking or bypass it?
During:
- Am I reviewing assumptions deeply?
- Could I explain why this output works?
- What risks or edge cases might AI be skipping?
After:
- Could I explain this solution tomorrow without rereading it?
- Did I preserve ownership?
- Was this leverage or dependency?
Over time, repeated AI habits don’t just affect productivity.
They shape how we think.
Those patterns shape your cognitive archetype
There are 4 main cognitive archetypes:
AI Architect
AI expands thinking without replacing ownership
AI Balancer
Mostly healthy, but mixed-mode creep needs monitoring
Autopilot Builder
Efficiency may be masking weakened comprehension
AI Passenger
AI may be driving too much of the reasoning path
These archetypes aren’t an exact science. They’re simply a framework for raising awareness.
Have you also noticed different "AI modes" in your own daily workflow? If so, what mode are you in the most?
What would be your cognitive archetype and why?
I’d be curious to hear how others are thinking about their own AI usage.
It feels like we’re all trying to figure out and build these habits in real time.
My take: I don’t think the right path is using AI less.
AI clearly offers real leverage, but leverage without awareness can come with hidden costs.
Knowing when to switch modes becomes key.
When should AI be a teacher, critic, accelerator or collaborator?
When should AI support the driver without taking the wheel?
Because faster output is great but only if understanding keeps up.
I built a personal tracker around this framework to better measure my own habits over time.
It helps me score AI modes, monitor dependency drift, and spot patterns in how I work so I can adjust more intentionally over time.
If it sounds useful to you too, I’m sharing it free and would genuinely love feedback: https://javz.gumroad.com/l/ai-thinking-balance-tracker
Top comments (63)
I believe I am an AI architect. Literally, my only AI is ChatGPT and it helps me expand my thinking when concepts aren't clicking. I treat it like my mentor but I also make sure that what it's saying is not from outdated data so I do cross-referencing on the side.
I also want to point out that what you described is close to metacognition which is a powerful way of thinking. Sadly, most people nowadays don't feel the need to exercise it especially now AI seems like the "magic" answer until it isn't.
Nice insights Elmar. What you say rings true for an AI architect. The fact that you leverage AI to expand your thinking and the fact checking from other sources are strong habits.
I agree with your point. The best way to stop seeing AI as "magic" is to dive deeper into how it works behind the scenes. When you figure out that it relies on stochastic probabilities and is prone to hallucinations, the magic part disappears and you begin to feel more skeptical in putting full trust into AI generated output.
This is a useful reminder that AI adoption is not just a tooling problem. It’s a cognitive/workflow problem too.
Indeed! Thanks for reading.
This framework really resonates with me as someone building AI-powered products. The distinction between "supportive" and "risky" modes is spot on — I've caught myself in autopilot mode more than once, especially during late-night debugging sessions. The question "Was this leverage or dependency?" is going on my wall. Love that you made the tracker free — going to try it this week.
I am glad this framework resonates with you @vicchen !
Would love to get your feedback on the tracker.
Happy to give feedback! From what I can tell building AI-powered financial analytics, the archetype shift often happens mid-project rather than at the start. Teams begin "supportive" but quietly drift into "risky" territory once velocity picks up and pressure mounts. What I'd love to see in a tracker: a way to flag when the ratio of AI-generated code to human-reviewed code crosses a threshold — not as a blocker, but as a nudge to pause and audit. On the 13F data pipeline I built, we use a similar internal check before deploying any parser update. Would the tracker surface those inflection points?
That is a great suggestion! The tracker does indeed measure velocity decrease. I used the term 'Dependency Drift' which compares the latest 7 days with the previous 7 days and watches for more risky sessions and other patterns, and suggests appropriate recommendations.
The ratio of AI-generated code to human-reviewed code is a good threshold to measure I agree, I will take note for my next iteration of the tracker.
Thanks Julien! The Dependency Drift metric is a smart approach — comparing 7-day windows catches gradual slippage that point-in-time checks miss. The AI code ratio threshold idea could complement it well as a leading indicator (before drift becomes visible in velocity). Happy to give more detailed feedback if you share the tracker link — building in the institutional investing space myself so I think about similar measurement challenges when tracking portfolio drift over time.
Thanks Vic! Indeed, good idea! I will include the AI code ratio threshold idea as a leading indicator in my next version.
I would love more detailed feedback.
Here is the link to the tracker: javz.gumroad.com/l/ai-thinking-bal...
Love that. A leading indicator is usually more useful than a postmortem metric anyway.
If you keep iterating on it, I'd be curious whether the strongest signal ends up being the ratio itself, or sudden changes in the ratio combined with velocity drop. That combo feels like the point where teams start losing the plot.
Just grabbed the tracker, will take a closer look.
I agree. I will definitely include this element in an upcoming iteration.
Sounds great, thanks!
Really interesting article... It's a reality that AI is all around us, and the question is how you use it... I really think that AI right now is empowering more than replacing... You need to use it more as an Architect than as a passenger...
Thanks Matías. Yes it's starting to shape our reality now. This is probably more pronounced in the developer space but it is still impacting everyone's daily lives to a certain extent. Aside from top down regulations and policy, it is up to us to decide how to use these powerful tools.
exactly!!! right now, it's like saying loudly you're using AI, it's like admitting you are not good enough, or like you need help to work... I don't think this way, tho... eventually, people will understand AI is a tool (a very powerful one), and people will use it like it or not... (Wikipedia is the perfect example... at the beginning, nobody trusted it because people can change it... eventually, that thinking changed, and now, I'm not going to say that is the source of truth... but a lot of people trust it)...
So... as I said... AI can do excellent things; it is up to you how you use it
I like your example of Wikipedia. If there is a common belief that a tool can be trusted, then more effort/attention will be given to reinforce that level of trust, shifting thinking over time.
The smartphone parallel landed for me. I track the same shift as fast loop versus slow loop instead of archetype: slow loop is the kind of thinking where you sit with a problem until the shape of the data answers itself. AI compresses that loop, which is great for grunt work and lethal for problems where the friction was the work. Last month I noticed I'd stopped writing scratch notes — the model fills the blank too quickly, and my own half-formed sentences never get a chance to sharpen. Had to physically close the editor for an hour at a time to get the slow loop back. Awareness alone doesn't fix it, deliberate friction does.
I like the way you framed this. Awareness + deliberate friction is the effective combination here.
I can relate to the scratch notes, I also noticed that I write less of those during periods when I leaned too heavily on my AI assistant.
'Periods when I leaned too heavily' is the right calibration — it's not a fixed style, it's a tide. The ratio of half-formed sentences to finished output drops, and I notice it three weeks late. The cheapest tell I've found is grepping for typos in my own commit messages: low count means I drafted in the model first and pasted clean text, high count means I was thinking on the keyboard. Crude, but it correlates with whether I can still reason about the codebase a week later.
grepping for typos! That's a smart proxy measure for reasoning quality. Nice one.
It's a cheap proxy but the real signal is what kind of typos. Concept-level (wrong noun, wrong variable name) means the model misunderstood. Surface-level (homophone, repeated word) means it understood and a sampler stutter happened. Different fixes one means rewrite the prompt, the other means re-roll.
Got it, thanks. There is also nuance within the typos themselves and appropriate actions performed. Very interesting.
Archetypes are useful as a mirror, not a cage. The interesting question isn't which one a developer is — it's whether their archetype matches the task in front of them. A "co-pilot" developer doing greenfield architecture struggles. Same person debugging gets a 10x. The archetype is a tendency; the task is the test.
— Max
the mirror analogy is a good one
Thanks. The mirror's the unsettling part — most workflow articles ask "what tool?" but yours asks "what kind of thinker have I become?" That second question is the one that scales. Tools change every six months. The archetype I default to changes much slower.
Very interesting article! I think I'm an AI architect – usually asking AI for feedback or ideas, especially when I feel blocked or uncertain. But every time I make sure to review the output with a critical eye and decide whether to follow the idea. I believe it's the single correct way of using this tool.
Thanks Klaudia! I agree with your usage of AI here. I would also add that there is real leverage too in automating repetitive tasks such as improving documentation, refactorings. With the caveat that you only automate away tasks that you already know how and have performed successfully in the past without AI assistance.
Be careful with documentation, though 😄 I saw people misuse AI here by prompting it to "generate docs for this piece of code". You can imagine the output 🙈 Moreover, very often it wasn't even properly reviewed. AI is very good for spellchecks, though, and for targeting the content against a certain audience.
True, thanks for the reminder. AI used for polishing or messaging formats is more advisable than using it to generate the whole document !
I really liked the framing of AI modes instead of treating AI usage as a binary discussion. I think that's the part most people miss. Using AI to challenge assumptions or explore tradeoffs feels very different from using it to bypass the uncomfortable parts of problem solving entirely, even though both technically look like productivity gains.
The “friction avoidance” point also felt very real. I’ve noticed there are moments where AI genuinely accelerates work, and other moments where it quietly becomes a shortcut around thinking through architecture, debugging paths, or system behavior. The dangerous part is that both modes can feel equally productive in the moment.
I also think the long-term effect here becomes more visible in debugging and systems design than in coding speed itself. Someone can generate working code very quickly, but when production behavior diverges from expectations, the depth of understanding becomes fast. That's probably where the difference between an AI Architect and an AI Passenger starts showing up operationally, not just intellectually.
I am glad that the AI modes framing resonated with you.
As you highlight, productivity metrics alone can sometimes hide issues such as rising levels of comprehension debt between engineers and their systems.
I agree with you on that last point. I witnessed this recently while debugging in a previous team I was in. It was tricky to debug because the latest code changes were generated by AI. The slippery slope is then leaning into AI to fix the problem as it can have even larger unintended consequences and makes it very hard to detect the root cause of the issue.
The four archetypes ring true — what the piece doesn't say (and probably can't, from outside a team) is that the archetype isn't fixed by the developer, it's pulled by the codebase. Senior engineers at Atoa drift between "skeptic" and "delegator" in the same week depending on whether they're touching a service with strong test coverage or one without — when the safety net is real, the same engineer leans into delegation; when it isn't, they revert to skepticism almost reflexively. The implication for engineering leaders: the way to move someone from skeptic → conductor isn't training, it's investing in the test/lint/review surface they ship into. The archetype is a function of the floor under them.
That is a very valuable input. The quality of the codebase itself influences how developers interact with said code, and hence their archetypes. We could still use the archetypes to provide a sense of direction. If the archetypes shift over time then it means the team leadership is making changes in the right direction. The tracker I implemented focusses on the individual level, but in a later version it could be interesting to add a team dimension to include the extra dynamics you mention here. Thanks for the input arun!
The use of AI reflects and magnifies the strengths and weaknesses of the user. A good developer will use it without losing ownership of the code. A sloppy developer will hide his setbacks and become more defensive. However, my experience in studying German tells me one thing: real time translator cripples the ability of the user to pick up the language. I know people who have been in Berlin for years and cannot really speak German. However, they can present ideas and even deliver speeches in German. They had prepared the speeches using translation tools at home and read off of their notes. Similar happens to me when it comes to specific phrases in German which I often look up and cannot remember because I don't frequently use them.
The cognitive loss or the inability to learn new knowledge or to retain useful information can be observed in other examples:
Programming is a skill to be learned. Research is a skill to be learned. Software Architecturing is also a skill to be learned. You are not born with these skills. We forget and lose if skills are not sharpened and applied. Your inborn biologic organs atrophy when not used. Use it or lose it.
Very interesting framing and cases of cognitive loss examples in our daily lives.
I agree, having lived in Berlin 4 years I can compeltely relate to your example of translation tools for German! :D
Some comments may only be visible to logged-in visitors. Sign in to view all comments.