«Важливо не забувати, як писати код руцями»: CEO GitHub про те, чому не варто покладатися лише на AI

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

CEO GitHub Томас Домке повідомив, що навіть у часи, коли ШІ активно пише код, розробникам не варто забувати як це робити самостійно. Він застерігає, що якщо повністю покластися на автогенерацію, можна втратити важливі навички й час.

У подкасті The MAD Podcast with Matt Turck він поділився думкою, що найефективніше — це вміти легко перемикатися: десь використати AI, а десь — швидко внести правки вручну.

«Найгірше — це витрачати кілька хвилин на пояснення простих змін у звичайній мові, коли можна просто написати цей рядок коду за три секунди», — каже Домке.

За його словами, ідеальний процес виглядає так: ШІ допомагає, пише код, створює pull request, але розробник має повний контроль і здатен швидко все підправити, якщо потрібно. Саме це й забезпечує реальну продуктивність.

Також він згадав модну нині концепцію вайбкодингу, коли фаундери стартапів покладаються лише на AI, без технічних знань. Цей термін увів Андрій Карпаті з OpenAI, а Домке зауважує: на самих вайбах далеко не заїдеш.

«Якщо у вас немає команди, яка справді розуміє, що робить, — ви не зможете створити складний, життєздатний продукт, який буде вартий наступного раунду інвестицій».

Його головна порада — давати розробникам свободу обирати: де ШІ справді допомагає, а де краще діяти ручками. Гнучкість — ось що має значення.

А ви погоджуєтеся з його словами?

👍ПодобаєтьсяСподобалось6
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
«Найгірше — це витрачати кілька хвилин на пояснення простих змін у звичайній мові, коли можна просто написати цей рядок коду за три секунди», — каже Домке.

Якщо це навіть CEO розуміє, який код в складних проектах писати не повинен...

А по іншому не буде.
AI на старті може клепанути гору коду хаотичної якості, а далі все руцями.
Ну ще може щось дуже точечно додати (аргумент в функцію + передати + порендерити).

Ну ще може щось дуже точечно додати (аргумент в функцію + передати + порендерити).

Це иснує в ІДЄ вже років 20 — автокомпліт та рефакторінг і він був до цього хайпа із цим ШІ

Не знаю, не бачив, юзаю Jetbrains.
Перемістити/переіменувати файл/функцію/змінну може (і усюди апдейтнути), але з аргументами — ні.
Автокомпліт трошки працював на закінчення, або div+tab ->

, чи дописувало до повноцінного виклику useState/useEffect.

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

А вот чистий 100% вайбкодинг, коли взагалі не заглядаєш що він там генерить, і програмуєш чисто промтами, тоді да, проект швидко перетворюється на «гору кода хаотичної якості», половина якого навіть не використовується. Такий варіант також робочий, тільки на маленьких проектах, на кілька тисяч строк коду.

У мене воркалоу приблизно таке:
1. Вибираю підзадачу
2. Вайб кодлю поки не доб’юсь потрібного функціоналу
3. Потім прошу переглянути і проревьювити всі зміни що зробили за цю сесію, підчистити
4. Роблю пункт 3 кілька раз, інколи з використанням кількох моделей.
5. Потім вже сам ревьювлю, і якщо щось не подобається, прошу поправити, або сам правлю
6. Комічу

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

А де це треба працювати, шоп генерувати код за допомогою ші ? Це типу сайт-візітка на хтмл чи шо ?

Не знаю що вони там пишуть у мене максимум використання ші це автокомпліт в ідє але він і до хайпа був

Та я сам нe вiрю що в гуглi 30% коду гeнeрить AI, алe що якось вони його таки використовують цiлком вiрю.

Дивлячись як виміряти, будь яка оцінка без методики оцінювання це сміття.

обовʼязково, бо буде як у Гіперіоні, коли люди стали залежні від машин, а самі нічого вже не могли)

На зараз можна погодитись, у майбутньому тобто надалі та дивлячись до якого рівня все то дійде... напевно частково.
Чому частково:
— з однієї сторони (ближче до сучасності) нп можна навести «актуальність» кодування на асемблері чи оптимізація руцями коду замість компайлера в цілому
— з іншої нп колись було що reading/writing (докупи з книгами) як artificial винахід погіршує як розуміння так і пам’ять, і що це було предметом дискусій

Підписатись на коментарі