Forem: Julien Avezou

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

Comments 4

19 min read

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

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

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

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

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

Not technical debt.

Something more subtle:

comprehension debt.

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

And AI is making this gap more important.

AI didn't create the problem.

This problem existed long before AI.

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

But AI can accelerate the problem.

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

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

But dangerous when it turns into:

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

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

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

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

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

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

What is comprehension debt?

Let's start with a more formal definition:

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

I am not basing this just on theory.

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

It was a stressful and demoralizing experience.

I constantly felt behind and had to keep up.

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

The code existed.

The services existed.

The tickets kept moving.

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

That is a hard place to work from.

You feel reactive all the time.

You are not just debugging the incident.

You are debugging your own lack of context.

Why AI makes this worth measuring now

AI-assisted development can be incredibly useful.

I use AI myself, quite frequently.

But I keep coming back to this question:

Are we increasing shipping velocity without increasing understanding velocity?

Because those are not the same thing.

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

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

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

The issue is not:

“Did AI write this?”

The better question is:

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

How the debt score is calculated

This is not meant to be a perfect mathematical model.

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

At a high level, the score combines two sides:

1) System pressure

These factors increase comprehension debt:

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

2) Team comprehension coverage

These factors reduce comprehension debt:

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

So the rough model is:

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

minus

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

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

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

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

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

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

Discussion

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

Also curious:

How does your team maintain understanding of the codebase?

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

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

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

We are getting better at generating code.

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

Get the template

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

It includes:

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

You can get it for free here

I would love feedback.

The missing layer in prompt engineering: thinking quality

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

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

Optimizing for better outputs often translates to:

Better prompts
More context
More structure

But lately, I’ve been wondering:

What if we’re optimizing the wrong layer?

Because the real question isn’t:

“How do I get better answers from AI?”

It’s:

“Is AI actually improving how I think?”

Because I’ve noticed something subtle:

My output was improving.

But my understanding was not always.

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

Good engineers ask better questions.

The best engineers question their own thinking.

Most of what I see optimizes for:

better outputs
faster generation
more automation

But much less for:

clearer thinking
stronger judgment
deeper understanding

AI isn’t just changing how we build.

It’s quietly reshaping how we think while building.

🧠 What kind of thinking do you actually need?

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

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

Instead of asking:

“What’s the best prompt for this?”

I started asking:

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

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

1) Explore

When I don’t fully understand the problem yet

2) Challenge

When I have a plan… but it might be wrong

3) Decide

When I need to choose between options

4) Audit

When I need to verify quality or correctness

5) Reflect

When I want to actually learn from what I did

This simple shift changed everything.

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

🔁 The simple loop that protects your thinking

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

Before AI

Write what you think first.

During AI

Use it to expand or challenge your thinking.

After AI

Ask yourself:

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

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

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

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

⚖️ Why one prompt is almost never enough

One thing I’ve been changing in my workflow:

I rarely rely on a single prompt anymore.

Instead, I use prompt pairing:

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

For example:

First prompt:

“Suggest 3 possible architectures for this system.”

Follow-up:

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

Why this matters:

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

incomplete
overly confident
biased toward common patterns

Prompt pairing helps you avoid:

first-answer bias
shallow reasoning
premature decisions

It forces a simple but powerful loop:

Generate → Critique → Decide

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

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

Another thing I started doing:

After important prompts, I ask myself:

“Did AI actually improve my thinking here?”

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

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

Not as a strict system.
More as a signal.

Because sometimes the pattern is obvious:

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

And over time, that compounds.

🛠️ A few prompts that changed how I work

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

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

Then I follow it with:

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

What this does:

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

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

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

Followed by:

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

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

👥 What’s changing in teams right now

Prompting is evolving quickly.

It’s becoming:

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

And more about:

prompt sequences
prompt-driven workflows

I’m also seeing patterns like:

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

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

🧩 The piece I felt was missing

I didn’t need more prompts.

I needed a way to answer:

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

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

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

Not to optimize productivity.
But to protect judgment.

⚙️ The system I ended up building for myself

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

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

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

All organized around real engineering use cases.

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

Would love your feedback on my system.

💬 Curious how others are approaching this

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

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

AI gives answers.

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

The 4 Cognitive Archetypes of Developers Using AI

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

Lately, I’ve been reflecting on something:

The question for most developers is no longer "Are you using AI?", but rather "How and why are you using AI?".

I’ve noticed AI tooling becoming increasingly embedded in my daily workflow. At this time last year, my usage of AI was limited to code autocomplete suggestions in my IDE that I would manually validate. Now I am using coding assistants to help ideate, prototype, and refactor my projects.
In just one year, my workflow has changed dramatically.

It's hard for me to now imagine coding without AI tooling as it has been making me more productive. It's the same feeling I got when I got my first smartphone.

AI increasingly feels like my first smartphone: transformative, incredibly useful, and powerful enough that I need intentional habits to avoid overdependence. For example, keeping it outside of my bedroom when I go to sleep and occasionally going on walks without it, just to be alone with my thoughts.

This is the kind of awareness I’m now trying to build around my AI usage: understanding how it shapes my thinking, where it helps, and where it may quietly erode it.

AI isn’t just changing how fast we build. It is also impacting how we think.

Because not all AI usage is equal. Each usage can be mapped to a certain cognitive cost.

Sometimes AI helps us think more clearly and move faster.
But sometimes it quietly replaces parts of our reasoning before we even notice.

I realized that sometimes I wasn’t using AI because I needed leverage, I was using it because I wanted to avoid friction.

That realization pushed me to start thinking less about AI usage in general, and more about AI modes.

Each AI mode carries a cognitive cost

I distinguish 3 groups: Supportive, Mixed, Risky.

Supportive modes:

Explaining unfamiliar code or architecture
Exploring tradeoffs
Critiquing a plan
Testing assumptions
Clarifying concepts

These modes use AI to expand your thinking and have a low cognitive cost.

Mixed modes:

Boilerplate generation
Refactoring suggestions
Drafting documentation

These modes use AI to save time but can also compress understanding if used carelessly. These modes have a sizeable cognitive cost.

Risky modes:

Blindly accepting generated solutions
Delegating core architecture too early
Letting AI define implementation before you’ve thought deeply
Heavy debugging delegation without understanding the root cause

These can feel productive on the surface, but these AI modes can weaken long-term comprehension if used frequently and have a high cognitive cost.

Hands-on reflective practices also affect your total score

When shipping code I also keep a set of reflective exercises that I can make use of at different stages of my workflow. These can reinforce healthy behavior that alleviate some of the cognitive cost from AI modes.

Before:

Did I attempt this myself first?
Am I using AI to expand my thinking or bypass it?

During:

Am I reviewing assumptions deeply?
Could I explain why this output works?
What risks or edge cases might AI be skipping?

After:

Could I explain this solution tomorrow without rereading it?
Did I preserve ownership?
Was this leverage or dependency?

Over time, repeated AI habits don’t just affect productivity.

They shape how we think.

Those patterns shape your cognitive archetype

There are 4 main cognitive archetypes:

AI Architect

AI expands thinking without replacing ownership

AI Balancer

Mostly healthy, but mixed-mode creep needs monitoring

Autopilot Builder

Efficiency may be masking weakened comprehension

AI Passenger

AI may be driving too much of the reasoning path

These archetypes aren’t an exact science. They’re simply a framework for raising awareness.

Have you also noticed different "AI modes" in your own daily workflow? If so, what mode are you in the most?

What would be your cognitive archetype and why?

I’d be curious to hear how others are thinking about their own AI usage.

It feels like we’re all trying to figure out and build these habits in real time.

My take: I don’t think the right path is using AI less.

AI clearly offers real leverage, but leverage without awareness can come with hidden costs.

Knowing when to switch modes becomes key.

When should AI be a teacher, critic, accelerator or collaborator?

When should AI support the driver without taking the wheel?

Because faster output is great but only if understanding keeps up.

I built a personal tracker around this framework to better measure my own habits over time.

It helps me score AI modes, monitor dependency drift, and spot patterns in how I work so I can adjust more intentionally over time.

If it sounds useful to you too, I’m sharing it free and would genuinely love feedback: https://javz.gumroad.com/l/ai-thinking-balance-tracker

AI through Visuals - Hardware

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

Most AI content today feels flat.

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

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

Why I’m starting this series

As engineers, our edge is not just using tools.

It’s understanding systems.

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

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

That’s where this idea came from.

Introducing: AI Visual Series

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

infrastructure
systems
tradeoffs
bottlenecks
real-world constraints

Not with walls of text…

But with visuals you can explore and interact with.

👉 You can explore the series here

The goal isn’t about simplifying AI.

It’s about making complex systems intuitive through visuals.

Because once you see something you think differently about it.

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

AI Hardware, Explained Visually

We talk about AI like it’s software.

Prompts. Models. APIs.

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

It runs on a massive physical stack of hardware.

1. The AI hardware stack

A modern AI system isn’t just a server.

It’s a layered system:

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

Each layer matters.

Each layer can break.

2. A global system

What surprised me most:

This stack is not built in one place.

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

No single country controls the full system.

3. Where things actually break

We used to think scaling AI meant just adding more GPUs

But that’s no longer true.

The real bottlenecks are now:

HBM memory
advanced packaging
networking
power availability
cooling

And here’s the counterintuitive part:

Compute itself is no longer the main constraint.

The key takeaway

The more I dig into AI…

The less it feels like software engineering.

And the more it feels like:

distributed systems
hardware engineering
energy infrastructure

All at once.

Why this matters for us

If you’re building with AI today:

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

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

You can play around with the interactive visuals here

What’s next in the series

I’ll keep building these visual explainers around:

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

Curious to hear:

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

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

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

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

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

Coding setup

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

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

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

What I learned building with my AI assistant

A few practices made the biggest difference for me:

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

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

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

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

Thoughts on the project itself

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

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

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

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

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

Tech stack

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

Architecture decisions I made early

A few design decisions shaped the project quite a bit.

Implemented today:

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

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

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

Still future work:

A few ideas are still more directional than finished:

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

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

Open-source release

The repo is now public and MIT-licensed:

JulienAvezou / ai-course-generator

Build custom code fundamentals courses with github and AI integrated workflows

Coding Course Generator

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

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

Open Source Status

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

Mission

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

View on GitHub

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

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

Screenshots

Closing thoughts

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

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

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

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

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

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

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

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

We’re entering a new era of software engineering.

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

This is a massive opportunity.

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

When execution becomes easier, thinking can quietly decrease.

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

You can ship faster than ever.

But speed alone does not build understanding.

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

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

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

Why I wrote this guide

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

One thing I realized along the way:

Growth didn’t come from writing more code.

It came from reflecting on the code I wrote.

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

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

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

So I started building small reflection habits around my work.

Over time, this turned into a structured system.

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

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

How to use the guide

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

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

Most exercises take 2–5 minutes.

15 exercises in total.

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

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

Example 1 — AI Dependency Detector

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

Here is the full exercise extracted from the guide:

Part 1 — Quick Self-Assessment

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

Interpreting Your Results

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

Part 2 — Dependency Signals

Reflect on the following questions:

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

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

Circle one: 1 2 3 4 5

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

☐ Improved ☐ Stayed the same ☐ Declined

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

_____________________________________________________________________

Part 3 — Cognitive Strength Check

Complete this short test after using AI:

Without looking at the code:

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

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

Part 4 — Adjustment Plan

If you notice rising dependency, choose one corrective action:

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

Write one commitment for your next session:
_____________________________________________________________________

Example 2 — Reflection Prompt Cards

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

system design
debugging / incidents
learning
promotion / impact
AI usage

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

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

For example:

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

These small questions compound over time and build intuitions.

I’m now sharing this guide for feedback

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

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

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

Mainly looking to get feedback from other engineers.

Would especially appreciate feedback on:

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

Curious how others approach this

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

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

Do you have any habits or systems in place?

AI can generate code.

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

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

Curious to hear your thoughts!

Turn Your Laptop Into an AI Agent (Free OpenClaw + Telegram Setup)

Julien Avezou — Mon, 13 Apr 2026 12:48:52 +0000

I have been following the developments of Openclaw and hadn't properly played around with it until now. The FOMO was too strong so I decided to experiment with it in a very low stakes context and share this experiment with you.

No APIs. No subscriptions. Just my machine.

Setting the scene

For those living under a rock these past months, let's start with defining what Openclaw is.
Only kidding, if you don't know what Openclaw is that's totally fine, things move fast these days and it's hard to keep up with everything. If you already know what Openclaw is, here is a refresher:

OpenClaw is a local AI agent runtime that connects LLMs to real-world tools, channels (like Telegram), and automation, letting you build autonomous, personalized AI systems that run on your own machine.

Openclaw is seen as revolutionary because it turns an LLM into a programmable system, not just a chatbot through agents, tool integrations, automations, native channels etc.

Now that we understand what we are working with, let's set some goals, a target architecture and structure for this tutorial.

My goals for this experiment:

Become familiar with the basics of OpenClaw ✅
Free setup for low stakes experimentation ✅
Local models only ✅
Isolation via VM for security ✅
Share this experiment in public to share knowledge ✅
Have fun and learn something new ✅

The flow for this tutorial:

User in Telegram
   ↓
Telegram bot/channel
   ↓
OpenClaw native Telegram channel
   ↓
bookbot agent
   ↓
Ollama on host Mac
   ↓
Mistral
   ↓
Response sent back to Telegram

Architecture diagram:

                           ┌──────────────────────────┐
                           │       Telegram App       │
                           │     (user messages)      │
                           └────────────┬─────────────┘
                                        │
                                        │ native Telegram channel
                                        ▼
                    ┌──────────────────────────────────────────┐
                    │          OpenClaw Gateway (VM)           │
                    │                                          │
                    │  Ubuntu VM in UTM                        │
                    │  - OpenClaw                              │
                    │  - native Telegram integration           │
                    │  - bookbot agent                         │
                    │  - cron / scheduling experiments         │
                    └────────────┬─────────────────────────────┘
                                 │
                                 │ model requests
                                 ▼
                 ┌────────────────────────────────────┐
                 │      Ollama on macOS host          │
                 │                                    │
                 │  - local runtime                   │
                 │  - mistral:latest                  │
                 │  - exposed to VM via local IP      │
                 └────────────┬───────────────────────┘
                              │
                              │ local inference
                              ▼
                 ┌────────────────────────────────────┐
                 │       Open source local model      │
                 │            (Mistral 7B)            │
                 └────────────────────────────────────┘

Having the model run on macOS keeps it fast, while having the agent logic inside the VM isolates it for better security:

┌─────────────────────────────────────────────────────────────────┐
│                        MacBook Pro (host)                      │
│                                                                 │
│  ┌──────────────────────────────┐   ┌─────────────────────────┐ │
│  │   Ollama                     │   │   UTM                   │ │
│  │   - mistral:latest          │   │   Ubuntu VM             │ │
│  │   - OLLAMA_HOST=0.0.0.0     │   │   - OpenClaw            │ │
│  │   - port 11434              │   │   - Telegram channel    │ │
│  └───────────────┬──────────────┘   │   - bookbot agent       │ │
│                  │                  └──────────┬──────────────┘ │
│                  └──────── local network ──────┘                │
└─────────────────────────────────────────────────────────────────┘

Resources used:

VM: 6GB RAM, 50GB disk
Host for Ollama: 6–8GB free RAM + ~15GB disk (model + cache)
Extra disk buffer: ~10GB
Model: one local 7B model

Model choice -> Mistral:

Low memory (~5GB in Ollama)
Fast on Apple Silicon
Stable for agent loops
Good enough reasoning + coding

Security:

Inside VM:
- No shared folders initially
- No SSH keys mounted
- Use limited permissions
Between VM ↔ host:
- Only expose Ollama port (11434)
- Restrict to localhost

I am being conservative here with the setup to avoid my machine crashing while working on my everyday tasks, i.e. having browser tabs and other apps running in parallel.

However feel free to tweak this setup according to your own preferences and resources available.

For reference, I am running this experiment on my Macbook Pro M4 24GB RAM 1TB SSD.

Let's begin!

Optimising available resources

Before starting on the actual Openclaw setup, I wanted to optimise my local resources.

1. Free SSD space

I personally found some applications I could easily delete to free up storage. I took advantage of this to do a spring clean and freed up plenty enough space!

2. Free RAM

Check Activity Monitor

My setup wasn't ideal.

Chrome was the biggest culprit!

Some tips to help reduce memory usage by Chrome:

Chrome → Settings → Performance → Turn on Memory Saver
Kill tabs - Keep <10 active tabs
Remove inactive extensions
Quit background apps you aren't actively using
Clear cache. Recommended to do this occasionally (monthly or before heavy workloads)
Restart Mac to clear any memory leaks

By following these steps, I optimised used memory by roughly 4 GB.

Install tools

Install Ollama (on host)

brew install ollama
ollama serve
ollama pull mistral

# test
ollama run mistral

Setup VM
- Install UTM
- Download Ubuntu ARM64 (downloading via the UTM Gallery worked for me)

Set the correct resources Memory: 6144 MiB (6GB) CPU: 4 cores

Start the VM
Clone OpenClaw and install pre-dependencies (in VM)

sudo apt update && sudo apt upgrade -y
sudo apt install -y git curl build-essential

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
export NVM_DIR="$HOME/.nvm"
. "$NVM_DIR/nvm.sh"
nvm install 22
nvm use 22
node -v
npm -v

corepack enable
corepack prepare pnpm@latest --activate
pnpm -v

git clone https://github.com/openclaw/openclaw.git
cd ~/openclaw

pnpm install
pnpm build

Install OpenClaw

# Find Mac IP and set in Ollama base URL during Openclaw onboarding
# run cmd below in terminal on host
ifconfig | grep inet
# look for something like: `192.168.x.x`

pnpm openclaw onboard --install-daemon

During onboarding select:

Quickstart
Model: Ollama
Ollama base URL: http://INSERT_YOUR_MAC_IP:11434
Ollama mode: Local
Default model: ollama/mistral:latest

Skip the rest of the remaining steps for now: channels, search providers, skills, hooks, hatch mode.

Test it manually after installation

pnpm openclaw agent --agent main --message "Say hello in one sentence." --thinking low

It should work and you get a response back from the agent!

The OpenClaw dashboard is useful to monitor for statuses and logs. You can access it on port 18789.

Install the Telegram app on your device and create your bot using @BotFather

/start
/newbot

After the new bot is created BotFather will provide you with a bot token. Keep it safe as we will need it for later when configuring Openclaw.

Configure the experiment

From this point on, I will proceed with my own business logic for OpenBooks. But feel free to implement the business logic for your own application.

Need inspiration for your own experiments?
This useful github repo showcases many potential implementations made possible with Openclaw: https://github.com/hesamsheikh/awesome-openclaw-usecases

Step 1 — Configure native Telegram channel

Now that OpenClaw is installed and your bot is created via @BotFather, let’s connect Telegram.

Add your Telegram bot to your Openclaw config:

~/.openclaw/openclaw.json

"channels": {
  "telegram": {
    "enabled": true,
    "botToken": "INSERT_YOUR_BOT_TOKEN"
  }
}

Restart the gateway:

pnpm openclaw gateway restart

Send a message to your bot in Telegram. You should now get a response from OpenClaw.

Step 2 — Create BookBot agent + workspace

Instead of using the default main agent, we create a dedicated agent for our experiment.

pnpm openclaw agents add bookbot

Bind Telegram to this agent:

pnpm openclaw agents bind --agent bookbot --bind telegram
pnpm openclaw agents bindings

# You should see: bookbot <- telegram

Now configure the agent behavior via its workspace:

# SOUL.md

You are BookBot.

You are a Telegram book recommendation assistant.

Recommend 3 books in this format:

📚 Recommendations

1. Title — Author  
Why: short reason  

2. Title — Author  
Why: short reason  

3. Title — Author  
Why: short reason  

Rules:
- No long intro
- No tool descriptions
- Keep it concise

# AGENTS.md

Interpret the following as recommendation requests:

- recommend me a book
- what should I read next
- books for developers
- books like [X]

If the request is clear → recommend 3 books  
If vague → ask 1 short clarifying question

Restart the gateway and test in Telegram:

Recommend 3 books for software engineers

Step 3 — Test scheduling (simple cron)

Before doing anything complex, let’s just prove scheduling works.

Create a one-shot reminder:

pnpm openclaw cron add \
  --name "Test reminder" \
  --at "10m" \
  --message "📚 Reading reminder: ask BookBot for recommendations!" \
  --announce \
  --channel telegram \
  --to "INSERT_YOUR_CHAT_ID"

List jobs:

pnpm openclaw cron list

Test immediately:

pnpm openclaw cron run <JOB_ID>

You should receive a Telegram message confirming that cron works!

Step 4 — Daily recurring cron job

Now convert this into a daily habit (adapt to your tz)

pnpm openclaw cron add \
  --name "Daily reading reminder" \
  --cron "0 9 * * *" \
  --tz "America/Toronto" \
  --message "📚 Daily reminder: ask BookBot for 3 new book recommendations." \
  --announce \
  --channel telegram \
  --to "INSERT_YOUR_CHAT_ID"

Test it:

pnpm openclaw cron run <JOB_ID>

🎉 We are done!

You now have:

a local AI agent
connected to Telegram
powered by a local model
with daily automation

All running on your own machine, for free.

Start and stop the experiment

Note: the setup runs locally, meaning that if your machine or VM shuts off then Openclaw will stop working.

Here are some tips to avoid this:

On host:

caffeinate

Prevent VM from going to sleep by disabling systemd sleep:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Start Openclaw agent & detach using tmux (in VM):

sudo apt install -y tmux

tmux new -s openclaw

cd ~/openclaw
openclaw gateway start

Press CTRL + B, then D to detach

Stop Openclaw agent (in VM):

tmux attach -t openclaw
openclaw gateway stop

On your host don't forget to stop serving the model via Ollama and shut off your VM when not in use to free resources.

Troubleshooting

To avoid unnecessary model calls and background noise, and if there is no explicit need for it, I would recommend disabling the heartbeat via the OpenClaw config and relying on an explicit cron job:

...
"heartbeat": {
  "every": "0m"
}
...

Move from model-driven skills to tool-dispatched skills so they bypass the model and call a deterministic local tool instead. This improves accuracy of outputs. Getting deterministic outputs felt like a struggle with OpenClaw in general, this helps.
Create a dedicated agent + routing binding vs hijacking main agent for more specific logic

Glossary of OpenClaw commands I found useful

# Gateway
pnpm openclaw gateway start
pnpm openclaw gateway restart

# Agents
pnpm openclaw agents add bookbot
pnpm openclaw agents bind --agent <AGENT> --bind <CHANNEL>
pnpm openclaw agents bindings

# Cron
pnpm openclaw cron add ...
pnpm openclaw cron list
pnpm openclaw cron run <JOB_ID>

# Debugging
journalctl --user -u openclaw-gateway.service -f
pnpm openclaw doctor --fix

Future improvements

Improve functionalities, add memory capability to unlock insights
“Compare this book to the last 3 books I read”
“Turn my reading history into themes and recommendations”
Consider a hybrid strategy where the setup is less resource intense during day as I work in parallel on manual tasks, but more resource intense and high performance at night while I am asleep for longer experiments.

Discussions

What are you using Openclaw for?
What does your setup look like?
Any tips/hacks with Openclaw to share? I have only started exploring this tool :)

🦞 Thanks for following along, I hope you enjoyed this tutorial! 🦞

The Standup Chaos Simulator

Julien Avezou — Fri, 10 Apr 2026 16:12:44 +0000

This is a submission for the DEV April Fools Challenge

What I Built

Most of us have sat in standups that somehow consumed time, generated stress, and produced zero meaningful decisions. So I decided to make a useless app to remember these moments in all their chaos and glory.

Behold Standup Chaos Simulator, a web app that generates chaotic developer standups in a chat UI.

Pick your team.

Assign roles.

Choose how doomed the sprint is.

Select extra chaos events.

Watch the meeting unfold message by message like a live team sync that should probably have been async.

Once the fake standup finishes, the app gives you a Team Dysfunction Meter, lets you copy the transcript, and exports the whole thing as a shareable GIF.

Demo

standup-chaos-simulator.vercel.app

Code

https://github.com/JulienAvezou/standup-chaos-simulator

How I Built It

Next.js
TypeScript
Tailwind CSS
html2canvas
gif.js

No backend, no database, no auth, no LLM calls.

I used Codex as my coding assistant for this project.

Prize Category

Community Favorite - many of us share the pain of standups :)

Don't be late for standup!

Drop your most chaotic standup GIF in the comments.

Any missing features you would like to add to generate even more chaos?

And if you have any stories to share about your most memorable standup moments, I would love to hear them!

Building a coding course generator in public #1: The problem with learning to code today

Julien Avezou — Tue, 31 Mar 2026 13:32:09 +0000

If I had to learn how to code today from scratch, I’m not sure I would learn it properly.

Not because there aren’t enough resources.

But because there are too many shortcuts.

With AI tools everywhere, it’s never been easier to build apps without fully understanding what’s happening under the hood.

And honestly… that’s very tempting!

How I learned to code

My path was much more traditional:

I started with a bootcamp to learn fundamentals
Then I built projects to apply what I learned
Then I gained real-world experience in a company

The first two steps were what got me my first job.

They gave me something more valuable than just code:
intuition, structure, and confidence.

The problem today

Learning to code today often falls into two extremes:

Too theoretical → you get stuck in tutorials
Too shallow → you ship things without understanding them

AI has amplified the second path.

You can now build fast…
but you might hit a wall later when things break, scale, or need to evolve.

My idea

So I decided to build something to explore this problem:

👉 A course generator that teaches coding through:

hands-on project building
coding fundamentals
best practices

Not theory-heavy.
Not AI shortcut-heavy.
But something in between.

Building in public

Over the next few weeks, I’ll be sharing this journey publicly.

The goal is simple:

experiment
learn
share everything along the way

I also plan to open-source the app once it’s ready so anyone can:

run it locally
learn from it
build on top of it

There are no monetization plans or intentions here, this is purely an experiment.

Some interesting statistics

AI is making building software more accessible than ever.

180M+ developers on GitHub with 36M new developers joining yearly.

63% of Vibe Coders are Non-Developers.

Emerging concerns in Vibe Coding highlight that 40% of junior developers admit to deploying AI-generated code they don't fully understand.

Stack Overflow’s 2024 survey finds 82% of developers use online resources as a primary way to learn.

Why this matters (to me)

I believe we’re entering a phase where:

The bottleneck is no longer building…
it’s understanding what you built

And that’s where fundamentals and best practices still matter.

My goal is to help:

self-taught developers
AI-assisted builders
beginners who want to go beyond “vibe coding”

…develop stronger engineering intuition and build more sustainable products.

What’s next

In the next post, I’ll dive into:

the technical setup
early architecture decisions
constraints for keeping this lightweight and accessible

Here is a sneak peek of the home page in the meantime!

Discussion

I’d love to hear your perspective:

How are you currently learning or improving your coding skills?
What’s your setup when building with AI tools?
Would you use something like this? Why or why not?

Data Sources: GitHub Octoverse 2025, Gartner, JetBrains Developer Ecosystem, Course Report, Second Talent Vibe Coding Statistics, McKinsey AI Survey. Report generated with Perplexity on March 18, 2026.

Why hiring junior developers pays off more than you think (I’ve lived it firsthand)

Julien Avezou — Wed, 25 Mar 2026 12:56:27 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

A trip down memory lane

I still remember my final interview.

It wasn’t a coding challenge or another algorithm question.

It was just a conversation.

We talked about my background in business and finance.
The internships I had done.
The projects I had built, including a drone media company and a project management app I had sold to an architecture firm in Belgium.
My short experience as a product manager in a startup.

Compared to the previous rounds that were full of logical tests, coding exercises, and pair programming, this one felt different.

I wasn’t trying to prove I could code but just talking about my life.
I was showing how I think, how I learn, and how I approach problems through my past experiences.

A week later, I got the offer.

Not for a standard role, but for an engineering graduate program.

And looking back, that moment changed everything...

The fast track wasn’t accidental

I went from coding bootcamp to senior software engineer in just over 5 years.

I worked hard.
I built side projects.
I kept learning constantly and found great mentors.

But the biggest accelerator early on?

The structure and exposure from that graduate program.

It gave me:

exposure to different teams and problem spaces
hands-on experience across technologies
a safe environment to learn fast and make mistakes
a cohort of peers growing at the same pace

Over the following years, I noticed something interesting.

Many of the highest-performing engineers in the company came from that same graduate track.

Not just technically, but in how they contributed to culture, collaboration, and leadership.

Why junior engineers outperform (when given the chance)

From what I observed, graduate engineers tend to overperform for a few key reasons:

They’re hungry
We were eager to prove ourselves. Every task mattered.
They learn fast
Coming from bootcamps or self-taught paths, learning was already part of our identity.
They bring different perspectives
Many of us didn’t come from traditional CS backgrounds.
We approached problems more practically, often with product or user context in mind.

That mix created strong synergies within teams:

theoretical depth from experienced engineers
practical execution and fresh thinking from juniors

And the ROI for companies is real

Investing in junior developers is a healthy strategy.

Here’s what I saw:

High employee retention
When a company invests in you early, you stay. Trust goes both ways.
Stronger leadership pipeline
Training juniors forces senior engineers to mentor and that builds leadership skills fast.
More diversity in hiring
In my experience, graduate programs brought in more women and more diverse backgrounds than traditional hiring pipelines.
Stronger engineering culture
A company known for growing talent attracts better people over time.

What helped me go from junior to senior

On a more personal level, here are a few learnings that made a big difference for me in the last years:

Leverage your non-technical strengths
My background in business and product helped me early on.
I contributed through communication, organization, and initiative, not just code
Adopt a T-shaped development approach
Go deep in one area, but stay curious across others.
Be visible
Share your work. Communicate progress. Talk about impact.
Silence slows your growth.
Document your journey
I kept a developer journal to track what I learned and achieved.
This helped massively with confidence, reflection and arguing my case at promotion rounds.
Build relationships
Inside and outside of work. Your network compounds just like your skills.
Get involved beyond your team
During my time at the company I:
- spoke at internal conferences
- contributed to the engineering blog
- joined hackathons
- participated in threat modeling sessions

The human side of growth

When I left the company, what struck me the most wasn’t the projects, nor the crazy amount of merch I had accumulated over the years...

It was the people.

At my farewell drinks, many of those who showed up were from my original graduate cohort.

We had all grown not just as engineers, but as people.

And that’s when it really hit me:

The real ROI of investing in juniors isn’t just technical output.
It’s the humans you nurture and the culture you foster over time.

Why I’m sharing this

Two reasons.

1) For companies
Cutting junior roles because of AI-driven productivity gains is a short-term decision.

From what I’ve witnessed, it’s a mistake.

The long-term ROI of investing in junior engineers, especially through structured programs, is massive.

And much of that value is human, not just technical.

2) For those on non-traditional paths
If you’re coming from a bootcamp, self-taught journey, or an “irregular” background suffering from imposter syndrome:

That’s not a weakness.
It’s your edge.

We live in a time where different perspectives are more valuable than ever.

Lean into them. Keep building. Keep learning.

None of this happens alone.

This is also a thank you to everyone who helped me along the way:

mentors
managers
teammates
fellow builders
friends and family

💬 Discussion

I’m curious to hear your thoughts:

Have you seen junior developers outperform expectations in your teams?
Are companies underinvesting in junior talent today?
How has AI changed (or not changed) the value of hiring juniors in your experience?
If you’ve gone through a graduate program, did it accelerate your growth?
For senior engineers: how has mentoring juniors impacted your own development?

A 1-hour experiment: vibe-coding an app to break the ice at a networking event

Julien Avezou — Fri, 20 Mar 2026 13:45:50 +0000

It’s 5pm. My event starts in an hour.

Plenty of time to build an app, right?

I’m currently exploring a new project idea. Still early, still messy.

One of the most common pieces of advice when building a product is to validate early by talking to potential users.

So I thought: why not use this networking event to start?

The problem is, walking up to people and asking them to answer questions about your idea can feel awkward.

I wanted something lighter. Something that would make the interaction feel natural instead of forced.

So I built a simple app.

A spin-the-wheel game where people could either:

win a prize
or answer a short survey

It may or may not have been slightly rigged 🤫

But the goal wasn’t the prize.

It was to create a moment.

A small interaction that lowers the barrier, gets a smile, and opens the door to a real conversation.

And surprisingly, it worked.

It made approaching people easier, sparked a few genuinely interesting discussions, and helped me collect my first real signals on the idea.

The quick technical setup

I used:

ChatGPT for ideation
Codex for implementation

Stack:

Expo
React Native
TypeScript
React Navigation
AsyncStorage

Here is me setting the content with Chat:

After the ideating, I find it useful to generate the prompts for Codex from Chat so I can just paste them over sequentially:

Then the implementation happens with Codex:

The app itself was simple:

wheel screen
short survey
responses view
profile screen with a QR code for LinkedIn

Expo Go was what made this possible in such a short time. Instead of building a full native app, I ran the Expo dev server locally and opened the project on my phone through Expo Go.

In practice, Expo Go provides the native container, while my app code is loaded as a JavaScript bundle from the local development server. That meant I could build and test the app on a real device almost instantly, without dealing with native build setup.

For a low-stakes prototype like this, that tradeoff was perfect:
fast iteration, real-device testing, and just enough functionality to get the job done.

Here is a quick visual recording of the app itself:

Learnings from this experience

For me, this is a great use case for vibe coding: building a very low-stakes prototype that solves a simple problem and can be put together quickly.

It also reminded me that small tools can make everyday situations more interesting. Sometimes the best projects are not the most ambitious ones, but the ones that make a real interaction easier, lighter, or more fun.

Discussion

How do you approach networking in a more natural way?

Do you have any original tactics/stories to collect customer interviews?

And how are you using vibe coding in your day-to-day?

I’ll introduce the project I am ideating for in my next post, document the learnings as I go, and eventually open-source the project so others can learn from it, reuse it, or take it further.

If you had to guess, what do you think this project is about?

Curious to hear your thoughts 🙂