My last 2 build logs (Log 23 and Log 24) detailed my audit journey. I resolved 90 security vulnerabilities and 50 architectural mistakes. Now, my staff highlight UI design errors rather than workflow failures within the app
In the past week, I rebuilt my development workflow to protect my gains. My core lesson still holds: AI follows my instructions when I use the right concepts. The model performs better when I use precise vocabulary; otherwise, it rarely volunteers critical details.
My coding vocabulary remains limited, as reading manuals cannot replace hands-on experience. Hence, I shifted my focus: A better way to express my operational intent.
AI model developers claim that coding is “solved,” and autonomous agents handle the entire development process. That assumption may hold for experts, but it fails for people like me, who are still learning.
Last week, I identified open-source skills that translate my operational intent into precise engineering language.
I have no interest in automating my development workflow. The goal: No code generation until the problem statement is not clearly defined. The skills or tools need to clarify not dilute my problem statement and helps me in verifying what was built.
Step 1: I initiate a grill-me session with aid of Matt Pocock’s grill-with-docs skill. AI takes on the role of an interrogator, with complete access to my codebase and cross-reference it with my documentation, project log, original project brief, and other artifacts across my project. The skill forces me to clarify my problem statement.
Step 2: I use improve-codebase-architecture skill to build a plan based on my existing code architecture (while avoiding further complexity). Once the plan is finalised, I generate a PRD using to-prd skill.
Step 3: The coding agent (Claude Code or Codex or Pi) reads the PRD before writing any new code. I instruct the coding agent to generate tests before it builds any features or workflows. Tests written after code is generated always pass, because AI mostly writes tests that pass mostly than actually finding faults.
Step 4: After AI has completed its coding efforts, I undertake a cleanup of my code via DeSlop skill. The goal is to reduce the AI-generated noise
Step 5: I audit the code review with aid of Code Quality Review skill, which does a complete structural audit of my the changes.
Step 6: I run my suite of unit and E2E tests. Once all tests are cleared, I do a local build to review the changes made. Only when I am satisfied, I commit the changes
This workflow may appear bureaucratic and boring.. However, a disciplined process is the only way I can control my development process.
Every skill I use has been built by engineers, who have open-sourced them. Will I be able to fall back on new tools as my needs evolve? Maybe not but I am grateful to people who have built and shared them.
Is this workflow correct? I have no idea. Is it better than what I had before? Still early to conclude but I now fix only one or two minor bugs weekly compared to 4-5 issues
My earlier workflow mirrored on how I use AI: plan, build, review, fix and deploy. It lacked proper engineering discipline, relying on a series of well-intentioned steps. It lacked technical vocabulary and systematic review gates.
What I have now is a slightly better process with checkpoints. The unknown unknowns I stated in my previous log still exists. No workflow can eliminate what I cannot see or don’t know.
The new workflow is a bet. How will this play out? No idea. I simply hope to catch flaws before they become a liability.