Lazy Scripts: my path to understand (a little bit) AI in my developer workflow

Cesar Bouli — Sat, 06 Jun 2026 12:07:34 +0000

I have a small repository called lazy-scripts.

At first, it was exactly what the name says: a bunch of lazy scripts. Nothing fancy. Some helpers to clean my Python environment, create a simple sandbox folder to make tests, and automate things I repeat too much in my daily developer life.

But after some time, this repository became something different for me. It became the place where I started to understand how I can really use AI as a developer, not only as a chat where I ask questions and copy code.

The beginning: simple scripts

The first idea was very practical.

I wanted commands that save me small amounts of time:

create a disposable development sandbox;
clean generated files from projects;
copy some reusable GitHub Actions workflows;
make repetitive local tasks easier.

This is still the base of the repository. I do not see it as a professional CLI product. It is more like my personal toolbox.

Today the repository has commands like:

bouli-sandbox, to recreate a local sandbox and open it in VS Code;
dev-garbage-collector, to clean Python, JavaScript, and Go generated files;
dev-lazy-gh, to copy reusable GitHub Actions workflows;
ai-sbx-codex, to start Codex inside an sbx sandbox;
ai-sbx-opencode, to start OpenCode inside an sbx sandbox;
ai-ralph-codex, to run my Ralph workflow with Codex.

The interesting part is that the repository history shows my own learning path. It started with simple shell scripts, and slowly became a place to test AI workflows with more control.

First contact with AI coding

Like many developers, I started using AI in the most obvious way.

I was creating code in a chat, copying it, downloading files, testing locally, asking again, fixing again.

It worked, but it was not a real workflow. It was more like using a very advanced autocomplete outside of my project.

After that I installed the Claude plugin in VS Code. The results were interesting, but I had a problem: I did not really like the code. Sometimes the code worked, but it did not feel like my code. Sometimes the price question also started to appear in my head.

Then I started looking more seriously into local AI.

Local AI: Cline, Ollama, Qwen

The idea of local AI was very attractive to me:

more control;
more privacy;
controlled price;
the possibility to experiment without thinking all the time about tokens.

So I started to play with Cline CLI, Ollama, and a Qwen model.

The results were interesting, but there was still something missing. The model could do things, but it did not always understand the project as I expected. And my programmer brain was still thinking like a classic programmer: architecture, small changes, review, responsibility.

At the same time, I was trying to understand how other programmers were using AI. This is not easy. There is a lot of content, but also a lot of hype. After some research, I found a video that finally gave me useful ideas about workflow: what a skill is for, who Ralph is, and why the process matters more than only the model.

That changed my focus.

The important question stopped being:

Which AI tool writes more code?

And became:

Which workflow helps me understand and review the code that is being created?

The problem with too much freedom

I tried Claude again later, and again I found something I did not like.

It started touching things I did not ask for. Worse: things outside of the project folder.

For me this is a big problem.

I want AI to help me develop, but I do not want to give it the same freedom I have on my machine. My computer is not the project. My repository is the project.

This is where the sbx command changed things for me.

With Docker sandboxing, I started to believe more in the workflow. The agent can work, but inside a controlled environment. This made the idea much more acceptable to me.

OpenCode, Codex, and the difference between planning and building

After that I tried OpenCode.

For me, the results were better than Cline. Still not perfect, but better. And working with these open source tools helped me understand something important: there is a difference between planning and building.

Sometimes I do not want the AI to change code yet. I want it to understand the project, create a PRD, suggest issues, split the work.

Only after that I want the implementation.

This is where Codex started to make sense for me. With all the previous learning, using Codex + a paid account felt much more useful. Not because now I can "vibe code" everything (I definetely can't), but because I finally had a process around it and that helps not just to make the things more understandable, but "cheaper" as well.

My current workflow

Nowadays, when I want to improve one of my personal projects, I usually follow this path:

I start with a clean repository, with no pending commits.
I ask the agent to check the repo and create a PRD.md file.
I explain my idea and ask for possible issues.
I review the issues to see if the direction is OK.
I ask the agent to create the issues.
Ralph on it.
I review the code for real.

This is the most important part for me: small steps and human code review.

If the AI creates a huge change, I cannot review it properly. If it creates small pieces, I can read the code, understand the decision, test it, and decide if I want to keep it.

Sometimes something is completely out of reality. In this case, I just restore the repo or drop the commit. No drama. But because the work is split in small parts, I can usually keep the useful parts and reject the bad ones.

Why lazy-scripts exists

The lazy-scripts repository is not only a collection of commands.

It is also my lab.

It has normal development scripts, like the garbage collector that cleans generated artifacts from Python, JavaScript, and Go projects. It has sandbox helpers. It has AI helpers. It has my current way to start Codex or OpenCode inside sbx. It has the commands I use to run Ralph workflows.

It is not perfect, and I do not want it to be perfect in the wrong way. It is a personal repository, so the code should be simple enough that I can understand and maintain it.

This is also part of my AI learning: if I cannot understand the generated code, the result is not really good for me.

What I do not believe yet

I still do not believe too much in starting a full project with pure vibe coding.

Maybe it works. Maybe the code is even good. But I think there is a risk: you become completely outside of the architecture. You have files, features, and commits, but you do not really know the system.

For now, I prefer another way:

use AI to understand the repo;
use AI to create a PRD;
use AI to suggest small issues;
use AI to implement one slice at a time;
review everything like a developer.

Maybe I will change my mind in the future. But today, this is the way that gives me better results.

Final thought

AI can write code. This is not the interesting part anymore.

The interesting part is how to create a workflow where the code still belongs to you.

If you are feeling lost, I highly recommend you to play and try to automate your daily life with tiny scripts like the ones I did. That makes you understand better your own wokflow, what you want and what you DON'T want to automate with or without AI.

In the end of the day, the prices will rise, we will need to be more productive, spending less "token$" and choosing what you can and what you cannot put in an "OpenAI" server.

Prompt to this post

DEV Community: Cesar Bouli