|
|
|
|
|
|
by antfarm
92 days ago
|
|
|
I found my peace with AI aided coding during the last three months. I started development of an environment for programming games and agent simulations that has its own S-expression based DSL, as a private project. Think somewhere between Processing and StarLogo, with a functional style and a unique programming model. I am having long design sessions with Claude Code and let it implement the resulting features and changes in version controlled increments. But I am the one who writes the example games and simulations in the DSL to get a feel for where its design needs to change to improve the user experience. This way I can work on the fun and creative parts and let Claude do the footwork. I let Claude simultaneously write code, tests and documentation for each increment, and I read it and suggest changes or ask for clarification. I find it a lot easier to dismiss an earlier design for a better idea than when I would have implemented every detail of the system myself, and I think so far the resulting product has largely benefited from this. To me, now more than ever it is important to keep the love for programming alive by having a side project as a creative outlet, with no time pressure and my own acceptance criteria (like beautiful code or clever solutions) that would not be acceptable in a commercial environment. |
|
|
- 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.