Artificial Intelligence is quickly taking over many tasks in the world. From the drive-thru speaker at your favorite fast food spot to scanning your home surveillance camera feeds to determine if that intruder is a human or just the neighbor’s cat, it’s everywhere. It’s no surprise, then, that it’s also effecting software engineering on the scale that it is. So, how am I using AI in my development processes?

Issues

When a bug report comes in, I personally review and verify each one. From there, the code in question is modified to remove the issue and tested (again, by me). Then the AI comes in to play. The modified code is submitted to the AI for independent testing and edge case investigation. I tell the AI something like:

I just fixed this error: <description of error>. Look for any issues this may cause elsewhere or any edge cases that I may have overlooked. Report back with new issues including severity, reproduction steps and proposed corrections.

The AI will review the changes and, depending on its findings, list whatever I messed up or didn’t catch. Then the process becomes a back-and-forth of fix and review with the AI until I’m satisfied. Usually it’s a one-and-done type scenario where I fix, it says “hey, you overlooked this”, I fix that, and it pats me on the head. A bit demoralizing, but it does help me catch issues I might not have previously.

New Products

One of the things I enjoy most about being a software engineer is building cool new things, so I’m very hesitant to hand over much of this process to AI. Working on auto-pilot in this regard just doesn’t appeal to me due to the thought that I might need to modify code later without AI and having it be so complex that I can’t understand what needs to change is horrifying. So, while I don’t write every line, I get to be creative and improve my output.

I start with the idea. Let’s say I want to create GraffitiWidget. I know what I want GraffitiWidget to do, how I want it to do that, and what I want it to look like. So I start with basic scaffolding. I build out the public API that I know I want, create a fairly long-winded description of GraffitiWidget, then hand it over to the AI. Let’s say GraffitiWidget is a collection class that stores and displays a bunch of GraffitiWidgetItems. I’ll create the base class with a private items() as GraffitiWidgetItem property and the support method signatures such as Add, AddAt, IndexOf, LastIndex, Remove, RemoveAll, RemoveAt. Next I’ll create the GraffitiWidgetItem class with its public API, such as a Title property. Finally, I’ll start writing the drawing code in GraffitiWidget‘s Paint event.

Once I have all of this basic scaffolding done along with some documentation on appearance and behaviors, and a rudimentary Paint event handler, I can turn it over to the AI with a prompt that’s something like:

This is the prototype project for GraffitiWidget. <implementation details and documentation> Fill in the scaffolded methods, make feature suggestions, and analyze my Paint event handler for obvious errors. Create test cases for functionality regardless of which of us wrote the code. Implement features present in documentation that do not currently exist in the source code.

Now we’ve got something cooking and this all took a very short amount of time. From there, I can orchestrate the AI to add or remove certain features, change colors used, implement additional test cases, etc. The AI asks me about each proposed modification, I verify that the proposed change is something I want and either approve, deny, provide alternate instruction, or jump in and code it myself. More often than not, I’m still jumping in and coding these things myself.

After some time, GraffitiWidget is looking pretty good. The AI and I have built something together that I believe is worth progressing from prototype to product. At this point I ask the AI to perform a full over-arching code review for bugs and performance, creating additional test suite cases as needed. And here’s another point where it shines: performance.

See, performance can be quite tricky. More advanced language features across the board (whether working in Xojo, TypeScript, C# or any other language) tend to require more advanced coding concepts and are sometimes fragile resulting in application crashes or hangs. Coding LLMs are pretty good at spotting bottlenecks then working in those advanced features to improve performance significantly and sometimes in ways that I’d not considered.

All-in-all, time from idea to product is cut significantly, and that’s a huge help in any codebase. You’ll see this first-hand in the next release with GraffitiProEditor, which is a product I’ve come back to off-and-on for years when I have the time and inclination. Using AI allowed me to finally push through my coder’s block on some implementation details, refine my data model, and vastly improve performance.

Code Review

Another way I’ve started using AI is to review my old code. For GraffitiSuite, this means I give it access to the source code then this prompt:

This is the GraffitiSuite Desktop source code, written in Xojo. Perform a full code review and look for API inconsistencies, missing descriptions, potential exceptions, or unintended behaviors. Create a list of each in a file called review.md with the following data: class/module name, method/event/property name, file name, line number, description of issue, and proposed solution. Make no changes without my explicit instruction.

This, of course, takes quite some time, but it gets me a well-defined list of things to investigate myself. From there, I check out each reported issue, verify the findings, then I can either fix it myself or tell the AI:

Fix review issue 12 with the proposed solution.

Or

I fixed review issue 12. Mark it off of our list.

Or even (and this comes up more often than I thought it would)

Review issue 12 is not a real bug. Mark it off of our list.

This process has allowed me to make significant sweeping changes throughout GraffitiSuite Desktop, iOS, and Web in a comparatively short amount of time, including updating the code for language changes over the years, typos, and improving documentation.

Conclusion

I’m still not too enamored with the idea of turning over my work to AI completely. I want to know what’s being created in my name, be able to understand it, and certainly have the ability to modify it on my own in the future. That said, it’s certainly helping with the more mundane and tedious aspects of my work.