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.

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.

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

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 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.

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.

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.

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

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.

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.

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.

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.

The details are important. You shape the details, and the details shape you in turn as well.

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.

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.

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.

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.