Have a single human AI chef. Everyone else has to write an engineering statement and submit it to the AI chef. All that interaction is outside the codebase. Engineers will take turns - perhaps 1 month stints - being the AI chef.
I guarantee you'll spend less on tokens, have better documentation, better code, and most importantly more competent engineers.
I actually quite like this idea and might try something like it on my team because we're defacto heading in this direction anyway and everyone's a bit frustrated, might be better if it was acknowledged and made official as something to try.
On the other hand, I think this denies the reality (in my experience anyway but I think enough people will agree) that one often solves a problem as they are working on it.
This method seems to presume that a good engineer will submit a well thought-out solution or direction giving the AI an extremely good overview of each problem and enough of a description of what to do that it will do things as expected and they can just review the result.
In my experience it just doesn't work that way in practice. One learns the problem and even the domain while developing the solution. So one would have to submit at least a half developed solution not just "instructions", for there to even be coherent instructions in the first place. And one needs that experience working on the problem to be able to properly evaluate a separately proposed solution.
All in all for me this leads more towards using AI as a co-developer than using it to just implement some fully thought out idea and then check what it did.
> This method seems to presume that a good engineer will submit a well thought-out solution or direction giving the AI an extremely good overview
Yes it does make that presumption - but that's part of the model here, that "prompt review" becomes the new code review and that the team is training on standard prompt semantics.
I'll share my outline - which is basically the one that was drilled into us in engineering school (CMU class 89)
1. Problem Statement
2. Definitions / Assumptions
3. Plan of attack / Options explored
4. Implemetation / Results
5. Limitations / Future Work
> So one would have to submit at least a half developed solution not just "instructions
The outline supports that in that you can fill out that part of the document which has been woeked on - including referencing any existing code.
Any other engineering students here recognize that outline?
I guarantee you'll spend less on tokens, have better documentation, better code, and most importantly more competent engineers.