Late on purpose
I was not an early enthusiastic adopter of AI tools. That is a fact about how I am built as an engineer, worth stating plainly before anything else in this piece.
I have spent since 2012 as a developer and, for a good stretch of that, as a tech lead, building my career on practices that are deliberate almost to the point of stubbornness: Extreme Programming, test-driven development, trunk-based development, incremental delivery. I picked up these habits because, one broken build or one regression shipped to production at a time, they proved themselves, not because they were fashionable. Every one of them asks something uncomfortable of you before it gives you anything back: write the test first, integrate before you feel ready, ship the thin slice instead of the whole feature. The discomfort is the mechanism.
So when a new tool arrives promising to remove friction, I do not treat that as good news by default. I treat it as a question. Does this raise the bar, or does it lower it while feeling like it raised it? That question is the only lens I have ever trusted, and it is the lens I want to apply here, honestly, to AI.
Ask any developer about JavaScript frameworks and you get a tired laugh. A new one launches almost every day. I have never shipped one of them into production the week it came out, and I'm not going to start now: too many unknowns, not enough hours spent finding out where it breaks.
This is a map of how a professional curiosity turned into a serious question I could not put down, including the parts of that process I am not entirely proud of. I'm not writing a tutorial here, and I won't tell you whether you should use these tools.
First contact: consumer tools
My first real session with ChatGPT left an impression I still remember clearly: it was fast, fluent, and confident in a way that felt almost unfair given how little effort I had put into the prompt. A second, quieter impression followed close behind: what was actually happening here? I did not have a good answer, and not having one bothered me more than the tool itself.
What kept me using it was different from that first impression. I started talking to it like a voice journal: thinking out loud about a decision, or a knot in a project I couldn't untangle on my own during a walk. After a few weeks, its memory of those earlier conversations started to matter. It remembered the shape of a problem I had described days before, and that continuity changed what I actually used the tool for.
I tried Notion AI and a handful of writing assistants around the same time, mostly for drafting and summarizing. They were useful. They were fast. They also left a doubt I could not shake, over whether I was in control of the tool or the tool was quietly setting the terms of how I thought about the thing I was writing. Editing a paragraph a model has already shaped for you is a different act than writing that paragraph yourself, even when the final text looks identical.
Cursor was my first contact with this class of tool in a professional context, and the one I used the most in those early months. What struck me was how immediate it felt: open it and it was already familiar, close enough to the classic editor I'd used for years, except the AI was right there alongside me from the first keystroke. But I noticed something in myself within the first week: I was accepting suggestions I had not fully read, let alone fully understood. Not often, and not on anything critical, but often enough that it registered as a signal rather than a one-off lapse.
The common thread across all three tools was the same. They removed friction. And friction, I had learned the hard way over a decade of practicing TDD and trunk-based development, is very often where the thinking lives.
The tension with my engineering identity
XP never asked me to accept practices on faith. Every practice comes with a reason, and the reason is usually a feedback loop. TDD is a tight loop that forces you to state your intent before you state your implementation; that loop is what catches the gap between what you meant and what you wrote. Trunk-based development is a forcing function that keeps the codebase in a state someone else can reason about today, not next sprint.
The risk I saw in AI-assisted coding was specific, not vague: a tool that produces plausible output without understanding is the exact inversion of what I try to build into a team. I do not want engineers who can produce code that looks right. I want engineers who know why it is right, because that is the only kind of correctness that survives contact with a production incident at 2 a.m.
There was a specific trade I kept circling back to. Every line of code I hand to a model is a line I no longer hold the same detailed knowledge of: why this branch exists, what edge case it was guarding against, what broke the last time someone touched it. That knowledge has value, and giving it away means I need something back in return. Early on, I couldn't see what that something was. All I could see was risk stacking up on my side of the table.
There's research behind that instinct too. DORA's State of DevOps work has shown for years that writing code was rarely the bottleneck in a software team, product or project, high-performing or not. The slow parts were review, integration, testing, deployment: coordination, not typing. An assistant that makes typing faster is solving a problem most teams didn't actually have. It wasn't my main problem either, and I knew going in that the upside would be limited.
So the question that started forming was personal, and slightly uncomfortable to sit with: if I use AI to write code I do not fully understand, who am I becoming as the engineer who builds it that way?
The moment the question became professional
There was no single event that turned this from a private discomfort into a professional question I had to answer. It was a threshold crossed gradually, the way most shifts in a career actually happen.
The context was hard to miss. Colleagues around me were adopting these tools quickly, some with discipline, some without much thought at all. Companies started declaring themselves "AI-first" as a strategic position, which is the kind of phrase that tells you more about a slide deck than about an engineering practice. And underneath all of it sat an implicit pressure that never announced itself directly: keep up, or fall behind.
My instinct was to wait. Waiting felt safe, and it felt aligned with everything I had built my career on. But at some point that was not a sustainable position anymore. The world around me was starting to find a lot of answers, and I had to start finding mine.
Once I saw that clearly, the question changed shape. It stopped being "How should I use AI?", which is a question that doesn't lead to a clear outcome, and it became something more like: "what kind of engineer do I want to be with these tools?", a question that cannot be resolved by picking a side, but by experimenting more and more.
What became clear, somewhere in that shift, was that these tools needed to be understood and folded into how I worked, not avoided indefinitely or kept at arm's length forever. So the question I actually started asking myself was narrower and more useful: how do I use these tools in a way that amplifies the practices that already work, instead of giving them up?
How I spent the wait
From day one I was reading, testing, and watching for the moment the tools would be ready for work that actually mattered: active preparation, not idle waiting. When the door opened, I already knew how to walk through it.
I decided not to integrate AI into my professional workflow until I had studied it seriously enough to trust my own judgment about it. That meant reading more than I expected to need, experimenting in low-risk contexts where a bad outcome would cost me an afternoon and not a production incident, and watching what happened to other engineers and teams around me. I paid closer attention to their failures than their demos, since demos are built to hide the things I needed to see.
I set myself one criterion, and I have held to it since: I would bring AI into my professional workflow only when I was confident it was helping keep the bar high, not quietly bypassing it. The withholding was deliberate: I wanted evidence before I extended trust, not a personality built around skepticism.
That criterion is the same standard I would apply to any practice, tool, or process change proposed to a team I was leading: show me the evidence, then we talk about adoption.
Opening of the journey
At this point I had the question, clearly stated for the first time, but not the answer. That distinction matters more than it might seem. Arriving at a clear question after months of low-grade discomfort is progress, even though it does not look like progress from the outside.
What came next was the harder part: beginning to experiment with discipline, and working out, case by case, what "using AI well" actually meant for someone who had spent over a decade building an engineering identity around deliberate, evidence-based practice. That is where the next piece picks up: the first serious experiments, and what happened when I looked closely enough at what held up and what did not.