I have reached a point where I genuinely feel that I am unusually effective at using AI to build software. Not because I believe AI replaces engineering, but because I came into the AI wave already knowing how software is supposed to work when the demo is over and real users arrive.
I Started Before the AI Wave
I learned to code before AI assistants became a normal part of the development workflow. That matters to me because I learned to think through systems without expecting a model to produce the answer first. I had to understand architecture, databases, APIs, frontend behaviour, backend logic, debugging, deployment, security, failure modes and the uncomfortable details that make production different from a tutorial.
So when AI coding tools became dramatically better, I did not experience them as a replacement for my engineering brain. I experienced them as an extremely fast new collaborator.
My Hybrid Model: Engineer + Pair Programmer
The way I use AI is closer to having a very fast pair programmer than having an automated code generator. I can describe the outcome, ask the model to explore an implementation, challenge its assumptions, reject weak approaches, restructure the architecture, test the edge cases and keep iterating until the result fits the system.
The important part is that I am still the engineer responsible for the decisions. AI can generate ten approaches in the time it might take me to write one. My job is knowing which approach belongs in production, which one only looks impressive, and which one will create technical debt six months later.
Vibe Coding, But With Engineering Discipline
I like the speed and creativity of what people call vibe coding. There is something powerful about being able to move from an idea to a working prototype extremely quickly. But I do not want to stop at the vibe.
My version is closer to production-aware vibe coding: move fast, use AI aggressively, keep the feedback loop short, but constantly ask what happens under load, what happens when a dependency fails, where the data lives, how authentication works, how secrets are handled, how backups happen, how errors are observed, how the system is tested, and how another engineer will maintain it.
I Know What the Finish Line Looks Like
This is probably the biggest advantage I feel I bring to AI-assisted development. I am not only asking, “Can we make this work?” I am asking, “What would this need to look like if someone depended on it tomorrow?”
- Clear architecture instead of a pile of generated files.
- Proper database design instead of convenient but fragile schemas.
- Authentication and authorization designed around actual threat boundaries.
- Validation, error handling and observability around important workflows.
- Tests for behaviour that can actually break the business.
- Backups, migrations and recovery paths for persistent data.
- Environment separation and secret management.
- Performance considerations before traffic becomes a problem.
- Security and privacy treated as architecture, not decoration.
- Documentation and code structure that another developer can understand.
AI Gives Me Leverage, Not Permission to Stop Thinking
One of the easiest ways to use AI badly is to confuse a confident answer with a correct answer. Models can hallucinate APIs, invent configuration, miss edge cases, misunderstand an existing codebase or produce an elegant-looking solution that is completely wrong for the actual constraints.
That is why I constantly verify. I read the code. I inspect the database. I test the workflow. I look at logs. I compare alternatives. I ask the model to critique its own implementation. I make it explain trade-offs. And when the answer still does not make sense, I throw it away.
Why the Combination Feels So Powerful
AI is extremely good at accelerating implementation, exploration, refactoring, documentation, brainstorming and pattern recognition. An experienced engineer brings context, taste, constraints, system thinking and accountability.
Put those together and the development loop changes completely. I can spend less time typing repetitive code and more time deciding what should exist, how the pieces should interact, what could fail and how to make the whole thing better.
Am I the Best at Using AI?
I obviously cannot objectively prove that I am the best. “Top 1 percent” is a personal benchmark, not a measured global ranking. But I do believe I have developed a rare combination: pre-AI software engineering instincts, strong production awareness, full-stack experience and an aggressive AI-assisted development workflow.
That combination is what I mean when I say I feel like I am a hybrid of a software engineer and a top-tier AI pair programmer. The model supplies extraordinary leverage. I supply the engineering direction, judgment and standards.
The Goal Is Still Good Software
I do not want to win an argument about whether AI or humans are better programmers. I want to build better systems faster.
If AI lets me explore ten architectures instead of two, understand a new codebase faster, automate repetitive implementation and spend more of my time on the decisions that matter, then I want to use it as hard as I responsibly can.
I started coding before the AI wave. Now I am building with the wave. And I think the most interesting developers of this era will not be the people who refuse AI or blindly outsource their thinking to it. They will be the engineers who understand software deeply enough to make AI dramatically more useful.