It’s no secret that Generative AI has become a massive trend in software development. My own experiences have evolved over time as tools have become increasingly more powerful.
Two years ago, everyone started out using ChatGPT as a replacement for StackOverflow. I’d be lying if I said I didn’t use it to better understand Ruby code (and to write some of it for me 🤣). We could copy/paste prompts into a web interface with our code in order to make it write test cases for us.
As time went on, the tools just kept getting better. I remember the first time I used Github Copilot and I thought to myself “oh this is really cool”. Watching those faint lines of code appear after things I type, the algorithm trying it’s damndest to predict my next move, and having it come up with the right answer sometimes, really started to show me how much more productive I could be with these tools.
Just when I thought the tooling couldn’t get better, I downloaded Windsurf and
started seriously using it. Yea yea, I know, Cursor is a thing, but I also use
Bulma instead of Tailwind for everything, ok? I go against the grain sometimes.
As I’m writing this post, I’m actually writing it in Windsurf. Don’t worry: I
didn’t have Windsurf write most of this for me. In fact: I’m not really sure I
can recommend using Windsurf to write a blog post for you. As I’m typing along
and watching Windsurf predict what I’m going to write, it’s not as good as
predicting what I’m going to write. It’s not as good as
predicting what I’m going to write. you can see that those last few tabs
didn’t quite convey anything coherent with everything else I’m talking about,
and… For some reason it repeated itself?
Beyond that though, Windsurf has been helping me immensely with work: I’ve been using it to rapidly prototype projects that I’d normally only have on the back burner, and automating more tedious tasks while taking time to review other team members code or updating JIRAs or working on designs.
However, one thing I have noticed in the work I produce using these tools is that I tend to not take enough time to review whatever the AI model is creating. There are sometimes bugs in the code that’s been generated, or typos, or something else in the code is just not correct, and if I took a little more time to review it before putting it up for review, I would be able to avoid a lot of the thrash of receiving comments and addressing them.
I had a bit of an experience like that this week, and it’s made me take a pause regarding how I approach code reviews.
The first time I ever participated in a code review was when I was working for Cerner back in 2014 in their DevAcademy training program for new hires. Code reviews were a really big focus for all of us in training: it was the first time that so many of our technical skills and communication skills were put to the test. Do you want to be able to close a task out soon? Gotta get your code up for review. Hope to ship that feature you’ve been working on all sprint? Go get them approvals.
Code reviews for a long time have acted as a litmus test: you can’t close a task if your code isn’t merged, and you can’t merge your code until you get all the necessary approvals on your review(s), and you can’t get those approvals until you address all the feedback. If it at least passes the vibe check with the rest of the team, you’re good to go. There’s a lot of other quality gates teams can put in place like test coverage and static analysis tools, but code reviews have been the engineering team’s last line of defense to catch bugs before pushing them to the rest of the business (QA, Security, Support, etc.).
In the past, when I’ve put code up for review that simply wasn’t ready to be shipped, it either came down to a lack of understanding of what problem I was trying to solve, or it was more of a rushed job, and in either case, it became obvious to myself and any other reviewers that whatever I put up wasn’t quite “done” yet. Because of this, and for as long as I can rememeber, I always tried to ensure that I was absolutely sure that whatever I was offering up in a review was ready to be shipped now.
As I began to mentor new engineers throughout my career, that’s also the same advice I gave them: if you want others to review it, you better make sure you’re ready to ship it. If you wouldn’t ship it today without being completely confident that it’s ready to go, don’t even put it up for review. Part of that stemmed from the fact that there used to require a lot of manual effort to even write the code to begin with, and that you as the author understood what that code was doing, and why you chose to make certain implementation choices.
I still stand by that advice, but I’ve come to realize that when I’m using AI tooling to write code, I need to take more of my own advice.
What I’ve come to learn from using AI is that it’s the same as using any tool in software development: you have to learn how to use it effectively. Some folks use AI and they’re really great at getting their desired end-result from it. Others take vibe-coding to an almost unhealthy level, simply trusting what’s generating will work without reviewing the changes themselves.
On the other side of that adoption spectrum, there are folks who outright refuse to use AI tools, either due to skepticism that what they’ll get is awful, or because they truly believe they are much better at writing code than AI is.
What I find to be best for myself is to integrate AI tools into my daily coding workflow, either when I get stuck on something, or if I want to save myself time with creating files that AI can create based on documentation I created, or if I want to go from nothing to POC on something as quickly as possible. Of course I’ll have to clean things up myself later, and put all the proprietary knobs and bits into the places I need them in, but I find that I’m able to accomplish a great deal more with this little pair programmer on the side of my editor than I could if I was researching and creating all of the code myself.
But therein lies the issue: just because the tool made it doesn’t mean it’s ready for prime time. In more recent examples at work: I had it generate a bunch of files for me based on documentation that I had the rest of my team reviewing over the last week. It was able to do a decent job, but after I put up all the files for review, I realized something:
I didn’t really review any of the files myself, and in doing so I put a lot of undue burden on other team members.
I’d say the tools got me about 65-70% of the way there, but there were so many little things I missed if I would have just taken the time to review it myself. I could have gone in and manually edited each file to make sure each one was correct. Heck, I probably could have told Windsurf what it had done wrong and it might have gone and done it for me.
What I’ve realized in using these tools is that my code review process needs to change. I need to pair with my newfangled editor, not just let it take the wheel. Each line and statement should be scrutinized, and not assumed to be correct.
I’m realizing that I need to reverse the principle a little bit: with all the time saved in implementing something, I need to dedicate a little more time to reviewing the code myself before it’s reviewed by others. After all, I’m still trying to ship something, and if it’s not ready, someone else is gonna catch it, and that’s not really fair to whoever that someone else is.
There’s an entire tab in VSCode/Windsurf/Cursor that I’ve always had that allows me to see git diffs of all the changes in the current working branch of code I’m working on. I’ve literally never used it though, because most of the time I’m using the Git CLI for everything. Some people might like using a visual client for Git, but I can’t stand them. I find them much harder to use than the CLI.
However, one thing that the CLI really lacks is a good way to quickly review diffs of unstaged changes. Much like how we typically rely on Github or Gitlab PRs/MRs to review code, I’m starting to realize that I should be picking through diffs of what Windsurf is helping me write before I send it off to the rest of the team. I think that little tab in the editor is going to start getting a lot more use from me!
So those are all my thoughts on how I’m going to start changing my workflow. Windsurf has been an absolute pleasure to use, and I’m getting a ton of value out of it, but no matter how fast I’m able to move with it, I’m realizing I can’t speed up at the expense of slowing everyone else down.