| Maybe this could work for some as a general recipe for how to collaborate with AI: - Split up the work so that you write the high-level client code, and have AI write the library/framework code. - Write some parts of your (client) code first. - Write a first iteration of the library/framework so that your code runs, along with tests and documentation. This gives the AI information on the desired implementation style. - Spend time designing/defining the interface (API, DSL or some other module boundary). Discuss the design with the AI and iterate until it feels good. - For each design increment, let AI implement, test and document its part, then adapt your client code. Or, change your code first and have AI change its interface/implementation to make it work. - Between iterations, study at least the generated tests, and discuss the implementation. - Keep iterations small and commit completed features before you advance to the next change. - Keep a TODO list and don't be afraid to dismiss an earlier design if it is no longer consistent with newer decisions. (This is a variation of the one-off program, but as a design tool.) That way, there is a clear separation of the client code and the libraries/framework layer, and you own the former and the interface to the latter, just not the low-level implementation (which is true for all 3rd party code, or all code you did not write). Of course this will not work for you if what you prefer is writing low-level code. But in a business context, where you have the detailed domain knowledge and communicate with the product department, it is a sensible division of labour. (And you keep designing the interface to the low-level code.) At least for me this workflow works, as I like spending time on getting the design and the boundaries right, as it results in readable and intentional (sometimes even beautiful) client code. It also keeps the creative element in the process and does not reduce the engineer to a mere manager of AI coding agents. |