Voice of the DBA

Tag: AI

  • Barely Reviewed Code

    Years ago I was giving a talk on software development and asked the audience how long it takes to review a PR that has 10 lines changed. Answers were in the minutes to tens of minutes range. I then asked how long it takes to review a PR that has 1,000 lines changed. Some people said hours, but a few people said seconds.

    I’ve often taken the latter, pessimistic view. Not because I don’t think engineers want to do a good job, but because I know human behavior. Most humans will get bored, lose focus, and end up skimming through a large amount of code. Many (most?) people don’t want to spend all that time, after all they have they their own code to write. They’ll just approve the PR and assume testing will catch any major issues.

    Even if a reviewer wants to do a great job, they likely will still miss things. It’s very hard to focus across that much code.

    This is a funny visual (from X) about code reviews. It’s titled “me reviewing code written by Claude before pushing it to production.” Plenty of people are probably laughing, or thinking this is a good reason to not use an AI to write code.

    However, I don’t think the problem is an AI writing code. If you trust the AI without reviewing things, that’s on you. You deserve blame if things fall apart.

    The bigger problem is that an AI can write code so quickly and can make so many changes that PRs will tend to be large. These changes will tend to not get human-reviewed with any level of focus or quality control. The problem is volume, not who wrote the code (or the quality). Certainly quality matters, but it’s easy to catch changes if you have a small volume of code. Harder if you have a lot.

    The more I use AI for spot work, to handle tedious things, to do something like subtly adjust spacing in a UI or focus on adjusting a few things in a data model, the easier it is to judge the focus and quality of the code. Is the change doing the job I need done, and is it doing it well?

    Code quality is a problem we’ve had ever since we started writing code. AI can make the problem worse, not because of poor coding, but because it will write so much code in a PR that you can’t review it appropriately.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Prompt Requests

    One of the challenges of AI-assisted coding agents is that they tend to produce A LOT of code. Even in refactoring or migration changes, the AIs can work quickly and generate such a volume of code that the process starts to become overwhelming. For pull requests, for CI/CD build systems, and certainly for human reviewers, they can be overwhelmed. This can become a real problem with OSS projects, where submissions can grow exponentially to the point that maintainers stop looking at pull requests. I suspect the same thing might happen in corporate repositories when lots of developers can refactor or submit huge amounts of code produced by AI agents in a fraction of the time it took a year ago.

    I was listening to an interview with an experienced software developer and OSS project maintainer who said that he preferred getting a “prompt request” that contained a description of a problem and the specification for a solution that he could submit to his own LLM to get the code. Rather than use an AI to review a code in a PR written by a human or AI agent, a great prompt that can communicates the problem and solution is preferred.

    That’s a fascinating idea to me. Specify what you want and let the code owners send it to an AI and get a code response whose quality and focus they can decide to implement, based on their own context provided to an LLM (standards, style, patterns, etc.)

    Of course, for open source projects, perhaps the maintainer doesn’t want to spend time managing AI agents or working through quality, but this does allow them to focus on the idea being suggested rather than attempting to review code, test it, judge the quality, and perhaps request changes from the submitter. They can take your idea and implement it. If it’s a simple fix, even better, as the maintainer might get quick help from an AI, using the style of code they are used to (their own).

    Software engineering is changing a lot in the age of AI, and this seems to be one of the more interesting things I’ve seen suggested. Not YOLO or vibe-coding, but rather a prompt that suggests the idea and turns contributors into a specification written for the robot coder.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Everything is the right question away

    When I was young and needed to learn about something, I had to go to a library or a bookstore to get information. I often started by looking through an encyclopedia. I had to wander between entries to learn more about the topic I was researching. A few lucky friends had their own copy of an encyclopedia, which was nice since we could research at home. At some point these collections of information were moved to CD/DVDs, which made them more portable and more accessible to a larger group of people than in the past.

    In the 90s we had the innovation of search engines, which allows us to more quickly move through information. There was more information available on the Internet than was ever published in encyclopedias. Over the years, these search engines improved their ability to rank and recommend information that is relevant to your query. However, you still need some idea of what you are trying to learn about. You have to direct the searches, although the Google auto-complete felt very predictive at times.

    However, I heard a quote recently that is the title of this piece: everything is the right question away.

    That might seem like something a search engine or even an encyclopedia would help with, but consider the fact that with an AI LLM you don’t have to specify much at all to get started. You can even ask it the question of how do I do/learn/find something and get a result that seems better than any computer system in the past. It might be better than what you get from most humans as well.

    Of course, you might not get the answer you want or need, though you can continue to ask the LLM and refine what you need. What’s even better is that once you get a good answer, you can shortcut the route to that knowledge by asking the LLM to provide you with a better prompt to get you to the place you end up in faster.

    Asking the right question to get an answer is an age-old human problem. Philosophers and religious figures have debated and hinted at this for centuries. You still need to build strong communication skills to ask a clear question and some expertise to judge the results. AI LLMs, however, make this a much easier and quicker process than at any time previously in human history.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Writing as an Art and a Job

    I remember listening to an interview with Rick Reilly in the mid 2000s. He was the back page columnist for Sports Illustrated for years as well as a writer in various pieces. He talked about how he would lay on the couch in his office sometimes, trying to think of what to write. His kids would come in looking for attention, but couldn’t understand that Dad was “working”.

    I had been writing the editorials at SQL Server Central and I could relate. Moving from 2 to 5 (eventually 6) editorials a week was a lot of work. It was stressful in a way I couldn’t imagine when I started writing them. I quickly realized that if I had to produce a new one every day, I was in trouble. There would be days I’d struggle. I needed to have a queue of pieces at least partially ready if I were going to manage this job and find balance with my family.

    Recently I was listening to an interview with Lee Child, who writes the Jack Reacher series. He said that writing is both a creative endeavor and a job. It requires some inspiration and time, but it also requires you to buckle down and get to work. This is an area where delays are inevitable (everyone gets writer’s block) and if you aren’t thinking ahead delays will occur. Delays aren’t great for newspapers or other scheduled events.

    SQL Server Central became a newspaper.

    One of the things I did early on was start to enhance my powers of observation. There’s no magic here; it’s really a habit to look at things in your life in a different way. For me, this meant considering each question posted on the forums, each bug reported in SQL Server, each complaint/criticism/success through the lens of both telling a story and generalizing the wider issue.

    I learned to write about what I experienced by seeing the experience as a source of inspiration.

    I started keeping notes. First in a text file, then OneNote, then Evernote, and today, Joplin. As I would see something interesting in the world, I’d make a note, copy a URL, write a sentence or two. I then regularly go back and flesh out these ideas and add to them. It’s similar to the recommendations I make for blogging: make notes, expand those later.

    The job part of this was making time to write on a regular basis. I used to try and write every day. I had some success, but I also learned some days I struggle to articulate my thoughts. Rather than struggle, I learned to just abandon the effort and go do other work, or sometimes, go to the gym or get away.

    The flip side of that is that when I feel the writing is flowing, I write more. I don’t stop after one editorial (or blog) and I’ll try to tackle another one or two. If I struggle with one topic, I may find another easier, so I flip through notes and keep trying to get another one when I am in the mood to write. I sometimes find I can write 3 or 4 in a day and then not do much writing for another few days.

    Many of you reading this do technical work. You work on systems, or in code, or both. However, the world is changing. I started this piece with the 25th anniversary of SQL Server Central in mind, but really, AI is front of mind. I’ve had 3 conversations today about AI stuff, and the one thing that stands out is communication and clearly expressing yourself if crucial to getting AI to work well for you.

    Learn to write better. It helps in your communications with humans and with AI LLMs.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.