Posted by fnthawar2 21 hours ago
That said I did happen to work with a team in ‘21 - ‘22 that got access to an older coding model from OpenAI, also called Codex, through a corporate partnership. We also tested it out in an autocomplete UX. Our experience was rather hit-or-miss and I was a bit skeptical of AI-based coding at the time. That blog post above and others like it were an eye-opener and made me wonder if we were just “holding it wrong.”
Then ChatGPT was released. It was nowhere as good as the models today but it could write reams and reams of correct code and I realized the world had changed forever.
I mean, it's not impossible - I wrote a "coding agent" with GPT-3. It sucked balls. The idea was you write a Markdown spec file and the tool then compiled it to an equivalent source code one shotting it every time, but it hardly worked at all. The file changed too much every time and instruction following wasn't good enough, so it'd keep changing the interface exported by the file, and there were lots of bugs etc.
> Shopify has been using LLMs to build software since 2021
GitHub Copilot integrated into VS Code started becoming available that year. It’s definitely not a coding agent, but it was certainly LLM-assisted programming.
But I'm curious what their update will be in a year or two. Because these costs don't reduce as dramatically with AI (unless you fully give up control and vibe code it):
1. Reading code
2. Manually testing code
2. AI will manually test code
Who wants to bet there still won't be a dark mode?
> When simulator interaction is needed, the CLI can connect to them via a remote mode and drive the UI via commands without having to inspect the layout or the accessibility tree. This enables blazing-fast performance and E2E tests.
I think I'm not following. Don't you still need to test the accessibility tree and layout in the actual layer the user will interact with?
In recent Rails releases, system tests, or E2E tests, are no longer enabled by default. The short version is that they’re significantly slower and more brittle. Basecamp also removed most of their E2E tests.
I don’t know what Shopify does internally, but my guess is that they’ve taken some of those lessons and are trying to apply the same thinking to mobile development too.
https://guides.rubyonrails.org/testing.html?#when-to-use-sys...
I work in Rails too, I try to keep them to a minimum, but I definitely try to do at least one happy-path test of any major page (which includes automated accessibility audit), going without them at all seems insane to me.
oh yeah, disclaimer: I write UI frameworks and dabble in PLs.
Is that something we should be engineering for right now?
Now this is somewhat problematic if someone wants to implement better fine grained reactive systems. And I posit that the next paradigm is going to be in that direction given what I've been working on (furthering current reactive systems which only go halfway).
The abstraction is huge advantage, especially when targeting different devices and screen sizes. We (and that includes Apple) have been learning the value of those kinds of abstraction boundaries for years, well before React.
It's also important to note that SwiftUI and UIKit are composable, so if some small part of your app needs low-level, finer grained control, then go ahead and use UIKit/Core Animation/Metal and SwiftUI for the rest.
Then you can only have islands of either paradigm within each other. UIKit and SwiftUI do indeed compose, albeit coarsely.
I can't blame them, they got influenced by react. Don't even blame react, it was a good attempt. Basically trying to build a UI from a snapshot of a tree. Except this is too simplistic a model. They designed it as if you could equate the number of games and the number of positions in chess. Like a markov chain. Except playing chess has side effects. A mere snapshot does not encode those.
I understand the mistake.
It also depends on features. Many apps don't rely on platform features (widgets, watch apps) and are essentially webviews, and those will continue to do just fine on RN.
I developed React native app for ios as side project and took breaks often and came back to have to do big updates with expo to make it work again. Maybe there is smoother process, but this was annoying
We have small shims for IOS or Android BLE. But otherwise the discussion of should you go native is really a discussion of how many employees do you have to throw with this?
Big win for security
I’m not aware of any attacks on native package managers in the past 5 years. The closest would be a poisoned Xcode build in China that wasn’t downloaded from Apple a while back.
Also getting an attack on one of the platforms means at least ~half your users are safe on the other one.