AI-Assisted Engineering Tutorials

How a working engineer uses an AI assistant across the whole job: analysis, requirements, planning, code, tests, debugging, AWS, UI walkthroughs, pull requests, review and customer support. One real feature on a real app, followed from ticket to pull request, with every prompt and every diff taken from an actual session. The theme throughout: the assistant writes, you read. Clicking Accept is not a review.

• AI-Assisted Engineering – One Feature, Ticket to Pull Request
  The whole series in one pass: pay with a saved card at checkout, from the ticket to the pull request. Every step, how long it took, where the assistant helped most, and every point where reading the diff mattered.
• AI-Assisted Engineering – Guardrails and When Not to Use It
  Secrets, destructive commands, production access, confident wrong answers and invented APIs. The settings and habits that contain each risk, and the tasks where doing it yourself is still the faster, safer choice.
• AI-Assisted Engineering – Customer Support Tickets
  From a customer's confused message to a reproduced bug and a reply a human would send. Triage, reproduction against the real app, what never goes into a prompt, and why the reply needs your judgement more than your typing.
• AI-Assisted Engineering – Responding to Code Review
  Working through review comments with the assistant: deciding which are right, answering the ones that are not, and making each fix a small, separate change. Plus using AI as a first reviewer before a human sees the PR.
• AI-Assisted Engineering – Commits and Pull Requests
  Commit messages that explain why, a PR description a reviewer can act on, and the check that matters most: does the description match the diff? Drafting with the assistant, and what to cut before it goes to a human.
• AI-Assisted Engineering – Feature Walkthroughs in the Browser
  Having the assistant drive the running app to prove a feature works: a Playwright script, screenshots at desktop and phone width, and the checks it could not do. Why a green test suite is not the same as a working screen.
• AI-Assisted Engineering – Investigating AWS
  Letting an assistant drive the AWS CLI: a read-only profile, CloudWatch, cost questions and configuration drift. The guardrails that make it safe, and the real investigations behind this site's own infrastructure.
• AI-Assisted Engineering – Debugging and Incidents
  Giving the assistant the evidence rather than your theory, letting it read logs and stack traces, and insisting on a root cause before a fix. A real failure met while building this feature, from first symptom to the line that caused it.
• AI-Assisted Engineering – Writing Tests That Prove Something
  An assistant will happily write tests that pass. The question is whether they fail when the code is wrong. Asking for behaviour rather than coverage, proving a test by breaking the code, and the test changes you should never accept.
• AI-Assisted Engineering – Writing Code in Small, Readable Diffs
  One plan step at a time, in the codebase's own style, verified before the next. How to keep diffs small enough to actually read, what drift looks like in practice, and how to push back when the assistant wanders off the plan.
• AI-Assisted Engineering – Planning: The Plan Is the Contract
  Plan mode, a written plan split into reviewable steps, and a progress report that survives the session. The plan is what you review every later diff against, so it is worth more of your attention than any single line of code.
• AI-Assisted Engineering – Turning a Ticket into Requirements
  A one-line ticket is not a spec. Using the assistant to draw out clarifying questions, edge cases and conflicts with existing behaviour before any code exists, and why the answers have to come from a person, not the model.
• AI-Assisted Engineering – Analysing an Unfamiliar Codebase
  Before changing anything, understand it. Using Claude read-only to trace checkout from the button to Stripe, size the change, and find the rules the code already enforces. Plus how to check that the explanation you got is true.
• AI-Assisted Engineering – Setting Claude Up for a Real Codebase
  An assistant is only as good as the context it starts with. CLAUDE.md as standing instructions, a progress report as shared state, memory, permission modes, and MCP servers for GitHub, AWS and the browser. What to put in each, and what to leave out.
• AI-Assisted Engineering – Read the Code, Follow the Plan
  Clicking Accept is not a review. The job moves from writing code to reading it: how to read an AI-written diff quickly, what to check first, how to hold the assistant to the agreed plan and spot drift, and a real case where accepting blind would have shipped a bug.
• AI-Assisted Engineering – You Own the Output
  What actually changes when an assistant writes most of the first draft, and what does not. Responsibility stays with the person who merges. The new split of the job, the habits that separate engineers who get faster from those who get sloppier, and the feature this series follows from ticket to pull request.