> Too many of these projects become viral hits that stop making any progress after the first symbolic success. Cynics would say these projects all too often stop exactly at the point where the actual challenges start.
What can you do to ensure the "real work" can actually be done, more precise paid for? Well, you could demo early in hope to attract coins. Maybe that is happening here.
I have not test-driven adk-go.
But if you - like me - have not toyed around with agents until now, there is a readable, nice example in [1] which explains itself.
Who do you mean with "many people"? Developers who do not care or middle management that oversold features and overcommitted w.r.t. deadlines? Or both? Someone else?
> Even if you don't notice the pot being boiled there are those of us that do.
Tangent: To me that sounds like a reference to the "frog boiling" story. This has been debunked [1], a healthy frog will not remain in a gradually heated pot of water. We need a better analogy for this.
I'm aware, but it's the understood turn of phrase at present. Similar to "tree shaking" which people started pushing back against at some point and I've no idea why because if it conveys the point then who cares whether or not farmers do it?
I get your point, but according to [1] ASML was a bad example.
There is no kill switch which might be pressed only under circumstances that may never be "adapted to current situations". So who does said plow belong to?
Regardless of whether there's a kill switch or not, it's really not practical to operate any advanced ASML equipment without ongoing support from the vendor.
This is pretty much the F-35 argument. The US may or may not have an immediate kill switch, but they 100% have a logistics kill switch that can be triggered with a weeks-to-months delay.
Yes, thank you for answering. The textures are free to use, but the URL should only be used for prototyping. Here is the website: https://www.transparenttextures.com/
> I am a bit confused on the "bypass" though. Wouldn't the adversary need push access to the repository to edit the workflow file? So, the portion that needs hardening is ensuring the wrong people do not have access to push files to the repository?
I understand it that way, too. But: Having company-wide policies in place (regarding actions) might be misunderstood/used as a security measure for the company against malicious/sloppy developers.
So documenting or highlighting the behaviour helps the devops guys avoid a wrong sense of security. Not much more.
What can you do to ensure the "real work" can actually be done, more precise paid for? Well, you could demo early in hope to attract coins. Maybe that is happening here.