DEV Community: Julien Avezou

My First Year at DEV Recap

Julien Avezou — Wed, 01 Jul 2026 13:46:22 +0000

I heard about DEV a while back from a former colleague who was posting regularly back then. She won a few challenges and prizes and spoke about how the community was so welcoming.

This was years ago. Aside from reading a post here and there, I never wrote or commented actively on the platform.

Things changed a year ago when I wrote my first post: We launched on product hunt this week was it worth it.

It got a total of 7 reactions. Some of those reactions were mine...

I naively thought that I could just release a post and that it would get immediate traction.

It didn't. For obvious reasons. I will get back to this point in a bit.

Months went by without posting. I felt discouraged that my first post had flopped so badly.

Then I saw an opportunity to write again through a DEV challenge. I could showcase my work again and even potentially win prizes. These extra incentives pushed me to share my second post.

This one gathered more reactions and even a couple of comments!

My motivation went back up and I was already thinking about my next post which I released just a week later.

I then started writing more and more posts. I saw the engagement and follower count increase over time. I kept going.

Things took a turn after one of my posts was awarded the highly coveted top 7 badge of the week. That really made my day and I felt that people were really tuned into what I was writing about.

From that point onwards I decided that I would write a weekly post on the platform so I can share my learnings, experiences and projects with the community. Aside from the odd week now and then, I am proud to say that I remained consistent with my writing goal.

Today I am proud of my progress achieved and even happier that I have a growing audience that enjoys engaging with my content. I even made multiple friends along the way!

I want to share with you a few reflections looking back at my first year with DEV. I hope you find inspiration in some of them.

Don't be distracted by vanity metrics. I know that I mentioned a couple of times the reactions count as being a source of motivation. Of course it would be!
Who wouldn't like getting engagement on a post they poured effort into writing and sharing with the world? However I would caution against fixating on just these reactions. I made the mistake of giving up after my first post due to the low engagement. In hindsight this was a mistake as months went by without me writing anything, reinforcing this feeling of disappointment. This was a mistake on my part and a lesson for anyone going through the same. This leads to my next point.
Be consistent. I can't overstate the importance of this. Some of your posts will perform better than others, and that's totally ok. What counts is to keep showing up over time. I never knew that the post that made it to Top 7 would be that specific one. But since I was posting regularly at that point it increased the odds of this happening. Being consistent is easier said than done.
Create a system. In order to become consistent I built in a habit of writing a weekly post. Writing has now become a part of my weekly routine where I dedicate an evening a week to writing my post.
Writing is healthy. I feel that writing is a moment of reflection for me that I need in my life. The weekly slot I block out to write is a moment for me to slow down, shape my thoughts and reflect. This is a weekly habit I am glad I picked up.
The more I write, the more ideas I get. You would think that writing one post a week is hard as you would eventually run out of ideas. However I find the opposite to be true. Everytime I write a post I get into a reflective state that gets me thinking of future post ideas.
Join DEV challenges. I have joined several challenges over the year and these pushed me to try out new tools and even collaborate on a post with other DEV members! I even won runner-up to one of the challenges which was a great moment.
Give before you take. This was a bug mistake I made when I first posted here on DEV. I thought I could promote a tool I made and get instant engagement. That is definitely the wrong way of thinking. Before I posted again I decided to engage with other members posts. Everyone is putting in effort to share their thoughts with the world. Acknowledge these efforts in others posts instead of just thinking about your own. Just think about it. If nobody engaged with anybody else, few people would keep posting.
Provide value above all. Don't write posts with the pure intent of selling a product to your audience. It's ok to share and mention what you are working on, but include valuable information that the user can take away from reading your post.
Have fun. Some of you might frown at this one but it is easy to start viewing posting as another task in your schedule. If this becomes the case I would advise taking a break from writing and only coming back once you feel that you want to keep writing. If you don't take any enjoyment out of posting, then what is the point?

As my first year at DEV wraps up, I want to thank all my followers for their engagement and also the community for being a safe space I can share my thoughts and experiences with, and learn from others.

I can't believe I have over 20k followers today. I am grateful to every single one of you!

Stay tuned for my year 2 recap!

Thank you DEV community: the Thinking Engineer Toolkit is live

Julien Avezou — Thu, 25 Jun 2026 12:58:12 +0000

Over the past weeks, I’ve been sharing a series of posts that gravitate around one question:

How do we use AI without outsourcing our judgment?

The engagement from this community in response to this series has been genuinely strong.

This indicates that the issue of cognitive offloading associated with AI use is real. It is a problem space that resonates highly amongst developers.

The comments, feedback, and discussions sparked along the way helped me sharpen the ideas behind what has now become The Thinking Engineer Toolkit.

A moment of gratitude

It has been a wonderful and insightful journey to share this series with you here, to learn from other engineers and builders, and explore how AI-assisted work is changing the way we think, build, and understand software.

Thank you for your inputs.

And to those who have also reached out to me to express their support, encouragement and kind words, I thank you deeply.

I look forward to many more discussions with you all.

I wanted to originally tag the most engaged members directly here but there is a 10 tag limit per post (rightfully so!). Since I didn't want to make anybody feel left out I will avoid doing this since there are definitely much more than 10 people I wanted to tag!

The posts that led to the Thinking Engineer Toolkit

The Toolkit was influenced by a series of posts I shared here on DEV, feel free to check them out:

Thinking in the Age of AI
Don’t let AI do your thinking: a practical guide for engineers
Thinking in the Age of AI — Team Edition
Don’t let AI break your collective thinking: a practical guide for engineering teams
Thinking in the Age of AI — Builder Edition
From vibe coding to clear thinking: what non-technical builders need in the age of AI
AI Thinking Balance Tracker
The 4 cognitive archetypes of developers using AI
Prompt System Guide
The missing layer in prompt engineering: thinking quality
System Comprehension Heatmap
Your Codebase Has Technical Debt. But Does Your Team Have Comprehension Debt?

Each post explored a different part of the same bigger problem:

AI is making us faster, but speed is not enough if understanding can't keep up.

Why I started The Thinking Engineer

I started The Thinking Engineer because I kept noticing a tension in my own workflow.

AI was helping me move faster.

It helped me brainstorm, debug, refactor, write, and build.

But I also noticed that if I used it passively, it could make my understanding thinner.

Sometimes I was thinking better with AI.

Other times, I was letting AI think too much for me.

I was confusing productivity with removing friction.

That distinction matters.

Because engineering is not just about producing code.

It is about judgment, tradeoffs, debugging, communication, system understanding, and knowing when something looks right but is actually shallow.

That is the problem I want to keep exploring:

How do we build effectively with AI while preserving the thinking skills that make engineering valuable?

What is inside the Thinking Engineer Toolkit?

The Toolkit brings together 6 resources:

1. Thinking in the Age of AI

A guide for individual engineers who want to use AI without weakening their own reasoning, learning, and technical intuition.

2. Thinking in the Age of AI - Team Edition

A guide for engineering teams that want to preserve shared understanding while adopting AI-assisted workflows.

3. Thinking in the Age of AI - Builder Edition

A guide for builders, founders, and non-technical creators using AI to build software without losing sight of the systems they are creating.

4. AI Thinking Balance Tracker

A spreadsheet to help developers notice how they use AI across different cognitive modes: learning, generating, debugging, reflecting, and executing.

5. System Comprehension Heatmap

A spreadsheet to help teams identify where system understanding is strong, fragile, or dangerously concentrated.

6. Prompt System Guide

A practical guide to using prompts not just to get better AI outputs, but to improve thinking quality.

Why bundle them together?

Each resource can be used on its own.

But together, they form a complete system.

The guides help you reflect.

The trackers help you observe patterns.

The heatmap helps teams surface comprehension debt.

The prompt guide helps improve the quality of your AI interactions.

Combined, they create a practical workflow for asking:

Am I using AI intentionally?
Do I understand what I am building?
Is my team preserving shared understanding?
Are we moving faster in a way that compounds learning?
Or are we moving faster in a way that hides fragility?

Based on my experience, this is the Toolkit I wish I had from the beginning: a way to create better habits around the questions that matter.

The bigger picture

I think the next phase of software engineering will not only reward people who can use AI tools.

It will reward people who can use AI tools while preserving judgment.

The engineers and builders who stand out will be the ones who can ask better questions, validate outputs carefully, understand systems deeply, and keep learning instead of just delegating.

That is what I mean by being a Thinking Engineer.

What I’ve learned from sharing this work

One thing I’ve appreciated from the DEV community is that the general consensus is not simply whether AI is good or bad.

It is more nuanced:

How do we use AI well?
Where does it help?
Where does it create dependency?

That is the conversation I want to keep having.

The nature of our roles is changing.

It is exciting and scary at the same time.

We are all figuring this out at the same time.

Get your Toolkit today

I want to share The Thinking Engineer Toolkit with you today free to help engineers and builders work effectively and sustainably with AI assistance. If you find it valuable, I would also appreciate any support so I can keep investing my time in creating such resources.

You can access the toolkit here.

Looking ahead

I would love to hear how you are approaching this in your own workflow:

How do you avoid over-relying on AI?
Do you have rules for when to use AI and when to think first?
Are you seeing comprehension debt emerge in teams or codebases?
What would make this Toolkit more useful in practice?
What should I improve next?

What Kind of AI-Assisted Developer Are You? Take the quiz.

Julien Avezou — Mon, 22 Jun 2026 13:22:01 +0000

AI makes us faster, but does it make us better engineers, or just more dependent?

As a follow-up to my post on the The 4 Cognitive Archetypes of Developers Using AI, I wanted to created a quiz as a self-assessment for AI-assisted development habits.

My previous post sparked many interesting discussions and insights. I took some of those elements and put together a series of questions to help evaluate how you are using AI as a developer.

The 4 Archetypes include:

AI Architect: owns the problem, uses AI as leverage

AI Balancer: productive with AI, still protects judgment

Autopilot Builder: fast, but may accept output too quickly

AI Passenger: lets AI do too much of the cognitive work

This assessment scores answers across dimensions:

ownership
reflection
dependency
leverage
verification
speed bias

The questions are based on everyday engineering decisions:

debugging production issues
reviewing AI-generated code
writing tests
refactoring
working with unfamiliar libraries
explaining AI-assisted PRs
documenting complex changes

Here is my Cognitive Archetype for example:

Each results page also displays a breakdown of associated strengths and weaknesses and recommended actions to improve your cognitive score.

Here are my results:

I want to clarify that I am not collecting or persisting any user data as part of this project. It's just a small tool I wanted to share to keep the conversation going and hopefully inspire some of you.

You can take the quiz here and share which archetype you got!

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