#LLM позволяют автоматизировать то, что раньше было автоматизировать невыгодно.

Я уже несколько раз про это писал в цикле #lab, #homelab, но вот вам еще две истории:

Одна программа проводила 20% всего CPU time в работе с map. Попросил LLM показать, в каких строчках кода чаще всего происходит обращение к map, с точностью до операции. LLM ответила, что можно сделать по профилю, но нужной точности не получить.

Я немножко подумал, и велел ей написать AST трансформацию кода, которая бы пропустила каждый access через wrapper, а враппер уже бы получил source location, и просто заинкрементил счетчик.

Вот, пожалуйста - https://github.com/pg83/ay/blob/master/probe_mapinstr.go. Сразу же нашли узкое место, и оптимизировали его.

Стал бы я так заморачиваться год назад? Да ни в жисть.

И вторая история, очень похожая.

У меня есть стайлгайд для go, https://github.com/pg83/ay/blob/master/STYLE.md, я его копирую из проекта в проект. Понятно дело, что LLM иногда промахиваются, и я попросил ее написать какую-нить настройку для существующего стайлера.

На что получил ответ "никто так не умеет".

На что я велел взять, и написать стайлер "под проект" - https://github.com/pg83/ay/blob/master/refac.go, больше 1000 строк кода.

Опять же, не представляю, что стал бы так заморачиваться год назад.

Мораль? Нет ее!