#LLM #development

Я часто зустрічаю повідомлення типу: “Я попросив щось зробити ШІ, він зробив дурню. ШІ - лайно. ШІ ще не скоро замінить людину.”
І хоча з останнім твердженням я більш-менш погоджуюсь - сучасний ШІ справді ще дуже далекий від повноцінної заміни людини. З першим я категорично не згоден.
Але хто я такий, щоб вас учити? Давайте краще звернемося до статті з сайту Мартіна Фаулера і подивимось як працювати з LLM.

У статті “Guiding an LLM for Robust Java ByteBuffer Code” https://martinfowler.com/articles/exploring-gen-ai/14-guiding-llm-java-bytebuffer.html розповідається, як розробник намагався змусити LLM створити код для заповнення ByteBuffer у Java.

Спочатку він попросив LLM створити код для певної структури даних.
Отриманий код працював, але змінював положення буфера (position()), що могло викликати проблеми в паралельних сценаріях або при роботі з загальними буферами типу MappedByteBuffer.

Щоб покращити рішення, розробник запропонував технічно-архітектурне рішення:
використовувати абсолютні методи (put(index, value)) замість маніпуляцій із позицією для уникнення побічних ефектів.
Після цього він провів рефакторинг, даючи LLM чіткі інструкції щодо організації доступу до даних та структури коду.

Завдяки такому підходу код вийшов чистішим, без побічних ефектів і краще придатним для реального використання.

Що показує цей приклад?

Цей кейс добре ілюструє, чому роль розробника залишається критично важливою при роботі з LLM:
Виявлення прихованих ризиків:
Початковий код виглядав робочим, але розробник побачив ризики побічних ефектів через маніпуляції з позицією буфера.

• Контекстна обізнаність: розробник розумів, як поведінка коду може вплинути на MappedByteBuffer, паралельне виконання і розробку бібліотек.
• Формування правильних патернів: він навмисно направив LLM на використання методів без збереження стану і роботи через абсолютні індекси.
• Застосування принципів проектування: переписаний код був не тільки правильнішим, але й краще структурованим - інкапсульованим, з константами і зручним для підтримки.
• Критична оцінка результату: на всіх етапах розробник оцінював не лише функціональність, а й нефункціональні вимоги: безпеку, стабільність і ремонтопридатність.

Висновок

ШІ, LLM - неймовірно потужні інструменти для розробки, які можуть суттєво прискорити роботу і допомогти у складних завданнях.
Але, як показує цей приклад, вони залишаються лише інструментами, які потребують досвідченого керівництва.
Створення надійних і якісних систем вимагає критичного мислення, розуміння контексту і глибоких знань інженерії програмного забезпечення.
Експерт не просто підказує код - він аналізує, направляє, вдосконалює і інтегрує рішення так, щоб воно відповідало вимогам реальної розробки.

references: https://martinfowler.com/articles/exploring-gen-ai/14-guiding-llm-java-bytebuffer.html