Hacker News Reader

Comment by smalltorch | Hacker News Reader

This seems like a recipe for bad code I dunno. How would someone using this app test as they go?

Agentic coding sorta works for me because you can stop and test each iteration and pinpoint where something has gone wrong.

Example: I ask for a tweak, it give me 20 lines, I test for the intended behavior and keep working on those 20 lines until I'm happy with the reliability/effects of it.

But that loop itself requires a environment in which the final product will be running and takes up most the time in my expirence.

View on HN

What model are you using? I can use Claude Code's remote control on Opus 4.8, have it implement a meaty feature, talk through edge cases, ask it to posit potential interactions we want to be careful of, have it write a plan and expand tests for surrounding areas, ask it to implement, ship that increment to testflight, then experiment with it on my phone - without being at home. My only limitation is that I like to clear context between ships, and that's tough to do using remote control.

and you never look at the code?

I understand the feasibility of this and sometimes in my lazier moments I skim the code changes and trust automated/manual testing to validate changes, but to just like... you don't even see what it did?

Of course I see it on device after it installs. But that's what I'm used to: I've spent more than a decade as a product manager, I don't read all the code my engineers write! My job is to dig into how well it actually works, put guardrails in place to make sure it has to work right, monitor the outcomes! And I make sure Claude gets the feedback from my monitoring and use, the patterns of bugs we find, updates its approach, documents the most important issues to check against in future testing.

I honestly think good technical product managers have a huge leg up on engineers in this world.

I guess if your shipping to TestFlight you still have the feedback loop, but it seems like it's adding a lot of steps. Whereas, if you were working on a app in a desktop environment, just build and boot to the simulator right there.

I could see the use case for the planning stage of the build though if your out and about and have a good idea.

If you could actually build and test locally I think I would have different thoughts. For instance, if I'm building a utility script for the CLI and can run it locally it makes sense not to whipout the desktop in some scenarios.

I used the simulator for a while when I was first building, but now that I'm building software that syncs in realtime between the watch and the phone, I found the simulator isn't enough - and sideloading doesn't consistently work with the watch! Testflight is another 30 seconds per build.

Maybe not for maintainable production code but I've definitely built apps/games for friends and this kind of thing would come in handy. I leave for work, I think of something I want to do, and this way I could just text the agent to do it.

There's also a lot to be said about planning modes which don't write anything, but rather just generate text files to be implemented later when I can watch over the repo more closely.

Reply on news.ycombinator.com