Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Embracing the parallel coding agent lifestyle

simonwillison.net

Post reply on HN
Print view View original

121–130 of 147 posts

Re: Embracing the parallel coding agent lifestyle

#121

Post by jmtulloss »

angelmm wrote: post #117
jmtulloss wrote: post #104

Earlier quoted context omitted.

Good point. The environments I’ve set up have been pretty easy but I’ll admit that at first I was very annoyed that it couldn’t just use a pre-existing GitHub action workflow. Edit: environment setup was also buggy when the product launched and still is from time to time. So, now that I have it set up I use it constantly, but they do need to make getting up and running a more delightful experience.

Also, Codex Cloud and similar services require you to give fully access to your repository, which might trigger some concerns. If you can run it locally, you still have the control, same development environment, and same permissions.

It doesn’t have access to your repo when the agent is running (unless you give it internet access and credentials). The code is checked out into the sandbox before it’s let loose.

Re: Embracing the parallel coding agent lifestyle

#122

Post by sgsjchs »

AdieuToLogic wrote: post #93
favoboa wrote: post #85

I believe AI isn't replacing developers, instead, it's turning every software engineer into a hybrid between EM + IC, basically turning them into super-managers. What we need is better tools for this upcoming new phase. Not a new IDE; we need to shift the whole paradigm. Here's one example: If we give the same task to 3 different agents, we have tools to review a diff of each OLD vs NEW separately, but we need tools…

> From what I've seen, the idea that AI is turning developers into super-managers is why some people struggle to adapt ... This "idea" is hyperbole. > Those who love to type their code and hate managing others tend to be more hesitant to adapt to this new reality. This is a false dichotomy and trivializes the real benefit of going through the process of authoring a change; how doing so increases one's knowledge of co…

I, too, enjoy the craftsmanship, but at the end of the day what matters is that the software works as required, how you arrive at that point doesn't matter.

Re: Embracing the parallel coding agent lifestyle

#124

Post by bryanrasmussen »

favoboa wrote: post #85

I believe AI isn't replacing developers, instead, it's turning every software engineer into a hybrid between EM + IC, basically turning them into super-managers. What we need is better tools for this upcoming new phase. Not a new IDE; we need to shift the whole paradigm. Here's one example: If we give the same task to 3 different agents, we have tools to review a diff of each OLD vs NEW separately, but we need tools…

you seem to think those who love to write their own code and dislike managing others also evidently don't like to communicate or work in teams, which seems a big leap to make.

Re: Embracing the parallel coding agent lifestyle

#126

Post by lgas »

never_inline wrote: post #109
munk-a wrote: post #55

I'm very happy to see the article covering the high labor costs of reviewing code. This may just be my neurodivergent self but I find code in the specific style I write to be much easier to quickly verify since there are habits and customs (very functional leaning) I have around how I approach specific tasks and can easily handwave seeing a certain style of function with the "Let me just double check that I wrote tha…

I have similar OCD behaviors which make reviewing difficult (regardless of AI or coworker code). specifically: * Excessive indentation / conditional control flow * Too verbose error handling, eg: catching every exception and wrapping. * Absence of typing AND precise documentation, i.e stringly-typed / dictly-typed stuff. * Hacky stuff. i.e using regex where actual parser from stdlib could've been used. * Excessive ad…

> In addition it can assume its writing some throwaway script ...

Do you explicitly tell it that it's writing production code? I find giving it appropriate context prevents or at least improves behaviors like this.

Re: Embracing the parallel coding agent lifestyle

#127

Post by vidarh »

b_e_n_t_o_n wrote: post #72
vidarh wrote: post #64

Earlier quoted context omitted.

Or you put them to work with strong test suites and get stuff done. I am in bed. I have Claude fixing complex compiler bugs right now. It has "earned" that privilege by proving it can make good enough fixes, systematically removing actual, real bugs in reasonable ways by being given an immutable test suite and detailed instructions of the approach to follow. There's no gambling involved. The results need to be checke…

If you were an x86 assembly expert would you still feel the same way? (assuming you aren't already)

Probably not. I have lots of experience with assembly in general, but not so much with x86. But the changes work and passes extensive tests, and some of them would be complex on any platform. I'm sure there will be cleanups and refinements needed, but I do know asm well enough to say that the fixes aren't horrific by any means - they're likely to be suboptimal, but supoptimal beats crashing or not compiling at all any day.

Re: Embracing the parallel coding agent lifestyle

#128

Post by vidarh »

evnp wrote: post #92
vidarh wrote: post #64

Earlier quoted context omitted.

Or you put them to work with strong test suites and get stuff done. I am in bed. I have Claude fixing complex compiler bugs right now. It has "earned" that privilege by proving it can make good enough fixes, systematically removing actual, real bugs in reasonable ways by being given an immutable test suite and detailed instructions of the approach to follow. There's no gambling involved. The results need to be checke…

Just curious, how do you go about making the test suite immutable? Was just reading this earlier today... https://news.ycombinator.com/item?id=45525085

Just don't give it write access, and rig it up so that you gate success on a file generated by running the test suite separate from the agent that it can't influence. It can tell me it has fixed things as much as it like, but until the tests actually passes it will just get told the problem still exists, to document the approach it tested and to document that it didn't work, and try again.

Re: Embracing the parallel coding agent lifestyle

#129

Post by jdougan »

simonw wrote: post #50
OtherShrezzing wrote: post #49

Earlier quoted context omitted.

To get around the sycophantic behaviour I prompt the model to > when discussing implementations, always talk as though you’re my manager at a Wall Street investment bank in the 1980s. Praise me modestly when I’ve done something well. Berate me mercilessly when I’ve done something poorly. The models will fairly rigidly write from the perspective of any personality archetype you tell it to. Other personas worth trying…

I tried "give me feedback on this blog post like you're a cynical Hacker News commenter" one time and Claude roasted me so hard I decided never to try that again!

Were the roasts correct?

Re: Embracing the parallel coding agent lifestyle

#130

Post by skydhash »

favoboa wrote: post #105
AdieuToLogic wrote: post #93

Earlier quoted context omitted.

> From what I've seen, the idea that AI is turning developers into super-managers is why some people struggle to adapt ... This "idea" is hyperbole. > Those who love to type their code and hate managing others tend to be more hesitant to adapt to this new reality. This is a false dichotomy and trivializes the real benefit of going through the process of authoring a change; how doing so increases one's knowledge of co…

Thanks for the detailed critique. I think we might be talking past each other on the "super-manager" term. I defined it as a hybrid of EM + IC roles, not pure management, though I can see how that term invited misinterpretation. On the false dichotomy: fair point that I painted two archetypes without acknowledging the complexity between them or the many other archetypes. What I was trying to capture was a pattern I'v…

> But when you delegate work to a junior developer, you still need to understand the problem deeply to communicate it properly, and to recognize when their solution is wrong or incomplete

You really don't. Most delegation work to a junior falls under the training guideline. Something trivial for you to execute, but will push the boundary of the junior. Also there's a lot of assumptions that you can make especially if you're familiar with the junior's knowledge and thought process. Also the task are trivial for you meaning you're already refraining from describing the actual solution.

> AI tools work similarly. You still hit edit-compile-test cycles when output doesn't compile or tests fail.

That's not what the edit-compile-test means, at least IMO. You edit by formulating an hypothesis using a formal notation, you compile to test if you've followed the formal structure (and have a faster artifact), and you test to verify the hypothesis.

The core thing here is the hypothesis, and Naur's theory of programming generally describe the mental model you build when all the hypotheses works. Most LLM prompts describe the end result and/or the processes. The hypothesis requires domain knowledge and to write the code requires knowledge of the programming environment. Failure in the latter parts (the compile and test) will point out the remaining gaps not highlighted by the first one.

Post reply on HN