Could we see some worked examples for some of these scenarios?
I would love to see more actual working prompts.
--
The statement I really take issue with is:
"Putting this all together, let's see how a complete workflow might look for tackling a specific, somewhat complicated feature in an ongoing app, like adding OAuth login."
Given the limitations you have discussed, do you think it's safe to have the AI writing authorization code?
--
But I know you said, your using the AI to get an overview of the workflow. But even so, a bad architectural recommendation could result in vulnerabilities. For secure code guidance, who do you trust?
Maybe for secure code, if you're going to use AI, you can ground the AI by saying ... use only the following sources: oauth.net and owasp.
--
I'm sorry, but ha ha, but this seems like a terrible example to use. :-)
--
The best part about your book, IMHO, is when you express your strong opinion, like whether LLM can reason.
The part I like least about your book, is when you make unworked, pie-in-sky statements.
--
I've learned so much from your book. I liked learning about Rice's theorem, and how obfuscating the variable names can help the LLM learn.
Thank you for writing all this great content! First of all, love your thoughtfulness, insight and depth!
It seems like the clean-room concerns for AI-generated code are similar to the issues with Open Source use and Stack Overflow use.
I'd love to see more on contamination concerns.
1. AI generated code gets shipped to production
2. AI generated code gets cut-n-pasted into Stack Overflow and then propagated
3. AI generated code gets into Open Source
4. AI generated code is itself trained on AI generated code
5. Can AI generated code by patented? Licensed? Released as Open Source? Released as Libraries?
6. If a module has a mixture of AI collaborated code and hand-written code, how will they be distinguished?
7. How we will track down the AI generated code in our code base if the AI generated code becomes out of date (like in-line code snippets or deprecated packages) - or is the AI itself is refreshed and we need to re-gen all the AI snippets
8. What is the target project uses AI generated code, and a security scanner (auditing authority, linter, etc) also uses AI generated code - how do we know they were generated by clean-room AI's of different lineage - worse - from the same AI that can't detect it's own mistakes.
Seems like companies need to think long and hard about their AI policy and IP policy.
Anyway you're producing great stuff. I'd love to hear about some corporate tooling to handle these kinds of issues - we used to use Black Duck at my last company.
One mistake AI makes (which is conceptually missing from your list) in my few use cases with R:
it writes lengthy code not using vectorization or built-in functions. I have several times reduced LOC from like 50 to below 10 using more elegant approaches. I know there are other metrics for code quality, but I have to maintain all that stuff later!
(when I respond with my shorter code it usually tells me how nicely my code uses language specific idiosyncrasies).
Yup, that's a terrific example. I tried to cover similar cases with the idea that biases in code generation show up as bad practices and inelegant code.
This is my second review.
Could we see some worked examples for some of these scenarios?
I would love to see more actual working prompts.
--
The statement I really take issue with is:
"Putting this all together, let's see how a complete workflow might look for tackling a specific, somewhat complicated feature in an ongoing app, like adding OAuth login."
Given the limitations you have discussed, do you think it's safe to have the AI writing authorization code?
--
But I know you said, your using the AI to get an overview of the workflow. But even so, a bad architectural recommendation could result in vulnerabilities. For secure code guidance, who do you trust?
Maybe for secure code, if you're going to use AI, you can ground the AI by saying ... use only the following sources: oauth.net and owasp.
--
I'm sorry, but ha ha, but this seems like a terrible example to use. :-)
--
The best part about your book, IMHO, is when you express your strong opinion, like whether LLM can reason.
The part I like least about your book, is when you make unworked, pie-in-sky statements.
--
I've learned so much from your book. I liked learning about Rice's theorem, and how obfuscating the variable names can help the LLM learn.
Thank you for writing all this great content! First of all, love your thoughtfulness, insight and depth!
It seems like the clean-room concerns for AI-generated code are similar to the issues with Open Source use and Stack Overflow use.
I'd love to see more on contamination concerns.
1. AI generated code gets shipped to production
2. AI generated code gets cut-n-pasted into Stack Overflow and then propagated
3. AI generated code gets into Open Source
4. AI generated code is itself trained on AI generated code
5. Can AI generated code by patented? Licensed? Released as Open Source? Released as Libraries?
6. If a module has a mixture of AI collaborated code and hand-written code, how will they be distinguished?
7. How we will track down the AI generated code in our code base if the AI generated code becomes out of date (like in-line code snippets or deprecated packages) - or is the AI itself is refreshed and we need to re-gen all the AI snippets
8. What is the target project uses AI generated code, and a security scanner (auditing authority, linter, etc) also uses AI generated code - how do we know they were generated by clean-room AI's of different lineage - worse - from the same AI that can't detect it's own mistakes.
Seems like companies need to think long and hard about their AI policy and IP policy.
Anyway you're producing great stuff. I'd love to hear about some corporate tooling to handle these kinds of issues - we used to use Black Duck at my last company.
Regards!
One mistake AI makes (which is conceptually missing from your list) in my few use cases with R:
it writes lengthy code not using vectorization or built-in functions. I have several times reduced LOC from like 50 to below 10 using more elegant approaches. I know there are other metrics for code quality, but I have to maintain all that stuff later!
(when I respond with my shorter code it usually tells me how nicely my code uses language specific idiosyncrasies).
Yup, that's a terrific example. I tried to cover similar cases with the idea that biases in code generation show up as bad practices and inelegant code.