Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by keeda - 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.by jimrandomh
- 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.
by momentmaker - 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 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.
- 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.
- 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.by rpdillon
- 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.by Jeremy1026
- 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.
- 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.
by bradfa - Powertools without safety features, basically.by oblio
- 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.
by Grombobulous - > 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
[2]: https://www.androidpolice.com/2018/04/16/beyondpods-first-pu...
[3]: https://web.archive.org/web/20190116224256/https://answers.e...
by cube00 - 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"
by malfist - 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.
by alexpotato - 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.
by spprashant - > "do i trust you to support this product?"
Excellent case for open source local software.
by xnx - 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?
by smalltorch - 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.
by dpoloncsak - > 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.
This right here!
I have very little issue with LLM-generated code, my issue is mostly with people throwing codebases over the fence, declaring it the best library/framework/app/platform/whatever and in 3 months I know the repo will say "Last commit 3 months ago".
Some things are "done" and don't need constant updates but most of the "bad" LLM code IMHO is the kind of stuff I know requires dedication (even if an LLM is writing all the code) and commitment to the library/etc for it to succeed.
If all you've done is vibe-coded something and aren't going to support it then I'll just vibe-code my own version tailor-made for my use-case that I can support myself.
I've thought about this a lot in relation to my side-business "could someone vibe code this?" and the answer is absolutely yes they could, but my customers don't come from me throwing code out into the world and walking away. My continued support, handling issues, being on-site for events (I make event-based software like food festivals) is where I provide the value. They've never once cared what the code looks like or how it works, it's the support they are really paying for. Someone to have the answers and track them down if they don't have the answer at their fingertips, that's the value I provide (and always have if I'm being honest).
Follow-through continues to be best way to achieve success IMHO.
by joshstrange - 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.
by over_bridge - I've been searching for the perfect notes app my whole life, and have been contemplating just building it myself now. I'd love if you could link me to your github and share it.by Gareth321
- > 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.
- I have noticed the exact behavior change on myself that you describe.
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
by torginus