Seconded, I would be interested in knowing people's workflows + experiences developing MacOS and iOS apps with claude, etc.
From the repo here, it looks like its just using swift command line tools, which might just work well enough with cursor/vscode/etc. for small projects. You won't have Xcode's other features but maybe thats fine for an agentic-first development workflow.
Since LLMs were introduced, I've been of the belief that this technology actually makes writing a *more* important skill to develop than less. So far that belief has held. No matter how advanced the model gets, you'll get better results if you can clarify your thoughts well in written language.
There may be a future AI-based system that can retain so much context it can kind of just "get what you mean" when you say off-the-cuff things, but I believe that a user that can think, speak, and write clearly will still have a skill advantage over one that does not.
FWIW, I've heard many people say that with voice dictation they ramble to LLMs and by speaking more words can convey their meaning well, even if their writing quality is low. I don't do this regularly, but when I have tried it, it seemed to work just as well as my purposefully-written prompts. I can imagine a non-technical person rambling enough that the AI gets what they mean.
Thats a fair counterpoint, and it has helped translate my random thoughts into more coherent text. I also haven't taken advantage of dictation much at all either, so maybe I'll give it a try. I still think the baseline skill that writing gives you translates to an LLM-use skill, which is thinking clearly and knowing how to structure your thoughts. Maybe folks can get that skill in other ways (oration, art, etc.). I don't need to give it essays, but I do need to give it clear instructions. Every time it spins off and does something I don't want, its because I didn't clarify my thoughts correctly.
Setting up SpeechNote with Kokoro is one of the the best things I've ever done.
I can speak faster than I type, and the flow state is much smoother when you can just dump a stream of consciousness into the context window in a matter of seconds. And the quality of the model is insane for something that runs locally, on reasonable hardware no less.
Swearing at an LLM is also much more fun when done verbally.
The prompt the user enters is actually not the prompt. Most agents will have an additional background step to use the user's prompt to generate the actual, detailed instructions, which is then used as the actual prompt for code generation. That's how the ability to build a website from "create a website that looks like twitter" is achieved.
My 85 year-old father could probably resolve 90% of his personal technology problems using an LLM. But for the same reason every phone call on these subjects ends with me saying "can it wait until I come over for lunch next week to take a look?", an LLM isn't a viable solution when he can't adequately describe the problem and its context.
Yeah, we've already seen that over the past few decades. It's both a limitation and a benefit, but until recently it was the only thing we had (well that, and just hiring another person to act as an LLM for us). LLMs are an upgrade.
> No matter how advanced the model gets, you'll get better results if you can clarify your thoughts well in written language.
This definitely agrees with my experience. But a corollary is that written human language is very cumbersome to encode some complex concepts. More and more I give up on LLM-assisted programming because it is easier to express my desires in code than using English to describe what forms I want to see in the produced code. Perhaps once LLMs get something akin to judgement and wisdom I can express my desires in the terms I can use with other experienced humans and take for granted certain obvious quality aspects I want in the results.
> So far that belief has held. No matter how advanced the model gets, you'll get better results if you can clarify your thoughts well in written language.
I've heard it well described as a k-type curve. Individuals that already know things will use this tool to learn and do many more things. Individuals that don't know a whole lot aren't going to learn or do a whole lot with this tool.
Fortunately for it, that city is mounted on some antigrav sled and moves around to always stay ahead of the launch vehicle, safe from my totally not intentional attempts at crashing into it.
Completely unrelated bug: pitch control can go down only to -5 degrees.
One thing I have been doing is breaking out of my long-held default mode of spinning up a react/nextjs project whenever I need frontend, and generating barebones HTML/CSS/JS for basic web apps. A lot of the reason we went with the former was the easy access to packages and easy-to-understand state management, but now that a lot of the functionality packages used to provide can be just as easily generated, I can get a lot more functionality while keeping dependencies minimal.
I haven't tried C or ASM yet, but it has been working very well with a C++ project I've been working on, and I'm sure it would do reasonably well with bare-bones C as well.
I'd be willing to bet it would struggle more with a lower-level language initially, but give it a solid set of guardrails with a testing/eval infrastructure and it'll get its way to what you want.
Pretty interesting take this. I wonder if there is a minimal state management we could evolve which would be sufficient for LLMs to use while still making it possible for a human to reason about the abstraction. It won't be as bloated as the existing ones we came up with organically however.
I mean, you're basically LLM-washing other people's code, then. All those UI components that other people wrote and at least expected attribution may not be libraries anymore, sure. But you've basically just copied and maybe lightly modified that code into your project and then slapped a sticker on it saying "mine." If you did that manually with open source code, you'd be in violation of the attribution terms almost all the licenses have in common. But somehow it's okay if the computer does it for you?
It is a gray area. What if you took Qt, removed macros, replaced anchoring with css for alignment, took all widget properties out into an entity component system and called it ET, could Trolltech complain? It is an entirely new design and nothing like they built. A ship of Theseus if you will.
The Ship of Theseus has nothing to do with the identity of the parts. That is not in question at all; they are explicitly different parts. The thought experiment is the question of the identity of the whole.
Qt in your example is a part. You're application is the whole. If you replaced Qt with WxWidgets, is your application still the same application?
But to answer your question, to replace Qt with you're own piecemeal code doesn't do anything more to Qt than replacing it with WxWidgets would: nothing. The Qt code is gone. The only way it would ship-of-theseus itself into "still being Qt, despite not being the original Qt" would be if Qt required all modifications to be copyright-assigned and upstreamed. That is absurd. I don't think I've ever seen a license that did anything like that.
Even though licenses like the GPL require reciprocal FOSS release in-kind, you still retain the rights to your code. If you were ever to remove the GPL'd library dependency, then you would no longer be required to reciprocate. Of course, that would be a new version of your software and the previous versions would still be available and still be FOSS. But neither are you required to continue to offer the original version to anyone new. You are only required to provide the source to people who have received your software. And technically, you only have to do it when they ask, but that's a different story.
We used higher level programming languages because "Developer time is more expensive than compute time", but if the AI techbros are right, we are approaching the point where that is not going to be true.
It's going to take the same amount of time creating a program in C as it does in Python.
Potentially, a lot of that isn't just code generation, it *is* requirements gathering, design iteration, analysis, debugging, etc.
I've been using CC for non-programming tasks and its been pretty successful so far, at least for personal projects (bordering on the edge of non-trivial). For instance, I'll get a 'designer' agent coming up with spec, and a 'design-critic' to challenge the design and make the original agent defend their choices. They can ask open questions after each round and I'll provide human feedback. After a few rounds of this, we whittle it down to a decent spec and try it out after handing it off to a coding agent.
Another example from work: I fired off some code analysis to an agent with the goal of creating integration tests, and then ran a set of spec reviewers in parallel to check its work before creating the actual tickets.
My point is there are a lot of steps involved in the whole product development process and isn't just "ship production code". And we can reduce the ambiguity/hallucinations/sycophancy by creating validation/checkpoints (either tests, 'critic' agents to challenge designs/spec, or human QA/validation when appropriate)
The end game of this approach is you have dozens or hundreds of agents running via some kind of orchestrator churning through a backlog that is combination human + AI generated, and the system posts questions to the human user(s) to gather feedback. The human spends most of the time doing high-level design/validation and answering open questions.
You definitely incur some cognitive debt and risk it doing something you don't want, but thats part of the fun for me (assuming it doesn't kill my AI bill).
Yep, I literally built this last night with Opus 4.5 after my wife and I challenged each other to a typing competition. I gave it direction and feedback but it wrote all the actual code. Wasn't a one shot (maybe 3-4 shot) but didn't really have to think about it all that hard.
With another more substantial personal project (Eurorack module firmware, almost ready to release), I set up Claude Code to act as a design assistant, where I'd give it feedback on current implementation, and it would go through several rounds of design/review/design/review until I honed it down. It had several good ideas that I wouldn't have thought of otherwise (or at least would have taken me much longer to do).
Really excited to do some other projects after this one is done.
Largely agreed, with one exception. If you're ever in Boston/Cambridge MA, check out the MIT museum. I've always told people that its a science museum but for adults. The Harvard museums are worth visiting as well, but the MIT museum really impressed me with their content.
The MIT museum isn't very good. It is a science museum for adults, but it is too passive an experience for the patron. I recommend the Exploratorium in San Francisco instead as the science museum for adults.
I've only been to a play (staged reading) at the new one but, in general, I'm not sure how interested most adults are in interactivity. I've been to the Exploratorium for an event and it was fun. (Having those sort of distractions are nice when you're tired of feeling like you need to speak to people at an event.) But not sure I'd have made a trip there otherwise.
Similar, My major in university was computer engineering (as opposed to pure CS or EE) because I wasn't sure if I wanted to go into a hardware or software profession. I ended up going with software since all the interesting opportunities were there, whereas most jobs in hardware seemed to be working for stodgy old companies barely making six figures if I was lucky.
It's made me one of the only leaders in my Software Org that actually knows what happens below the level of the instruction set. I can talk about the power and heat implications of algorithmic decisions. But mostly nobody cares, theres always enough money to buy more servers.
From the repo here, it looks like its just using swift command line tools, which might just work well enough with cursor/vscode/etc. for small projects. You won't have Xcode's other features but maybe thats fine for an agentic-first development workflow.
reply