Comment by collingreen
21 hours ago
Seriously! What a bonkers thing to claim. "I had codex use maestro so I assume it made Android work well and idiomatically".
It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem, which makes me feel fear in my heart when I imagine the first "production is down" page coming in. I already hated mobile because it's so much harder to maintain than web (and I don't do any spyware or IAP so no benefits for me there); this yolo approach would give me constant dread.
It shows that at least some software development is moving away from code and to product management instead. I'm not passing judgement on that; I actually think that's great for a lot of software. It is interesting to see the shift happening though and will be fun to see if the general quality of software noticeably changes over the next few years.
> It's a fine project to do but clearly they put zero value on being familiar with the project's codebase/stack and ecosystem,
As much as I dislike it, I think that's the future of _all_ non-critical software (think social media, crms, CI, food delivery etc). Leadership in many companies is explicitly asking employees to have multiple agents running through the day and that will lead to this.
Read this for example: https://www.uber.com/in/en/blog/efficient-software-factory/ . A very useful system, I am sure. But when you have AI at every layer from code to review to triaging, rest assured AI is the only know who knows your system. And you better hope it's not telling you that something is load bearing during an incident.
I read the article and couldn't understand it. I asked Gemini; Pareto things definitely sounds like science.
I read the article again:
- We had bugs. We let agents try to fix the bugs. True positive (fixed bug) is the F1 score. Here are the results for different models. Fixes worked 50% of the time.
- We needed to find a query. Without a knowledge graph it took 20mins, and didn't work. We used a knowledge graph. It was fast (20s), and found the right thing.
I gave my LLM my summary of the article and apparently I "hit the nail on the head".
I have no clue if I learned anything.
I answered elsewhere that I don’t personally use Android phones but we have people on our team that do. Which is why I don’t want to personally claim that it feels native.
But yes we are having real Android users test it.
So it’s quite the contrary. I care MORE what real users say. I can only guarantee that the app does things when I tap. So I’m not trusting the agent on UX, only on functionality. But whether it feels native, I am relying on those users in our team.
That's much better than my original, perhaps unfair, read. Thanks for the additional info.
I still would feel scared operating an established product off a newly changed stack the team isn't familiar with though.
> this yolo approach would give me constant dread.
When you’re completely ignorant, there’s nothing to be afraid of.
I wrote every single line of the react native app we ported, and maintained it for 9 years. So suffice to say, I'm familiar with the code.
But I am going to always prioritize the user experience over a developer (like myself)'s need for satisfaction to see code. And a pure native app is _always_ going to behave better than react native.
This gives me a chance to do that.
> And a pure native app is _always_ going to behave better than react native.
Maybe iOS is better about consistency, but I've used enough horribly made Android apps that I would not expect one that's vibe coded to behave better than a professionally made react native version.
I would if it were based on the RN version. RN is kind of okay on iOS, but really shitty on Android. Would be difficult to be _worse_.
That said, I do recommend reading the code the LLM produces whether you understand the language or not. What better time to learn?
Maybe. Android might still be a mess, fair point.
>So suffice to say, I'm familiar with the code.
You are familiar with the React Native code, you are not familiar with the Swift or Kotlin code, and likely nobody on your team is, since the AI wrote all of it for you.
First “production is down” page means you just tell codex production is down and to fix it.
Presumably a sarcastic post, but this is actually going to be how things are done soon. I had a box that OOMed and needed to be rebooted every few weeks. It was a disaster recovery standby box so figuring out what was going on never rose to the top of my priority list. So I asked Claude to dig into it (proxying the commands it wanted to run through me) and in an hour it had diagnosed the problem, fixed it, and taught me a bunch about memory usage in our system on modern kernels.
Not sarcastic. I have a moderately successful app and I haven’t once looked at the code (though I am capable, so far atleast). The only time I open Xcode is if I have to modify signing certificates. I did set up a slack workflow with a “fix it” button that basically tells Codex to fix the issue, run comprehensive tests, manually UI test for that particular issue with computer use and then deploy it.
2 replies →