DEV Community: Julien Avezou

ReflectionCLI 2.0: a local-first thinking CLI for AI-assisted development

Julien Avezou — Mon, 20 Jul 2026 12:37:37 +0000

The original concept behind this tool won the runner-up award for the Github CLI Challenge earlier this year.

As a reminder, ReflectCLI is a tool to promote thoughtful coding through structured reflection.

What does it do?

Before each commit, answer reflective questions to build your personal developer knowledge dataset.

The tool is local-first by design. It stores everything locally inside the current Git repo:

.git/git-reflect/log.json

No account, no cloud sync, no authentication, and no external AI API call.

Why build it?

AI-assisted development is powerful, but it can encourage cognitive offloading, letting tools do the thinking instead of developing deeper understanding. git-reflect interrupts this pattern by making reflection part of your workflow.

Each answer becomes part of your personal knowledge base, documenting not just what you built, but why you built it that way and what you learned. Over time, this dataset reveals patterns in your thinking and helps you grow as a developer.

If you want to read about the original tool, check out my previous post here.

Since building the original version, I've spent months researching how AI changes the way developers learn, reason, and make technical decisions.

Many of the ideas from those discussions have now been incorporated into ReflectionCLI 2.0.

What started as a simple Git pre-commit reflection hook has evolved into a local-first thinking tool for developers working alongside AI assistants.

What's New

Comprehension debt tracking

You can now record artifacts you shipped but don't fully understand yet.

reflection debt add "Understand why the cache invalidates on user updates" \
  --project api \
  --tags cache,ai \
  --context "AI generated most of the invalidation logic"

These artifacts can easily be retrieved and resolved later.

reflection debt list
reflection debt resolve debt-001

Explain-back mode

This workflow focuses on active recall and asks a series of questions to assess your ability to explain the piece of code.

reflection explain

AI outsourcing audit

Checks whether too much judgment was outsourced to AI in a coding session.

reflection audit \
  --ai-generated yes \
  --verified no \
  --can-explain no \
  --edge-cases no \
  --alternatives no \
  --challenged no \
  --create-debt

Decision journal

You can record your technical decisions directly from the terminal.

reflection decide \
  --project api \
  --tags caching,performance \
  --title "Use Redis for session cache" \
  --context "Need shared cache across instances" \
  --options "Redis|In-memory cache|Database table" \
  --chosen "Redis" \
  --reasoning "Shared state and expiry support are built in" \
  --tradeoffs "Adds infrastructure dependency" \
  --expected "Lower latency and consistent sessions" \
  --review-date 2026-06-16

And review that decision at a later stage.

reflection decision review decision-001

Weekly thinking report

Generate a local Markdown report from your reflection data to summarize learning, surface unclear areas, AI usage types, comprehension debt levels and opportunities to improve.

reflection weekly --output weekly-thinking-report.md

Prompt reflection

This workflow is for reviewing prompts you used with AI so you can improve future prompting.

reflection prompt \
  --project cli \
  --tags prompts,testing \
  --prompt "Write unit tests for this parser" \
  --goal "Improve parser coverage" \
  --output "Generated happy path tests" \
  --worked "It identified basic branches" \
  --unclear "It did not know our edge cases" \
  --assumptions "Parser behavior was fully visible" \
  --lessons "Include edge cases and expected failures"

Direct reflection command You can reflect on your work through intentional thinking sessions, not just during commits.

reflection learn
reflection explain
reflection audit
reflection weekly

The goal here is not to avoid AI.

It's to ensure that while AI helps us write code faster, we continue building the understanding, judgment, and decision-making skills that make us better engineers over the long term.

If you want to check out the tool, it is open source here.

Let me know your thoughts on the new features and if you have any ideas for further improvements!

Start Building for Agents, Not Just Humans

Julien Avezou — Mon, 13 Jul 2026 12:45:55 +0000

For decades, software was designed around one assumption:

A human would be the one using it.

That assumption is starting to break.

We are entering a world where software increasingly needs to serve two categories of users:

human users
agent users

And those two stakeholders have very different requirements.

My observation

Over the last months, I have noticed that an increasing number of products are being built with AI agents in mind rather than humans.

I recently connected with builders actively working on products for AI agents to use:

make specific data points for merchants searchable by AI agents so they can differentiate and reveal this information to human consumers when searching via LLMs.
improve the searchability of human profiles on the internet by providing crawlable inputs for LLMs to ingest and agents to act upon

We are witnessing a big shift at the moment. An increasing number of companies, big and small, are leaning into this trend. The big players in AI are making it easier for companies to plug into emerging AI ecosystems through things like Claude Connectors or ChatGPT Apps.

The goal is to build high-leverage infrastructure for agents.

A merchant for instance may soon care less about whether a user lands directly on their homepage, and more about whether an AI shopping agent can accurately retrieve and compare their product information.

This shift opens up timely opportunities to build tooling that supports and plugs into these new agent-first ecosystems.

Noticeable trends

Some important trends I am seeing:

1) UI matters less, interfaces matter more

Think of it as the agent bringing relevant data directly to the human user, rather than the human manually navigating systems to find it themselves.

One consequence of this is the increasingly uniform chat interface we now see across many AI products.

The agent runs in the backend with a minimalistic human oversight layer.

Agent-first systems optimize less for visual exploration and more for reliable retrieval.

In many cases, APIs, schemas, and retrieval layers are becoming the real interface.

MCPs are one example of this shift.

The early web often felt handcrafted and expressive.
But maybe that's just my nostalgia speaking...

2) The internet is becoming machine-readable infrastructure.

LLMs are frequently trained on data pulled from the internet. As a result, you need to think about the quality of your data and how it can be used by LLMs.

Content is no longer just being consumed by humans. Increasingly, it is being parsed, ranked, retrieved, and acted upon by machines.

Think schema markup, citation-ready and brand-coherent content. High-authority mentions to elevate trust.

3) System design will change with agentic systems

Agentic systems require a very different kind of infrastructure than traditional apps.

Reliability, permissions, memory, observability, and rollback mechanisms become critical because the system is no longer just displaying information to humans, but actively acting on their behalf.

Trust becomes critical.

Visual polish matters less than reliability for agentic systems.

Safety mechanisms are also crucial:

approval systems
human-in-loop controls
policy engines
simulation environments

The mindset shift

My main takeaway from this post is to start considering the AI Agent as a new category of stakeholder with requirements to be satisfied.

Here is a good list of questions as a starting point for your new agent stakeholder:

What would an agent need to know to act safely here?
Is this information readable by machines, or only understandable by humans?
What decisions should the agent make, and which should remain human-owned?
What signals should change the agent’s behavior?
What is the agent’s failure mode?
What would make this workflow easier to delegate?
What should be logged, remembered, or learned from this interaction?
Is the interface designed for human navigation or agent retrieval?
What policy should govern the agent here?
Could this become a reusable agent primitive?

Taking this perspective as an agent will help unblock new ideas and opportunities and help you engineer more reliable systems over time.

I recently shifted gears into this mindset and unlocked a new way of thinking about software design.

Let's discuss

Are you excited about this shift?

Can you think of any opportunities that can arise from this new agent-first paradigm?

Closing remarks

For years, we optimized software for clicks.

Now we may need to optimize software for delegation.

That changes how we think about:

interfaces
trust
documentation
infrastructure
even discoverability itself

The next generation of software may not be defined by the best UI.

But by how effectively humans and agents collaborate together.

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.