Technical research
Mapping an unfamiliar problem space fast: what approaches exist and which sources are worth reading in full. I still read the primary material before committing.
Workflow
AI-Augmented Engineering Workflow
AI is part of how I work now, the way version control and a good editor are. It shortens the distance between a question and a working answer. Whether the software is correct, maintainable and worth building stays my call.
I treat it like a fast, well-read colleague: useful for a first draft, worth arguing with, never the final authority. Nothing reaches a system a business depends on without passing my own review.
A model can propose three architectures. Deciding which one survives a real budget, a real team and real data is engineering work that doesn't transfer to a tool.
The practical result is throughput. Work that cost a weekend of reading now costs an evening, so more of my time goes to understanding the problem, choosing what to build, and checking that it behaves the way I claimed.
The loop
6 stages
Six stages run on every build, and each splits the same way. Everything left of the line is a draft I asked for. Everything right of it is a decision I'm answerable for.
- 1
Understand
- 2
Design
- 3
Build
- 4
Verify
- 5
Document
- 6
Ship
Then it loops. Shipping produces the next round of things I didn't understand, which is where stage one gets its material.
Where I apply it
Architecture exploration
I ask for several viable structures, then argue against each. Three defensible options side by side make the trade-offs explicit instead of leaving them buried in a first instinct.
Documentation
READMEs, architecture notes and setup guides for systems I've already built. The understanding is mine. The first draft of the prose doesn't have to be.
Rapid prototyping
A rough version, fast enough to learn from. A prototype that answers a question in an hour beats a plan that argues about it for a week.
Refactoring
Restructuring working code without changing behaviour: extracting a module, tightening types, removing duplication. Tests are the contract that proves nothing broke.
Debugging
A second perspective on a stack trace. AI is fastest at eliminating wrong hypotheses, and that's most of what debugging is.
Testing
Cases around boundaries I've defined, especially the edge conditions that are easy to miss when you wrote the implementation yourself.
Code review
A first pass before a human one: naming, error handling, unhandled cases, drift from the conventions already there. It clears the ordinary mistakes so review can be about design.
Learning new technology
Building something small in an unfamiliar language and asking why it's shaped the way it is. That's the gap between reading docs and understanding intent.
API exploration
What an API genuinely supports, and how it fails, before I design around it. GDS and payment integrations are unforgiving about assumptions.
UI generation
A first interface pass to react to. Judging a layout that exists is far easier than specifying one that doesn't, so drafts are material for critique.
Technical writing
Case studies, proposals and specifications, structured so the reasoning behind a system outlives the person who built it.
Brainstorming
Thinking out loud against something that pushes back. Most ideas don't survive that conversation, which is why it's worth having early.
Productivity
Scripts, migrations, boilerplate and formatting, handled fast enough that attention stays on the parts that need it.
Toolkit
Modern Engineering Toolkit
Not a skills list. These are the tools I reach for at each stage, from the first unfamiliar question through to the version that ships and has to keep working.
Research
Mapping a problem before I commit. Asking more than one model is deliberate, because where they disagree is usually where the real trade-off hides.
ChatGPTGoogle GeminiKimiClaude Code
Architecture
Exploring candidate structures, arguing against each, then recording the decision somewhere it can be revisited months later.
Claude CodeChatGPTNotion
Development
The editor is still where the work happens. AI sits inside it, with version control as the safety net that makes fast iteration reversible.
VS CodeClaude CodeOpenAI CodexGitHub CopilotGit
Documentation
READMEs, architecture notes and internal guides written alongside the build rather than bolted on after, so the reasoning outlives whoever wrote it.
NotionClaude CodeGitHub
Testing
API behaviour checked against the real service, cases drafted around boundaries I define, and checks that run on every push instead of when someone remembers.
PostmanClaude CodeGitHub
Design
Interface work starts as layout and hierarchy, not decoration. Generated first passes are raw material to correct, never the shipped result.
FigmaGoogle GeminiClaude Code
Productivity
Planning and tracking, kept light enough that the process supports the engineering instead of becoming a second project.
NotionChatGPTGitHub Copilot
Continuous learning
What I'm picking up, not what I already have. Docker is listed as learning because that's what it is, and I'd rather say so than imply fluency.
Docker (Learning)KimiOpenAI CodexGoogle Gemini