Your CTO is right, reviewing code is harder than writing it. Any experienced programmer will confirm that.
If the human is the bottleneck the logical step is to use a different AI to review the code produced by the original AI. You can even use two different AIs to review the code generated by the first one and accept the code if both agree it does not have bugs. I doubt this will guarantee a high quality product, but it is the solution to doing all your code with AI.
The prudent choice would be to push any generated code to production only after it was tested and reviewed by an experienced human programmer.
There was a thread on LinkedIn recently about this, and basically I think the answer is platform engineering. More testing, more guardrails in production, experiments instead of manual reviews of code.
Stop caring what the code looks like, and start caring about what the code does.
I'm using Gemini in Google Search to get one line snippets. Sometimes they are wrong, but close enough to fix them. It's like going to expert-exchange or stack-overflow, sometime better, sometimes less predictable.
I don’t know how you could possibly consider that acceptable insofar as you’re writing software and have a professional, moral, and ethical obligation to make it as robust as humanly possible, not just some exercise in approximation.
A few month ago I wanted to do a short pause in Chez Scheme. I use mostly Racket, that is very similar, but there a a few differences here and there. I wanted to send a bug report about a program that entered an infinite loop. Without the pause the example just printed a lot of "" and the screen got intermediately full. With a short pause it was possible to read the debug message just above the "********..." and hit ^C to take a deeper look.
I went to Google, expecting to go to SO (is EE still online?), but Gemini gave me the answer. There is no builtin easy "pause", so I had to create a time period of 1 seconds and then use another instruction to wait for that period.
I think they had arguments in the wrong order, it looks like it's fixed now, perhaps it was wrong only in my mind because I expected the other order. I looked at the online docs https://cisco.github.io/ChezScheme/csug/system.html#./system... . Fixed the example and adjusted the duration. (I initially used 1 second, but it's boring and it looks like the program hanged. .01 is too fast, probably .1 or .2 is the best, I don't remember the exact details.)
As an employee and engineer, it is still your job to produce and validate working code. AI makes its easier, faster, but that still doesn't absolve you of the responsibility. At the end of the day, humans are responsible for what ships. If your code breaks the product because AI went nutz and inserted a Guacamole recipe in a library, then that's on us for not catching it.
I work at a security focused company, top in the entire industry, and blaming AI is not allowed. We use AI, even integrated inside our product, but we aren't ignorant. AI can and will write bad and broken code.
Your CTO is right, reviewing code is harder than writing it. Any experienced programmer will confirm that.
If the human is the bottleneck the logical step is to use a different AI to review the code produced by the original AI. You can even use two different AIs to review the code generated by the first one and accept the code if both agree it does not have bugs. I doubt this will guarantee a high quality product, but it is the solution to doing all your code with AI.
The prudent choice would be to push any generated code to production only after it was tested and reviewed by an experienced human programmer.
There was a thread on LinkedIn recently about this, and basically I think the answer is platform engineering. More testing, more guardrails in production, experiments instead of manual reviews of code.
Stop caring what the code looks like, and start caring about what the code does.
You stop using AI.
I'm using Gemini in Google Search to get one line snippets. Sometimes they are wrong, but close enough to fix them. It's like going to expert-exchange or stack-overflow, sometime better, sometimes less predictable.
I don’t know how you could possibly consider that acceptable insofar as you’re writing software and have a professional, moral, and ethical obligation to make it as robust as humanly possible, not just some exercise in approximation.
Anecdote time, take a seat:
A few month ago I wanted to do a short pause in Chez Scheme. I use mostly Racket, that is very similar, but there a a few differences here and there. I wanted to send a bug report about a program that entered an infinite loop. Without the pause the example just printed a lot of "" and the screen got intermediately full. With a short pause it was possible to read the debug message just above the "********..." and hit ^C to take a deeper look.
I went to Google, expecting to go to SO (is EE still online?), but Gemini gave me the answer. There is no builtin easy "pause", so I had to create a time period of 1 seconds and then use another instruction to wait for that period.
Me> https://www.google.com/search?q=pause+1+second+chez+scheme*
Gemini> (sleep (make-time 'time-duration 0 1))
I think they had arguments in the wrong order, it looks like it's fixed now, perhaps it was wrong only in my mind because I expected the other order. I looked at the online docs https://cisco.github.io/ChezScheme/csug/system.html#./system... . Fixed the example and adjusted the duration. (I initially used 1 second, but it's boring and it looks like the program hanged. .01 is too fast, probably .1 or .2 is the best, I don't remember the exact details.)
---
Back to your question:
I consider that totally professional and moral.
As an employee and engineer, it is still your job to produce and validate working code. AI makes its easier, faster, but that still doesn't absolve you of the responsibility. At the end of the day, humans are responsible for what ships. If your code breaks the product because AI went nutz and inserted a Guacamole recipe in a library, then that's on us for not catching it.
I work at a security focused company, top in the entire industry, and blaming AI is not allowed. We use AI, even integrated inside our product, but we aren't ignorant. AI can and will write bad and broken code.