Let’s face it, AI is improving at coding incredibly rapidly. It’s a bit like Moore’s law, but now every 18 weeks instead of 18 months.
Good remark Rein.
To often we focus on the flaws of a new technology/development.
But neglect the speed in which it is improving.
Not sure if it is 18 weeks, but certainly next year we will have all (slightly) changed verdict.
I think Rein's estimate of doubling every 18 weeks is fairly good on the spot.
The current AI compared to that in februari this year is already incredable. Recursive self improvement is on the horizon in my opinion, where AI will write the next generation of AI's. (and do that in a loop)
Only limit seems to be the amount of electricity and chips the companies can claim for themselfs.
MichelG wrote: Tue Aug 18, 2026 17:56
I think Rein's estimate of doubling every 18 weeks is fairly good on the spot.
The current AI compared to that in februari this year is already incredable. Recursive self improvement is on the horizon in my opinion, where AI will write the next generation of AI's. (and do that in a loop)
Only limit seems to be the amount of electricity and chips the companies can claim for themselfs.
I’m late to the game. Over on Talkchess I codeveloped 100% symmetry-reduced indexing for endgame databases (May). I had the idea to also codevelop an identical Qt GUI for Kingsrow-Hub so that Ed could forget about the Win32 API. Alas, Gijsbert beat me to it by a week. Currently I am sitting on the couch with my iPad, using Claude Code Cloud and ChatGPT Codex Cloud to babysit my GitHub C++ projects and do all kinds of refactoring and documentation (that I had neglected for a decade).
I decided to take the easy route too. Although I already programmed a large part of a GUI with MFC it has two drawbacks, it looks a bit old-fashioned, and it's impossible to port it to Linux. So I decided to use QT as the primary toolbox (another option would have been wxWidgets).
In just one day of work with Codex the GUI is already capable of playing a match between two HUB engines. Ares does not support HUB, probably it will never support HUB, but I will add it with a proprietary protocol.
The board looks nice too, actually this was most of the work because with the QT drawing function it kept looking ugly, so I decided to let Codex implement it with OpenGL.
Too bad, the forum doesn't allow me to add another screenshot, I hope they will fix this some day.
Joost Buijs wrote: Sat Aug 22, 2026 10:28
In just one day of work with Codex the GUI is already capable of playing a match between two HUB engines. Ares does not support HUB, probably it will never support HUB, but I will add it with a proprietary protocol.
Why would you add a proprietary protocol instead of HUB when the latter is also a breeze to get to work with Codex?
Joost Buijs wrote: Sat Aug 22, 2026 10:28
In just one day of work with Codex the GUI is already capable of playing a match between two HUB engines. Ares does not support HUB, probably it will never support HUB, but I will add it with a proprietary protocol.
Why would you add a proprietary protocol instead of HUB when the latter is also a breeze to get to work with Codex?
HUB clearly has more overhead than a binary protocol. While this is not a problem for games with 'normal' time controls, it becomes noticeable in very fast games. Of course, completely integrating the engine into the GUI is an even better solution.
