Forem: Julien Avezou

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 🙂

Autonomous AI Research Does Not Need a Giant Framework

Julien Avezou — Thu, 12 Mar 2026 12:45:10 +0000

A lot of the conversation around AI agents has drifted toward increasingly complex frameworks, orchestration layers, memory systems, and multi-agent abstractions. At the same time, a quieter and more interesting movement is emerging: small, purpose-built loops that optimise for one thing well.

That is what drew me to autoresearch, an open-source repo created by Andrej Karpathy and published very recently, which has drawn a lot of attention this week in the field of AI.

Why is autoresearch important?

At its core, autoresearch is a very simple idea: give an agent a real training loop, let it make small changes, run short experiments, evaluate results, and keep iterating in a self-contained setup. No huge platform or any over-engineered agent stack. Just a tight feedback loop around real model training.

That simplicity is exactly what makes it so appealing. Just a couple hundred lines of Python...

autoresearch is built around three important files:

prepare.py: handles one-time data preparation, tokenizer setup, and runtime utilities
train.py: the main training file that the agent is allowed to modify
program.md: the instruction file that defines how the agent should behave during the experiment. You define this.

The agent reads program.md, modifies train.py, runs training, checks metrics, and decides what to do next.

This strips autonomous research down to its essence. Instead of building a huge agent framework first, you start with a minimal loop that already does useful work.

It is a good reminder that progress in agentic systems may come less from adding more layers and more from building tighter, more disciplined loops.

My idea

I wanted to run a real autonomous research experiment locally, on my own machine, with minimal infrastructure and no cloud GPU dependency.

My constraint was simple:

run on my MacBook Pro
use CPU only
keep it practical
generate insight, not just raw performance chasing

That led me to an experiment around reflective iteration.

My experiment question was:

Does adding a structured self-reflection step help an autonomous agent make better model improvement decisions over time?

The setup compared two loops:

A: non-reflective loop
B: reflective loop

The difference was small but important.

In mode A, the agent simply proposed the next change from a fixed queue and ran it.

In mode B, the agent first reflected on the previous result in a structured way before choosing the next change.

The goal was not only to improve validation performance, but to test whether reflection improved the quality of experimental decision-making.

How I set up my experiment

If you want to run this on a MacBook like I did, the easiest starting point is this fork.

The steps I followed:

Fork the repo to my own GitHub account and clone it locally.
Open the repo with my coding agent or assistant.

For this setup, I used Codex 5.3 with medium reasoning depth. It was especially useful for planning, checking dependencies, repository structure, experiment constraints, and execution.

Prepare the experiment.

Verify that all dependencies are installed and that all prerequisite training steps are ready

Define the experiment in program.md.

What worked well for me was not replacing the original file, but enhancing it. I created a standalone experiment definition and combined it with the base repository rules, so I could preserve important constraints from the original setup.

Optimise my execution environment.

After defining the experiment, I asked Codex to help me refine the setup without changing the actual experiment design.

The idea was to keep the experiment logic in program.md, and use setup prompts only for execution environment and setup discipline.

This approach kept the repo simple and prevented setup conversations from contaminating the actual experiment logic.

Run the experiment loop itself.

Once everything was ready, the experiment loop was straightforward:

the agent edits train.py
the run executes
results get logged
the next run is chosen
the loop repeats

What mattered most was keeping each change small and isolated so the outcomes stayed interpretable.

Some practical tips

For longer experiments, I strongly recommend hardening the execution environment a bit. My practical setup for a long-running experiment was:
- tmux to protect against terminal closure
- caffeinate to prevent the Mac from sleeping
- log files for crash visibility
- nice to slightly reduce CPU priority
- laptop plugged into power
- heavy apps closed

This is a setup I will reuse for local long-running agent experiments going forward.

Explicitly tell your coding assistant that you want the full experiment to continue automatically without manual input. In my case, it set up a runner script so I could let the experiment continue while I worked on other things.
Also tell it to provide regular status updates. That makes the process much easier to monitor over time.

Experiment results

Here are the results from the experiment:

Baseline:
val_bpb = 1.622929
lower is better

Comparison outcomes:
Best A (non_reflective): 1.623505
Best B (reflective): 1.621094

Runs to beat baseline:
A: never beat baseline
B: beat baseline on B01

Improvement ratio:
A: 0/5 = 0%
B: 3/5 = 60%

Average runtime:
A: 501.38s
B: 478.14s

Iteration quality trend:
A: flat at 0.50 every run
B: consistently high at 0.93-1.00, average 0.944

This was a small experiment but it showed something meaningful.

Under this CPU-constrained local setup, structured reflection improved the quality of the agent’s decisions. The reflective loop not only produced better validation outcomes, it also got there faster and with a much cleaner iteration pattern.

So the takeaway is not just that reflection helped performance.
It helped reasoning quality and efficiency. And it produced a more coherent experimental trajectory.

The best reflective run converged on a small set of parameter changes that outperformed baseline:

Reflection is a habit I have been practicing as an engineer which has helped me with my career and personal growth. Agents seem to agree with this...

Why I think this matters

The most interesting thing about this experiment is not the absolute performance gain. It is the fact that a lightweight, local, interpretable agent loop was able to produce measurable differences in research behavior so quickly.

That suggests a useful direction for agentic AI work:

less framework overhead
tighter loops
better constraints
clearer reasoning
more emphasis on experiment quality, not just experiment quantity
more focus on setting up an optimised evaluation function

If that direction holds up in larger studies, it could become a more practical path for real-world autonomous research systems.

What I want to try next

The next obvious step is scale.

I want to rerun this experiment with a much larger run budget, probably around 80+ runs, to see whether the signal strengthens or weakens over longer search trajectories.

That would make the conclusion much more robust.

This was a small pilot, not a definitive benchmark. The comparison used 5 runs per mode on a single local machine, so I treat the outcome as directional evidence rather than proof. Still, the signal was clear enough to justify running a larger follow-up.

Discussion

Have you tinkered with autoresearch yet? What do you think of the approach? What would be some useful experiments to run with this setup?

Also, what does your agentic setup look like today? I am curious to know.

Turning Community Event Downtime Into Interaction With a Live Heatmap App

Julien Avezou — Sun, 01 Mar 2026 23:12:39 +0000

This is a submission for the DEV Weekend Challenge: Community

I’m travelling this weekend, so this post is shorter than I would have liked.

To get this challenge on time, I leaned heavily on Codex 5.3 for the heavy lifting. Realistically, I would not have had enough time to complete it otherwise.

I am overall happy how this app landed (no pun intended).

Here is a photo of me building on the plane if you don't believe me!

The Community

This idea is inspired by the local tech communities I attend in Toronto.

At many events, there’s a window of time where people are arriving, getting seated, and waiting for things to begin.

Nothing is happening yet, but everyone is physically there.

I feel that is a missed opportunity.

I wanted to build something simple that gives event guests a reason to participate immediately. With this app, organizers can put a live prompt on screen and let attendees answer a short set of questions from their phones. The responses roll up into a live “heatmap” view for the room.

It gives people something lightweight and interactive to do while they wait, and it naturally creates conversation. If the room can see how other people are feeling about a topic, that often becomes an easy social entry point before the event even starts.

What I Built

The app is intentionally simple.

First, the organizer creates a session and adds a short title plus a few questions.

Those questions can be:

yes/no
a rating from 1 to 5
a single-choice question with a few options

Once the session is created, the organizer gets a host screen with a QR code and a join link.

Attendees scan the QR code, answer the questions on their phones, and submit their responses.

As responses come in, the host screen shows the number of participants. When the organizer is ready, they hit Reveal, and the results appear as simple charts for everyone to see.

So the flow is:

Create a session.
Share the join link or QR code.
Collect responses.
Reveal the aggregate results live.

No accounts, no logins, no personal data collection. Just quick participation.

Demo

Code

The code can be found here
Instructions are provided on how to run the app locally to try it out.

How I Built It

I built this with Remix, Cloudflare Pages, a separate Cloudflare Worker, and a Durable Object.

On the UI side:

Remix handles the pages and form actions
Recharts renders the result charts
qrcode.react renders the QR code on the presenter screen

On the backend side:

A Cloudflare Worker exposes the session API
A Durable Object stores each live session’s state

This stack was chosen because of the following:

The product itself is event-oriented: short-lived sessions, lightweight state, and fast interaction. Durable Objects are a strong fit for that because each session can map cleanly to a single stateful object.
Cloudflare keeps the deployment model simple. Pages is a good fit for the frontend, Workers are a good fit for the API, and the integration between them is straightforward.
The app doesn’t need a traditional database or a complicated backend architecture. I only needed:
session creation
response counting
reveal state
aggregate results

That made a Worker + Durable Object model much more appealing than spinning up a heavier stack.

The app has two parts.

The first part is the Remix frontend:

a page to create a session
a page for attendees to join and answer
a presenter page to monitor and reveal results

The second part is the backend Worker, which owns session state through a Durable Object.

Each session gets its own Durable Object instance.

That Durable Object stores:

the session title
the questions
the participant count
whether results have been revealed
aggregate answer counts

A key design choice is that the app does not store raw individual submissions long-term. When someone submits answers, the backend validates them, increments the correct aggregate counters, increments the participant count, and discards the raw response payload.

That keeps the system intentionally lightweight and privacy-friendly.

The presenter screen uses polling every two seconds to refresh:

participant count
reveal status
aggregate results (once revealed)

So there are no websockets here. The screen simply asks the backend for the latest snapshot on a fixed interval.

The backend routes are simple:

create a session
fetch session metadata
submit answers
reveal results
fetch aggregate results

That’s enough to support the full experience without adding unnecessary complexity.

Closing thoughts

If I had more time, I’d probably add:

better visualizations
themed event templates
question packs for different types of events
smoother host controls
a save function of the final heatmap snapshot for the presenter

But for a weekend build, especially one assembled while travelling, I’m happy with where it landed (this pun was too good not to be used twice)!

The Increasing Need for Human Connection in the Age of AI

Julien Avezou — Tue, 24 Feb 2026 12:02:47 +0000

Is it just me, or are tech events and communities on the rise?

I’ve been thinking about this lately, and I’d genuinely love to hear your experience too.

I recently moved to a new city and started attending local tech events. My motivations were simple: I wanted to build a network, connect and exchange ideas with people who share similar interests (and maybe the occasional free pizza…).

As I’ve been going through this process, I’ve noticed something interesting. Event attendance seems to be increasing, especially tech-related ones.

It made me wonder: could this be connected to the rapid rise of AI adoption?

Here are a few thoughts I’ve been reflecting on.

Lower barriers, broader audiences

AI has dramatically lowered the barrier to building software.

People from different backgrounds and skill sets can now prototype and ship ideas faster than ever before. That naturally attracts a more diverse group of builders such as designers, operators, marketers, students, domain experts etc. All curious to experiment.

More builders lead to more curiosity, which in turn leads to more demand for spaces to connect.

Tech events become natural gathering points.

The rise of “build and demo” culture

AI enables extremely fast execution.

I attended an open build event last weekend where we had just under a 2 hours to create and demo working products! A few years ago, that kind of turnaround would have been unrealistic for most people.

“Vibe coding” and AI-assisted development make it possible.

But here’s the interesting part: speed creates output, yet output still needs validation.

When you build fast and mostly solo, you still need others to:

react
challenge
validate
question

Those in-person interactions build trust in a way that’s hard to replicate alone behind a screen.

Shared meaning in a hyper-fast world

AI allows individuals to ship at incredible speed.

But meaning is rarely created in isolation.

If everything becomes hyper-efficient and personalized through AI tooling, we may paradoxically crave shared experiences even more. Community events might be a reaction to that acceleration as a way to ground our work in something social and collective.

We don’t just want to ship.
We want to feel that what we’re building matters to someone.

Fear, identity, and uncertainty

There’s also a more emotional layer.

AI is reshaping jobs, workflows, and even professional identity. That creates uncertainty, fear and questions about long-term relevance.

In times of rapid change, humans naturally move toward connection.

We seek reassurance, belonging and perspective.

Communities provide psychological stability in unstable times.

Empathy as a competitive advantage

Building sophisticated AI systems isn’t just about logic.

Empathy, human judgment, and vulnerability matter deeply.

If we want AI systems that align with human values, we need rich human experiences feeding into them. Pure rationality isn’t enough. Understanding nuance, context, and emotion requires exposure to real people.

Connecting with others doesn’t just make us better professionals, it might also help us shape more human-centered AI in the long term.

AI may democratize cognitive power.
Human connection contextualizes it.

The remote work effect

And of course, we can’t ignore the post-pandemic shift.

With the rise of remote and hybrid work, many of us spend more time physically isolated. Even if we’re constantly “connected” online, it’s not the same.

There’s something uniquely energizing about eye contact, spontaneous conversations, shared ideas and laughter.

I want to say that online communities, such as dev.to (which I genuinely cherish) create amazing connection. However physical presence adds another layer that’s harder to replicate digitally.

Personally, I feel lucky to experience both.

I’m curious:

Do you notice similar trends where you live?
Do you see increasing value in local tech communities?

And if you happen to be in Toronto, where I’m currently based, I’d love to hear your recommendations or even meet up at an event sometime!

I Tried Coding With AI Glasses. Here’s What Actually Happened.

Julien Avezou — Tue, 17 Feb 2026 13:16:09 +0000

I was recently gifted a pair of AI glasses. This is not the kind of purchase I would make for myself. But since I now own a pair, I saw this as an interesting opportunity to assess whether these glasses could improve my daily life as a developer.

Initial experiments

The first thing I tried was using the integrated AI to ask me to explain code on my screen. The results were… disappointing. I tried different situations:

Explaining a simple HTML file
Debugging a specific line of code
Providing context-aware explanations

It couldn’t reliably identify what I was looking at. It lacked precise understanding of the visual context.

I started thinking about a better pipeline:

Capture frame from glasses camera
Apply OCR to extract visible text
Feed image + extracted context into a capable vision model
Send result to an LLM
Return explanation as audio through the glasses

In theory, this could turn the glasses into a real-time coding assistant. However this felt like too much work, complex and expensive. And less reliable than simply prompting an assistant directly inside the editor.

A different idea: Life commits

That’s when I realized something.

Maybe AI glasses aren’t useful because they help you code better. Maybe they’re useful because they help you understand yourself better.

So I tried something different.

What if I used my glasses to capture my life? I call them life commits. Just like Git commits capture the evolution of code, life commits capture the evolution of your day.

It is very seamless to take photos with your glasses on the fly, unlike a phone which you need to take out of your pocket, creating friction.

The idea is simple:

Every hour, the app prompts you to capture a moment.

The captured image is automatically classified using Apple's Vision framework:

VNClassifyImageRequest()

This allows categorization of environments like:

workspace
outdoors
social
exercise
indoors
screen time

Then, I associate an emotional score with each moment.

This can be done in two ways:

Hand gestures, detected using:

VNDetectHumanHandPoseRequest()

Or manually, through the app.

Over time, this creates a timeline of:

where you spend your time
what environments you inhabit
how those environments correlate with your emotional state

The insights and patterns could be interesting to look at over time to improve your daily life and improve your emotional state.

Here is a demo of the flow I built:

Here is the working prototype to test this idea: https://github.com/JulienAvezou/ai-glasses

Would I recommend buying AI glasses?

I surprisingly enjoy listening to music through my glasses. While it doesn’t replace a comfy headset, it’s nice to hear music clearly without having anything on or above your ears.

Prompting the AI to provide simple explanations while coding is nice too, as it’s very convenient to just have a conversation on the go whether at the desk or moving around.

The ease of taking photos or videos on the fly is nice too.

But right now, AI glasses still feel like early hardware.

Not useless. But not essential.

They don’t fundamentally change how I code.

But they do change how I capture and reflect on my life.

That might be their real potential.

So what do you think? Gadget or useful?

Curious to know if someone out there is actively using AI glasses.

How do you incorporate them into your daily routine? (exercising, coding, …)

Using AI to Build a Tool That Stops Me From Blindly Using AI

Julien Avezou — Fri, 13 Feb 2026 21:04:23 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I vibe coded ReflectCLI! A tool to promote thoughtful coding through structured reflection. Before each commit, answer reflective questions to build your personal developer knowledge dataset.
I fully leaned into Github Copilot CLI to build this tool so I could assess its capabilities fully. It's also a tool I wanted to build for a while but didn't have the time due to other ongoing projects. This was a perfect opportunity to make it a reality!

Tech Stack

Language: TypeScript
Runtime: Node.js 18+
CLI Framework: inquirer.js
Testing: Jest
Linting: ESLint 8 + Prettier
CI/CD: GitHub Actions
Build: TypeScript compiler

Why I built this?

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.

One could argue that good engineers already reflect when writing PR descriptions. But PR descriptions happen after the decisions are made.
git-reflect happens while those decisions are still fluid. It’s the difference between explaining your thinking and improving it.

Demo

The process is simple:

Install the hook:

git-reflect install

Make changes and commit:

git add .
git commit -m "Your commit message"

Answer reflection questions — You'll be prompted with 7 thoughtful questions before the commit completes.
View your reflections:

cat .git/git-reflect/log.json | jq .

Here is the full flow in action:

And here is the stored reflection log:

My Experience with GitHub Copilot CLI

Ease of setup. I was ready to go in just a few minutes.
The plan mode was particularly impressive. It helped establish a clear, structured plan with distinct phases, which made the implementation phase much easier. The clarifying questions Copilot asked to define the scope were thoughtful and helped sharpen the direction of the project.

During implementation, the level of control and transparency stood out. Permissions were granular, and the execution steps were very transparent, allowing me to follow along closely and ensure the right changes were being made.
I appreciated the PROJECT_SUMMARY generated at the end. It included useful metrics such as lines of code, files created, number of commits, and total implementation time. This made the process feel tangible and measurable.

Troubleshooting was also a very positive experience. When I realized parts of the hook were not working correctly, I resumed the Copilot session and described the issue. Copilot resolved multiple problems on the first attempt and provided clear explanations of what went wrong, which made it a valuable learning experience.

Having everything happen directly from the CLI felt seamless. It allowed me to stay in flow and complete the project from start to finish without constantly switching contexts or windows.

Overall, a fun experience that made me realize (again) how efficient coding assistants are becoming. I was able to plan and execute on this idea in just a few hours!

If you are interested in the code and want to try it out on your own machine, check out my repository on Github.

Repo: https://github.com/JulienAvezou/ReflectionCLI/blob/master/README.md

If you have any questions or can think of areas for improvement/feature ideas, do share!

Why Learning Basic Robotics Made Me a Better Software Engineer in the Age of AI

Julien Avezou — Tue, 10 Feb 2026 13:41:01 +0000

I recently bought a starter kit for Arduino to learn robotics. I was curious to learn some basic concepts and get inspired by what's possible to build, not just in software but also in the physical world. I want to emphasize that my current goal is not to pursue robotics at a deep level, it's simply to expose myself to the basic concepts so I can develop my intuitions for the field.

As I wrap up the course, I wanted to share my thoughts on how learning robotics has been valuable for my developer journey, especially in this age of AI.

Before I share my thoughts, some context for those interested in what the kit is about. The course included in the kit consists of a series of Arduino projects that gradually build upon each other with clear explanations, schematics, and code examples. The projects ranged from powering a single LED to setting up more complex systems involving motors and IR sensors.

Here is a photo of me tinkering away. In my head, I felt like Tony Stark. The reality was far more humble... But hey, you have to start somewhere!

My thoughts after completing this course:

It strengthens core foundations.
Pursuing robotics requires you to engage with mathematics, physics, and electronics in a concrete manner. These foundations build thinking patterns that are useful for software engineering.
It helps build intuitions for working with non-deterministic systems just like AI systems.
Robotic systems don't always behave predictably. Sensors introduce noise. Motors behave inconsistently. Timing matters. Multiple variables interact simultaneously. Continuous feedback loops (observe, decide, act) are central for robotic systems. We are increasingly seeing these feedback loops in AI systems, especially agentic workflows.
It develops systems-level thinking.
An increasingly valued skill for software engineers in the age of AI is the ability to reason with systems such as control systems, embedded systems, feedback systems. Robotics helps develop intuitions around building systems.
It feels very tangible.
The software you write translates into physical movement, sound, light. This is very satisfying to experience.
It's simply fun. Maybe I should have just started with this point. If you like building things you will find this entertaining. Sometimes that's all you need to pursue something.

Robotics reminded me that great engineers don’t just understand code. They understand systems. And in the age of AI, systems thinking is becoming one of the most valuable skills we can develop.

Discussions

Have you explored robotics as a software engineer?
Did it change how you think about systems, software, or AI?

Curious to hear from both robotics engineers and software engineers who have explored this path.

Build Your Own ChatGPT App (Run It Locally)

Julien Avezou — Wed, 04 Feb 2026 14:07:48 +0000

ChatGPT recently opened submissions for their Apps feature to developers, which is a way to display interactive widgets from third-party apps directly into conversations. This opens up interesting opportunities to enhance user experience directly within ChatGPT by offering more than just text interactions.

In this article, I will share my experience exploring this feature so you can easily test and create your own ChatGPT App locally to get started.

I will start by outlining the basics of what a ChatGPT App is and how it works. I will then offer a step-by-step tutorial on how to quickly get started with your own ChatGPT App locally for quick prototyping and experimentation.

What is a ChatGPT App?

A ChatGPT App is an interactive widget that appears directly within the chat from the conversation context or manual triggering.

It can be broken down into 3 main components:

MCP Server - The backend that defines tools which you can think of as functions the model can call (in this case ChatGPTs), and resources (UI templates that ChatGPT renders).
Widget - HTML that runs in a sandboxed iframe with its own state, event handling, and direct communication with your backend through the window.openai object that ChatGPT injects. This object offers different interaction options such as direct tool calls (window.openai.callTool()) or a follow-up message (window.openai.sendFollowUpMessage()) which sends a message back into the chat to keep the conversational loop going.
ChatGPT - The host which orchestrates the tool calling, rendering of the widget and the conversation state.

An example of a tool definition is as follows:

Tool: find_houses

# Description used by ChatGPT to decide when to trigger the tool
Description: "Finds houses by location and number of rooms"

# Inputs schema outlines the parameters
Inputs: location (required), number_rooms (optional)

# Outputs defines which resource to render with the data as UI
Output: → ui://widget/list.html

It is useful to visualize the full flow as a diagram:

Let's now build our own ChatGPT App

Here is a simple example of a ChatGPT App I built for local testing. It's open source so you can use the repo as a template as we move along this tutorial.

Let's create the App

The repo structure will look something like this:

chatgpt-app/
├─ public/
│  └─ widget.html
├─ server.js
├─ package.json
└─ README.md

Create your files and adapt your own logic for the widget and server. For the server, register the tools and resources you want. For the widget add the UI elements, state and event handling you want. Please refer to the files in my open source repo for inspiration if needed.

Let's run the App

ChatGPT needs an HTTPS URL to reach our local server. For this tutorial we will use ngrok to provide us with an HTTPS URL.

# 1) create repo + install
npm install

# 2) run local MCP
npm run dev

# 3) in another terminal
ngrok http 8787
# copy https://....ngrok.app and add /mcp

Let's connect this App to ChatGPT
You first need to enable developer mode for ChatGPT. This allows you to add unverified connectors. Memory is disabled in this mode.
Settings > Apps > Advanced settings > Developer mode (toggle)

You can then create your App (ie. establish the connection between your MCP server and the ChatGPT host)
Settings > Apps > Create App

In the form, the connector needs to point to the HTTPS URL from ngrok with /mcp, for eg. https://abcd-1234.ngrok.app/mcp
For this demo we will choose 'no authentication'.

Let's trigger the App
ChatGPT can surface an App based on context or explicit tagging.

And there you go! You should now have your own ChatGPT App running locally. 👏👏👏

Before we end, here are a couple of learnings based on personal experience developing my App:

due to caching, I often found it faster to delete the connector entirely and establish the connection again instead of trying ot figure out which parts of the UI or metadata were cached
I caused unnecessary re-renders and behavior that was hard to debug when I leaned heavily on tool calls for state updates. Moving more state locally to the widget made the setup more reliable.

This tutorial is intentionally limited to local development and fast prototyping. It therefore doesn't cover important aspects such as security, authentication, in-depth state management and privacy which are necessary before moving to production. So I strongly advise you to read the official documentation and implement best practices to mitigate any risks before going live. A few considerations on top of mind include idempotent calls, rate limiting and robust error handling.

With over 800 million weekly active users on ChatGPT, ChatGPT Apps could be a huge opportunity for developers to tap into.

What do you think? Is this just another feature or do you see potential in developing your own ChatGPT App?

Forem: Julien Avezou

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

Setting the scene

Optimising available resources

1. Free SSD space

2. Free RAM

Install tools

Configure the experiment

Step 1 — Configure native Telegram channel

Step 2 — Create BookBot agent + workspace

Step 3 — Test scheduling (simple cron)

Step 4 — Daily recurring cron job

Start and stop the experiment

Troubleshooting

Glossary of OpenClaw commands I found useful

Future improvements

Discussions

The Standup Chaos Simulator

What I Built

Demo

Code

How I Built It

Prize Category

Don't be late for standup!

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

How I learned to code

The problem today

My idea

Building in public

Some interesting statistics

Why this matters (to me)

What’s next

Discussion

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

A trip down memory lane

The fast track wasn’t accidental

Why junior engineers outperform (when given the chance)

And the ROI for companies is real

What helped me go from junior to senior

The human side of growth

Why I’m sharing this

💬 Discussion

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

The quick technical setup

Learnings from this experience

Discussion

Autonomous AI Research Does Not Need a Giant Framework

Why is autoresearch important?

My idea

How I set up my experiment

Some practical tips

Experiment results

Why I think this matters

What I want to try next

Links

Discussion

Turning Community Event Downtime Into Interaction With a Live Heatmap App

The Community

What I Built

Demo

Code

How I Built It

Closing thoughts

The Increasing Need for Human Connection in the Age of AI

Lower barriers, broader audiences

The rise of “build and demo” culture

Shared meaning in a hyper-fast world

Fear, identity, and uncertainty

Empathy as a competitive advantage

The remote work effect

I Tried Coding With AI Glasses. Here’s What Actually Happened.

Initial experiments

A different idea: Life commits

Would I recommend buying AI glasses?

Using AI to Build a Tool That Stops Me From Blindly Using AI

What I Built

Tech Stack

Why I built this?

Demo

My Experience with GitHub Copilot CLI