AI has made me dramatically faster, and I think that matters to you. Work that used to take me a month now takes days. I want to explain why that's true, because the explanation is the part that should determine whether you believe it.
Why it works for me specifically
The speedup isn't the model. Everyone has the same models.
It's that I've been writing software for twenty-five years, so I know what correct looks like. When I watch an AI write code, I can see it going wrong while it's going wrong — a data model that will not survive its second requirement, an abstraction in the wrong place, error handling that quietly swallows the case that matters. I stop it and redirect before the mistake becomes three files deep.
That's the whole mechanism. AI generates plausible code very fast. Plausible is not the same as correct, and the gap between them is exactly where experience lives. Someone who can't see the difference gets speed and a mess. Someone who can see it gets speed.
The honest version of the claim is not "AI made me ten times better." It's that AI removed most of the typing, the boilerplate, the API lookups, and the first-draft scaffolding — and left the parts that were always the actual work: deciding what to build, noticing when something is subtly wrong, and knowing which shortcuts you'll regret.
What's changed in three years
I've been using these tools since they were barely useful, and the trajectory is not subtle. Three years ago AI was a faster way to look things up. Today it's a genuine collaborator on design, implementation, and testing — provided you drive it.
Knowing how to drive it is its own accumulated skill, and it isn't obvious. Where to give context and where to withhold it. When to let it run and when to take the keyboard. How to phrase a problem so the answer is verifiable rather than merely confident. Which tasks it's reliably good at and which it will fail at while sounding certain. That took real time to learn, and most of it doesn't transfer from reading about it.
Staying current is part of the job
I spend six to seven hours a week on this — reading, testing new releases, and working with tools across services rather than committing to one vendor's view of the world. Not as a hobby. This field moves fast enough that a practitioner who stopped paying attention eighteen months ago is now confidently wrong about what's possible.
That has a direct effect on your project. It means model selection is based on what's actually good this quarter rather than what I learned once. It means I know which capabilities are real and which are demos. And it means when I tell you something isn't worth building with AI yet, that's a current assessment rather than a stale one.
It also means I'll tell you when something has changed. A decision we made six months ago on cost or capability grounds may simply be wrong now, and that's worth revisiting rather than defending.
The skills I've built
I've encoded my own engineering practices into a set of reusable Skills — instructions the AI works from, so the code it produces on my projects follows the same conventions whether it's written on a Tuesday or eight months later on a different codebase.
They cover four areas:
- Architecture and code patterns. Layered separation, domain models kept distinct from persistence, boundaries in the places that make a system testable. The same structure across my projects, because it's the structure I've found holds up.
- Testing and verification. How tests get written, what actually needs coverage, and contract-level checks that fail when a response shape changes rather than letting it reach the frontend.
- Documentation standards. Markdown in the repository beside the code, decision records for the choices that aren't obvious, handover material written as the work happens rather than reconstructed at the end.
- Review and correction. What to check in generated code and where models reliably go wrong — silent error handling, invented API surfaces, tests that assert the implementation rather than the behavior, confident answers to questions that needed more context.
This is the part I'd point to if you want to know whether "I use AI well" means anything. It's not a preference. It's a documented set of practices, applied consistently, that I've refined over hundreds of hours of watching where this goes right and where it goes wrong.
What it doesn't change
I own every line that ships. If I can't explain why the code is the way it is, it doesn't go in. You're hiring an engineer who uses good tools, not someone forwarding model output.
Architecture is still mine. The decisions that are expensive to reverse — data models, boundaries, what's a service and what isn't — are made by me. AI is very good at writing code inside a design and unreliable at choosing the design.
Speed doesn't lower the bar. Faster delivery means more time for testing, documentation, and the second look — not a lower standard applied sooner.
Your policy wins. Some organizations prohibit AI tooling, or restrict it to self-hosted models, or require that no proprietary code leaves the building. Tell me your constraints and I'll work inside them. It's your code and your risk decision, not mine.
What this means for your budget
The plain consequence: you get more for the same money.
I bill for time. If AI makes me three times faster on the parts it's good at, that's three times less time on your invoice for those parts — not the same invoice with more margin for me. It also changes what's worth doing at all. Work that couldn't be justified at a month of effort is often obviously worth it at a week, which tends to matter most for the things teams keep deferring: the internal tool, the migration, the test coverage nobody had time for.
Questions
If you want to talk through how this would apply to your project — or you're skeptical, which is reasonable — I'm happy to get into specifics.