bfbf

Weird take. Just because you can use curl it doesn’t mean you can’t value a GUI to be able to store and manipulate requests quickly and view a formatted response body.

I use postman all the time to explore apis. Sure I could do it from the command line, but this is quicker and it saves my request payloads.

(Though now I’m obviously open to suggestions for better tools)

On a micro scale, yes I see this regularly at work: some devs blindly put up ai generated PRs that are fundamentally flawed or don’t actually complete the work in the ticket. It’s often trivial to check this. Similarly some tickets are written by ai that make incorrect assumptions about our product, resulting in nonsensical requirements.

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.

I mean a very quick check in ChatGPT got it wrong today, yeah! I’m not sure what model I was using, but it proves the point!

But people who are bad at maths are unlikely to be writing about maths. A crude example might be if you search for “2+2=” in the training data, you’re much more likely to find “4” as the next character.

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

But the OP already addressed this-he can just ask ChatGPT directly how to fix the brakes. He’s gone looking for a human expert because (for whatever reason) he doesn’t want that.

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.

Not the author but it likely means running automated UI tests in the sim, yes. This involves running the app and programmatically selecting and sending interaction events.

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!

Probably it’s less popular in America, but it’s huge in Asia, so I doubt the solitaire version is more well known globally

Thank you for this. Playing with my in-laws I’m always completely baffled by the scoring!

Do you have TestFlight installed? That’s the only other way I can think of delivering apps besides the App Store and MDM.

But that’s the point, no? Prototyping is useful but beyond a proof of concept, you still need a suitable user interface. I have no problems if there’s a rationale behind UI changes, but often we have stakeholders telling us to do something inconsistent just so their pet project can be presented to the user. That’s not design.

It’s amazing how many blank stares I get when I, as mobile engineer, tell stakeholders that we shouldn’t just implement some random interface idea they thought up in the shower and we instead need design input!

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

In my experience, it’s even more effort to get good code with an agent-when writing by hand, I fully understand the rationale for each line I write. With ai, I have to assess every clause and think about why it’s there. Even when code reviewing juniors, there’s a level of trust that they had a reason for including each line (assuming they’re not using ai too for a moment); that’s not at all my experience with Codex.

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.

If you click the full screen window, your little window is now behind it…

MacOS definitely has its issues but this just makes it sound like you have different expectations of how an OS should work. Different isn’t always bad. Hiding applications is a pretty key concept in MacOS. Shortcuts are pretty straightforward? Cmd+H to hide, Cmd+Q to quit. Spaces aren’t hidden- there’s lots of ways to access them, but it seems you haven’t bothered to learn them. In your example pressing ctrl+right would have switched the first full screen space. You could also have right clicked the Chrome icon in the dock for a list of windows.

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.

Gotta say as a Swift dev I agree—followed the link the to Translate docs and was pleasantly surprised to see a discussion section clearly explaining the usage, which is not always the case for Apple APIs! But this wasn’t really just an article about the API. It was about the complexity of trying to build on the stack of Swift/SPM/ParseableCommand/Foundation/Concurrency/Translation without having a good grasp of any of them. I was frustrated reading it, but I think it does point to the underlying knowledge that’s needed to be proficient at something like this. None of it is a particular indictment of Swift as an ecosystem (though there are lots of valid criticisms)-it’s just the nature of development and something that’s massively eroded by relying too much on these ghosts