It's not clear to me why they booed him. you think for only asserting predictions that benefit him? Not because they agree on those predictions and don't want that future, blame him for this role in it?
I really thought that this was unintentional. It's hard to believe that you think this is fine to do because one can opt out. Take it for whatever it's worth, this is not OK. It is really bad. You want people's data to help you make your product better? Make it opt in and ask for their help.
I like the separation of planning and execution. I think the right set of artifacts to pass on to the execution will evolve but may be it's different for different types of work.
From the project: "The plugin enqueues the input and a daemon picks it up - planning, building, reviewing, and validating autonomously."
The part that is not clear to me (and causes most problems for me) is the "validating". It makes a mistake, or decides mocking an interface is fine, etc. declares success and moves on to the next. The bigger the project the more small mistakes compound. It sounds like the agent is doing the validation. What's the approach here for validation?
In Great Automatic Grammatizator by Roald Dahl was one of the
stories that stayed with me through the years. In the story, there is a machine that can write stories, replacing authors but they were at least paying real authors to use their names.
https://en.wikipedia.org/wiki/The_Great_Automatic_Grammatiza...
@cebert Have you looked at us serverless specific solutions like Thundra (my company), Serverless.com, etc.? I think the cost for use case may be order of magnitude lower since the pricing is only based on number of invocations.
What if it was easy to see why a test is flaky, compare failed/successful test runs like a code diff? Would that be useful?
This is what we're building at Thundra (foresight product), instrument the tests as well as backend services to enable devs to quickly diagnose failing/flaky tests. Would appreciate any feedback you may have, here or privately.