DEV Community: Julien Avezou

Building a Chrome Extension to Make AI Use More Intentional

Julien Avezou — Mon, 15 Jun 2026 14:44:53 +0000

After posting several articles about the impact of AI on developers and sharing resources to help mitigate some of the risks, I wanted to share a new tool I've been building and experimenting with.

I introduce you to ThinkMode!

A chrome extension that helps developers choose a thinking mode before prompting AI, and calculate the associated cognitive cost after prompting AI.

AI makes it easy to skip thinking.

This tool helps slow down and integrate thinking before and after prompting the AI.

As a browser extension it can be easily integrated into your everyday LLM chat prompting workflow.

The Idea

Before opening a prompt, ThinkMode asks you to describe what you are trying to do.

It then recommends one of 5 modes:

Explore: understand the problem before solving it
Challenge: pressure-test an existing plan
Decide: compare options and tradeoffs
Audit: review quality, correctness, tests, and edge cases
Reflect: learn from what you just did

The goal is to match the prompt with the kind of thinking intended for the task.

The tool also includes a manual AI usage log.

After using AI, you can log how you used it.

Usage is grouped into three categories:

Supportive: AI helps expand your thinking
Mixed: AI saves time but may compress understanding
Risky: AI may replace your judgment

Each log adds to a cognitive cost meter. Riskier usage fills it faster.

Cognitive cost measures tradeoffs between using AI to expand understanding vs outsourcing judgment.

When the meter is full, ThinkMode temporarily pauses supported AI chat pages for 5 minutes.

Most developer tools optimize for speed.

I wanted to experiment with a tool that introduces intentional friction in order to surface reflection.

How it works

ThinkMode is a Manifest V3 Chrome extension built with React, TypeScript, and Vite.

The architecture includes:

a content script detects supported AI chat pages
a floating button opens the extension
a background service worker coordinates the side panel
a React side panel handles the main workflow
shared TypeScript modules handle recommendation logic and prompt generation

The extension currently supports ChatGPT, Claude, and Gemini pages.

There is no backend nor LLM API call involved.

ThinkMode does not read conversations, scrape page content, send analytics, or store data remotely.

The recommendation engine is deterministic. It uses simple keyword rules to choose a thinking mode which felt reasonable considering this is an MVP.

What I Learned

Sometimes the useful AI tool is not the one that gives you a better answer.

It can be the one that helps you ask a better question.

I'm curious:

Have you ever caught yourself accepting an AI answer before fully understanding the problem?

If so, what habits or tools help you stay engaged in the thinking process?

How to install

You can download the extension free here from the chrome web store

Otherwise you can run the extension locally using developer mode from chrome extensions. The code is open source here on github.

Feel free to fork it and adapt it to your own needs.

Would really appreciate a star or review if you find it useful!

If you can think of ways to improve this tool or want to see other features, let me know in the comments!

I Built an Interview Prep Tool Instead of Grinding LeetCode

Julien Avezou — Mon, 08 Jun 2026 13:20:06 +0000

I am currently preparing for Software Engineer interviews.

Like many developers, my first instinct was to open LeetCode and start grinding problems.

It seems that most interview prep I see suggests grinding random problems.

Instead I decided to focus on understanding the underlying patterns rather than memorizing the problems.

Practicing structured retrieval and being aware of how everything connects together is key.

I'd rather deeply understand 20 patterns than superficially solve 200 problems.

Many interview questions are simply variations of the same underlying ideas.

So I built a tool focused on recognizing patterns, recalling templates, and explaining tradeoffs out loud.

With this app, you can practice the following:

DS&A pattern flashcards
Problem → pattern quizzes
JavaScript code template fill-ins
Complexity quizzes
System design cheatsheets
System design flashcards
Tradeoff quizzes
Explain-back scenarios

I am currently using the tool and am finding it useful in my interview preparation: once you start recognizing the pattern, the implementation becomes much easier to reason about.

I wanted to share the tool here in case it helps others preparing for interviews. I deployed it on Vercel to be easily used by everyone. But you can also run it locally.

Note that I don't collect or persist any data with this project. It uses local storage.
There is no login, you can just start practicing immediately.
The code is open source if you want to fork it and adapt it for your own needs.

Website
Repo

Tech Stack used for this project:

Next.js
TypeScript
React
Tailwind CSS
LocalStorage
Static typed data files

This project was also a fun experiment in AI-assisted development.

I feel that building internal tools that help me in my daily life is a great use case for AI.

Since I am actively preparing for interviews, I would love to gauge the community here and learn from you too:

How do you prepare best for SWE interviews? Any tips to share?

What preparation methods gave you the highest ROI?

I'm also exploring Software Engineer opportunities, so I'd be happy to connect with anyone hiring or going through a similar search.

Why Every Developer Should Attend Tech Week at Least Once

Julien Avezou — Thu, 04 Jun 2026 12:33:00 +0000

Last week, Toronto hosted Tech Week. A city-wide celebration filled with events and workshops revolving around the Technology sector.

I had such a great time and wanted to share with you my experience and reasons to attend Tech Week in your city or nearest city hosting it.

Additionally I want to share some tips and suggestions to elevate your experience.

First of all, Tech Week is a great opportunity to learn new things. I listened to talks and participated in workshops where I learned about cutting edge technologies such as the latest quantum computers and agentic protocols.

It is also an opportunity to broaden your horizons and step out of your comfort zone. For instance I attended one morning of lectures and panels on how the public sector is handling AI adoption and ways to enable efficient collaboration between the public and private sectors. I have never worked in the public sector so it was a good opportunity for me to get a better understanding of the landscape and mechanisms in place in the sector.

It is an excellent opportunity to expand your network and meet interesting people who share similar interests to you. I pushed myself to make connections at each event I attended and now have multiple coffee chats lined up with people I met throughout the week. As a founder it is a great opportunity to find customers. As a job seeker it is also a chance to identify which companies are actively hiring. As a student it's a nice occasion to find a potential mentor.

It's also a moment to have fun and share good memories with others who share similar passions and interests as you. I went on a couple of runs with other developers, had a fun night out, participated in a great hackathon and gave a talk at an event about my Thinking Engineer Toolkit.

And it goes without saying that you will likely end the week with some free merch and a lot of free food and drinks! Your wallet will thank you, your diet not so much... But I counterbalanced this by walking as much as I could between events. This also became a chance for me to explore different parts of the city too.

A tip I want to share with you is to think about how you can add to your own experience while also providing value to others in the process. I came up with an experiment inspired by the Million Dollar Homepage (look it up if you don't know, it's one of the coolest internet experiments imo). The idea is I would approach other builders and ask if they want to share their project on my Builder's Grid for extra visibility.
This wall will live on the internet and people can check out different projects from builders attending Tech Week. Quite a few builders registered allowing me to create lots of nice connections and break the ice during networking events.
You can check out the Grid here:
https://ttw-builder-grid.vercel.app

Another tip is don't be afraid to approach other people. Push yourself to make at least 2-3 connections per event. It might feel awkward at the start but you will quickly feel more comfortable approaching others and building connections over time.

I also advise you to find the balance that is right for you and that fits around your own schedule without feeling overwhelming. If you are feeling rushed to get from one event to the next then it takes away the joy and you might miss out on valuable connections. Quality beats quantity. I personally attended 9 events over the week which I found was a good amount alongside my regular schedule.

Curious to know if you have attended Tech Week in your own city and what your experience was like?

Here are some pictures from walking between events.

From vibe coding to clear thinking: what non-technical builders need in the age of AI

Julien Avezou — Mon, 01 Jun 2026 12:43:53 +0000

Over the past few months, I’ve increasingly noticed something through my network:

more people from non-technical backgrounds are building software as AI tooling improves.

Designers are prototyping product ideas.
Product managers are testing workflows.
Founders are building MVPs.
Operators are creating internal tools.
People who would not have called themselves “technical” a year ago are now using AI to make ideas tangible.

I think this is genuinely exciting.

It has never been easier to create.

I even attended a hackathon where participants only had 20 minutes to build a demoable product!

This raises the question:

When AI makes building easier, how do we make sure understanding does not disappear?

I recently published Thinking in the Age of AI, a guide for software engineers (you can check out my previous post here).

That guide focused on individual reflection for engineers: how to keep developing technical intuition, reasoning, and judgment while using AI tools.

But the landscape has changed quickly.

AI-assisted building is no longer only an engineering workflow.

It is becoming a builder workflow accessible to all.

And by builders, I mean anyone using AI to turn ideas into software-like artifacts:

vibe coders
designers
product managers
founders
operators
marketers
students
non-engineering team members

So I wanted to create a new version of the system for this wider builder audience.

Thinking in the Age of AI: Builder Edition

The opportunity is real

I do not think we should dismiss this shift.

I have spoken with people from all kinds of backgrounds who are actively building now.

People who previously had to wait for engineering time can now create something concrete.

That changes the conversation.

Instead of describing an abstract idea, you can show a flow.

Instead of writing a long product spec, you can prototype the interaction.

Instead of asking “would this work?”, you can test a rough version.

That is powerful.

But there is a trap.

A prototype can look much more complete than it really is.

The interface may look polished.
The buttons may respond.
The demo may feel convincing.
The generated app may run locally.

But software is not just what appears on the screen.

Software also includes:

data
deployment
behavior
permissions
edge cases
security
reliability
failure handling
maintenance
ownership
user trust

AI makes the visible layer easier to create.

But the invisible layer still requires judgment.

There is an opportunity here for both engineers and non-technical builders to collaborate better.

As an engineer, I have felt frustrated in the past when product or design decisions seemed misaligned with technical constraints. I am sure I am not the only one.

And I have also heard the opposite frustration from non-engineers: that engineers can sometimes seem overly cautious, slow, or resistant to ideas that feel obvious from a product or design perspective.

Often, both sides are reacting to incomplete context.

The fact that building is becoming accessible to more people may also be an opportunity to reduce these misalignments.

With the right mindset and shared language, this process can become much more effective.

The prototype illusion

One of the ideas I explore in the guide is what I call the prototype illusion.

This happens when a prototype looks more complete than it really is.

A prototype is allowed to be incomplete.

It is allowed to be messy.

It is allowed to fake things.

The problem starts when the builder does not know what is real and what is fake.

That is where collaboration with engineers can break down.

A designer might show an AI-generated prototype and think:

“This is almost done.”

An engineer might look at the same prototype and think:

“This needs to be rebuilt from scratch.”

Both people may be right from their own perspective.

The issue is not the prototype.

The issue is the missing shared understanding.

2 practical exercises to grow this shared understanding

Here are two exercises from the Builder Edition guide that you can start using immediately.

I chose these two because they address the most common source of friction: a prototype that looks clear to one person but means something very different to someone else.

1. Real vs Fake Functionality Map

This is one of the most important habits for AI-assisted building to fight the prototype illusion.

Use this worksheet after creating a prototype, demo, or AI-generated app.

Time required: 5-10 minutes.

Step 1 — List the Main Features

What does this prototype appear to do?

1. ___________________________________________
2. ___________________________________________
3. ___________________________________________

Step 2 — Classify Each Feature

For each feature, mark whether it is real, mocked, partial, or unknown.

Feature 1: ___________________________________________
☐ Real
☐ Mocked
☐ Partial
☐ Unknown

Notes:
_____________________________________________________________________
_____________________________________________________________________

Feature 2: ___________________________________________

☐ Real
☐ Mocked
☐ Partial
☐ Unknown

Notes:
_____________________________________________________________________
_____________________________________________________________________

Feature 3: ___________________________________________

☐ Real
☐ Mocked
☐ Partial
☐ Unknown

Notes:
_____________________________________________________________________
_____________________________________________________________________

Step 3 — Identify the Illusion

Which part looks more complete than it really is?
_____________________________________________________________________
_____________________________________________________________________

What might someone misunderstand if they saw this demo?
_____________________________________________________________________
_____________________________________________________________________

What should I explicitly say before showing it?
_____________________________________________________________________
_____________________________________________________________________

Step 4 — Clarify the Next Step

What needs to happen before this becomes real software?
☐ Product validation
☐ Design refinement
☐ Engineering review
☐ Database design
☐ Authentication
☐ Permission handling
☐ API integration
☐ Testing
☐ Security review
☐ Performance review
☐ Deployment setup
☐ Other:
_______________________________

Most important next step:
_____________________________________________________________________
_____________________________________________________________________

2. Engineer Handoff Template

This might be the most useful exercise for teams.

The best handoff is not perfect code.

The best handoff is clear context.

Use this when asking an engineer to review, rebuild, extend, or estimate work based
on an AI-generated prototype.

Time required: 10-15 minutes.

Handoff Summary

Feature or prototype name:
_____________________________________________________________________
_____________________________________________________________________

One-sentence summary:
_____________________________________________________________________
_____________________________________________________________________

Who is the target user?
_____________________________________________________________________
_____________________________________________________________________

What problem does this solve?
_____________________________________________________________________
_____________________________________________________________________

Prototype Status

Built with:
_____________________________________________________________________
_____________________________________________________________________

AI tools used:
_____________________________________________________________________
_____________________________________________________________________

What works today?
_____________________________________________________________________
_____________________________________________________________________

What is mocked?
_____________________________________________________________________
_____________________________________________________________________

What is incomplete?
_____________________________________________________________________
_____________________________________________________________________

What is known to be fragile?
_____________________________________________________________________
_____________________________________________________________________

Product Intent

Core user flow:
1. __________________________________________________________________
2. __________________________________________________________________
3. __________________________________________________________________
4. __________________________________________________________________

Must-have behavior:
_____________________________________________________________________
_____________________________________________________________________

Nice-to-have behavior:
_____________________________________________________________________
_____________________________________________________________________

Success criteria:
_____________________________________________________________________
_____________________________________________________________________

Technical Unknowns

I need help understanding:
☐ Database structure
☐ Authentication
☐ Permissions
☐ APIs
☐ Deployment
☐ Security
☐ Performance
☐ Testing
☐ Maintainability
☐ Integration with existing systems
☐ Other: ______________________________

Specific questions:
1. __________________________________________________________________
2. __________________________________________________________________
3. __________________________________________________________________

Review Request

What kind of feedback do I need?
☐ Is this technically feasible?
☐ What would need to be rebuilt?
☐ What risks do you see?
☐ What is the simplest reliable implementation?
☐ What should we not ship as-is?
☐ What assumptions are wrong?
☐ What is the rough complexity?
☐ What should I clarify before this becomes engineering work?

Most important engineering question:
_____________________________________________________________________
_____________________________________________________________________

What engineers wish non-technical builders knew

One section of the guide is called What Engineers Wish You Knew.

Engineers are usually not trying to slow you down.

When they ask about edge cases, permissions, data, security, or failure states, they are not dismissing the idea.

They are thinking about what happens when the idea becomes real.

A working demo is not the same as production-ready software.

Simple-looking features can hide complex systems.

AI-generated prototypes can improve collaboration a lot.

But only if they are presented honestly.

That honesty builds trust.

So what happens to software engineers?

This is the part I’m still thinking through.

If more people can build software-like prototypes, does the world need fewer software engineers?

Maybe in some areas.

But I suspect the role changes more than it disappears.

The value of software engineers may shift even more toward:

system design
technical judgment
reliability
security
integration
maintainability
reviewing AI-generated work
helping teams understand trade-offs
turning prototypes into durable systems

In other words, engineers may spend less time being the only people who can create the first version.

But more time being the people who can make software real, safe, reliable, and maintainable.

That is a different kind of leverage.

It also means non-technical builders and engineers will need better collaboration patterns.

The future may not be “engineers vs vibe coders.”

It may be:

builders create more concrete ideas earlier, and engineers help turn the right ones into real systems.

But for that to work, both sides need shared understanding.

I am generally optimistic, but not because I think the transition will be easy.

Work changes when tools change.

A 2024 MIT study estimated that about 6 out of 10 jobs people do today did not exist in 1940. That does not prove AI will automatically create better outcomes, but it is a useful reminder that roles evolve when technology changes.

My own strategy as an engineer is to become a broader generalist: someone who can understand product, systems, AI workflows, and collaboration across disciplines.

Why I wrote this guide

I wrote Thinking in the Age of AI: Builder Edition because I think this shift is too important to ignore.

AI-assisted building is here.

Non-technical builders are already creating software.

That is not going away.

The question is whether we develop better habits around it.

It includes worksheets, checklists, prompts, and reflection cards to help builders:

understand what AI generated
separate real functionality from mocked behavior
identify hidden technical risk
avoid common vibe coding traps
find edge cases earlier
prepare better engineer handoffs
know when something needs review

The goal is not to make people afraid of building with AI.

The goal is to help people build with more clarity.

AI can generate prototypes.

Builders must generate clarity.

Discussion

I’m curious how others are seeing this shift.

For non-technical builders:

Where do you feel most unsure when building with AI?
Is it code quality, data, security, deployment, edge cases, or knowing when to ask an engineer?

For engineers:

How do you feel about working with AI-generated prototypes from designers, PMs, founders, or other non-technical builders?
What makes those handoffs useful vs frustrating?

For everyone:

Do you think the world will need more software engineers, fewer software engineers, or just a different kind of software engineer?

If you want to explore the full set of exercises, prompts, and worksheets, you can get the guide free here.

Don’t let AI break your collective thinking: a practical guide for engineering teams

Julien Avezou — Mon, 25 May 2026 11:20:07 +0000

Over the past few years, my workflow as an engineer has changed a lot.

I went from the occasional autocomplete to using AI for ideation, debugging, refactoring, and system design when appropriate.

At the individual level, the gains were obvious.

But something more subtle started happening at the team level.

The unexpected downside

AI didn’t just make us faster.

It changed how we think together.

I’ve been in teams that adopted strong practices around knowledge sharing and AI usage, and others that didn’t.

The difference is noticeable.

Some teams became faster and sharper.

Others became:

faster… but misaligned
productive… but shallow
shipping more… but understanding less

From experience, teams have always struggled with effective knowledge sharing.

However, AI is accelerating the issue for teams that are not prepared.

The core issue

AI can improve individual productivity when used appropriately.

But engineering is rarely an individual activity.

It’s a coordination problem.

It depends on:

shared mental models
clear reasoning
aligned decisions

Without these, speed creates drift.

“AI can generate output. Teams must generate shared understanding.”

That’s the gap most teams aren’t addressing yet.

From individual thinking → team thinking

In my previous guide (Thinking in the Age of AI introduced via this post), I focused on:

How engineers can maintain strong thinking individually

We will now focus on the next layer:

How teams can think well together while using AI

At the team level, more dynamics come into play than at the individual level.

This is my attempt to put forward some practical solutions to help engineering teams.

What I’ve been experimenting with

I’ve been experimenting with a series of practices that can be used across teams.

Not big process changes.

Just lightweight habits that:

make reasoning visible
slow thinking down just enough
turn daily work into learning

4 practical exercises you can try with your team this week

1. AI usage transparency

After AI-assisted code is merged, add a simple note:

Was AI used?
Where was it used?
What was verified manually?

This sounds trivial, but it changes team behavior.

Without this, AI usage becomes invisible.

Over time, no one knows:

where the team relies on AI the most
what types of problems are being outsourced
where verification is weak

With this, patterns start to emerge.

This leads to better discussions around:

when AI is actually helpful
where we should slow down
where we were over-relying without realizing it

You can use this template:

AI Usage Declaration

AI used? ☐ Yes ☐ No

If yes:

• Where was AI used?
_____________________________________________________________________
_____________________________________________________________________

• Purpose:

☐ Generate
☐ Refactor
☐ Debug
☐ Explore

• What was verified manually?
_____________________________________________________________________
_____________________________________________________________________

2. Team AI dependency check

Every couple of weeks, take 5 minutes and ask:

Are we skipping initial reasoning more often?
Are we accepting AI outputs without challenge?
Is debugging depth decreasing?
Are explanations getting weaker?

You don’t need metrics. Just honest discussion.

This is less about “reducing AI usage” and more about using it intentionally.

I’ve seen teams drift without noticing it.
Nothing breaks immediately.

But over time:

intuition weakens
understanding becomes uneven
fewer people can explain the system clearly

This exercise helps catch that early—and adjust before it becomes a real problem.

You can use this template:

Team AI Dependency Signals

☐ Engineers skip initial reasoning
☐ AI outputs accepted without challenge
☐ Debugging depth decreasing
☐ Code explanations unclear
☐ Increased reliance for simple tasks

What pattern do we observe?
_____________________________________________________________________
_____________________________________________________________________

What adjustment will we make?
_____________________________________________________________________
_____________________________________________________________________

3. No-AI debugging sessions

Pick a real bug.

One engineer debugs it without AI, while narrating their reasoning.
The team watches and helps out when needed.

At first it feels slow.

Then you realize most engineers rarely see how others think anymore

This surfaces:

debugging patterns
assumptions
decision-making

In my experience, debugging sessions under this format are one of the fastest ways to level up a team.

Ideally, document the session with notes from both the debugger and the observers.

You can use this template:

Debugger Notes

What do I think is happening?
_____________________________________________________________________
_____________________________________________________________________

What signal am I checking first?
_____________________________________________________________________
_____________________________________________________________________

What assumption am I testing?
_____________________________________________________________________
_____________________________________________________________________

What changed my understanding?
_____________________________________________________________________
_____________________________________________________________________


Team Observation Notes

What reasoning pattern did we notice?
_____________________________________________________________________
_____________________________________________________________________

What step was most valuable to observe?
_____________________________________________________________________
_____________________________________________________________________

What should we reuse next time?
_____________________________________________________________________
_____________________________________________________________________

4. Shared mental model builder

Teams encounter valuable learning moments every day:

debugging complex issues
resolving incidents
designing systems
working with AI-generated solutions

But without deliberate extraction, these lessons remain isolated.

This exercise converts a specific team experience into a shared mental model.

In other words, a reusable principle that applies beyond a single situation.

Over time, these models become a powerful layer of collective intelligence.

You can use this template:

Situation:
_____________________________________________________________________
_____________________________________________________________________

Underlying mechanism:
_____________________________________________________________________
_____________________________________________________________________

Complete the sentence:
“In systems like this, ____________________________________________.”

Where else does this apply?
1. _______________________________________________________________
2. _______________________________________________________________
3. _______________________________________________________________

Now you have a reusable insight, not just a fix

Over time, this builds real team intuition.

Open discussion

I’m curious how others are handling this.

Most teams aren’t thinking about this yet. That’s why I think it’s worth discussing.

Are you seeing similar patterns in your teams?
Have you introduced any practices around AI usage at a team level?
Or is it mostly individual-driven right now?

If you’re interested

I put together a full system with:

exercises like the ones above
workflow templates
prompt cards for team reflection

You can get the guide for free here

I would love your feedback on this.

Final thought

AI is making it easier than ever to move fast.

But speed is not the same as understanding.

The teams that stand out won’t just be the ones using AI the most.

They’ll be the ones that learn the fastest and think most clearly together

Curious to hear how others are navigating this.

My first collaboration post on DEV! Was so much fun! Check it out to see verdicts on Gemma 4 from multiple writers here!

Julien Avezou — Fri, 22 May 2026 19:17:31 +0000

Gemma 4 Challenge: Write about Gemma 4 Submission

FrancisTRᴅᴇᴠ (っ◔◡◔)っ for The DEVengers

May 22

Should you use Gemma 4 for your Development? A Multiversal Analysis to Determine if Gemma 4 is Right for You!

#discuss #devchallenge #gemmachallenge #gemma

19 min read

Your Codebase Has Technical Debt. But Does Your Team Have Comprehension Debt?

Julien Avezou — Mon, 18 May 2026 12:08:26 +0000

Have you ever been thrown into an unfamiliar codebase while deadlines got tighter, stress levels rose, and incidents became harder to resolve?

I have, and it's not a pleasant experience.

This got me thinking about a kind of debt engineering teams rarely measure.

Not technical debt.

Something more subtle:

comprehension debt.

I think of comprehension debt as the gap between how fast a system changes and how well the team understands it.

And AI is making this gap more important.

AI didn't create the problem.

This problem existed long before AI.

Teams have always struggled with knowledge silos, undocumented systems, fragile ownership, and “only one person knows how this works” situations.

But AI can accelerate the problem.

When AI helps us write, refactor, and ship code faster, the codebase can evolve faster than the team’s shared understanding.

That is useful when paired with strong review, explanation, documentation, and ownership.

But dangerous when it turns into:

“The code changed, but nobody really understands the system better.”

That is the kind of risk I wanted to make more visible.

What if I could quantify comprehension debt somehow? At least to a certain degree of approximation.

I started exploring the different variables and components that would impact comprehension, for better or worse.

Based on my experience, conversations with other engineers, and patterns I’ve seen across teams, I started building a scoring methodology to approximate comprehension debt.

My goal here is to help engineering teams spot where critical or highly connected systems are changing faster than the team understands them.

What is comprehension debt?

Let's start with a more formal definition:

Comprehension debt rises when system impact, complexity, dependency surface area, change velocity, and AI-assisted change speed outpace team understanding, coverage, redundancy, documentation, and human ownership.

I am not basing this just on theory.

I experienced the negative effects of high comprehension debt recently in one of my past teams.

It was a stressful and demoralizing experience.

I constantly felt behind and had to keep up.

Incidents were getting worse and harder to resolve over time because the level of system understanding across the team was too low.

The code existed.

The services existed.

The tickets kept moving.

But the shared mental model of the system was not keeping up.

That is a hard place to work from.

You feel reactive all the time.

You are not just debugging the incident.

You are debugging your own lack of context.

Why AI makes this worth measuring now

AI-assisted development can be incredibly useful.

I use AI myself, quite frequently.

But I keep coming back to this question:

Are we increasing shipping velocity without increasing understanding velocity?

Because those are not the same thing.

A team can ship more code and still understand less of the system over time.

AI can help generate implementation options, refactor code, explain files, write tests, and speed up repetitive work.

But if AI-assisted changes are merged without enough human explanation, review, documentation, or ownership, comprehension debt can accumulate faster.

The issue is not:

“Did AI write this?”

The better question is:

“Can the team still explain, review, modify, deploy, and recover this system safely?”

How the debt score is calculated

This is not meant to be a perfect mathematical model.

It is an attempt to make an invisible engineering risk visible enough to discuss, compare, and improve.

At a high level, the score combines two sides:

1) System pressure

These factors increase comprehension debt:

high criticality
high complexity
high change velocity
high incident sensitivity
high dependency surface area
high ownership concentration
high AI acceleration risk when AI is used without strong human guardrails

2) Team comprehension coverage

These factors reduce comprehension debt:

more safe modifiers
more clear explainers
stronger reviewer redundancy
better documentation
more recent hands-on exposure
stronger on-call familiarity
better engineer-system capability scores

So the rough model is:

Comprehension Debt =
System pressure
+ dependency pressure
+ ownership concentration
+ optional AI acceleration

minus

human coverage
+ documentation quality
+ reviewer redundancy
+ recent exposure
+ operational familiarity

To detect dangerous gaps, a Minimum Viable Coverage check for critical systems is performed.

For a critical system, the sheet checks whether it has:

at least 2 safe modifiers
at least 2 capable reviewers
documentation quality of 3 or higher
recent hands-on exposure of 3 or higher
on-call familiarity of 3 or higher

If one of these is missing, the system gets an MVC gap.

A critical system with an MVC gap should be flagged even if the overall debt score looks moderate.

Discussion

I am very open to feedback on how the methodology could be improved.

Also curious:

How does your team maintain understanding of the codebase?

What signals tell you that your team is starting to lose understanding of a system?

And have you noticed AI changing the speed at which your systems evolve compared to the speed at which your team understands them?

I think this is going to become a much bigger engineering leadership problem as AI generation and automation accelerates.

We are getting better at generating code.

But we still need to get better at preserving shared understanding.

Get the template

To make this easier to reason about, I turned the methodology into a spreadsheet-first template:
System Comprehension Heatmap

It includes:

System Inventory
Engineer-System Matrix
Overview Dashboard
Risk Recommendations
optional AI acceleration scoring
Minimum Viable Coverage checks
quick-start PDF guide

You can get it for free here

I would love feedback.

The missing layer in prompt engineering: thinking quality

Julien Avezou — Mon, 11 May 2026 12:45:04 +0000

I've seen countless prompting trends and prompt packs to use but most discussions around prompt engineering focus on one thing:
getting better outputs

Optimizing for better outputs often translates to:

Better prompts
More context
More structure

But lately, I’ve been wondering:

What if we’re optimizing the wrong layer?

Because the real question isn’t:

“How do I get better answers from AI?”

It’s:

“Is AI actually improving how I think?”

Because I’ve noticed something subtle:

My output was improving.

But my understanding was not always.

After working in several teams and environments, I have observed that:

Good engineers ask better questions.

The best engineers question their own thinking.

Most of what I see optimizes for:

better outputs
faster generation
more automation

But much less for:

clearer thinking
stronger judgment
deeper understanding

AI isn’t just changing how we build.

It’s quietly reshaping how we think while building.

🧠 What kind of thinking do you actually need?

That’s when I realized I didn’t need more prompts.

I needed a way to choose the right kind of thinking first.

Instead of asking:

“What’s the best prompt for this?”

I started asking:

“What kind of thinking do I need right now?”

That led me to structure my prompting around 5 simple thinking modes:

1) Explore

When I don’t fully understand the problem yet

2) Challenge

When I have a plan… but it might be wrong

3) Decide

When I need to choose between options

4) Audit

When I need to verify quality or correctness

5) Reflect

When I want to actually learn from what I did

This simple shift changed everything.

Instead of using AI reactively,
I started using it intentionally based on the thinking task.

🔁 The simple loop that protects your thinking

This is a simple workflow framework that makes a big difference.

Before AI

Write what you think first.

During AI

Use it to expand or challenge your thinking.

After AI

Ask yourself:

Did I verify this?
Did I just accept it?
Can I explain it without AI?

It sounds simple, but it’s surprisingly easy to skip.

And when you skip it, you start noticing something subtle:

Your output improves.
But your understanding doesn’t always follow.

⚖️ Why one prompt is almost never enough

One thing I’ve been changing in my workflow:

I rarely rely on a single prompt anymore.

Instead, I use prompt pairing:

1) one prompt to generate
2) one prompt to challenge

For example:

First prompt:

“Suggest 3 possible architectures for this system.”

Follow-up:

“Now challenge each option: what are the hidden risks, failure modes, and long-term maintenance issues?”

Why this matters:

AI is very good at giving plausible first answers.
But those answers are often:

incomplete
overly confident
biased toward common patterns

Prompt pairing helps you avoid:

first-answer bias
shallow reasoning
premature decisions

It forces a simple but powerful loop:

Generate → Critique → Decide

And that loop alone has probably improved my decision quality more than any single “better prompt”.

📊 A simple way to check if AI is helping or hurting your thinking

Another thing I started doing:

After important prompts, I ask myself:

“Did AI actually improve my thinking here?”

I use a simple thinking score (0–5):

Did I write my own initial view before prompting?
Did I challenge or refine the output?
Did I verify at least one important claim?
Did I make the final judgment myself?
Can I explain the result without AI?

Not as a strict system.
More as a signal.

Because sometimes the pattern is obvious:

You get great output.
You move faster.
But you didn’t actually understand what happened.

And over time, that compounds.

🛠️ A few prompts that changed how I work

Here’s one I use a lot (Explore Mode):

“I am working on a vague engineering problem.
Before suggesting solutions, help me frame the problem.
List the goal, constraints, stakeholders, unknowns, assumptions, edge cases, and the questions I should answer myself first.”

Then I follow it with:

“Now turn this into the 5 questions I should answer manually before asking for implementation help.”

What this does:

forces clarity before coding
surfaces unknowns early
prevents jumping too quickly into solutions

Another one I’ve been using more (Challenge Mode):

“Pressure-test this architecture proposal.
Identify assumptions, weak points, hidden dependencies, and failure modes.
For each, explain what evidence would confirm or disprove it.”

Followed by:

“Which of these should I verify first, and how?”

This one has saved me from a few very confident but flawed directions.

👥 What’s changing in teams right now

Prompting is evolving quickly.

It’s becoming:

more collaborative
more embedded in workflows
less about “one perfect prompt”

And more about:

prompt sequences
prompt-driven workflows

I’m also seeing patterns like:

Prompt Driven Development (explore before coding)
Prompt versioning (iterating prompts like code)
Shared team prompts (internal playbooks)

But most of these still optimize for output quality.
Not thinking quality.

🧩 The piece I felt was missing

I didn’t need more prompts.

I needed a way to answer:

“Is AI making my thinking better or just faster?”

So I started using a simple self-check after important prompts:

Did I think before prompting?
Did I challenge the output?
Did I verify anything?
Did I make the final judgment?
Can I explain it without AI?

Not to optimize productivity.
But to protect judgment.

⚙️ The system I ended up building for myself

I ended up structuring this into a prompt system I now use daily:

5 thinking modes
Before / During / After workflow
Paired prompts (generate → challenge)
Simple thinking quality score

Recommended loop: Before AI - Core Prompt - Paired Follow-up - Manual Reflection - Thinking Score.

All organized around real engineering use cases.

If you’re interested, I shared the full prompt system as a free PDF (100 prompts structured by thinking mode). (100 prompts structured by thinking mode).

Would love your feedback on my system.

💬 Curious how others are approaching this

How do you approach prompting today?
Do you reflect on your AI usage at all?
Are teams starting to standardize prompting internally?

I’m especially curious about how this is evolving at the team/org level.

AI gives answers.

But engineers who compound over time are the ones who protect how they think.

The 4 Cognitive Archetypes of Developers Using AI

Julien Avezou — Mon, 04 May 2026 14:47:35 +0000

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

AI through Visuals - Hardware

Julien Avezou — Tue, 28 Apr 2026 11:17:35 +0000

Most AI content today feels flat.

We read threads.
We skim blog posts.
We copy prompts.

But very rarely do we actually see how AI systems work.

Why I’m starting this series

As engineers, our edge is not just using tools.

It’s understanding systems.

Lately, I’ve been thinking a lot about this:

Are we still thinking deeply about what we’re building…
or just orchestrating tools we don’t fully understand?

That’s where this idea came from.

Introducing: AI Visual Series

I’m starting a series of interactive visual explainers to break down AI concepts:

infrastructure
systems
tradeoffs
bottlenecks
real-world constraints

Not with walls of text…

But with visuals you can explore and interact with.

👉 You can explore the series here

The goal isn’t about simplifying AI.

It’s about making complex systems intuitive through visuals.

Because once you see something you think differently about it.

Without further delay, let's explore the first post in this series.

AI Hardware, Explained Visually

We talk about AI like it’s software.

Prompts. Models. APIs.

But modern AI doesn’t run on “code”.

It runs on a massive physical stack of hardware.

1. The AI hardware stack

A modern AI system isn’t just a server.

It’s a layered system:

GPU / accelerator
CPU
high-bandwidth memory (HBM)
advanced packaging
networking
storage
power
cooling

Each layer matters.

Each layer can break.

2. A global system

What surprised me most:

This stack is not built in one place.

Design → United States
Fabrication → Taiwan
Memory → South Korea
Lithography → Netherlands
Materials → Japan
Assembly + deployment → China + Southeast Asia

No single country controls the full system.

3. Where things actually break

We used to think scaling AI meant just adding more GPUs

But that’s no longer true.

The real bottlenecks are now:

HBM memory
advanced packaging
networking
power availability
cooling

And here’s the counterintuitive part:

Compute itself is no longer the main constraint.

The key takeaway

The more I dig into AI…

The less it feels like software engineering.

And the more it feels like:

distributed systems
hardware engineering
energy infrastructure

All at once.

Why this matters for us

If you’re building with AI today:

you’re sitting on top of this entire stack
you’re affected by its constraints
you’re making decisions that depend on it

Understanding it, even at a high level, changes how you think.

You can play around with the interactive visuals here

What’s next in the series

I’ll keep building these visual explainers around:

evolution of AI chips
cost of a prompt
model capability vs compute
open vs closed AI ecosystems

Curious to hear:

👉 what AI concepts would you like to see visualized next?

Building a coding course generator in public #2: what I learned

Julien Avezou — Wed, 22 Apr 2026 12:49:24 +0000

Building fast with AI is easy but building something you can actually run, inspect, and trust is harder. This project is my attempt to teach builders core engineering intuitions when building projects.

This is the second and closing post in my mini build-in-public series around a coding course generator. The goal was not to polish a hosted SaaS. It was to validate the concept quickly, release the code, and see whether a local-first learning product built with AI assistance could help others.

Coding setup

VS Code
ChatGPT 5.4 for ideation and planning
Codex 5.3 for scaffolding and broader architectural changes
Codex 5.3 Spark for faster live coding and pair-programming-style iteration

Because this was a side experiment and I wanted fast feedback, I used ChatGPT and Codex heavily throughout the build. That definitely helped me move faster. It also made one thing very clear: AI can accelerate implementation, but it does not remove the need for architectural steering, debugging discipline, and careful review.

I stopped thinking about this as "AI writes the code" fairly quickly. The better framing for me was: I am still the engineer, but I now have a very fast collaborator that needs clear direction.

What I learned building with my AI assistant

A few practices made the biggest difference for me:

Spend time in planning mode before implementation. Longer planning conversations up front saved me from a lot of drift later.
Be explicit about architecture. If I did not define boundaries early, the assistant would fill in the blanks in ways I did not actually want.
State the expected end result clearly. Prompts worked much better when I described success criteria, constraints, and what “done” should look like.
Add observability early. Admin pages, job logs, and debug surfaces helped a lot once the system had multiple moving parts.
Debug collaboratively, not passively. The best prompts were the ones where I pasted the full error, the relevant code path, and the current hypothesis.
Work in smaller slices. Smaller prompts with checkpoints were much easier to validate than one large mega-prompt.
Test between slices. Typechecks, linting, and automated tests were essential to keep momentum without accumulating silent breakage.
Ask for pre-mortems and final audits. Some of the most useful prompts were “what am I missing?” and “review this repo for architectural risk.”

For Codex specifically, a few habits helped a lot: use plan mode for architecture, keep a reusable prompt contract, isolate bigger changes in branches or worktrees when useful, and run a final repo-wide audit once the main implementation is in place.

One other thing I noticed: model choice matters less than matching the model and reasoning depth to the task. When I wanted speed, I went lighter. When I was stuck on architecture or a harder bug, I switched to a deeper pass instead of trying to force a fast model to solve everything.
For example, this is high-level comparison between Codex 5.3 and Codex 5.3 spark that I would switch between:

This is the sequence of prompts I ran with Codex, notice how they are split into smaller building blocks to maintain frequent control and checkpoints when building the project:

Thoughts on the project itself

The hardest part of this project was not generating code. It was deciding how to structure the learning experience for a beginner.

I wanted AI to be optional, not the foundation of the product. That mattered a lot to me. The default experience should still work without any AI setup, and the product should still teach healthy habits rather than turn into a black box.

That pushed me toward a local-first design. The app is meant to run on your machine. It lists guided project-based courses, scaffolds a starter project into your own GitHub repository, and tracks progression through pull requests and validation checks. If you configure an OpenAI or Anthropic key, it can also post optional advisory AI reviews on PRs.

I also experimented with skill-focused course generation around intents like debugging and error_handling. That idea is still promising to me, but I want to be honest about its current state: the custom course pipeline is still experimental, and the UI is currently marked as temporarily disabled while I harden it.

The deeper challenge here is educational design. How do you teach fundamentals in a way that is practical, motivating, and not overly abstract? The repo reflects that tension quite a bit. The course structure includes step-zero onboarding, glossary terms, review checklists, concept primers, reflection prompts, and milestone validation. The goal is not just “finish tasks,” but build better engineering intuition along the way.

Tech stack

TypeScript
Next.js 15
React 19
Node.js 22
pnpm monorepo
Prisma
PostgreSQL
a local background worker using tsx
GitHub API integration with outbound sync and optional webhook ingestion
OpenAI / Anthropic integrations for optional AI features
Vitest, ESLint, and Prettier

Architecture decisions I made early

A few design decisions shaped the project quite a bit.

Implemented today:

Local-first web app plus background worker
Queue-based job processing with retries
Optional AI layer on top of deterministic milestone validation and progression
Structured logging for jobs, events, and LLM activity
Admin pages for monitoring job and LLM behavior
An LLM gateway with token limits, request hashing, cache support, and secret scanning on diff input
AI PR review based on trimmed diff context rather than dumping the full repo into the model
Template and course versioning
Course-plan validation against a concept dependency graph, so the learning progression stays more coherent

One detail I particularly like is that milestone progression is deterministic. AI can help as an advisory layer, but it does not decide the underlying progression state. That felt like the right tradeoff for a learning product.

Another useful decision was adding structured logs and worker heartbeats early. Once you have a web app, a worker, GitHub sync, and optional AI behavior, silent failure becomes expensive. I wanted the system to be inspectable.

Still future work:

A few ideas are still more directional than finished:

better cost controls as usage scales
a stronger and more reliable custom-course generation pipeline
better reuse and sharing of generated courses
richer reflection and learning artifacts around the core course flow

So while I am happy with the foundation, I do not want to oversell the current state. The core local-first flow is the real shipped value today.

Open-source release

The repo is now public and MIT-licensed:

JulienAvezou / ai-course-generator

Build custom code fundamentals courses with github and AI integrated workflows

Coding Course Generator

Local-first, open-source software for learning healthy coding fundamentals in the age of AI.

This project is a build-in-public social experiment. The goal is not to ship a hosted product. The goal is to help learners run the app locally, scaffold a real project into their own GitHub repository, and learn fundamentals, debugging habits, and engineering discipline through guided milestones.

Open Source Status

The source code in this repository is licensed under MIT.
The repo is intentionally private at the package-manager level in package.json to prevent accidental npm publishing.
This repository is publicly visible on GitHub and is intended to be cloned and run locally.
Treat the codebase, docs, screenshots, and git history as public-facing project material.

Mission

Teach programming fundamentals through real projects
Teach professional engineering habits, not just syntax
Help AI-assisted builders develop better judgment, debugging ability, and maintainable code instincts
Keep the whole system…

View on GitHub

The intended usage is simple: clone it, run it locally, inspect everything, and fork it if you want to push the idea further. That is also why I kept AI optional. You do not need AI features to use the core product.

What I am releasing today is not a polished production platform. It is a local-first open-source project with a real architecture, a clear learning idea, and a working core flow. The custom course pipeline generation is still too experimental, I will try to implement a working version when I have some extra time to dedicate to this project.

Screenshots

Closing thoughts

This project was a useful reminder that AI can accelerate building, but it does not replace product judgment or engineering clarity. If anything, it makes those qualities more important.

If you want to try it, fork it, or build on top of it, I would love to see what you do with it. I am especially interested in hearing what you would change in the learning flow, the validation model, or the AI workflow.

How would you design a beginner coding product today: should AI be a guide, a reviewer, or mostly stay out of the way until the learner gets stuck?

As a beginner, what resources are you using today to learn how to code?

For experienced coders, what resources would you recommend to beginners learning to code today?

Don’t let AI do your thinking: a practical guide for engineers

Julien Avezou — Thu, 16 Apr 2026 10:59:58 +0000

I designed a "Thinking Guide" for engineers building with AI. And looking for your feedback.

We’re entering a new era of software engineering.

Code can now be generated instantly. Entire functions, components, even systems can be scaffolded in seconds.

This is a massive opportunity.

But there’s a subtle tradeoff I’ve been thinking a lot about lately:

When execution becomes easier, thinking can quietly decrease.

Not because we’re less capable, but because many of the moments that used to force us to think - debugging, struggling, reasoning - are now compressed or skipped.

You can ship faster than ever.

But speed alone does not build understanding.

Several studies suggest that heavy reliance on AI tools can reduce cognitive effort, weaken critical thinking, and impair long‑term learning, which are all forms of cognitive offloading.

A recent experimental learning study reported in Psychology Today (“Cognitive Offloading: Using AI Reduces New Skill Formation”) showed that learners who relied heavily on AI while acquiring a complex skill (e.g., coding assistance) formed substantially fewer new skills than those who completed the same tasks without AI. The authors conclude that when tasks are done with the goal of learning, offloading key steps to AI “considerably reduces” skill formation and recommend delaying AI support until a solid base of independent proficiency is built.

The takeaway isn’t to avoid AI. It’s to use it in a way that keeps you thinking, rather than replace your thinking.

Why I wrote this guide

Over the past few years, I went from a graduate with no experience to a senior software engineer in 5 years, while also building and launching my own projects.

One thing I realized along the way:

Growth didn’t come from writing more code.

It came from reflecting on the code I wrote.

After debugging an issue, what signal led me to the root cause?

After designing a system, what trade-offs did I make?

After using AI, did I actually understand what was generated?

So I started building small reflection habits around my work.

Over time, this turned into a structured system.

I recently turned that system into a guide:
"Thinking in the Age of AI"

The goal is simple:
Help engineers keep developing their judgment and intuition while using AI tools.

How to use the guide

This isn’t meant to be read once and forgotten.

It’s designed to be used in small moments during your workflow.

Most exercises take 2–5 minutes.

15 exercises in total.

You don’t need to use everything. Just start by picking one tool and applying it consistently.

The idea is not to reflect more.
But to reflect deliberately.

Example 1 — AI Dependency Detector

One of the tools in the guide is a quick and effective assessment on whether AI strengthening your thinking, or replacing it.

Here is the full exercise extracted from the guide:

Part 1 — Quick Self-Assessment

For each statement, check the box if it applies to you frequently.
☐ I use AI before attempting to think through the problem myself.
☐ I paste AI-generated code without fully reading it.
☐ I struggle to explain AI-generated solutions afterward.
☐ I rely on AI for problems I previously could solve independently.
☐ I rarely rewrite AI-generated code in my own style.
☐ I feel uncomfortable solving similar problems without AI.
☐ I accept AI solutions even when I do not fully understand them.
☐ I use AI to avoid difficult cognitive effort.

Interpreting Your Results

0–2 boxes checked → AI is likely accelerating your thinking. 
3–5 boxes checked → Monitor usage and reintroduce friction. 
6+ boxes checked → Consider temporarily increasing independent problem-solving time.

Part 2 — Dependency Signals

Reflect on the following questions:

When AI is unavailable, how confident would I feel solving similar problems?

1 — Not confident 2 — Somewhat unsure 3 — Neutral 4 — Confident 5 — Fully confident

Circle one: 1 2 3 4 5

Have my independent debugging skills improved, stayed the same, or declined over the past months?

☐ Improved ☐ Stayed the same ☐ Declined

If I removed AI from my workflow tomorrow, what would weaken first?

_____________________________________________________________________

Part 3 — Cognitive Strength Check

Complete this short test after using AI:

Without looking at the code:

• Can I describe the logic step by step? 
• Can I identify edge cases? 
• Can I reason about time/space complexity? 
• Can I modify the solution confidently?

If you answered “no” to multiple items, this is not failure, it is a signal.

Part 4 — Adjustment Plan

If you notice rising dependency, choose one corrective action:

☐ Attempt solutions yourself for 5–10 minutes before using AI 
☐ Rewrite AI-generated code in my own words 
☐ Explain the solution aloud after generating it 
☐ Use AI only after defining constraints clearly 
☐ Limit AI use for certain categories (e.g., debugging)

Write one commitment for your next session:
_____________________________________________________________________

Example 2 — Reflection Prompt Cards

I also created a set of prompt cards organized by engineering themes:

system design
debugging / incidents
learning
promotion / impact
AI usage

I printed them out and keep them on my desk when building products so that I can ask myself the right questions along the way.

Whenever I’m working, I can pull a relevant card and quickly reflect.

For example:

"What trade-offs did I consciously make here?"
"What signal led me to the root cause?"
"What would I do differently if I had to rebuild this from scratch?"

These small questions compound over time and build intuitions.

I’m now sharing this guide for feedback

If you’re curious, I’ve put the guide here:

👉 https://javz.gumroad.com/l/thinking-in-the-age-of-ai

You can grab it for free (just set the price to 0).
If it ends up being useful, feel free to support so I can keep investing my time in creating resources to help engineers, totally optional of course.

Mainly looking to get feedback from other engineers.

Would especially appreciate feedback on:

which exercises feel useful vs unnecessary
what feels missing
how this fits into your actual workflow

Curious how others approach this

I’d also love to hear from other devs here:

How do you make sure your thinking keeps up with AI tools?

Do you have any habits or systems in place?

AI can generate code.

But the engineers who will stand out are the ones who continue to think deeply while using it.

That’s what I’m trying to build here. This guide is helping me, I hope it can help you too along your journey as a dev.

Curious to hear your thoughts!