Спочатку навчись писати руками: чи варто забороняти джунам використовувати AI?

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

Побачила цікаве обговорення на Reddit, де сіньйор порівнює двох джунів у команді. Один пробує розібратися, а інший просто копіює код з чату, навіть не вчитуючись. Доходить до смішного: коли на код-рев’ю питають «що це?», джун чесно каже «не знаю, приберу це».

Згадала, як сама проходила курс Fullstack: наш ментор наполягав, щоб ми не юзали ніяких АІ-інструментів, навіть розширення для VS Code. Доводилося писати все руками, навіть найпростіші речі. І зараз я думаю, що це було правильно, бо AI може бути дуже корисним, але щоб ефективно ним користуватися, треба мати базу і розуміти, що саме ти робиш.

Цікаво, як ви ставитеся до цього: чи варто джунам на старті обмежувати доступ до AI, щоб вони спершу навчилися писати й аналізувати код самостійно?
👍ПодобаєтьсяСподобалось8
До обраногоВ обраному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

хай використовують бʼють шишки по свому

Чим більше джунів, які не вміють писати код, тим дорожче будуть мої послуги... ;)

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

Да нет, зачем, ИИ — такой же инструмент.
Просто нужно следовать принципу own your mistakes, т.е. если человек напортачил — то это его ошибка, вне зависимости от того, сам он её сделал, вычитал со StackOveflow или поверил галлюцинации чатжпт.
А если человек по итогу часто ошибается и/или не может объяснить, что за код он пишет — добро пожаловать на выход.

Погодите, а как же collective code ownership? А как же «успех индивидуума = заслуга менеджера, ошибка программиста = ошибка программиста, менеджер ни при чем»?

Коментар видалено автором допису.

Коментар видалено автором допису.

дайте джунам спокій працювати так, як їм подобається. вони не такі ригідні як сіньори і в них ще буде чому повчитися старперам, а не навпаки (якщо мова про ШІ). через років 5 буде достатньо статистичних даних, щоб зробити висновки, що і для яких задач краще.

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

бгг, нещодавно було смєшноє

зустріла знайомого, що працює на інженерній менеджерській позиції у одному німецькому необанку. з горящими очима загнаного у кут бідолаги він розповів мені, що завдяки ШІ вони прискорились десь 3х, хоча стейкхолдери вимагають 10х, а ціль 50х. не всі люди витримують такий темп, багато овертаймів, але кого це їбе? їм сказали, що ШІ прискорює, от і зробить 50х.

через 2 тижні у того необанку сталася бага — тобі переказують гроші, а транзакція проходить 2 рази і ти отримуєш подвійну суму. десь через тиждень багу пофіксили — в аппці з’явилася транзакція зі знаком мінус — що свідчить, що то був не просто UI глюк апплікухи

я не можу стверджувати, що бага сталося саме через ШІ, але припускаю, що є зв’язок з очікуванням 50х (бо в вас є тепер ШІ), овертаймами та критичними багами, що займають потім тиждень часу пофіксити

Помітьє, є ШІ нема ШІ — а на досліди Peple Ware як не зважали так і не зважають. Коли робиться система мотивації, що базується лише на негативних методах — робиться не прискорення, а бракована продукція. Це при тому, що японці бознаколи винайшли як прискорюватись х20, і так роботичне обладнаня і автоматичні лінії це їх. Людей не гнали в шию, а дали фреймверк і грощі за прискорення. Про чучело майстера, яких за подвійним дзеркалом дивиться як його лупцюють — мало хто не чув. Да вкалують вони так, що уряд вирішив виключати світло в не робочі години в технологічних зонах.

я не можу стверджувати, що бага сталося саме через ШІ,

Головне що ви в «правильному» топіку запостили, де народ не сильно в деталі вдається і не до кінця коментра читає. Потім через місяць будуть друг другу пересказувати міфи, як із-за ШІ в Германії найбільший банк стопнувся.

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

ні, без ші він буде повільніше вчитись, інша справа, що крім ші треба щоб він читав теорію, бо без неї дійсно просто буде копіювати код з чату

Я б сказав, не тільки теорію.

Ще й кожен рядок Коду пропускати крізь себе. Щоб розуміти, ЩО він робить.

P.S> Це я по своєму досвіду сумному. =) Так «зфакапився» з вайбкодінгом, що... «Но пассаран»!

База тверда повинна бути. Щоб малєйший «глюк» ШІ не вибивав розробку (бо нікому поправити вручну — «не зрозуміть ніччо»).

Від джуна залежить. Є джуни вайтішники, а є джуни-гіки, які ще в школі програмили, слідкують за технологіями, пишуть пет проджекти. У нас в компанії є джуни кращі за половину сінйорів.

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

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

У нас в компанії є джуни кращі за половину сінйорів.

у вас в компанії личку «сіньор» видають за кількість відсиджених жопочасів чи за довжину бороди?

перше, плюс в золоті часи ІТ (пре-ковід, ковід) багатьох відвертих і навіть слабих мідлів, сінйорами відразу брали

Не всі сінйори звісно такі, но мінімум кожен третій-четвертий. Но назви ентерпрайз чи будь-яку велику компанію де не так? я би сказав не так тільки в стартапах на початкових стадіях де треба їбашитии

перше, плюс в золоті часи ІТ (пре-ковід, ковід) багатьох відвертих і навіть слабих мідлів, сінйорами відразу брали

це сіньор по відсіджуванню дупи

Так, а такі як ти тут розказують що це колодязь знань і досвіду, і що АІшні вайбкодери їм в мізінець не годяться, що ці сіінйори будуть виправляти АІшний код через рік.

Із власних спостережень, АІ дисиденти в основному серед таких сінйорів. Нормальні сінйори або вовсю в АІ залазять, або не залазять по іншим причинам ніж "говно, не працює, не допомагає, сповільнює).

я не знаю де ти береш ці спостереження, навіть на моєму тракторному заводі німецьки сіньори 60+ юзають ШІ аж бєгом, але звичайно там, де воно дійсно працює і прискорює

Так, а такі як ти тут розказують що це колодязь знань і досвіду, і що АІшні вайбкодери їм в мізінець не годяться

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

ну а якщо я б зараз наймала людей на свій проект, то це були сіньори, які вміють використати ШІ, а не вайбкодери візіонери рівня «пишу 6 проектів одночасно, коли одна модель думає, я пишу промпт для іншої, іпать-який-я-***єнно-продуктивний-мєга-чел», бо потрібен результат, а не спостерігати як діти граються за мої кошти

я не знаю де ти береш ці спостереження, навіть на моєму тракторному заводі німецьки сіньори 60+ юзають ШІ аж бєгом, але звичайно там, де воно дійсно працює і прискорює

Я про вік нічого не казав
Я не казав що всі сінйори ШІ дисиденти
Я не казав що всі фейкові сінйори ШІ дисиденти
Я сказав що серед ШІ дисидентів в основному фейкові сінйори, які жопою насиділи своє сінйорство.
На швейній фабриці працюють в основному жінки != всі жінки швейки

У тебе елементарні скіли логіки відсутні

пишу 6 проектів одночасно, коли одна модель думає, я пишу промпт для іншої, іпать-який-я-***єнно-продуктивний-мєга-чел"

лол, так це вони і є:

сіньори, які вміють використати ШІ

Чим більше у тебе розуміння і досвіду з ШІ, тим складніший у тебе вокрфлоу, тим більше паралельно агентів ти можеш ганяти, тим менше вони потребують твоєї уваги.

Чи чого ти очікуєш від сінйора з ШІ?

Чим більше у тебе розуміння і досвіду з ШІ, тим складніший у тебе вокрфлоу, тим більше паралельно агентів ти можеш ганяти, тим менше вони потребують твоєї уваги.

Чи чого ти очікуєш від сінйора з ШІ?

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

О, демагогія почалася і спригування з теми

Це всі true сінйори вміють, зі ШІ і без (ті що з ШІ роблять це швидше при інших рівних), інакше не був би сінйором.

Ти сказала що найняла би сінйора з ШІ але сінйор який ганяє кілька агентів параельно для вирішення задач і вирішує кілька задач паралельно це прям фу-фу-фу. Тому так і не відповіла на питання, як по твоєму сінйор має використовувати ШІ для рішення задач?

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

ти слабо уявляєш що це означає

А що тут гадати? Це декілька віртуальних десктопів з кількома проектами з кількома агєнтами, над якими ви працюєте одночасно.

Елементарно же ж! Що тут може бути незрозумілим взагалі? 👻👻👻

Ну тобто більшість «сіньорів», отримуючі по тищщі баксів/наносєк, займаються звичайним паразитизмом, зазвичай?

«Втиранням якоїсь Дічі» про свою «мєга-компетентність», «незамінність» та займаючись лютєйшим ІБД, майже нічого не роблячи на фірмі взагалі?

Порівняно з джунами та мідлами — які «усю лямку тягнуть», гроблять здоров’я та нерви за дуже малий прайс?

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

Вони спали спокійно, могли диктувати свої умови, так як на ринку був дефіцит кадрів. Но, layoff-и, АІшка зараз все змінять. Там, де до АІшки треба було розгрібати тони коду і ходити за питаннями до сінйорів, читати документацію, зараз АІшка по коду, по джирі, по історії в гіті все розкаже. Ніколи онборд на новий проект не був таким простим і швидким як зараз.

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

Єдина їх користь досвід в домені, знань... в інфраструктурі і архітектурі

То що відмічено як -єдина- і становить одну з головних цінностей. А додатково то буквально кодування чи запам’ятовування патернів з ним пов’язаних — то найнудніша частина яку з задоволенням можна віддати машині щоб вона і греблася в ній.

Тобто якщо зазначена «ШІшка» конкурує з тими для кого машинерія то найголовніше — то гуд, а профі у своїх доменах зможуть спати ще більш спокійно та обирати-диктувати умови ще більше вільно)

Проблема не в АІ а в джуну. Він би так же само з стековерфлоу скопіпастив би бездумно. Но без АІ в заголовку тема би не взлетіла.

Та що там джуни, я знаю сінйорів які це роблять. Особливо на поекті бездумно копі-пастячи якусь логіку не розбираючись що там і не розуміючи що тут ініціалізація он цих то пропепрті і цих об’єктів не потрібна. Но він весь код сніпет скопіпастив.

При використанні АІшки, найважливіше — це розуміти, що воно тобі пише. Бездумно копіпастити — це поганий варіант, який веде до анархії та вакханалії.

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

веде до анархії та вакханалії

Шикарна фраза! Схоронив! )))

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

Зараз ми просто в перехідному періоді. ШІ не гарантує правильний результат, тому його треба перевіряти. Саме для цього і є рев’ю. І от тут якраз ховається справжня робота програміста. Саме написання коду ніколи не було великою проблемою. У мене 90% часу йде на відлагодження: треба перевірити, як воно реально працює, чи все йде як задумано.

Тому написання коду не застаріло. Проблема того джуна не в тому, що він юзав ШІ, а в тому, що він не зробив ці 90% роботи і не проаналізував результат. Що досить важко робити, якщо ти не знаєш як програмувати.

Зараз ми просто в перехідному періоді. ШІ не гарантує правильний результат, тому його треба перевіряти

в переходном периоде куда? к faith driven development где мы отметаем сомнения что сгенерированный код может не соответствовать ожиданиям?

Якщо у нас буде верифікований код, то проблема зводиться до коректності специфікації, а не до віри в правильність коду. Але зараз LLM не генерують верифікацію, і коли почнуть, нікому не відомо. Може за 5 років, може за 100. А поки що ми в перехідному періоді, де розробник все ще контролює та перевіряє згенерований код.

Якщо у нас буде верифікований код, то проблема зводиться до коректності специфікації, а не до віри в правильність коду

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

Але зараз LLM не генерують верифікацію, і коли почнуть, нікому не відомо

никогда, ну точнее ее можно сделать по старинке через автоматизацию тестирования и сделать все тоже через ллм, но это все равно не будет гарантией и точно не будет универсальным решением

В мене наприклад 90% часу — це SOLID, паттерни, архітектура, секьюріті, перформанс, юніт тести, інтеграції. Наприклад як зробити інтеграцію з ISO7816 девайсами, як оптимізувати оффлайн роботу сервісу, як знайти та позбутися XSS та RCE, чи як оптимізувати криптографію щоб розтягнути функціонал на усю систему. Я більше часу думаю, аніж перевіряю. Можу сказати зо народження специфікації йде після розуміння протоколу, принципів роботи, та глибокого аналізу. Це усе системна робота, і кожен день я стикаюся з чимось незнайомим, але спочатку намагаюсь вчитися, а не промтити.

А промпт — це не навчання?

Ніт, для переважної більшості — це гра у розмову зі стохастичною папугою.

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

P.S> Спойлер: LLM, як «стохастична папуга», нічого в плані «сенсу» — на відміну від людини (що хоч трошки) не розуміє в діалозі взагалі.

Тільки токени «угадує». Ну, таке.

Саме для цього і є рев’ю. І от тут якраз ховається справжня робота програміста.

Джун буде клепати мержреквести, а сіньор має то все перевіряти? То нахіба той джун потрібен? І коли сіньору виконувати свою роботу, якщо ждун за допомогою AI клепає мр швидше ніж сіньор їх в стані проревʼювати? [питання в повітря]

Проблема того джуна не в тому, що він юзав ШІ, а в тому, що він не зробив ці 90% роботи і не проаналізував результат. Що досить важко робити, якщо ти не знаєш як програмувати.

Так ждун має займатись завданнями відповідно своїх сил та навичок і зі збільшенням складності та різноманітності задач — рости. Це і є шлях перетворення ждуна в сіньора і цей шлях потрібно проходити.

Ревʼю чужого кода, а тим більше ревʼю вихлопа з AI, який може видавати досить серйозного рівня код/рішення — взагалі не компетенція джуна. Моя особиста думка, ждунам користуватись AI можна і навіть треба, але в якості ментора для навчання, для пошука рішень, але точно це не має бути copilot чи агент для написання кода.

У мене 2 протилежні думки на цей рахунок.

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

Думка 2 — варто бути on the cutting edge of tech і якщо якась технологія покращує життя та спрощує робочий процес — варто цим користуватися, бо якщо не користуватися — можна програти гонку тим, хто цим користується і рухається по ринку та між ітераціями продукту набагато швидше.

варто бути on the cutting edge

А також, якщо є можливість, можна почекати поки технологію відполірують та позбивають ентузіастами гострі кути по ходу, і не треба буде потім голову забивати чимось що відсіється по тим чи іншим причинам у процесі становлення. Якщо з поточним станом роботи/проектів не дуже — то так, cutting edge теж опція.

Цікавості заради, а на якому рівні вимагається пояснення — організація і керування пам’яті? Впливу GC? Складності алгоритму O(N)?
Можливо, якщо хтось вимагає пояснення, то сам не дуже розуміється на алгоритмах?
Очевидно, що проблема не в джуні, а в поставленій задачі, а джун з аі мав її згенерувати і потестити, що якраз і є рівнем джуна сьогодні. А вимагати від джуна самописного коду — максимально не ефективно.

Коли створили перші станки — їх спалили робітники, які втратили роботу а потім ті станки були всюди. Те саме з ШІ — його забороняють але вже школярі роблять застосунки на рівні галєр 5ти річної давнини.
якщо розуміеш що треба зробити, +/- знаєш як воно має бути то ШІ то купа джунів на всілякі теми. створить план проекту (треба перевірити) а потім потроху клепати модулі проекту і постійно тестуємо. Залежно від велічі прожекту за тиждень може вийти за маштабами щось схоже на фейсбук (може не таке продуктивне) а ще за тиждень може бути вже Rокет сайнс :) і не забувайте комітити часто ....

А тобто коли сініор не може пояснити згенерований код це нормально ? Тим не менше ми йдемо до цього і скоро це буде абсолютно нормально, головне буде чітко розуміти промпт і вміти його віддебажити. Бо станом на зараз дуже далеко не кожний зможе пояснити асемблерний вивід своєї програми на ЯВУ, чи правила перетворення згенерованого байт коду в машинні інструкції. Попередні покоління програмістів рвали волосся на дупі через це, бо там воювали за кожний конкретний такт СPU подекуди і не дай хтось вставить ділення там де можна зробити здвиг.

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

Коли я вчився в університеті, нам доводилось на лабораторних работах писати код на асемблері в бірюзовому редакторі Norton Commander, або запустити Turbo Pascal — що було не зручно бо для запуску того же TASM чи MASM треба було виходити, в MS DOS GUI та звичних вікон не було. Одного разу в Vi бо така була лабораторна робота для UNIX, тоді я подумав що NC/Midnight це насправді ще і супер. Так на той момент це вже було те саме, що ломом підмітати плац, як в тому військовому анекдоті. Нічого це не додає як тільки бажання використовувати чи створювати більш продуктивні інструменти.

Є суттєва різниця. Коли ми пишемо на C/Ada/..., мова має формальну семантику, і ми виходимо з припущення що компілятор працює коректно (або навіть маємо формальні докази для деяких компіляторів). Для критичних систем часто компілюють з мінімальною оптимізацією саме для верифікованості асемблерного коду.

А от з LLM-генерованим кодом проблема в тому, що «компілятор» (сама модель) не має ні формальної специфікації, ні гарантій коректності. Ти не можеш бути впевнений, що промпт дасть саме ту семантику, яку ти хотів.

Берем Clean Architecture Роберта Мартіна ака Дядька Боба і читаємо, що оскільки математично доведений метод який запропонував Едгер Дейстрера в цілому провалився і визнаний вічним двигуном в ІТ, то ми використовуєм науково доказовий метод в розробці программого забеспечення, тобто тестуємо. Просто через стабільність для переважної кількості типових і шаблонних задач, ми не стикаємось із тими багами, що є в засобах розробки, чи навіть операційних системах чи самому залізі. Тим не меше у них там багтрекери із тисячами багів.
Таким чином що ШІ, що людина однаково можуть створити баги (дефекти) і часто з тих же причин, скажімо довидумує реалізацію чогось крли вимоги не достатньо формальні чи ясні.
От що дісно погано, це коли лющина нічогісенько не розуміє в результаті і не здатна виправити помилку, це як би пілот літака який в сутності станом на зараз дублює компьютерні системи авто пілота, в разі нештатної ситуації не міг би взяти на себе керування — в такому немає жодного толку. Та через якийсь час орієнтовно через 10 років, так це вже буде не порібно зовсім. Умовно достаньо буде запиьати ШІ виправити не вірний результат.

Дядько Боб, звісно, красень і піарник від бога, але давайте чесно: його експертиза дуже специфічна і, м’яко кажучи, обмежена. Він усе життя перекладав дані з JSON у базу і назад у великих корпораціях. Він ніколи не писав драйвери, не працював у геймдеві та не проектував складні мережеві протоколи.

Тому, коли він пише, що методи Дейкстри провалилися... це звучить просто смішно. Насправді ідеї Дейкстри не провалилися, вони просто випередили свій час. Тоді банально не вистачало теорії, інструментів і обчислювальних потужностей. А от зараз мрії Дейкстри якраз стають реальністю. Подивіться на TLA+, на системи на кшталт Coq або Lean, на SMT-солвери. Навіть той самий Rust сьогодні на рівні компілятора робить частину тієї математичної перевірки коректності, про яку говорив Дейкстра.

Проблема «Чистої архітектури» в тому, що вона намагається видати за складність звичайну бюрократію. Якщо розробка Linux Kernel це проектування ракетного двигуна, то типовий ентерпрайз це просто розстановка товарів на стелажах у супермаркеті. Так, там треба знати, де стоїть молоко, а де хліб, щоб нічого не переплутати, але це не ракетобудування.

Че ???

Дядько Боб, звісно, красень і піарник від бога, але давайте чесно: його експертиза дуже специфічна і, м’яко кажучи, обмежена. Він усе життя перекладав дані з JSON у базу і назад у великих корпораціях. Він ніколи не писав драйвери, не працював у геймдеві та не проектував складні мережеві протоколи.

uk.wikipedia.org/wiki/Роберт_Мартін
Власне коли він був ленійним программістом то працював над IDSET на асемблері Honeywell H200 ще в 60-ті роки. З його подальших продуктів най відомішим є FitNesse фреймверк для автоматичного тестування, зараз майже повально витіснений Cucumber, а в 10-14 роки ми його активно використовували — другий дещо зручніший дійсно.
Дядько Боб як не крути професійний консалтер здебільшого, з репутацією, що відрізняє його від інфоциган. Та безперечно досвід має.
При цьому пременшати досягнення Едгера Дейкстери не будемо, лауреат премії Тюрінга як не як. Автор ALGOL, Автор структурного програмування взагілі, та виклкика за ім’ям, що надало можливість виделення в структурі під программ — тобто процедур (в С void foo() ) та функцій, коретежей як то структури (record — algol, pascal і т.д., struct в С) і т.д. і т.п.

Якщо розробка Linux Kernel це проектування ракетного двигуна, то типовий ентерпрайз це просто розстановка товарів на стелажах у супермаркеті.

Ага — тільки це буде : Google, Microsoft та Amazon. GCP, AWS та Azure — типу не системний софт?

але це не ракетобудування.

така сама специфіка — так вже сталось що в універі я вчився ІТ специфічному для саме ракетобудування, тоді в Україні ще булись якісь залишки цього. Там робота може полягати в тому що ви берете модель в текстовому формату IGES і робите експорт її в текстовий же формат STEP, щоби стойка ЧПУ прийняла модель експортовану з : SolidWorks, Сatia, Autodesk Invertor чи іншої CAD системи. Супер грандіозна різниця із JSON маніпуляцією. А PLM системи — це чистої води CRUD на мікросеврісних архітектурах.

головне буде чітко розуміти промпт і вміти його віддебажити

очень-очень далеко до этого
— AI жестко косячит даже в маленьких песочницах в 300-500 строчек без внешних зависимостей (или с системными зависимостями, которые хорошо известны и идеально документированы)
— то, что генерируется, плохо читаемо, а читать надо, потому что см. предущий пункт
— в промптах замахаешься перечислять все edge cases, а так как общий уровень не очень, то обработаны они будут в режиме «по умолчанию» в джуниорском исполнении
— выдаваемый по спекам результат абсолютно не предсказуем, рандом там вообще зашит по умолчанию, завтра выкатили минорный апдейт или стала не так фаза луны и после дописывания одного предложения в спеку ты получаешь абсолютно новый код, который нужно внимательно перечитывать (потому что смотри первый пункт)

Уже сильно лучше, но да косяки есть. Еще в начале прошлого года, все плохо было кроме скажем python под который видимо были заточены все модели. Сейчас по лучше уже, причем некоторые модели даже умеют подстраиваться под код стайл который ты им скармливаеш.
А скажем типичный CRUD по шаблону, но делает на раз или SQL запрос запросто даже со сложными джонтами, если конечно хорошо и достаточно формально задать промпт.

бо там воювали за кожний конкретний такт СPU подекуди і не дай хтось вставить ділення там де можна зробити здвиг

Ну ось тому і «маємо те, що маємо».

Космічні кораблі управлялися у 60-70-х програмами, що на дискету влазили та на допотопних процесорах, у 100500 разів слабіших за сучасні у смартфоні (і добре до Місяця та Марса долітали) — а зараз більшість аплікацій обвішана фреймворками, важить нємєрянно, як оті жирабаси на фаст-фуді, та на сучасних процах тормозить, відбираючи шалені гігабайти ОЗУ...

Спочатку навчися писати руками — це якби сьогоднішніх сеньорів вчили спочатку на перфокартах писати.

перфокарта — это носитель информации

Хоча пробивати дірочки на перфокартах — це була окрема від програмування професія.
Але також не завадить вивчити, перед тим як на клаві друкувати.

это странный способ сказать что новое лучше старого, но только это не оно, это устоявшееся и экспериментальное. по-нормальному джунам нужно и то, и то

Станом на сьогодні ШІ ще не може повністю замінити людину в програмуванні. Але, можливо буде так, що людині для того щоб стати мідлом треба буде знати лише алгоритми. А все інше робитиме ШІ.

но ии уже умеет алгоритмы лучше большинства синьоров

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

Чи варто дужну/трейні використовувати ШІ для написання коду?
Дуже обмежено, бо спокуса взяти щось готове і не розібратися як воно працює велика, а строки завжди тиснуть.

Чи варто дужну/трейні використовувати ШІ для аналізу вимог і пошуку рішення?
Дуже варто, бо в багатьох випадках ШІ має сильно більше часу ніж Лід який сказав «зробити щоб красівоє і не падало»

Навіщо обмежувати?

Якщо завдання з fullstack вирішується за допомогою ШІ, то тоді навіщо ви його вчили? Ось у чому питання! Тобто: «У чому моя мотивація написати програму БЕЗ ШІ»?

Написав пост в особистому блозі на схожу тему:

t.me/obrizan2/296

Чи треба вивчати програмування, коли є ШІ?

Я вивчав компʼютерну інженерію в ХНУРЕ у 2000-2005.

На першому курсі ми вивчали мову асемблера та писали на ньому програми, хоча вже існували розвинені компілятори С/С++.

На другому курсі ми вручну синтезували апаратні схеми на логічних елементах, хоча вже існували програми логічного синтезу.

Коли я викладав «Оптимізацію швидкодії програмного забезпечення», то ми зі студентами тестували різні варіанти алгоритмів, та їх машинний код, хоча в сучасних компіляторах вже існували сотні алгоритмів оптимізації.

Ну ви зрозуміли до чого я веду.

Я не можу сказати, що я усе це вивчав марно, та воно мені не було корисним. Навпаки, дивлячись на поточний стан розвитку програмного забезпечення, то ці знання і вміння досі можуть бути корисними. Лінус Торвальдс досі оптимізує ядро Лінукса на асемблері, враховуючи такти процесора та промахи в кеш-памʼять. А ffmpeg — найпоширеніший інструмент для перекодування відео — пишеться мовою асемблера (ключові алгоритми).

Може середньому програмісту і не потрібні ці знання. Але як показують наведені приклади — топові інженери повинні знати та вміти робити «під капотом».

Бути середнім програмістом або топовим — це вибір людини.

Якщо би я знову поступив вчитися на компʼютерну інженерію, то я би знову поліз би вивчати що там під капотом.

— Чи треба вивчати програмування, коли є ШІ?
— Так, треба.

повинні знати та вміти робити «під капотом»

Колись у нас на деяких екзаменах можна було користуватися чим завгодно, але... але потім був допит з пристрастю — треба було все пояснювати, доти поки екзаменатору не ставало ясно що все то студент розуміє і може сам пояснити написане.

тобто -знати-вміти- також можна перефразувати як — принаймні повинні розуміти що то і до чого

Так, викладач баз даних нам і казав: «ви можете прийти на екзамен з книгами, я буду з вами спілкуватись як з професіоналом». Я прийшов з книгою та отримав «добре».

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