Flagship essay
The Velocity Paradox: Why AI Should Slow You Down
AI speeds up drafting, not understanding. The highest-leverage AI workflow shifts effort from typing to specification, architecture, and verification.
Henry Dennis
Writing and building for a world where code is cheap and judgement matters more.
I write about AI-native software, engineering judgement, and the architectural decisions that make systems easier to trust and evolve.
-
20%
API response-time improvement across production endpoints
-
25
developers brought together through the PHP Guild
-
350+
business clients supported by the platform work at Tillo
-
5,500+
bookable slots generated in Tutorful’s first six months of launch
Featured ideas
Start here
Three essays that best capture the argument running through the site.
Positioning note
Building Bridges Between Code and Understanding
Why I write about full-stack development, system thinking, and the patterns that connect them.
Field test
Gemini 3 vs. GPT-5-Codex: The Real Daily Driver Test
Google's Gemini 3 is here. Forget the "reasoning" hype—how does the standard model actually stack up against GPT-5-Codex in a daily coding workflow?
Selected work
Work that held up in real systems
Examples where architecture, product shape, and delivery constraints had to be resolved together.
Tillo
Senior Software Developer
Making partner-facing platform systems faster, clearer, and easier to extend
Constraint
Performance, partner onboarding, and integration architecture all needed to improve together. Isolated fixes would have moved the symptoms around without improving the system.
Decision
Used Datadog APM to identify production bottlenecks, refactored webhook logic around strategy patterns for a broader offering, and stayed close to client integrations so platform decisions reflected real onboarding friction.
Result
Response times improved by 20%, the webhook service became easier to expand without duplication, and the product surface became more trustworthy for partners relying on it.
This is the kind of work I am drawn to: technical decisions that make both the internals and the external experience better.
Tutorful
Software Developer
Designing for messy real-world constraints without making the platform brittle
Constraint
A document validation flow had to handle multiple DBS certificate formats and localisations while the wider product was also evolving quickly across web and mobile.
Decision
Built the validation API with AWS Textract, planned availability infrastructure that could scale operationally, and helped sunset a legacy Laravel API to reduce long-term maintenance drag.
Result
The system supported real-world input variability, unlocked more product capability, and avoided leaving a larger clean-up bill behind for the team.
I care about the hard middle ground where product ambition meets operational complexity and architecture has to stay realistic.
Sonin
Lead Software Developer, iOS
Bridging app architecture, backend reality, and delivery infrastructure
Constraint
Mobile work often absorbs the cost of unclear backend contracts, shifting requirements, and infrastructure decisions made elsewhere in the stack.
Decision
Re-architected iOS work around SwiftUI and MVVM, built serverless video infrastructure for inspection workflows, and regularly stepped into the joins between app teams, APIs, and delivery concerns.
Result
Products became easier to evolve, teams had clearer technical boundaries, and delivery stopped depending on one part of the system pretending the rest did not exist.
My bias is always toward coherence: making the whole system easier to reason about, not just polishing one layer of it.
Current themes
What keeps showing up
The ideas, tensions, and system questions that keep returning across the work.
01
AI-native software
I am interested in what changes when code gets cheaper, agents get more capable, and software becomes a system of humans, tools, interfaces, and infrastructure.
02
Systems design
I care about boundaries, trade-offs, failure modes, and the architectural decisions that decide whether a product compounds or becomes harder to change every quarter.
03
Product taste
Good engineering is not only execution. It is deciding what deserves complexity, what should stay simple, and what makes software actually feel coherent to its users.
04
Maintainability
As generation gets cheaper, quality matters more. I pay attention to clarity, observability, trust, and the habits that make a system hold up after the demo.