I feel like this ultimately boils down to something similar to nocode vs code debates that you mention. (Is openclaw having these flowcharts similar to nocode territory?)
at some point, code is more efficient in doing so, maybe even people will then have this code itself be generated by AI but then once again, you are one hallucination away from a security nightmare or doesn't it become openclaw type thing once again
But even after that, at some point, the question ultimately boils down to responsibility. AI can't bear responsibility and there are projects which need responsibility because that way things can be secure.
I think that the conclusion from this is that, we need developers in the loop for the responsibility and checks even if AI generated code stays prevalent and we are seeing some developers already go ahead and call them slop janitors in the sense that they will remove the slop from codebase.
I do believe that the end reason behind it is responsibility. We need someone to be accountable for code and we need someone to take a look and one who understands the things to prevent things from going south in case your project requires security which for almost all production related things/not just basic tinkering is almost necessary.
Yeah responsibility and accountability are also some areas I'd like to explore. I'm mostly digging through this artifact I created with Claude to look at first order and second order effects and then "traffic jams" in the "good science fiction doesn't predict the car, it predicts the traffic jam" and what kind of roles might pop up to solve those issues: https://claude.ai/public/artifacts/39e718fa-bc4b-4f45-a3d5-5...
I've mostly been digging through my own version of that and trying to find things I find interesting and seeing what kinds of stories we can build about what a day in that job might look like.
Funny I actually saw this tweet this morning about an Openclaw instance getting too advanced for the users to know how to control and fix: https://x.com/jspeiser/status/2033880731202547784?s=46&t=sAq...
> Funny I actually saw this tweet this morning about an Openclaw instance getting too advanced for the users to know how to control and fix: https://x.com/jspeiser/status/2033880731202547784?s=46&t=sAq...
I feel like this ultimately boils down to something similar to nocode vs code debates that you mention. (Is openclaw having these flowcharts similar to nocode territory?)
at some point, code is more efficient in doing so, maybe even people will then have this code itself be generated by AI but then once again, you are one hallucination away from a security nightmare or doesn't it become openclaw type thing once again
But even after that, at some point, the question ultimately boils down to responsibility. AI can't bear responsibility and there are projects which need responsibility because that way things can be secure.
I think that the conclusion from this is that, we need developers in the loop for the responsibility and checks even if AI generated code stays prevalent and we are seeing some developers already go ahead and call them slop janitors in the sense that they will remove the slop from codebase.
I do believe that the end reason behind it is responsibility. We need someone to be accountable for code and we need someone to take a look and one who understands the things to prevent things from going south in case your project requires security which for almost all production related things/not just basic tinkering is almost necessary.
Yeah responsibility and accountability are also some areas I'd like to explore. I'm mostly digging through this artifact I created with Claude to look at first order and second order effects and then "traffic jams" in the "good science fiction doesn't predict the car, it predicts the traffic jam" and what kind of roles might pop up to solve those issues: https://claude.ai/public/artifacts/39e718fa-bc4b-4f45-a3d5-5...
I've mostly been digging through my own version of that and trying to find things I find interesting and seeing what kinds of stories we can build about what a day in that job might look like.