A LinkedIn post by Soumen Sarkar highlighted how tech can become depressing though negative feedback in particular.
Where code reviews become tense and some engineers “lacked tact and nuance”.
I suggested a fix where
“Code review responses could be passed through an LLM that removes everything except technical details, and leaves out personal comments.
And an LLM could be the first layer of code review fine tuned on previous reviews with only technical details.”
In this post I will explore a proof of concept using a local LLM, namely mistralai/Mistral-7B-v0.1 q8_0
Say you have this code review:
This structure choice is terrible, it should be consolidated into a list, and what were you thinking hard coding prices!?
They should be pulled from the database!:
price_1 =10.00
price_2 = 20.00
price_3 = 25.00
price_4 = 50.00
Like this! :
product_prices = [prices pulled from database here]
An LLM filtered review with the following instructions.
Filter the following review for any overly negative feedback, and rephrase in a friendly professional way. Do not use exclamation marks. Only revise remarks, do not alter code:
[content of review]
And the result:
The current structure choice could be improved, and I suggest considering consolidating the prices into a list instead of hardcoding them directly into variables. It would also be beneficial to pull prices from the database rather than manually entering them. Here is an example of how this could be implemented:product_prices = [prices_from_database]
A bit verbose, but much less aggressive. And this can be taken farther with a LLM pre-review that could include instructions on organizational coding standards as part of the context.
Here is a very basic concept example:
Review the following Python code for quality, and DRYness. Make suggestions for improvement for issues. Phrase the review in a friendly professional way. Be concise and give an example of how the code could be improved by returning adjusted code.
Code standards to be followed:
– no data hardcoded – pull from database
– variables naming should use camel caps
[code to be reviewed]
And the result:
Dear [Author],
Thank you for sharing this Python code. Here are some suggestions for improvement in terms of quality and DRYness:
- Data should not be hardcoded in the code. It is better to pull data from a database instead. This makes the code more flexible and easier to maintain.
- Variable naming should follow camel case convention. Using camelCase for variables makes the code more readable and self-explanatory.
Here is an updated version of the code that incorporates these suggestions:
import sqlite3
def get_prices(conn):
cursor = conn.cursor()
cursor.execute("SELECT price FROM items")
prices = [row[0] for row in cursor.fetchall()]
return prices
def main():
conn = sqlite3.connect('database.db')
prices = get_prices(conn)
print(f"Prices: {prices}")
conn.close()
if __name__ == '__main__':
main()In this updated version, the get_prices() function retrieves the prices from a SQLite database using the sqlite3 module. The main() function creates a connection to the database and calls the get_prices() function to retrieve the prices. Finally, it prints the prices to the console and closes the database connection.
By following these best practices, the code is more robust, maintainable, and DRY.
This is a very simplistic example; prompting and result could be refined significantly, but the core result is there.
