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
I Tried Building a Real App with AI. It Took a Year
41–50 of 90 posts
Re: I Tried Building a Real App with AI. It Took a Year
#42I 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.
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.
I agree with your observation. Although the framing of the question signals some of the response "Do you think.. " forces the model to check for the cost-benefits.
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.
Re: I Tried Building a Real App with AI. It Took a Year
#43> 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…
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.
Re: I Tried Building a Real App with AI. It Took a Year
#44I'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.
Re: I Tried Building a Real App with AI. It Took a Year
#45I'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…
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.
Re: I Tried Building a Real App with AI. It Took a Year
#46> 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 priz…
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…
Simple hack for yourself: Simply disbelieve all "lifetime" claims, presumptively. I do.
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.
Re: I Tried Building a Real App with AI. It Took a Year
#47I 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.
Re: I Tried Building a Real App with AI. It Took a Year
#48[flagged]
Re: I Tried Building a Real App with AI. It Took a Year
#49I'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…
> 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.
Depends on how it manifests. If things change every app release sometimes for better sometimes for worse and nothing really stays consistent over time it is clearly bad for user.
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.
Re: I Tried Building a Real App with AI. It Took a Year
#50I'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…
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 infrastructur…
> I carefully considered execution flow and made sure the simple looking code actually did everything correctly
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).