There are three things to make money:

- tell lies to ones who want to hear lies -> riches

- tell truth to ones who want to hear truth -> modesty

- tell truth to ones who want to hear lies -> bankruptcy

p.s. read it on a blog name I dont remember :(

If my polite neighbour smiles, holds the door, but also pisses on my doormat every few days, I call him LOUD a jerk and tell him to stop. I never approve the piss because he said good morning.

How is this a fair analogy? The NYT isn't pissing on your doormat. Making it harder to cancel is an annoyance, but it's not like they don't let you.

Thank you for writing this and your below longer comment.

I printed them with OP to remind me any time i’m afraid somebody can criticize my work and that it’s not worth to produce/write/publish.

no matter how good, there will always be people like you here, so no need to worry.

## performance data for token generation using lmstudio

- gemma4-31b normal q8 -> 5.1 tok/s

- gemma4-31b normal q16 -> 3.7 t/s

- gemma4-31b distil q16 -> 3.6 t/s

- gemma4-31b distil q8 -> 5.7 tok/s (!)

- gemma4-26b-a4b ud q8kxl -> 38 t/s (!)

- gemma4-26b-a4b ud q16 -> 12 t/s

- gemma4-26b-a4b cl q8 -> 42 t/s (!)

- gemma4-26b-a4b cl q16 -> 12 t/s

- qwen3.5-35b-a3b-UD@q6_k -> 52 t/s (!)

- qwen3.5-35b-a3b-uncensored-hauhaucs-aggressive@q8_0 -> 34 tok/s (!)

- qwen3.5-35b-a3b-uncensored-hauhaucs-aggressive@bf16 -> 11 tok/s

- qwen3.5-27b-claude-4.6-opus-reasoning-distilled-v2 q8 -> 8 tok/s

- qwen3.5 122B A10B MXFP4 Mo qwen3.5-122b-a10b (q4) -> 11 tok/s

- qwen3.5-122b-a10b-uncensored-hauhaucs-aggressive (q6) -> 10 tok/s

interesting, I just tried this very model, unsloth, Q8, so in theory more capable than Simon's Q4, and get those three "pelicans". definitely NOT opus quality. lmstudio, via Simon's llm, but not apple/mlx. Of course the same short prompt.

Simon, any ideas?

https://ibb.co/gFvwzf7M

https://ibb.co/dYHRC3y

https://ibb.co/FLc6kggm (tried here temperature 0.7 instead of pure defaults)

try Unsloth recommended settings

    Thinking mode for general tasks: temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

    Thinking mode for precise coding tasks (e.g. WebDev): temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0

    Instruct (or non-thinking) mode for general tasks: temperature=0.7, top_p=0.8, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

    Instruct (or non-thinking) mode for reasoning tasks: temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

(Please note that the support for sampling parameters varies according to inference frameworks.)

all the examples for visual UI, are tasks which already are (or soon be) done by the agent, not human. hence not needed.

I suspect that final(*) UI is much more similar to TUI: being kind of conversational (human <> AI). Current GUIs provided by your bank/etc are much less effective/useful for us, comparing to conversation way: 'show/do me sth which I just need'. Not to mention (lack of) walled garden effect, and attention grabbing not in the user interest (popups, self-promo, nagging). Also if taking into account age factor. Also that we do not have to learn, yet another GUI (teach a new bank to your mom ;). So at least 4 distinct and important advantages for TUI.

My bet: TUI/conversation win (*).

*) there will be some UI where graphical information density is important (air controller?) especially in time critical environments. yet even there I suspect it's more like conversation with dynamic image/report/graph generated on the go. Not the UI per se.

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

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?

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.

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

Can you expand with more technical explanation how are those two points implemented:

- You can bring your shell environments / init scripts / aliases with you in a noninvasive way. I.e. you don't have to modify the remote system dotfiles, when you connect through xpipe it will set up any scripts you want to have available automatically

- You can link up your password manager with your SSH client and other connection methods that require passwords

Feel free to write here or refer to any url you recommend.

Thank you, and good luck with your product!

- When XPipe will open a terminal connection and you have specified custom shell environments / init scripts for a certain system, it will first automatically create a temporary init script on the target system in the background, which will be run as the login script only for that terminal launch from XPipe. That way it's noninvasive and doesn't change any existing configuration on the system

- XPipe acts as an askpass program for SSH, meaning that it can listen to any password requests made from the ssh client, forward that your password manager, and reply with the password that the password manager returned. If you password manager supports the SSH-agent, XPipe can also use it to supply keys for ssh as well.

Authy has one superb feature: you can switch a toggle to lick/unlock accessing a vault from new devices.

quite handy and can further increase security (trading it of course with lack of recovery would you lost all your devices).

Interesting, thanks for sharing!

> Do not whitewash harmfull practice as the law.

You say that as if "The Law" is not already a set of whitewashed harmful practices.