My Journey to Trusting GenAI With More of My Code

Over the past few years, my development workflow has gone through a quiet but profound shift. It did not happen all at once, and it did not follow a carefully designed plan. It evolved the way most good engineering habits do: a lot of experimentation, a few guardrails, some hard lessons, and the occasional moment of wondering when this new normal became so normal.

What started as a fun experiment with early GitHub Copilot has turned into a completely different way of building software.

From Autocomplete to Something Smarter

When Copilot first arrived in beta, it felt like autocomplete with personality. Helpful, playful, sometimes uncanny, but still an assistant. It could finish a function or guess the next few lines, but you would never mistake it for a co developer. It was a spark of what might be possible, not a partner.

Then the models got better. Fast.

The Shift From Coding to Specifying

Somewhere along the way, I noticed I was writing fewer lines of implementation code, not because I was coding less but because I was coding differently.

I started spending more of my time writing tests, defining interfaces, describing expected behavior, and validating outcomes. I moved upstream in the thought process. Instead of asking how to implement something, I focused on how I wanted it to behave. The implementation came second.

Bit by bit, the act of writing code shifted into the act of defining intent. GenAI could take a well specified feature and generate a solid first draft of both the implementation and the tests. My job became more about shaping that intent and less about typing the logic.

And honestly, the transition felt natural.

A Meaningful Threshold

Recently, it hit me that I have crossed a real trust threshold.

My workflows, guardrails, and instructions are now tuned enough that I am confident in the quality of the generated code and the testing structure behind it. It is not blind confidence. It is a healthy trust backed by verification.

For example, I now begin every feature with a test specification and clear acceptance criteria. Only after those are locked in do I ask the model to generate an implementation. The discipline of starting from the tests has made a significant difference in the predictability and correctness of the output.

I still review everything. I still refactor. I still catch mistakes. But the overall quality and consistency have reached a point where the trust is real, and the productivity gains are undeniable.

The Pivot to Spec Driven Development

Looking at the bigger picture, the most important change has been the move from vibe coding to spec driven development.

Vibe coding is that creative, exploratory style where you start writing code and figure it out as you go. It is fun, but it does not scale well with GenAI.

Spec driven development, on the other hand, plays to the strengths of these models. When the constraints are clear, the inputs and outputs are defined, and the acceptance criteria are unambiguous, the model can produce remarkably trustworthy code. It is predictable, it is consistent, and it is easier to validate.

The surprising part is that the discipline required for spec driven development has made me a better engineer too. The clarity I need to give the model forces clarity in my own thinking.

Why This Matters

We are stepping into an era where developers act more like architects, testers, and system designers. The models write the first draft. The humans ensure it is correct, safe, scalable, and aligned with the broader architecture.

This shift is not about outsourcing our work. It is about elevating it.

Instead of spending energy on boilerplate, syntax, and repetitive logic, we can focus on higher level design, testing rigor, and the strategic aspects of building systems.

The Trust But Verify Spectrum

Engineers fall across a wide spectrum in their comfort with GenAI generated code.

Some do not trust any of it and review every token.
Some trust it for small tasks but not for anything critical.
Some let it generate entire files and only step in when tests fail.
Some run fully automated flows with human review near the end.

There is no correct position. There is only progress.

Wherever you are today, you likely were not in that same place six months ago. And you will not be in the same place six months from now. The tools evolve. Our skills evolve. Our guardrails evolve.

What I’m Curious About

I would love to hear how others are navigating this shift.

• Where are you on the trust but verify spectrum?
• What guardrails, tests, workflows, or design patterns have helped you lean into GenAI with confidence?
• How have your instructions or prompting style changed over time?
• Are you writing more tests? More specs? Fewer lines of code?

This is a shared evolution, and the more we compare notes, the faster we learn.

Closing Thought

GenAI did not take away my coding. It changed it.
I still build. I still design. I still debug.
I just do it with a different set of tools and a different mindset.

And I would not want to go back.

---

Also published on LinkedIn: