How I actually work with AI
The AI-assisted part of this portfolio isn't a code-completion habit — it's a structured, multi-month self-directed curriculum run with an AI instructor, covering DevOps and now a full-stack track. This page shows the actual methodology, not a claim about it.
The methodology
Every course starts with a course-level overview and rationale before a single module begins — what's being built, why this project shape specifically forces the right lessons, and how it connects to what came before.
Each module follows the same discipline: a concept is explained, a hint or direction is given, then a small hands-on task is attached immediately — never a long lecture block before any hands-on work.
The AI describes what to do in plain English. I write every line of code and run every command myself. No unsolicited code is ever generated for me — this is a hard rule, not a preference.
Problems are always introduced before their solution — manual docker run wiring before Compose, raw SQL before an ORM, manual namespace isolation before Docker is even opened. The tool's value has to be self-evident, not asserted.
Real breakages are planted deliberately — a reversed COPY instruction to force a cache-invalidation lesson, a disabled healthcheck to force a real race-condition failure — so the failure is observed directly, not summarized in prose.
Real evidence, not claims
Context
During the Git & GitHub hardening course, an accidental merge into a protected branch was handled as a genuine incident — full response via git revert through the actual protected-branch workflow, not a simulated walkthrough.
Outcome
Direct, hands-on fluency in recovery operations most developers only read about: reflog recovery, branch-deletion recovery, and a real multi-branch divergence resolved live.
Context
In the Docker course, a Dockerfile's COPY order was deliberately written backwards — source before the dependency manifest — specifically to force a full cache invalidation on a trivial source change.
Outcome
The fix, and the cache hit that followed, were observed directly rather than taken on faith — this is the difference between knowing a rule and having verified it.
Context
An early attempt to trigger a memory limit failure failed silently, because Buffer.alloc() without touching pages doesn't register as real resident memory. The discrepancy was diagnosed by comparing the kernel's own memory accounting against the script's internal counter.
Outcome
Fixed by forcing real page commitment, then a genuine OOM kill was triggered and confirmed via OOMKilled: true and exit code 137 — a signature worth recognizing in any real production incident.
Context
A production integration-test pipeline failed for a subtle reason: two files had been refactored to read new environment variables, but the CI workflow's env-file generation step still wrote the old shape. The API silently fell through to a default host with nothing listening on it.
Outcome
Root-caused by adding real error logging to a health endpoint that had been swallowing the actual database error — a genuine permanent fix in its own right — then confirmed directly against the actual Pool config rather than trusting a stale assumption.
Where the line is
The AI describes what to do in plain English. I write and run the code myself. This is a standing rule across every course, not a case-by-case choice.
Third-party AI suggestions (including from tools like GitHub Copilot encountered mid-project) are judged on merit. A suggestion that correctly diagnosed a real problem but proposed fixing the wrong layer was rejected in favor of fixing the actual broken piece — with a clear, respectful reason recorded either way.
When I catch an error or misstep in the AI's direction, that correction is treated as final and the work adjusts immediately — no re-litigating a decision I've already made with better information.
Claims get verified against actual command output, actual file contents, and actual logs — not assumed from a mental model. This shows up as a repeated pattern across every course: check first, then act.
This same discipline — real friction before the tool that solves it, errors drilled rather than described, decisions verified against evidence — is the same approach carried into Huzaifa Portal and the pSEO Engine: build it by hand first, understand exactly why a tool or abstraction earns its place, then adopt it deliberately.
Try it
A small, scoped assistant answering questions about the projects and background on this portfolio — running on Cloudflare Workers AI's free tier, with a static fallback if that's ever unavailable. It only knows what's on this site.
Project assistant