Motivation and Background

A lot of people are doing AI-assisted development. This is a practice which until recently was a somewhat niche and promising area of research. Today this tech is going mainstream. There are many tools offering to reduce time to delivery through the application of AI algorithms to software development processes. And some users of these systems can be quite enthusiastic about this new way or programming.

It seems clear that AI-assisted development tools are good at generating simple websites with little or no coding required by the operator. There remain many questions on the long-term use of these tools and the real impact they will have on software development productivity more generally. There are many applications for which maintenance and redevelopment costs dominate the costs of development. It appears to be less proven whether these tools will be able to cut these costs.

There are also significant environmental sustainability concerns regarding the electricity and water use of LLMs. The conditions under which AI-assisted development is performed as well as the specific uses to which this tecnology is put are also matters of ethical concern. While this article focuses on the practical use of AI-assisted development, any significant deployment of this technology should consider these broader concerns.

Set up

As someone who's been experimenting with these tools for a while, it might be helpful for me to share some of my more recent experiences with this technology. Please consider the following as case study in the use of these tools. For this experiment I intentionally took the stance as a beginner. I did not read manuals or tutorials (at first). I tried to hold the tools up to the standards of tooling that I've come to expect as a software developer.

The Simplest Possible Application

Years ago I developed a concept regarding the most simple starting point for a complex system. Just as systems like Google and Twitter started from a simple application and grew somewhat organically into very complex systems, one might wonder what the most simple yet useful application could be which could serve as a starting point for the development of an arbitrarily complex system.

We already have "hello world" which is a common starting point for understanding a programming language or platform. As helpful as it is, "hello world" is not a practically useful application. It doesn't "do" anything. For this experiment we'll need an application with basic practical utility.

For this, I developed a design for a mobile application with a single button. Pressing that button would cause a record to be written in a database (not located on the phone). The database could then be read to identify the times at which the button was pressed.

This may not sound like a practically useful application at first, but as a simple way to help remind me of notable events of my day, it actually works pretty well.

Primary Tool: Cursor

So this design was my starting point. The primary tool that I chose to evaluate was Cursor. My expectation was that Cursor would be able to understand what I wanted, to create a reasonable architecture for the application, and to generate the code to implement it, including the front-end design. I expected to do zero coding, and to have to read the code only to satisfy my curiosity about how it worked.

My thinking was that my ask to Cursor here was so minimal that it should be able to handle it without much fuss. Mainly I was asking Cursor to handle all of the mobile app development complexity -- configuration files and build process and all that nonsense that can make mobile development a pain.

Spoiler alert: Cursor did not come very close at all to meeting my expectations. While it eliminated some off the pain of the mobile development process, overall the experience was quite challenging and I am not sure whether Cursor provided much benefit at all.

Developing the Application

First off, I asked Cursor to plan my app. The plan it put together was pretty legible and I would call it reasonable from a high level. Of course, I didn't need a plan -- For such simple app I already had a design in mind. What Cursor came up with diverged from my assumptions in two ways. 1) It used a app-to-database approach, using a third-party database as a service provider, instead of standing up resources in AWS for the data tier. 2) It used a native toolkit to develop the front end.

After some reflection, I chose to keep #1 and reject #2. #1 would be slower to develop than the alternative, but it would give me exposure to an interesting technology that could in theory reduce my backend complexity. #2 I challenged because I wanted to do my coding in Go if possible. With some prodding Cursor gave me a front end written in Fyne.

Then I told Cursor to build it and it started spinning its wheels. Interestingly Cursor can take a long time to generate code, even for seemingly simple requests, where the constraints in place dictate a certain solution. But build it did, and I ended up with a mobile application as well as some SQL commands to give to the database provider to create the database.

Into the weeds

At this point I can just list some things that didn't work.

• The database code for inserting records into the database was not correct.
• In many places Cursor seemed to be using outdated code that did not match the version of the libraries or services it had selected.
• The Fyne code compiled and ran on OS X, but just gave me a blank screen on the phone.

So then I did some things.

• I introduced a domain model using the Nonzero Sum Design Language tools. Overall, this helped with Cursor's hallucinations. The model was fixed, and if Cursor's code didn't match thee interfaces, it was easily rejected.
• I decided to revert plan #2 and go back to using Kotlin for the front end. Cursor barfed up an app for me which also didn't work. I was being lowered into mobile debugging hell. Well, I'd been here before. Removing the multi-platform layer (Fyne) at least reduced the surface area for what I had to debug. I'd like to get back to Fyne at some point as it seems promising.
• I fussed with getting the SQL to work. Cursor would make suggestions inline. Some I'd keep, most I trashed. It was very annoying. On balance Cursor helped me get the syntax for the SQL client, which was new to me, but I'm not sure it did any better there than I would have gotten from a few Google searches.

Clutching victory from the jaws of slop

So Cursor's front end seemed reasonable but what do I know? I am not a mobile dev expert. So I put it in android studio and yet again produced another brick. After many tries at simplifications and messing around with the threading model, I asked Android studio "Why is this s***t not working?" and it merrily identified some typos and other garbage that Cursor had put into the config file. Then it introduced me to the logger and before long my app was running on my phone. Happy dance time!

After that, it was just coding as I have always done to get it over the finish line. That work included developing an app to display and extend the data that was being written to the database by the app. During that time I had Cursor over my sholder, throwing spaghetti at the wall, with a low hit rate. It is hard to say whether Cursor helped or hurt at this stage. It is probably fair to say that Cursor kept me out of the flow state with its constant barrage of low-quality suggestions.

Overall, my experience was mixed. Instead of hours it took days to complete the task. Instead of a joyful experience, it was mostly frustrating work. The tooling was a patchwork -- I had to piece together the experience using Cursor, Gemini, Android studio, and Google searches. As a product, AI-assisted development is feeling pretty rough at the moment.

Perhaps you might read this and come to other conclusions. I'd be interested in hearing them!

Without any real basis, I am hopeful that for climate-friendly use cases, AI-assisted development can be an ethical choice. For now I will continue experimenting and building with this technology -- exploring to find its edges and useful control points. There is clearly value here to be mined if one can keep a scientific mindset and avoid getting too carried away. And tools like the Nonzero Sum Design Language can help programmers bring these AIs into alignment as we learn how to work with them.