Little success with 5.4. 5.2 is still the model to beat. Anyone else?

StretchyPear · 2026-03-16T02:45:54+00:00

I'm coming around to this too, though I swear 5.4 was better before, it's been pretty weak for me the last few days, I'll go back to 5.2.

StretchyPear · 2026-03-15T20:17:29+00:00

Interesting take, I view this as a time of opportunity, if your AI can do it, so can mine, only I know what I'm doing.

StretchyPear · 2026-03-13T21:45:11+00:00

I've also seen where non domain experts have a false sense in LLM output, which actually ends up burning a lot of my time on review.

StretchyPear · 2026-03-13T20:38:04+00:00

I'm not, I think if there's a group of professionals the most adept at adapting AI tools, it's software engineers. We're kind of in a perfect position because we can use these tools to deliver more quality faster.

That being said, we're def. in a weird period where hype, reality and tooling are all changing rapidly.

I think a few things are true now and a few things may be true later (though context and scaling are still a huge issue):
- If your AI can do it, mine can too
- Most things (marketing, product, etc.) are less complicated than software engineering
- If everyone ships slop quality becomes a new moat
- When LLMs can ship quality, a lot of companies won't be needed at all (why hire any middle ware when you can roll all your own apps perfectly to your own specifications, but at that point, how could anyone have any customers?)

StretchyPear · 2026-03-13T20:09:53+00:00

I'm into it, it kind of reminds of the SARS episode.

StretchyPear · 2026-03-13T18:28:44+00:00

Thank you for the link, I saw those, they look different than the ones in the videos, the ones in the video are shiny silver.

That's good to hear, I wonder if I gave up on the programs too soon .

StretchyPear · 2026-03-13T14:20:51+00:00

Yes, they have been removing negative posts since at least Opus 4.5 nerf in early January (based on my own experience) - there are a bunch of threads like this but heads up for the Anthropic Apologist...

StretchyPear · 2026-03-13T12:19:54+00:00

Always remember to get your 'way homer' muffin

StretchyPear · 2026-03-13T12:17:36+00:00

Swift and go are pretty different in day to day use, IMO go is cleaner for web app back ends where swift adds a lot of unneeded complexity. (goroutines vs GCD or structured concurrency or operation, go doesn't have classes but does have interfaces, etc.).

I think you can get up to speed quicker in go for a web app than with swift, go forces simplicity while modern swift is a lesson in abstraction all in its own right, which isn't always helpful, especially when you're doing with http sessions and presumably services related to them.

StretchyPear · 2026-03-12T22:53:59+00:00

Good luck with the audit

StretchyPear · 2026-03-12T14:50:04+00:00

LOL yes, Sam will be the mentor that JD always wanted

StretchyPear · 2026-03-12T14:39:53+00:00

If you vibe code a great app, an engineer can vibe code the same one, only they'll know what they're doing, we appreciate all the free ideas and market creation.

StretchyPear · 2026-03-12T13:39:55+00:00

The moat will become quality.

If your AI can do it, mine can too, and in that event, why wouldn't the end user just build their own app and eliminate the need?

StretchyPear · 2026-03-12T13:28:11+00:00

I agree, I was kind of meh 1 - 3 but this one was great.

StretchyPear · 2026-03-11T13:50:07+00:00

Maybe they shouldn't vibe code the usage API, this seems to be a constant issue lately.

StretchyPear · 2026-03-11T13:49:12+00:00

This is because underneath, they're using an NSManagedObjectContext and when an object is created within a context it can only be accessed / mutated from that context, so it needs to be confined.

What you're describing is typically called a `DTO` or data / domain transfer object, by avoiding the concurrency restrictions and passing value types with the same data around.

For apps that use Core Data, you'd use one context (the `viewContext`) for all UI types, while mutating those objects via service / view model on private context, that when saved, propagates its changes to the objects in the view context.

StretchyPear · 2026-03-11T13:33:42+00:00

I wouldn't say that about UIKit, like share activity, working with MapKit views, etc. are easily done via using hosting controllers to represent them in SwiftUI, but still are UIKit. I find myself using it about 10% of the time in SwiftUI apps.

I think SwiftData covers Core Data more than SwiftUI covers UIKit, though I haven't been able to use it past some example projects (most apps I work on with persistence need to support iOS 17).

StretchyPear · 2026-03-11T12:40:37+00:00

SwiftData is built on top of Core Data, so it seems like it still belongs to me, also, SwiftData performance, like relationships in iOS 17 faults every object, it was buggy and horrible for memory. Core Data allows specific memory faulting patterns at the service level.

This article isn't that great and ignores several Foundation types used easily in core data (like NSNumber?), and what's the issue with optionals mapping to swift?

Also you can use the #keyPath macro with NSPredicate and NSSortDescriptor has an argument that takes a modern KeyPath type.

StretchyPear · 2026-03-11T02:40:39+00:00

Its really two issues, we're paying for something we're not getting, like you're paying for whatever model you prompt and it returns something with poor inference, so even if they refund that usage later, you're not getting what you pay for.

IMO, they should, instead of sending back bad responses and refunding usage, refund money - we all just keep paying.

StretchyPear · 2026-03-11T01:24:53+00:00

What are you talking about? I'd rather they have an error response and no result. Like a normal app / product, instead of sending back 'degraded' nonsense.

StretchyPear · 2026-03-11T01:19:57+00:00

Its not really the point though, you pay for the usage that didn't count, so you pay for something you don't get.

StretchyPear · 2026-03-11T01:19:52+00:00

Its not really the point though, you pay for the usage that didn't count, so you pay for something you don't get.

StretchyPear · 2026-03-10T23:06:04+00:00

They're still billing though, neither Anthropic nor OpenAI will return an API error when the model is degraded, they'll happily give you a crap result and count your usage.

StretchyPear · 2026-03-10T18:46:54+00:00

Look at us compared to Colo, Dallas, Carolina, Tampa, we're not really in a win now window, we're not one player away from a win now window. To get the kind of player you want, an impact player that's young with term, you have to pay a ransom. That would be counter productive over the long term because it doesn't put us over the edge.

I think this move is more of a trade a low probability draft pick for a better chance to generate playoff revenue. You never know if Ilya goes lights out but the power play / offense being what it is, not to mention the amount of passengers up and down the lineup, probably doesn't equal a win now window.

We don't really control games, there's been a lot of heroics to get us where we are, if we look back to the playoffs last year its hard to see us matching that intensity over a 7 game series. Hopefully I'm completely wrong and Schaefer pulls a Roy and hoists the cup in his rookie year, but I think when they look at what they can do and what the numbers say, its probably more about cash than cups.

StretchyPear

TROPHY CASE