Hello everyone, hope all is well and you have been a take a moment for yourself. In the constant challenge of rhetoric that is social media, I try and break through the humbug and find solutions.
Today, I read one sort of “humbug adjacent” post I was interested in, referencing how software developers have a tendency to shy away from code reviews and how AI can be a tool to use in code review.
I have to admit, that for me: I respect code reviews. Even as my career has evolved, I find myself coding every day. I’m currently working on RPC and Rust programming because why not?
What I liked about this post that I quickly read, was: yeah I can see how folks may be reticent to have a code review. Being reviewed can feel awful, I still feel pretty lame when folks challenge my work. Mainly, because when I see the flaw someone points out I go: “Dangit, yep I missed that.“
My personal opinion on a key factor that makes a senior engineer is that one can allow their ego to be bruised and have the maturity to not let it affect your delivery. It is very difficult to walk that walk, and I would be lying if I haven’t taken some feedback really poorly in the past.
I’m trying to keep this intro short, but I didn’t grow up with what is being coined as “Vibe Coding“. I had to put in the work to figure out everything. I feel that is why I have a competitive advantage in many ways, as there is a generation who is coming of age who can only ask a question to a bot and get an answer.
And hey, I do it too. I love asking Co-pilot to help, and I really like to ask it for code reviews!
The way I ground myself with this though is to not ask for specifics per-se but what are best practices. I am not sure I will ever trust a bot to refactor an entire solution, but small pieces of the whole, sure.
Why? Co-pilot doesn’t know you. It does not know what you know, it knows what has been input. Here is a prompt I use to ask for a code review:
”Using my .pylintrc and Sonar Cube’s recommendations for secure code, can you review X,Y or Z thing. Don’t worry about being perfect, or too clever - can you suggest some alternatives on how I can do this better?”
I have found that this prompt is super helpful, but not perfect. It is not the most complex prompt, tries to state clear boundaries and asks for alternatives.
What I am expecting it to do is look at my linting and Sonar Cube information in VS Code, take in their standards and give me output that points out what I may have missed.
With Claude, this seems to get a higher ratio of good answers vs. bad answers.
There are exceptions to this: it will over-code pydantic models all the time. Claude is just obsessed with overloading a pydantic model with nonsense. My favorite though, that I argue with it to stop doing all the time is with logging and how I have my linting configured specifically for logging.
If is ask a similar prompt and additionally ask: “Can you also add some logging into my code“ - somehow the results miss the basics about format strings and logging-format-interpolation (W1202)
TL;DR on this is that logging can be weird and what co-pilot consistently gives back in logger is:
logger.error(f”I am an error with this message: {message}”)
Instead of the standard set in my editor:
logger.error(”I am an error with this message: %s”, message)
I’m not trying to debate logging: you do you. However, in my spec it clearly states there is a standard being used.
W1202: Use lazy % formatting in logging functions (logging-format-interpolation)
And, fair point if none of that made sense if you don’t use python logging. Here is a medium post on this that will explain it better than I, but this is the point I love from this article:
Trust Your Linter
If you’re seeing those linting errors [from logging formats] — don’t ignore them! They’re not outdated and they aren’t useless — they will prevent you from making your logging call accidentally break your application!
And the point is, that I am specifically asking co-pilot to follow a standard. However, because I am not clearly stating “Use lazy % formatting in logging functions“ that directive for want of a better term is being dismissed as minutia.
This is why I want to have a better baseline of prompt information I can feed into co-pilot to have it avoid these scenarios. If co-pilot is going to review my code, then review it properly.
I am super cool with a template matrix, working on “Use/Avoid“ scenarios I can feed to AI, I just want a place to do it so I can be more productive in quantifiable way, rather than a “feels“ kind of way. It would be so cool to have a standards file I can point co-pilot to, that would make sense to me and to co-pilot.
It is not my place to tell anyone what is right for their org on AI coding, but I will say that my choice and my choice for teams I lead is to remain grounded in sustainable delivery that doesn’t destroy your return on investment, or worse get you sued.
I have absolutely 1000% seen bad code shipped to prod - hell, I’ve shipped bad code to prod. In my opinion, AI borking code is not new in the industry as humans bork code all the time. However, what should be new to the industry is that because we can inform AI as to what code quality standards we want, then I feel it is a poor choice to invest in junk script kiddie-esque solutions when folks can get a better answer.
Given the correct prompts and boundaries this is a reality now: today. I feel that as this space matures, in the end the ROI is to have shippable code that on the margins is better when reviewed both by bots and by humans.
My intuition is still telling me that the narrow knowledge of both humans and bots can be bridged by humans using their brains, earning their knowledge and applying that experience to being 10X+ developers by leveraging AI coding.
This is how I walk my walk and with my experience, going from 10x to 100x, because my code doesn’t break. Does yours?