5 ms·

I Tried Building a Real App with AI. It Took a Year

111 points by surprisetalk 3mo ago

robertlagrant 3mo ago
This is how I hope the world will continue to be, because then programming, which is one of the most enjoyable things ever, may remain a human task, assisted by AI and other tools.
- rpdillon 3mo ago
  Yes! There are a lot of people over using AI right now and a lot of people abstaining, but ultimately I think the development process described in the post will be where we settle. I was told at work that we should adopt AI faster because "we're falling behind" and I tried to explain that the speed of light has not changed. It's our human ability to understand the code and our ability to make decisions about what to do next. AI can only speed up parts of it.
smalltorch 3mo ago
Were you using exclusively free plans to build your app? 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.
- InsideOutSanta 3mo ago
  If you read the article, you'll see that the author took the same approach one would use when writing an app manually from scratch: > 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.
  - smalltorch 3mo ago
    It's not apparent if these were exclusively free LLMs though. I still don't quite understand the time scale unless the author didnt pay...which would be really impressive
  - oblio 3mo ago
    > 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.
    - InsideOutSanta 3mo ago
      I don't think any app should be built like this. Rather, I think this approach should be used when you already have a large codebase and are making atomic changes to it. In fact, I think taking this approach for greenfield work is more likely to result in slop because early accidental decisions turn into fundamental design choices. 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.
      - oblio 3mo ago
        Most apps, just like most buildings, aren't greenfield, though :-)
      - zem 3mo ago
        I write greenfield projects this way and have continued to do so with LLMs. it works very well if you have a decent idea of the architecture you are heading towards, and if you are willing to refector aggressively if you have a better idea. to me the key point is that I get those better ideas a lot more readily by looking at the code than by planning up front - I have a good feel for when adding the next feature is harder than it should be, or when the resulting code is messier than I would like, and seeing the concrete code usually gives me the best idea for how exactly to improve it.
gwbas1c 3mo ago
> Spending your time cleaning up AI slop that you didn't want to write in the first place doesn't sound like much fun. 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.
- acedTrex 3mo ago
  Human written slop is SIGNIFICANTLY more enjoyable than LLM slop, it tells a story no matter how bad the dev is. LLM slop is a tidal wave of meaningless drivel.
  - subscribed 3mo ago
    As a someone who's fixing my own slop from the all the past years and with the help of the good coding agent, no less, no, human slop is not enjoyable, it's embarrassing.
Jeremy1026 3mo ago
So, how much was hand-written after the initial 6 hours? It sounds like quite a bit. My experience has been very different. I haven't gotten to the point of releasing anything from AI yet, but I'll spend a weekend throwing prompts, then I'll have an application that does the thing that I asked it to do. I'll use the application over the next week or so keeping a task list of things that I'd want to tweak, bugs, or features that are missing, then I share that document with the AI and tell it to clear the list. If I'm building something with AI, I really don't touch the code. If there is a bad pattern the code, I flag it in my task list and tell the AI to fix it.
- InsideOutSanta 3mo ago
  Yeah, I think not manually fixing issues, but telling the LLM to fix them and update its own documentation to reflect the fix, is a somewhat unpleasant but necessary approach. Otherwise, the LLM is just going to make the same mistake again elsewhere, or randomly revert your change, or get confused.
bradfa 3mo ago
Making production software is still hard. You still need to know what you're doing. Making good software still requires significant investment of time and intelligence. 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.
- player1234 3mo ago
  [dead]
- oblio 3mo ago
  Powertools without safety features, basically.
thenatureboy 3mo ago
Pretty sure I could bang this out in a day now w/ Claude/Codex.
spprashant 3mo ago
I think we are moving from "can you build this product?" to "do i trust you to support this product?". Software is cheap, trust is a premium. 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.
- smalltorch 3mo ago
  What are the actual maintenance items you will run into for offline utilities if the initial version has been throughly tested and works exactly how you want it? 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?
  - spprashant 3mo ago
    The OS changes all the time, Apple/Google stop supporting an API your app relied on, security vulnerabilities get published, even stupid stuff like timezone changes can break a perfect app in strange ways.
    - oblio 3mo ago
      Besides that, security cipher updates, internet protocol updates, there are a myriad ways applications that stand still can break.
  - jorisw 3mo ago
    Software will never be truly stable as long as their environment (the world, ultimately) is not stable
- dpoloncsak 3mo ago
  I will say, when working with the recent batch of frontier models, even the last batch, if you ask "Do you think we should xyz" it may sometimes push back for an alternate solution. 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.
cube00 3mo ago
> There is an option to buy a lifetime licence but it costs a whopping £44.99. 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 https://news.ycombinator.com/item?id=46768909 [2]: https://www.androidpolice.com/2018/04/16/beyondpods-first-public-update-two-years-reportedly-buggy-unusable/ https://www.androidpolice.com/2018/04/16/beyondpods-first-pu... [3]: https://web.archive.org/web/20190116224256/https://answers.ea.com/t5/Other-EA-Mobile-Games/Monopoly-App-Being-Removed/td-p/6484879 https://web.archive.org/web/20190116224256/https://answers.e...
- malfist 3mo ago
  My weightlifting app sold me a pro unlock to get weight calcualors years ago. Then they introduced a subscription model to get that plus some features I didn't want, they promised my purchase would be respected for all time. 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"
  - diskzero 3mo ago
    That is rough. I assume this is a web application? 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.
    - 3mo ago
over_bridge 3mo ago
I've used AI for building a hobbyist note app myself. It's also a mixed bag but a lot of that comes down to how I've changed. 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.
- Chance-Device 3mo ago
  > AI has made it very easy to make a lot of bad apps quickly 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.
  - SoftTalker 3mo ago
    Code that is untidy and unaesthetic from a developer’s perspective is also likely to be confusing to a user and perform or scale poorly, in my experience at least.
    - Chance-Device 3mo ago
      I think these are separate things. I get the heuristic you’re applying, but with rigorous testing code quality doesn’t matter the same way anymore. Indeed, what is quality?
Shorel 3mo ago
I tried building a real app with AI. It took a week or two. 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 :)
feverzsj 3mo ago
If there is "NO AI" certification, people will always choose such products.
- agos 3mo ago
  "always" is a bit strong here.
  - hn_submit 3mo ago
    No it isn't. I don't trust A.I. to generate maintainable and correct code and the people that use are too lazy or incompetent to write it themselves so I don't trust them either. Ergo: I'd always go for "NO A.I. WAS USED IN CREATING THIS PROGRAM"
    - agos 3mo ago
      I'm sure you will, but "people" in general will not give a crap about it and continue to choose the most convenient/cheap/ergonomic thing and only a minority will look at such a certification (which does not exist)
      - hn_submit 3mo ago
        They will when software starts failing left and right. And companies too when they realize their developers are unable to fix the software because they have no idea how it works. Companies chasing pipe-dreams of getting rid of all those developers will go bust in a couple of years. At the very least their brand image will be tarnished.
ipunchghosts 3mo ago
The authors experience is not mine. I have an app/website combo deployed that is getting 60+ visitors a day and the app is getting downloaded weekly. Both are growing. All "vibe" coded. Now I have 20 YOE in software too before the booon of AI.
- zedascouves 3mo ago
  same here. Did a timeslot management app for beauty salons etc. Tons of features, never once looked at source or even database (C#+pgsql) 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
  - kevinrineer 3mo ago
    > 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 That seems ethical. Vibes based fees.
    - zedascouves 3mo ago
      It is, and it is common practice. Dressed up as additional features like everyone else. Every feature cost me the same (tending to $0), but i price them as i see fit.
mvkel 3mo ago
> This was just before Claude Code was released so this wasn't full agentic hands-off engineering. Instead, I broke down the development into lots of small tasks and went through them manually with the AI, testing each change as I went 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.
- arendtio 3mo ago
  I am not exactly sure, but my gut feeling is that Cursor existed before Claude Code was released, and the term vibe coding existed already at that time. 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).
  - ModernMech 3mo ago
    People were using the word "vibe" to describe this process as early as 2023: https://simonwillison.net/2023/Dec/31/ai-in-2023/ https://simonwillison.net/2023/Dec/31/ai-in-2023/ Here it's called "Vibes Based Development"
  - mvkel 3mo ago
    My point was that it was critiquing a development process from 2023 in 2026, regardless of the term used.
xnx 3mo ago
If you started to build an app today, it would take a month. Models and infrastructure are very different now.
lilerjee 3mo ago
Developing an app involves in many details, and AI cannot solve or think about all of them, many details will use default values, make up some values, or just left blank. The details are important. You shape the details, and the details shape you in turn as well.
jstummbillig 3mo ago
> If the AI bubble does ever pop, I am not sure there is going to be enough competent developers left who are willing to pick up the pieces. 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.
vanyaland 3mo ago
llms write bad core data sync code by default, so that icloud bug tracks. merge policies and conflict resolution i still end up doing by hand
alexpotato 3mo ago
I've spent a lot of time in my career as a SRE/DevOps which includes running MANY outages due to a combination of uncaught bugs and/or crazy infra failures. [0] 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. 0 - https://x.com/alexpotato/status/1215876962809339904 https://x.com/alexpotato/status/1215876962809339904
Ecsta 3mo ago
I made a simple app to solve a local/personal problem for people in my area. Keeping it focused made it fairly easy to get it built. I spent more time on the marketing website and images than I did building the actual app haha.
meerita 3mo ago
[flagged]
nullbio 3mo ago
Yep. AI will speed you up a bit, but it's no panacea.
Grombobulous 3mo ago
I think the author arrived at the sort of bad middle trench of AI: where you use it knowing how the code works and trying to fit it into a paradigm (Xcode) that it’s not well-suited for. 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.
rahimnathwani 3mo ago
If I were building a habit tracking app for iOS I wouldn't start from scratch. Even if I had a completely new take on the UI, I would try to reuse or adapt a data model from an existing app. The easiest way to do that would be to clone the repo for the open source Loop habit tracker: https://github.com/iSoron/uhabits https://github.com/iSoron/uhabits and then ask Claude Code to study the data model and API, and help me think through what I need to add/change to support the features I want. Once the data model is in great shape, then let the AI go and build, test, iterate etc.
frizlab 3mo ago
Obligatory “it’s Xcode with a lowercase c” comment. I know, not very interesting but it drives me mad…
momentmaker 3mo ago
I have similar experience as the author where I don't know the first thing about Swift but I was able to make my first iOS app[0] from start to finish on the initial release in about 3 weeks. I think the hardest part was actually automating the release pipeline to directly upload to the App Store for a release with Test Flight. It wouldn't have been possible without Claude's help. Then next hard and tedious part was do a complete conversion to Android with Kotlin, which I also didn't have any experience either. That one-to-one parity was rather painful but it was done in about a month or so. Now I just develop create features on the iOS version first and then do a parity match with the Android version after with Claude. [0] https://github.com/walktalkmeditate/pilgrim-ios https://github.com/walktalkmeditate/pilgrim-ios
jimrandomh 3mo ago
The first thing to check for, in accounts like this, is "which AI model"? There is a subset of people who somehow don't realize how important that decision is, and don't mention or don't foreground which AI model they were using. This sort of person invariably gets much worse results out of AI, because they turn out to be using a shit-tier low-cost model instead of something that's actually good at what they're using it for.
effnorwood 3mo ago
Copilot isn't very good, you're right.
animanoir 3mo ago
[dead]
tim-projects 3mo ago
I've been working on an app over a year. I think it needs to be considered that agent cli's only really released about a year ago. Before that, I was copy and pasting code between web chat windows into a terminal. Additionally, the ai models only got good in November/December last year. How easily we forget. The result of this? I had to do several full rewrites and there are still many bugs left over from these. AI simply wasn't powerful enough to do the task and littered the codebase with issues that I'm still even now dealing with.
keeda 3mo ago
Maybe it's my PTSD from developing iOS apps speaking, but this reads to me more like an indictment of developing on Apple platforms than developing with AI. Even if it's partly about AI from a year ago. I haven't really done any iOS-native programming in about a decade, but I have spent a godless number of days working through bugs, inconsistent behaviors, poor documentation, and weirdly broken builds in Xcode and iOS and various SDKs, and then going through a different version of the same hell for every new release. Like, after suffering through the first few upgrade cycles, I started keeping a journal of repeated issues that came up, hoping I could reference it and save me some headache the next time... and then the journal just kept growing!! Every goddamn new release had a bunch of new headaches to deal with. I recently touched upon some iOS/MacOS-related development (Safari extensions), hoping things had improved over the years, and immediately ran into frustrating dev experiences. Unfortunately I'll be doing more of this. TFA was light on the details, but it still left me with a bit of a 1000 yard stare.
hoppp 3mo ago
What I find a problem is when I build everything with AI then if I have a flaw in a fundamental concept it can become very hard to refactor, to the point that the project can die. So far I never built anything that didn't need human in the loop, otherwise things just don't function well or my ideas are not translated as well.

111 points by surprisetalk 3mo ago

This is how I hope the world will continue to be, because then programming, which is one of the most enjoyable things ever, may remain a human task, assisted by AI and other tools.

rpdillon 3mo ago
Yes! There are a lot of people over using AI right now and a lot of people abstaining, but ultimately I think the development process described in the post will be where we settle. I was told at work that we should adopt AI faster because "we're falling behind" and I tried to explain that the speed of light has not changed. It's our human ability to understand the code and our ability to make decisions about what to do next. AI can only speed up parts of it.

smalltorch 3mo ago

Were you using exclusively free plans to build your app? 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.

InsideOutSanta 3mo ago
If you read the article, you'll see that the author took the same approach one would use when writing an app manually from scratch: > 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.
- smalltorch 3mo ago
  It's not apparent if these were exclusively free LLMs though. I still don't quite understand the time scale unless the author didnt pay...which would be really impressive
- oblio 3mo ago
  > 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.
  - InsideOutSanta 3mo ago
    I don't think any app should be built like this. Rather, I think this approach should be used when you already have a large codebase and are making atomic changes to it. In fact, I think taking this approach for greenfield work is more likely to result in slop because early accidental decisions turn into fundamental design choices. 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.
    - oblio 3mo ago
      Most apps, just like most buildings, aren't greenfield, though :-)
    - zem 3mo ago
      I write greenfield projects this way and have continued to do so with LLMs. it works very well if you have a decent idea of the architecture you are heading towards, and if you are willing to refector aggressively if you have a better idea. to me the key point is that I get those better ideas a lot more readily by looking at the code than by planning up front - I have a good feel for when adding the next feature is harder than it should be, or when the resulting code is messier than I would like, and seeing the concrete code usually gives me the best idea for how exactly to improve it.

gwbas1c 3mo ago

> Spending your time cleaning up AI slop that you didn't want to write in the first place doesn't sound like much fun. 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.

acedTrex 3mo ago
Human written slop is SIGNIFICANTLY more enjoyable than LLM slop, it tells a story no matter how bad the dev is. LLM slop is a tidal wave of meaningless drivel.
- subscribed 3mo ago
  As a someone who's fixing my own slop from the all the past years and with the help of the good coding agent, no less, no, human slop is not enjoyable, it's embarrassing.

Jeremy1026 3mo ago

So, how much was hand-written after the initial 6 hours? It sounds like quite a bit. My experience has been very different. I haven't gotten to the point of releasing anything from AI yet, but I'll spend a weekend throwing prompts, then I'll have an application that does the thing that I asked it to do. I'll use the application over the next week or so keeping a task list of things that I'd want to tweak, bugs, or features that are missing, then I share that document with the AI and tell it to clear the list. If I'm building something with AI, I really don't touch the code. If there is a bad pattern the code, I flag it in my task list and tell the AI to fix it.

InsideOutSanta 3mo ago
Yeah, I think not manually fixing issues, but telling the LLM to fix them and update its own documentation to reflect the fix, is a somewhat unpleasant but necessary approach. Otherwise, the LLM is just going to make the same mistake again elsewhere, or randomly revert your change, or get confused.

bradfa 3mo ago

Making production software is still hard. You still need to know what you're doing. Making good software still requires significant investment of time and intelligence. 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.

player1234 3mo ago
[dead]
oblio 3mo ago
Powertools without safety features, basically.

thenatureboy 3mo ago

Pretty sure I could bang this out in a day now w/ Claude/Codex.

spprashant 3mo ago

I think we are moving from "can you build this product?" to "do i trust you to support this product?". Software is cheap, trust is a premium. 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.

smalltorch 3mo ago
What are the actual maintenance items you will run into for offline utilities if the initial version has been throughly tested and works exactly how you want it? 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?
- spprashant 3mo ago
  The OS changes all the time, Apple/Google stop supporting an API your app relied on, security vulnerabilities get published, even stupid stuff like timezone changes can break a perfect app in strange ways.
  - oblio 3mo ago
    Besides that, security cipher updates, internet protocol updates, there are a myriad ways applications that stand still can break.
- jorisw 3mo ago
  Software will never be truly stable as long as their environment (the world, ultimately) is not stable
dpoloncsak 3mo ago
I will say, when working with the recent batch of frontier models, even the last batch, if you ask "Do you think we should xyz" it may sometimes push back for an alternate solution. 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.

cube00 3mo ago

> There is an option to buy a lifetime licence but it costs a whopping £44.99. 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 https://news.ycombinator.com/item?id=46768909 [2]: https://www.androidpolice.com/2018/04/16/beyondpods-first-public-update-two-years-reportedly-buggy-unusable/ https://www.androidpolice.com/2018/04/16/beyondpods-first-pu... [3]: https://web.archive.org/web/20190116224256/https://answers.ea.com/t5/Other-EA-Mobile-Games/Monopoly-App-Being-Removed/td-p/6484879 https://web.archive.org/web/20190116224256/https://answers.e...

malfist 3mo ago
My weightlifting app sold me a pro unlock to get weight calcualors years ago. Then they introduced a subscription model to get that plus some features I didn't want, they promised my purchase would be respected for all time. 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"
- diskzero 3mo ago
  That is rough. I assume this is a web application? 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.
  - 3mo ago

over_bridge 3mo ago

I've used AI for building a hobbyist note app myself. It's also a mixed bag but a lot of that comes down to how I've changed. 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.

Chance-Device 3mo ago
> AI has made it very easy to make a lot of bad apps quickly 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.
- SoftTalker 3mo ago
  Code that is untidy and unaesthetic from a developer’s perspective is also likely to be confusing to a user and perform or scale poorly, in my experience at least.
  - Chance-Device 3mo ago
    I think these are separate things. I get the heuristic you’re applying, but with rigorous testing code quality doesn’t matter the same way anymore. Indeed, what is quality?

Shorel 3mo ago

I tried building a real app with AI. It took a week or two. 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 :)

feverzsj 3mo ago

If there is "NO AI" certification, people will always choose such products.

agos 3mo ago
"always" is a bit strong here.
- hn_submit 3mo ago
  No it isn't. I don't trust A.I. to generate maintainable and correct code and the people that use are too lazy or incompetent to write it themselves so I don't trust them either. Ergo: I'd always go for "NO A.I. WAS USED IN CREATING THIS PROGRAM"
  - agos 3mo ago
    I'm sure you will, but "people" in general will not give a crap about it and continue to choose the most convenient/cheap/ergonomic thing and only a minority will look at such a certification (which does not exist)
    - hn_submit 3mo ago
      They will when software starts failing left and right. And companies too when they realize their developers are unable to fix the software because they have no idea how it works. Companies chasing pipe-dreams of getting rid of all those developers will go bust in a couple of years. At the very least their brand image will be tarnished.

ipunchghosts 3mo ago

The authors experience is not mine. I have an app/website combo deployed that is getting 60+ visitors a day and the app is getting downloaded weekly. Both are growing. All "vibe" coded. Now I have 20 YOE in software too before the booon of AI.

zedascouves 3mo ago
same here. Did a timeslot management app for beauty salons etc. Tons of features, never once looked at source or even database (C#+pgsql) 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
- kevinrineer 3mo ago
  > 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 That seems ethical. Vibes based fees.
  - zedascouves 3mo ago
    It is, and it is common practice. Dressed up as additional features like everyone else. Every feature cost me the same (tending to $0), but i price them as i see fit.

mvkel 3mo ago

> This was just before Claude Code was released so this wasn't full agentic hands-off engineering. Instead, I broke down the development into lots of small tasks and went through them manually with the AI, testing each change as I went 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.

arendtio 3mo ago
I am not exactly sure, but my gut feeling is that Cursor existed before Claude Code was released, and the term vibe coding existed already at that time. 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).
- ModernMech 3mo ago
  People were using the word "vibe" to describe this process as early as 2023: https://simonwillison.net/2023/Dec/31/ai-in-2023/ https://simonwillison.net/2023/Dec/31/ai-in-2023/ Here it's called "Vibes Based Development"
- mvkel 3mo ago
  My point was that it was critiquing a development process from 2023 in 2026, regardless of the term used.

xnx 3mo ago

If you started to build an app today, it would take a month. Models and infrastructure are very different now.

lilerjee 3mo ago

Developing an app involves in many details, and AI cannot solve or think about all of them, many details will use default values, make up some values, or just left blank. The details are important. You shape the details, and the details shape you in turn as well.

jstummbillig 3mo ago

> If the AI bubble does ever pop, I am not sure there is going to be enough competent developers left who are willing to pick up the pieces. 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.

vanyaland 3mo ago

llms write bad core data sync code by default, so that icloud bug tracks. merge policies and conflict resolution i still end up doing by hand

alexpotato 3mo ago

I've spent a lot of time in my career as a SRE/DevOps which includes running MANY outages due to a combination of uncaught bugs and/or crazy infra failures. [0] 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. 0 - https://x.com/alexpotato/status/1215876962809339904 https://x.com/alexpotato/status/1215876962809339904

Ecsta 3mo ago

I made a simple app to solve a local/personal problem for people in my area. Keeping it focused made it fairly easy to get it built. I spent more time on the marketing website and images than I did building the actual app haha.

meerita 3mo ago

[flagged]

nullbio 3mo ago

Yep. AI will speed you up a bit, but it's no panacea.

Grombobulous 3mo ago

I think the author arrived at the sort of bad middle trench of AI: where you use it knowing how the code works and trying to fit it into a paradigm (Xcode) that it’s not well-suited for. 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.

rahimnathwani 3mo ago

If I were building a habit tracking app for iOS I wouldn't start from scratch. Even if I had a completely new take on the UI, I would try to reuse or adapt a data model from an existing app. The easiest way to do that would be to clone the repo for the open source Loop habit tracker: https://github.com/iSoron/uhabits https://github.com/iSoron/uhabits and then ask Claude Code to study the data model and API, and help me think through what I need to add/change to support the features I want. Once the data model is in great shape, then let the AI go and build, test, iterate etc.

frizlab 3mo ago

Obligatory “it’s Xcode with a lowercase c” comment. I know, not very interesting but it drives me mad…

momentmaker 3mo ago

I have similar experience as the author where I don't know the first thing about Swift but I was able to make my first iOS app[0] from start to finish on the initial release in about 3 weeks. I think the hardest part was actually automating the release pipeline to directly upload to the App Store for a release with Test Flight. It wouldn't have been possible without Claude's help. Then next hard and tedious part was do a complete conversion to Android with Kotlin, which I also didn't have any experience either. That one-to-one parity was rather painful but it was done in about a month or so. Now I just develop create features on the iOS version first and then do a parity match with the Android version after with Claude. [0] https://github.com/walktalkmeditate/pilgrim-ios https://github.com/walktalkmeditate/pilgrim-ios

jimrandomh 3mo ago

The first thing to check for, in accounts like this, is "which AI model"? There is a subset of people who somehow don't realize how important that decision is, and don't mention or don't foreground which AI model they were using. This sort of person invariably gets much worse results out of AI, because they turn out to be using a shit-tier low-cost model instead of something that's actually good at what they're using it for.

effnorwood 3mo ago

Copilot isn't very good, you're right.

animanoir 3mo ago

[dead]

tim-projects 3mo ago

I've been working on an app over a year. I think it needs to be considered that agent cli's only really released about a year ago. Before that, I was copy and pasting code between web chat windows into a terminal. Additionally, the ai models only got good in November/December last year. How easily we forget. The result of this? I had to do several full rewrites and there are still many bugs left over from these. AI simply wasn't powerful enough to do the task and littered the codebase with issues that I'm still even now dealing with.

keeda 3mo ago

Maybe it's my PTSD from developing iOS apps speaking, but this reads to me more like an indictment of developing on Apple platforms than developing with AI. Even if it's partly about AI from a year ago. I haven't really done any iOS-native programming in about a decade, but I have spent a godless number of days working through bugs, inconsistent behaviors, poor documentation, and weirdly broken builds in Xcode and iOS and various SDKs, and then going through a different version of the same hell for every new release. Like, after suffering through the first few upgrade cycles, I started keeping a journal of repeated issues that came up, hoping I could reference it and save me some headache the next time... and then the journal just kept growing!! Every goddamn new release had a bunch of new headaches to deal with. I recently touched upon some iOS/MacOS-related development (Safari extensions), hoping things had improved over the years, and immediately ran into frustrating dev experiences. Unfortunately I'll be doing more of this. TFA was light on the details, but it still left me with a bit of a 1000 yard stare.

hoppp 3mo ago

What I find a problem is when I build everything with AI then if I have a flaw in a fundamental concept it can become very hard to refactor, to the point that the project can die. So far I never built anything that didn't need human in the loop, otherwise things just don't function well or my ideas are not translated as well.