My current approach for working with LLMs.

1. Assume they are gaslighting you AT ALL TIMES.
2. Use them to quickly generate a LOT of prototypes.
3. Live in and experience the prototypes.
4. Synthesise all the knowledge gained from the prototypes.
5. Throw ALL the prototypes away.
6. Design your architecture.
7. Either code the final solution yourself or if using an LLM go SUPER SLOW and verify at every possible point with at least tests and live telemetry.
8. Never let the LLM commit to git.

@samaaron Interesting to hear your take on this. I share the fundamental idea about gaslighting. I find I’m using TDD, critical dialogue, and documentation MCPs as key tools and guardrails.

@aeskildsen Yes, absolutely - TDD is a very useful technique in certain place and also agreed about MCP tools - I've been building a huge amount of tooling and the more "eyes" I give it the better I've found it to be.

I kind of bundled all these things into the heavily overloaded word "verify".

@samaaron It’s wild how much we build all that context and tooling around the LLM tool. In some ways I think it makes me both more aware of architectural considerations, contextual knowledge I need to research, and slightly less sharp when it comes to the actual code syntax. The latter of which feels dangerous at times - what will this lead to if I write less and less code myself. But the former, I believe, means I can make better code decisions and get more work done in the same amount of time.
@aeskildsen Yes, it's certainly a very different approach - but I feel I've been able to build more sophisticated software more sustainably than ever before.
@samaaron Me too. And SuperSonic is an amazing example, IMO. I’m currently playing around with making a supersonic svelte wrapper library for use in sveltekit applications, by the way :)
@aeskildsen Awesome! Please do let me know if you run into any issues or rough edges - I really want to make it as polished as I can.
@samaaron Will do! Is GitHub your preferred place for feedback?