I Tried Building a Real App with AI. It Took a Year(alexhyett.com) |
I Tried Building a Real App with AI. It Took a Year(alexhyett.com) |
The 6 months of cleanup is something a true no-code vibe coder would have never done. I also think that kind of person might be inclined to keep AI going down the simplest development lane possible, which probably means using a more web-native technology rather than a native app that relies on an IDE the AI can’t work well with.
Something like Expo, for example.
I found that the most time consuming part of iOS app development in a vibe coder scenario was the various “red tape” of the process for the App Store including submission.
Before AI dev was expensive so I'd spend hours planning features. I filled 5 notebooks with UI sketches and data schemas and lists of names of what to call things. Building was more or less final as I only had 5-10 hrs a week max and wanted to move on.
Now I type directly into the Claude Code chat box and it writes it in front of me. I haven't planned a thing in months. As a result the app swings wildly around based on my whims and feelings. I can rewrite the whole thing based on something I thought of in the shower. Then days later I realize it isn't right and I rebuild it again. All of the rewrites have done a number on the code and I see dead patterns everywhere from stuff long since deleted.
In a professional app I'd have others to hold me accountable so it's not exactly the same but AI has made it very easy to make a lot of bad apps quickly. If you know exactly what you want though it can feel like magic.
I just hope it's still respecting the data loading and caching algorithms I designed so carefully cause I wouldn't know if it wasn't anymore.
But, thanks to the magic of keeping track of time and tasks, I have discovered:
- I am not all that faster when project timelines are concerned
- I've often built things with AI with the latest and greatest technologies that I've always wanted to learn but never did, like write a microservice backend with the trendiest frameworks with infrastructure as code and all the bells and whistles, while previously I was content with a server executable sitting on disk (maybe in a container), writing to a sqlite db file next to it.
- The new tech has serious performance DX/UX and cost issues. While previously deployment was just a copy, now I have to wait for terraform to churn through the monstrosity I made with AI. Debugging is hard.
- There's no prestige in building with fancy tech. AI can build using microservice orchestration. It can build using a simple CRUD blob as well. You just have to ask it. A lot of appeal of said fancy tech lay in prestige, newness, and exclusivity, and it sucks in very tangible ways.
- I used to be much more awesome than I gave myself credit for. Looking back at my old code, the amount of highly dense and quality code I cranked out during my productive periods was way more than I though, and you could feel it was thought through. Rather than doing the feature sloppily then fixing the 5 corner cases, like AI does, I carefully considered execution flow and made sure the simple looking code actually did everything correctly. This meant that it had a ton of missing mental context that I couldn't replicate just by looking at it after a long while, and touching the code without rebuilding it was a futile exercise.
- I fooled myself into thinking I understood what AI was doing, but in reality, I was far less aware than I expected and needed to be
That is what I love about coding. Not just insofar as it's necessary and useful (it is both), but just as a puzzle in its own right, to a fault. It's just a type of "imagination" that I don't really apply often otherwise, since e.g. I'm not into math, not an organizer or manager etc. Though I did have jobs where I instantly saw ways to optimise some things I do credit to having practised with code. You just try to think through what will happen given the known landscape and the given decided plan, what could happen given the known unknowns, how your heuristics would deal with that, and unless it's all green you see if you can change the landscape, the plan, explore some unknowns, and/or improve your heuristics (by which I just mean what you use to make ad-hoc decisions when things don't go according to plan). That kind of becomes a habit which can get applied to and improve lots of things. Measure twice, cut once, so I don't have to spend three days because of a stray comma (again).
Is it bad from a user or performance perspective, or just untidy and unaesthetic from a developer’s perspective? Because the developer’s perspective is becoming increasingly unimportant as LLMs become the main readers and writers of the code.
Users really like stability of their experience. They want the things that are working to keep working. If something is bit weird but acceptable they expect it to continue like that. Going back and forth between things might be the worst. After bad bugs like data being lost or thing not working at all.
Until the LLM itself becomes confused by the 10 layers of old patterns that weren't fully deleted from the code base, 5 of which do more or less the same thing but in minutely different ways that cause issues.
Developers and companies who put real care into their product will come out on top. A large part of that is going to be, what not to build - something AI agents will always say yes to.
To be fair, was always the case but its only going to be made more apparent as AI scales out.
Now, I can't promise it's advice is worth taking, but they do seem to be taking strides at judging the relevancy of some needless additions.
We can definitely mould AI agents to think more critically about these things, I dont know how effective it will be in the long term honestly.
Is it typically bug hunting on edge cases? Feature requests? If the initial product is polished enough, what can I realistically expect to run into down the line?
In my opinion, the basics of software engineering haven't changed, it's just faster to write the code.
e.g. the below plan is just applicable for humans or LLMs when building systems that are sensitive to small changes/errors and have catastrophic failure modes. (e.g. trading, avionics, health etc)
1. Have a very detailed plan of how you want it to work
2. Break the work into components
3. Work on each component and test the component extensively
4. Once that component is good, move on to the next component
5. Tie all those components together and confirm they work via integration tests etc
There is a STRONG temptation to just tell the LLM "Build me a system" but that is a bad idea and was also a bad idea with humans.
Sure, LLMs speed up #2 and possibly #3. For #3 specifically, almost all of the top developers I know are using LLMs to write the code but are writing the tests by hand or spending most of the time reviewing the test code written by LLMs. I would argue that this is how it should be.
Using LLM tools can greatly accelerate development when used effectively, it can enable much smaller high performing teams to be much more effective. But it's not magic and if you're holding it wrong it really can be a hindrance rather than a benefit.
I've given up trusting lifetime anything from the app stores now.
Mobile OSs seem to evolve so much faster, add new layers of security, lock pro features behind app store billing APIs that require the developer's account remains in good standing.
I've been burnt by three apps cutting and running now. One where the developers got their prize jobs at Microsoft and AWS [1], another where they sold the app off to another company that gave up maintaining it [2] and finally EA (enough said) [3]
[1]: https://news.ycombinator.com/item?id=46768909
[2]: https://www.androidpolice.com/2018/04/16/beyondpods-first-pu...
[3]: https://web.archive.org/web/20190116224256/https://answers.e...
The details are important. You shape the details, and the details shape you in turn as well.
I didn't find app building to take that long, even without knowing the ins and outs of kotlin and swift.
I did find the process of publishing the app to be one of the hardest things. The last 10 - 20 percent of app development still requires a lot of paperwork of you aren't already a developer.
> I started with a simple hello world application. Then added in the habit list, the ability to add a habit, edit a habit and so on.
This hands-on, incremental approach works, of course. But I don't think it is the most effective way of using LLMs to write apps.
1. Which apps should be built like this?
2. Which apps shouldn't be built like this?
My instinct is that any app worth building and using for a long time should be built incrementally. Otherwise, slop.
There is so much confusion around "the AI bubble". I am sure a lot of things will deflate, fail, people will go out of business, model development might slow, people might lose money on hopeful 1000x investments – but not because from here on out we suddenly notice that AI capability was all just illusionary and we will not want it anymore.
In terms of capabilities, at the very least, what we now have will be here, forever. LLMs will be here, and they will be used, until something better comes along.
Is there really much use in deconstructing a vibe coding process that was used before the term "vibe coding" existed? It's like critiquing a caveman's fire-starting routine.
> Meanwhile, the senior developers are in 2 camps. One half are using AI for absolutely everything but are slowly losing their ability to code. The other half are so sick of AI and are getting burnt out having to write prompts every day that they just don't want to do it anymore.
Again, this sounds like what developers were saying about AI a year ago. The refrain from the development world hasn't sounded like that for a while.
EDIT: Okay, Andrej tweeted about Vibe Coding on February 3rd 2025, and Claude Code was released in the same month. But Cursor was already there (I can see usage starting January 2025 in my account and know that it took me a few weeks before I tried it).
Pretty much every job I've had since 2003 involved cleaning up human-written slop.
For the moment, I'm finding that AI speeds up certain things: It can bang out unit tests in a few minutes, or do 80% of the work for me; but once it gets to the "test, make small change, test" loop, that's all done by hand.
The problem lies in convincing other people to use it. So far I am the only user.
And, this is not a new experience. I have a utility to change the gamma ramp in a GPU, for windows, that still works in Windows 98, XP, 10, and 11, even Linux and X Window with Wine, and so far I am the only user.
I wrote it because I had an old CRT that was too dark and unusable with the default gamma.
So now everyone can do these one-user apps. Welcome to my world :)
Now I have 20 YOE in software too before the booon of AI.
The hard part were actually the sales but I'm getting quite some, going physically(!) to places.
Hosting costs $50, revenue is ~1k/month, nothing special but its basically on autopilot.
I did have the app for 6 months for free on a first client where they would give me feedback bugs etc until i felt it was stable.
I don't even have a pricing page, i try to see how much i get can from each client, from $5/mo to $100/mo
Last September they declared that the app was "too valuable to give away for free" and told me I had to subscribe to use it. Even though it hadn't been free, I'd paid for it, and nothing about it had changed in the decade since I paid for it. Everything else was already locked behind a subscription I didn't find value in.
Seems like a lot of companies these days think "lifetime" means "until we really really want more money"
Also, the more and more every {expletive deleted} app thinks that the simple features are worth a $14.99/month subscription, the more sense going to open source makes. Yeah, it can be a bit annoying. But "a bit annoying" starts winning out over "a cumulative $200/month set of subscriptions" eventually.
I went through a previous thought experiment about what would happen when we moved a paid up front feature behind a subscription. This was the outcome I came to. Unless the user bought and installed a physical app, on the desktop, outside of an app store, they were going to get the rug pulled out from under them.
Instead, I've settled on a top-down approach: I write an in-depth spec for the whole app first, then have the LLM implement reviewable sections of it.