[pbowyer]

Developer of 20+ years here, can't give you an accurate multiplier but I am faster.

Because spotting holes in specs has never been one of my strengths. And working without technical colleagues much of the time, it's a boon to be able to "rubber-duck" my ideas with something that is at least more intelligent than plastic.

Grabbing multipliers from thin air, the coding bit may only be 2x faster with a poorer-quality outcome, but working out what's needed is a good 5x faster.

And yes, I'm using the same adversarial AI MO as @wood_spirit, combined with Matt Pocock's excellent /grill-me and /grill-with-docs skills [1] and Plannotator [2] to review the plans.

1. https://github.com/mattpocock/skills

2. https://github.com/backnotprop/plannotator

[devilsdata]

I actually use LLMs a lot to rubber duck my problems and help develop plans. Then I manually code, to ensure my skills don't deteriorate. I feel like I'm a lot faster, with few of the downsides. Do you have any thoughts on this process?

[pbowyer]

If you can type code fast and accurately, it sounds a great process to use. You're using LLMs for the bit where they bring great value, and yourself as a higher quality coding agent :)

[louiskottmann]

That's my take as well, I find fixing poor/overengineered LLM code taxing.

[sn9]

Have you considered incorporating formal modelling?

Like:

[0] https://csci1710.github.io/2026/ and https://forge-fm.github.io/book/2026/

[1] https://elliotswart.github.io/pragmaticformalmodeling/

[2] https://quint.sh/

[pbowyer]

Only at the "hmm that seems an interesting idea" level.

Thanks for the links, going to have a read and see if I can apply any to my work.

[SkyPuncher]

Thanks for sharing those. They look interesting.