Hacker News Reader

Comment by rdslw | Hacker News Reader

Congrats on the app.

I'm seeing that "great-ai-unlock" is happening. I see in last month a lot of new software being codeveloped with claude/codex/gemini/you-name it.

Before, it was too costly to do sth like the Posture app: here, you would have to know Swift and apple apis to write such tool. Would you be C# (very good) programmer with free weekend, and an idea: no cookie for ya.

These days, due to "great-ai-unlock" your skills can be easily transferred and used to cross platforms boundary and code such useful app in a weekend or so.

Jevons paradox is indeed working (https://en.wikipedia.org/wiki/Jevons_paradox).

View on HN

Maybe this is a naive take, but I don't really think LLMs have done that much to change the actual situation around ability/outcomes. If you are actually a very good C# programmer, knowing Swift and searching some Apple documentation seems very reasonable.

It might help "unstick" you if you aren't super confident, but it doesn't seem to me like it's actually leveling up mediocre programmers to "very good" ones, in familiar or unfamiliar domains.

> I don't really think LLMs have done that much to change the actual situation around ability/outcomes

from my own experiences and many others I have seen on this site and elsewhere, I'm not sure how anyone could conclude this.

> it doesn't seem to me like it's actually leveling up mediocre programmers to "very good" ones

Oh well then if this is your metric then maybe your take is correct, but not relevant? From the top level comment I thought we were talking about the bar being lowered for building something thanks to AI and you don't need to become any better at being a programmer to do so.

I don't care how good of a programmer you are, if you don't know Apple stuff (Swift, Xcode, all the random iOS/Mac app BS) you aren't making an Apple app in a weekend. Learning things is easy but still takes time, and proficiency is only earned by trying and failing a number of times — unless you're an LLM, in which case you're already proficient in everything.

No I can confirm this. I am at least an average C# dev, with 16 years of experience.

I have built a very nicely responsive real-time syncing iOS app in what amounts to a weekend of time. (I only have an hour here and there, young kids) I had zero iOS/Swift development experience prior to it.

I can also confirm that this wouldn't have been built if it weren't for Claude Code. It's "just" an improved groceries app, that works especially well for my wife and me.

Without LLM's, and with just an hour here and there, I wouldn't have done the work to learn the intricacies of iOS and Swift dev, set up the app, and actually tweak and polish it so it works well -- just to scratch the itch of a bit better groceries handling.

Thanks rdslw. I mentioned something similar on my blog post about this app here: https://tomjohnell.com/posturr-a-macos-app-that-blurs-your-s...

I love coming up with fun ideas and only having to worry about the fun part - not the toil. I would never have made this app without llm support.

Neat app. Any tips on how you used Claude Code to develop this?

My first prompt was:

"Help me develop a MacOS app that blurs my screen the closer my mouse is to the top of the monitor"

That was my PoC to see if there's APIs Claude could find that would make this easy to do. Once I proved that worked, I asked it to instead help me devise a way to adjust that blur based on my posture. It suggested the vision framework and measuring head height.

Just kept iterating, one step at a time. Any toil I experienced, I asked it to remove or automate.

This is going to sound very basic, but did you do it in a blank repo or did you use the cloned integration in Xcode, or a third thing I'm not thinking of?

Not the OP, but I’ve had success starting with a blank app created by Xcode with the appropriate language/frameworks (ie something that will already run but does nothing). You then ask Claude to start from that point.

The only issue I’ve had is sometimes Xcode not ‘seeing’ new files that Claude has created along the way, and needing to add these manually into the Xcode project. (A Google around suggests this shouldn’t happen if you create the project in the right way, and yet it still sometimes does.)

I have had good success with using xcodegen and only a project.yml checked in. Claude can get tripped up on managing the xcode project xml.

However, before that, i set up a blank project in xcode, used the xcode github integration to create a new repo on github, set up one xcode cloud workflow and use it to push one build to testflight. That way, you get all the automatic config of app ids, profiles etc, and xcode cloud can not be enabled other way. Then tell claude to migrate to xcodegen and to run it in CI automatically.

I've started to develop iOS apps from scratch using only claude code web (no mac), by setting up a "Branch Build" workflow in xcode cloud, and a skill that teaches claude how to check builds and fetch logs.

Along with a workflow that pushes any merge on main to internal TestFlight, the dream of developing iPhone apps on the iPhone finally lives. I've tried most options for this over the years and they never stuck.

These are simple apps that build in 1-5 min on xcode cloud. For larger builds it probably won't work so well.

I don't see how the Jevons paradox would apply here. Code being cheaper and faster to produce obviously causes the demand for apps such as this one to grow. That's just supply and demand.

An example of where I think the paradox would apply might be one where LLMs made software engineers more efficient yet the demand for SWEs would grow.

What a stupid thing to call a paradox. When infrastructure is better, you'd expect it to be used more.

It's because they're misusing the term. Jevons' paradox doesn't apply to the simple idea that "cheaper code leads to more demand for code", that's just the concept of price curves.

Instead, Jevons' paradox refers to a counterintuitive rebound effect: AI tools make engineers more productive, which you'd expect to reduce the marginal demand for additional engineers (since the same output requires fewer people). In reality, this efficiency lowers the effective cost of software development, sparking even greater overall demand for new features and projects, which ultimately increases total spending on engineering talent.

Jevons paradox is a failure mode, not something that "works".

Reply on news.ycombinator.com