Claudio Lassala's Blog

Stage 4 gave me a reason to bring a few years of accumulated work together. I had Markdown prompts, skills for writing stories and tests, and notes on how teams moved from stakeholder conversations through design, implementation, and testing. I wanted to turn that experience into a harness I could use on real product work at Improving.

Start with what you already know

Some of my prompts began as Markdown files I attached to a chat. I refined them, turned them into custom commands, and eventually into skills. I already had ways to write stories, plan work, build tests, and review code.

I also had a document describing a development process I had used with teams. It gave me a practical starting point for the harness. I brought that material together with the certification requirements and notes about what I still needed to learn.

I put those resources into a Devin project and asked it to help shape a plan. It asked questions and connected the requirements to work I already knew. I reviewed its proposal and decided what belonged in the workflow.

Give each step a job

The harness takes a feature story through planning, implementation, testing, verification, and a final human review. It pauses for me to approve or reject the plan before implementation begins. Each step has a defined role, and its output becomes input to the next.

That handoff is important. A weak plan or misleading result early in the process can affect everything that follows. Each step needs a way to check whether it did its job.

I use deterministic checks where clear pass-or-fail rules fit, and adversarial reviews to look for problems the regular checks may miss. Then I use the finished feature myself. Tests can pass while an interface still feels confusing or awkward.

Dark mode is one example. If labels are unreadable in dark mode, I don’t consider the feature done. I added Playwright checks for both light and dark themes, but I still want to click through the feature before calling it finished.

Keep a record of what happens

The harness records each step, including failures, rework, and model-call costs. One feature used about $1.15 in model calls and took roughly two hours to work through. I look at the cost breakdown to see where rework happened and whether a skill should produce a better result earlier.

I started with SWE 1.7 while it was free. When it became paid, I switched the harness to DeepSeek v4.1 Flash. It has worked well for this workflow so far. I still judge a model by what it does in the role I give it, including whether its reviews are consistent and useful.

The logs give me something concrete to improve. After a run, I can review what went wrong, change a prompt or skill in a separate session, and check the evaluation results. The iteration history helps me see whether the change worked, not just whether the new prompt seems better.

I use the same approach with a local retrieval system for my writing and notes. A colleague suggested adding a graph database. Someone else suggested that I include nearby sentences and dates in the metadata when ingesting material. Those experiments changed what the system could retrieve. The graph still needs work, but keeping notes on the changes helps me understand what I tried and what to improve next.

The work continues after certification

The certification gave me a reason to assemble these pieces, but I wanted the result to be useful after the submission. By the time I shared it with the group, I had used the harness to build 25+ features. That gave me real runs to examine, including cases where the checks caught problems and places where I still needed to refine the process. I wrote more about earning the certification in Stage 4 Certified: My Journey to AI Governance.

For me, AI maturity shows up in the habits around the tools: break work into steps, evaluate the results, keep a record, make human decisions explicit, and improve the process when the evidence points to a weakness.

An impressive diagram doesn’t earn my trust, and neither does an agent declaring itself done. I need to see the workflow behave on real work, inspect its failures, and check what changes after a fix. The logs and human checkpoints help me do that.