Неймінг стає менш важливим: як інженер Anthropic радить писати код в епоху ШІ
Нещодавно ми обговорювали чи залишилися ще динозаври, які пишуть код тільки руками. Думки тоді розділилися. Хтось давно все делегував ШІ, а хтось скаржиться на години дебагу після генерації.
А днями я послухала подкаст з інженером Anthropic Таріком Шихіпаром:
На початку розмови Тарік каже що більшість софту написаного до ери LLM була не дуже хорошою. А далі розповідає як саме штучний інтелект змінює їхній підхід до розробки.
Наприклад, на його думку неймінг і стилістика коду поступово стають менш важливими. А щодо техборгу він припускає що майже кожна кодова база з часом дійде до моменту коли її захочеться просто віддати моделі на повний рерайт.
«...almost every codebase will have this moment where you ask the model to rewrite all of it».
Звучить круто, але на практиці такі масові ШІ-рерайти поки що йдуть зі скрипом. Згадайте нещодавню історію з Bun. Згенерувати величезний шмат коду можна швидко, а от розуміти його і дебажити — зовсім інша історія.
Можливо саме тому Тарік так багато говорить про перевірку. Через те що моделі генерують купу коду дуже сильно зростає потреба в тестах та інших способах верифікації. Його оцінка тут досить радикальна, бо він радить мати «a hundred times more testing code than you’ve ever had before».
Водночас інженер наголошує що технічна експертиза нікуди не зникає. Розробнику все ще потрібно розуміти що саме варто будувати помічати проблеми та оцінювати якість результату.
Цікаво як такі ідеї метчаться з вашими реаліями. Ви б ризикнули забити на рефакторинг і неймінг в надії, що ШІ колись усе ідеально перепише? Чи такі радикальні підходи можуть працювати лише в компаніях, які самі ж цей ШІ і створюють?
24 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівЇм просто треба прискорити момент коли люди втратять змогу розібратись і працювати з кодом.
Маркетинг і не більше, навіть, сам Claude не згоден:
«Це справді Тарік Шихіпар з команди Claude Code, і я підтягнув сам подкаст, щоб не спекулювати з чужих переказів.
Моя загальна реакція: ідеї не марні, але їх варто читати з поправкою на те, хто саме їх каже. Anthropic — це компанія, яка (а) сама створює модель, тож має привілейований, найсвіжіший доступ до її можливостей, (б) працює переважно над кодом, який сама ж і споживає (внутрішні тули, дашборди, скрипти для експериментів), і (в) має культуру, де інженер сидить поруч і власноруч перевіряє кожен diff. Це дуже інша ситуація, ніж прод-код фінтеху чи банку, де за баг платять реальні гроші й регулятори.
....
Неймінг і стиль стають менш важливими. Частково погоджуюсь — але з нюансом. Якщо код читає переважно модель (яка вміє тримати в контексті весь файл і робити semantic search), а не людина, яка сканує око́м, то справді частина сенсу „гарного неймінгу“ (щоб людина швидко зрозуміла призначення змінної) слабшає. Але неймінг ще служить і іншій функції — він кодує намір і домені-специфічну семантику, яку модель сама вивести не може („чому це pendingSettlement, а не просто amount“). Я б сказав: стиль-guidelines (табуляції, порядок імпортів) — так, стають дешевшими, бо їх лінтер/агент відновить за секунду. А смислові назви, що передають бізнес-логіку — ні, вони й далі критичні, просто тепер їх більше читає модель, ніж людина.»
Хотілось би нагадати слова Дейкстри про те що хороший програміст має також добре володіти рідною мовою.
А стала ще гіршою.
просто DOU Community Manager мають план по створенню нових тем для обговорення.
а про що тема, що там Тарік порадив — як код писати чи як в носі колупатись — діло десяте.
p.s.
але скоро ллм-ка замінить 90% Community Manager і буде писати за них статті.
уверен что больше ллм никого не заменит, на данный момент ллм больше всего заменила только суппорт, все кто сделал эту замену финансово пострадали, бо никто из клиентов не хочет говорить с вот этим вот. во всех остальных сферах все свелось к тому что платить надо не людям, а провайдерам ллм. рано или поздно инвестиции провайдерам закончатся и они начнут объявлять себя банкротами
запомните этот пост ©
«Хороший софт настане через2-3 тижні!»
почав робити апку з event sourcing дизайном, в апці є тести та готові контракти для побудови проекцій на основі подій з кафка, дав агенту таску додати агрегат та проєкцію, тести пройшли і робота виконана, через день заглянув в код, а там проєкція будується з всіх подій агрегату кожен раз, навколо агрегатів написаний ще один контракт, який будує власні агрегати і використовує event store як базу для проєкцій. Тому я впевнений, щось серйозне неможливо зробити без review та знання архітектури. Агенти дуже гарно пишуть код який проходить тести, але це не значить, що цей код виконує задачу.
Пффф, я теж умію писати тести які проходять, але не факт що вони щось тестують. І вмію це робити крутіше за клода :-)
thumbs.dreamstime.com/b/none-58954330.jpg
но теперь то мы понимаем, глядя на нынешний поток слопа, что было, в принципе, терпимо и будет становиться только хуже
Тарик какую-то чушь посоветовал и рад.
Это наверное фишка anthropic. У нас практически каждую пятницу ребята с anthropic делают learning sessions и рассказывают про успешный успех, новые методы программирования и тд.
Потом народ начинает сыпать вопросами и ребята начинают отвечать с улыбками, уточнениями и оказывается там такие же инженеры как и мы, все всё понимают, но продавать свой продукт и «революцию» же как-то нужно.
Мне кажется все наоборот: чем лучше структурирован код, тем проще LLM его понимать и продолжать. Хороший naming, namespaces, явные зависимости, типы и границы контекстов дают модели гораздо больше семантики.
Модели в любом случае учились на огромном количестве публичного кода с гитхаба, и логично ожидать, что им проще работать с хорошо структурированным чем с legacy без namespaces, нормальных связей и понятного naming;
Нещодавно Чавунний Ідійот порадив мені в простенькій схемі використати резистор 10 кОм замість 10 Ом. Якщо ЧІ лажає на таких простих речах, то неймінг не втрачає свого значення — перевіряти легше.
Какая модель LLM это посоветовала и какое было думание? Что в контекст передали? Похоже на слабую модель на минимальном думание либо контекст не передали.
Звичайний чятікгпт, те шо по дефолту стоїть. Але ж і керування польовиком не є складним.
Просто я помітив, що чим ближче до реального світу, тим гірше ЧІ радить. «Програмує» він значно краще.
Програмування- Більша база тексту для навчання і очевидна ідея монетизації, тому туди й фокус.
Ну і на тести актуальні модель прикрутити. А все інше — розважальний контент.
якщо дійсно цікаво, як треба, то в мене є бандл, який розказує від керівника інженера до кодінг-формлов, як слід це робити, щоб потім не застрелитися.
leanpub.com/…mspecstoloopsthatremember
І в дійсності неймінг важливий, тому що він формує контекст, і він формує семантику в дійсності. Тому, тіпа, а бракодабру в LLM буде набагато гірше розуміти. І вам для бракодабри, до речі, треба якийсь структурований граф кодової бази. Тому ні, це погана порада на загал. Так не працює.
це нормальна маркетингова стратегія, тобто вас треба навчити гидрити-код, який ніхто, крім Антропіка, підтримувати не буде. Потім у вас не буде звалу, і ви просто будете платити більше гаражів. Це треба зробити рекомендацію безперечною, розповісти, що саме так і треба робити. Якби я був Антропіком, я би таки робив чудову маркетингову стратегію.
Дуже дивна позиція. Вже не раз помічав, що правильний неймінг і структура дозволяють LLM швидше й ефективніше виконувати завдання, бо створюють для неї якісний семантичний контекст. Ба більше, під час змін модель зазвичай продовжує вже наявні в кодовій базі патерни. Якщо код структурований добре, то вона частіше продовжує цю структуру. Якщо там хаос, то дуже легко отримати ще більше хаосу.
Тому теза про те, що на неймінг можна «забити», виглядає дуже сумнівно. Хороша структура, типи й неймінг зменшують неоднозначність, обсяг контексту, який треба відновлювати моделі, і кількість ітерацій під час виконання завдання. Погана структура робить протилежне: моделі потрібно аналізувати більше контексту, вона частіше неправильно розуміє залежності, а розробнику доводиться витрачати більше часу на перевірку й виправлення результату.
А щодо ідеї просто переписати legacy-код нейромережею, то тут усе ще цікавіше. У legacy-системах величезна кількість неявного знання: костилі, приховані залежності, історичні обмеження, edge cases і бізнес-правила, які часто ніде явно не задокументовані.
Код взагалі не є повною специфікацією системи. Тому модель може чудово переписати те, що бачить, але не знати, яка дивна поведінка є випадковою помилкою, а яка — критично важливим бізнес-інваріантом. Без дуже сильного набору тестів, контрактів і специфікацій такий «повний rewrite» легко перетворюється на генерацію нової системи з новим набором прихованих помилок.
Не стають, бо LLM, нагадаю — є мовними(!) моделями. Тому гарна структура та особливо неймінг допомагають LLM краще розуміти та писати код, бо семантика є важливою частиною того, як LLM передбачає наступний токен, а отже — генерує код.
Вона була найкращою хоча б того, що іншого не було. Чи ми можемо сказати, що «до ери LLM» ми не мали гарного софту? Не можемо. Ілон Маск створив XSpace на софті, що написаний до «ери LLM», та й навіть всі LLM написані на цьому софті. А який якісний софт ми створили «у еру LLM»? Чого його ховать він нас всі ці роки?
Навайбкодили DLSS 5 xD