My First LLM App

My beliefs about what LLMs can accomplish have changed from a little skepticism to more optimism. I’ve written two apps using LLMs while on paternity leave, one of them I shipped (well, soon will) to the iOS app store. I used both Google’s Antigravity and Anthropic’s Claude. Both are impressive.

The App

The app allows me to track how much milk my baby drinks and how much he naps. I consider it as the same complexity as a TODO app. I provided high-level product requirements instead of the code I wanted it to write. The LLM initially chose to write a react native app, a technology stack I have no experience with. I allowed it to continue and with just a three or four prompts I had a working app.

I decided to convert the react native app to a swift iOS app, again that I have no experience with. I wanted to share Core Data with my wife who also has an iPhone, and it looked like CloudKit supported it. Antigravity was able to do this with just a few prompts.

I switched to Claude next because Xcode didn’t offer antigravity as an option. I haven’t been counting, but I’m guessing it took less than 10 prompts to get a working app on my phone.

I can’t believe how quickly I had a working app! This was a fun experience, resonating with Mattias’s experience. I’ve lost track of the times I’ve started projects only to abandon them 20% through.

Takeaways

Companies that figure out how to make LLMs work with pre-LLM codebases will have a competitive advantage. Our job is to bring value to the company. How can we make LLMs deliver on their hype and work for us and our companies?

I realize that a large portion of my success and excitement comes from building a brand new app and not adding a complex feature to pre-LLM codebase. I do that with my day job and have mixed-but-positive results. That leads me to think how we can get the results of a brand new app with old code.

Should we change the way we work with existing and future code?

LLMs do provide a competitive advantage under the right conditions. I’ve seen that with creating new apps. But I’ve had mixed results at my day job working on a large, pre-LLM codebase. How do we get the LLMs to perform close to the new app experience?

• Do we write better documentation for the code we write? In-code documentation, external documentation?
• Should the documentation include a few examples of how to use the code?
• Do we need to write better APIs and define clear boundaries?

These are best practices that we should be following already. But sprint planning is next week and we still have two stories left, maybe I’ll write a TODO instead. Our code will be better off if we do any of these even if LLMs crash and burn from their expense.

Choose popular frameworks?

Should us engineers now include “likely to work best with LLM” when we get the rare chance to choose a new framework? The case for in-house frameworks is getting weaker. I’m assuming LLMs will be better equipped to write code for popular frameworks given how often react is chosen (See Paul Kinlan’s post on dead framework theory)

Be curious

Try to make LLMs work for you. Don’t try it once dismiss it for the next 6 weeks after observing sub-optimal results. What happens if your competition figure it out before you do? Think about what could have improved the results. Write some things down. Discuss it with colleagues and friends. Do something, but don’t abandon all attempts.

Will it even matter?

Perhaps it’s all just hype and we’ll be back to where we started in a year or two after the cash runs out.