bfbf
You could argue that these are just examples of laziness, but I think these are both tasks that require critical thinking, and it’s easier to hand them off to an llm that at least purports to do this for you.
I’d argue that both setting requirements, and self code review are both things that need careful attention. (What _exactly_ do you need doing? Does your work correctly do the thing that needs doing?).
I have no fundamental issue with using ai, but there’s no doubt that applying critical thinking to both these tasks directly, and to the broader question of “should I use ai for this job” should result in a different outcome.
Personally I would also not agree with your take that working with llms has allowed me to do “acute critical thinking”. It’s sped up my development time, sure, but I would argue that my evaluation of, say a new sdk now using Claude is far less detailed than it would’ve been in the past when I did it by reading docs. As a side note, I’ve been rereading Douglas Hofstadter’s GEB recently in paperback, and I’ve found a lot of joy in wrestling with paragraphs and writing notes in the margins. This is way more focussed attention than I really give anything when working with llms.
Obviously llms are far more complex than this, but I think this proves the point. The fact you had to add the “recent” qualifier there highlights that llms in general were bad and had to be provided with corrective targeted training data to improve. (And they still can’t count the R’s in strawberry!)
For me the issue is very clear: I happily use AI to answer tons of questions each day, but if I’m reading your website/blog/article/Jira ticket, I expect real human input.
It should matter whether the author “sweated over it for hours”, because that means they actually considered the best way to communicate something. If they didn’t do that, then they clearly don’t care enough about about the quality of their output and I shouldn’t spend any time at all on it. In fact it’s worse than that because if the author doesn’t respect the reader enough to craft their output, then I as a reader have no respect for their work, and I resent that they’ve taken my attention for the time it takes me to realize it’s ai generated. If you’re publishing Ai content, then I can only presume you have an ulterior motive than plain communication- in the case of OP I’d assume this is for ad revenue or clicks.
There are many types of writing, and I struggle to think of many where a statistical model could feasibly produce an acceptable output for the given intention.
Eg. A poet chooses their words extremely carefully; a good instruction manual is written by the designers of the product (not just guessing at a common or plausible method); a news article has an angle/story beyond just the facts.
Your previous experience was probably the agent running regular unit tests, which obviously don’t need ui environment, but mostly *do* need an iOS runtime, which is why it needs to boot the simulator.
An idiosyncrasy of the way unit tests are executed in Xcode is that they run from the actual app deployment target, and so while running unit tests you’ll also see any app initialisation and background tasks running at the same time. It’s quite a good idea to use compiler directives or launch arguments to disable the usual app setup in the App or App Delegate. Why this isn’t a built in option is beyond me, but it’s definitely confusing behaviour when you’re just running isolated tests!
“But why can’t you just do it?” Because I recognise the importance of consistent UX and an IA that can actually be followed.
Just like developers, (proper) designers solve problems, an we need to stop asking them for faster bikes.
Last month I did the majority of my work through an agent, and while I did review its work, I’m now finding edge cases and bugs of the kind that I’d never have expected a human to introduce. Obviously it’s on me to better review its output, but the perceived gains of just throwing a quick bug ticket at the ai quickly disappear when you want to have a scalable project.
BTW the dock doesn’t have to be hidden, and idk if it was a typo but alt+tab isn’t a default shortcut. Command is the key used for system shortcuts, so maybe you should have tried that? Like yeah it’s different but that doesn’t make it bad. If you been using it for 10 years without figuring that out…
—-
I’m with you on the 1st party apps though, and the stupid corners on Tahoe.
Apple’s documentation is often very poor, and I will note that Swift Packages (especially CLIs) doesn’t always feel great. As another commenter noted, anything other than Xcode feels like fighting an uphill battle.
But many of your frustrations could be solved by checking not API docs, but just the Swift language guide. You seem perturbed, for example, that the Package initializer expects ordered arguments. It is a basic part of Swift’s design that arguments are always ordered and exclusively are either named or unnamed (never optionally both).
The ghost’s use of semaphores with async/await is a massive red flag in terms of mixing two asynchronous frameworks (Concurrency and GCD). I’d not be surprised if it worked, but that’s really against the grain in terms of how either framework were designed. This is the shortfall of relying on bottled ghosts to learn new tools. I know from experience that the documentation on Concurrency (async/await) is pretty good, and lays out a clear rationale for how it’s intended to be used, but that is a huge piece of documentation and it’s a big hill to climb when all you’re building is a small tool. This is the risk we run when asking AI for help when it itself is ignorant of the actual intended use of the apis and is only trained on the output of developers. Here it’s easy to see that it was faced with a problem of synchronous access to an async function and reached for a common solution (semaphore), despite the fact that semaphores are part of a 10 year old framework, and the async/await keywords are only 2-3 years old!
Anyway, the article reminded me of the challenges of learning a new (programming) language. There’s more to it than just following tutorials and blindly directing AI. I know the feeling, having to currently learn c# at the moment. I can write simple functions and follow the syntax, but I can’t intuitively understand what’s happening like I can with Swift. Is that because Swift is better than C#? Not really- it’s just that I’m fluent in one but not the other. Ironically I guess you probably get this already from learning Mandarin, but you’ve not written an article about how frustrating it is that it inexplicably insists on using tones to express meaning, when English is fine without it(!).
I’m sorry you had a bad experience with Swift. I do genuinely think it’s a great language to write, and the open source Swift Evolution team are great. They are continually pushing for more openness and more cross platform compatibility, and I do like the way that the core of the language is strongly opinionated in a way that makes it clear what’s happening if you do understand the syntax. What’s hard is then the application of Apple’s APIs which are wildly inconsistent and often incomplete. Some are maintained while others are still wrappers for 15 year old objective C that have no concept of modern Swift paradigms. That said, I’d still encourage you to persevere with Swift. Once you get past those rough edges of stdio and UI and get into the heart of a Package, I would expect most of these complaints to disappear!