AI пише код, а я втрачаю навички? Рефлексія джуна
Привіт всім! Я junior developer і зараз проходжу той етап, коли вже не зовсім новачок, але ще не відчуваю себе впевнено...
Останнім часом я багато думаю про AI в розробці. І це не про «вау, як швидко тепер пишеться код», а скоріше про змішані відчуття — іноді навіть легку тривогу.
Хочу просто поділитися своїми думками як людини, яка зараз перебуває у цьому всьому всередині.
Про Copilot і де в мене починається «занадто легко»
Якщо чесно, я теж активно юзаю AI. У мене в терміналі живе GitHub Copilot CLI, інколи я пробувала різні інструменти типу Claude або інші AI асистенти для коду, і це суперська штука.
Але я використовую його не для того, щоб він писав за мене логіку. Для мене це радше помічник у рутині:
- швидко накинути юніт тести, особливо коли багато моків;
- розібратись у легасі проєкті, де важко одразу зрозуміти, що де лежить;
- швидше знайти причину бага;
- або просто під час навчання щось уточнити.
Тобто це не виглядає як «AI робить мою роботу», а скоріше як «AI прискорює те, що я і так роблю».
Але навіть при цьому я ловлю себе на дивному моменті.
Коли під рукою є інструмент, який за секунду дає відповідь, ти здається менше напружуєш мозок. Зникає цей момент інтенсивного думання, коли ти пів години дебажиш, ламаєш голову, але врешті-решт знаходиш рішення і воно залізобетонно карбується в пам’яті.
А з AI часто є ризик просто отримати відповідь, погодитись і піти далі.
І я не впевнена, це розвиток чи навпаки щось, що може потроху розслабляти навички. Я боюсь, що якщо повністю довіритися генераціям, то через рік-два мої власні навички просто атрофуються. Що буде, якщо компанія завтра не зможе оплатити ліцензії, або ШІ сервіси кардинально змінять тарифи (про що вже ходять чутки)? Чи зможу я так само впевнено писати код з чистого листа на інтерв’ю перед техлідом?
Про дві дуже різні думки про майбутнє
Я читала і чула дві позиції, які трохи суперечать одна одній.
Перша:
AI змінює ринок, і тепер важливо не просто писати код, а розуміти систему, бізнес, продукт і ризики.
Друга:
AI дорогий, нестабільний, і без сильних базових навичок розробник просто не витягне, коли інструменти зміняться або стануть недоступні.
І проблема в тому, що обидві думки звучать логічно.
І як джун я чесно не відчуваю, що можу обрати правильну.
Пастка «інженерного мислення» для джуна
Зараз дуже модно говорити: «кодери не потрібні, потрібні інженери, які розуміють бізнес, метрики, гроші і як працює продукт».
І чесно, як для людини з приблизно роком досвіду, це інколи звучить трохи як пастка. Я розумію, що важливо розуміти, навіщо ти робиш фічу. Але якщо я буду добре розбиратися в бізнес метриках, а мій код при цьому падає на першому edge case або має проблеми з безпекою — мені здається, це не дуже допоможе продукту.
Мені зараз ближча думка, що базові технічні речі все ще критично важливі. Бо AI інколи помиляється в складних моментах: перформанс, нестандартні баги, безпека. І щоб помітити ці помилки, мені все одно потрібно добре розуміти, як це все працює під капотом — хоча б на базовому рівні: як працює .NET, база даних, асинхронність.
І є трохи страх, що якщо джуни зараз повністю підуть у «тільки продуктове мислення» і перестануть глибоко вчити технічні речі, можна втратити фундамент. І тоді буде складно робити надійний код без підказок AI.
Що мене реально трохи лякає?
Мене не лякає те, що я не вмію писати код — мені це якраз подобається, і я продовжую вчитись.
Мене більше лякає інше: відчуття, що можна непомітно втратити базу.
Що ти ніби «вмієш», але тільки поки поруч є AI або підказки.
І ще трохи лякає ринок.
Коли бачиш сотні відгуків на одну вакансію, починає здаватись, що ти просто одна з багатьох.
І навіть якщо ти нормальний кандидат — ти можеш просто загубитись серед шуму.
Що мене здивувало?
Мене здивувало, наскільки по різному люди бачать майбутнє розробки.
Хтось каже:
«головне — інженерне мислення і розуміння бізнесу»
Хтось каже:
«без сильних технічних навичок ти не виживеш, AI це не замінить»
І дивно те, що обидві сторони одночасно можуть бути праві.
І саме це трохи збиває.
Бо зрештою ти просто намагаєшся зрозуміти: а що мені зараз реально вчити?
І як з цим жити далі?
Я не можу сказати, що я вже знайшла баланс.
Зараз я намагаюсь робити для себе просту річ:
- використовувати AI як інструмент;
- але не дозволяти йому повністю забирати «складне мислення»;
- і час від часу робити речі вручну, навіть якщо це довше.
Можливо, через кілька років я подивлюсь на це інакше.
Але зараз мені здається, що найважливіше — не втратити здатність думати самій, навіть якщо AI поруч.
Питання до читачів
Мені реально цікаво:
- чи ви помічаєте, що AI змінює спосіб, як ви думаєте над задачами?
- де у вас межа між «це допомагає» і «я вже занадто залежу»?
- і як ви вважаєте: джуну важливіше зараз глибока технічна база чи ширше інженерне/продуктове мислення?
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівПросіть AI робити ревʼю вашого коду. Також рекомендую питати: «А як це можна було б зробити краще з точки зору реалій проєкту або загальновідомих практик?».
«Чому так?»
«Які є альтернативи?»
«Як це зробили б у production?»
«Які тут trade-offs?»
«Що буде bottleneck?»
«Як це вплине на support/readability/testing?»
etc.
Це дуже розширює кругозір, особливо якщо працюєте в якомусь legacy і вимушені самі писати гімнокод, бо такий стиль уже склався в проєкті)))
самое плохое для современных джунов, что им будет крайне сложно будет дорости до уровня нынешних синьоров. слишком велик соблазн все делегировать машине (которая кажется сильно «умнее» и эффективнее) и из-за этого остановиться в развитии.
А сьогоднішні сеньйори навіть паяльника в руках не тримали, щоб плату відремонтувати. Занадто велика спокуса делегувати це машинам у Китаї і просто замінити деталь на нову.
Але нічого, ніби не зупинилися в розвитку
плохая аналогия.
генерируемый код имеет огромное количество проблем и туда надо постоянно лазить, чтобы их исправлять. человек все еще активно нужен даже на «тактическом» уровне.
джун этих проблем не видит. оно сгенерировало то, что зачастую выше его уровня, вне понимания, то, что он руками написать не может. поэтому он радуется и бежит генерировать дальше. ну и чему он научится через год такой работы?
Рано чи пізно воно зламається і такий джун залізе в цикл «експеримент — результат — аналіз — новий експеримент». Просто він виглядатиме трохи інакше ніж раніше.
когда это навайбкоженое гавно ломается, там обычно уже синьоры не берутся чинить ни за какие деньги
Но ведь похожее уже было, когда люди писали на ассемблере, а потом перешли на Си или Python и перестали понимать, как на самом деле инструкции генерируются. Думаю, код Python и ассемблер по эффективности не ближе, чем Python и Python с ЛЛМ.
и снова аналогия. не надо неуместных аналогий.
И в чем же ее неуместность?
мы постоянно вынуждены лазить на этаж ниже для контроля.
чтобы в этом пропала необходимость, мы должны дождаться качественного скачка, когда инструкции на человеческом языке будут сразу корректно и идеально компилироваться в готовую программу (машинный код). это теоретическое будущее, о котором пока говорить рано. но вот когда оно наступит, тогда и можете доставать из кармана все свои аналогии.
Да, сейчас люди проверяют из-за недоверия, но так же и раньше те, кто знают ассемблер, могли проверять, насколько Си-код правильно компилируется. Кто начинал не с ассемблера, не проверяет и доверяет компилятору. Достаточно иметь тесты, которые будут проверять, что сгенерированный код работает. Вполне можно не лазить на уровень ниже.
проблема глубже.
существуют гарантии перевода си в машинный код, которые никогда не нарушаются в корректно работающем компиляторе. т.е. результат компиляции можно предсказать.
а LLM это вероятностный предсказатель следущего токена. никаких гарантий.
Рассмотрим задачу чуть иначе:C-программистам, и они пишут код. Компилятор гарантирует перевод C в машинный код, но у нас всё так же нет гарантии, что любой программист переведёт требования в машинный код одинаково.
Менеджер делегирует задачу
Давая задачи разным людям, менеджер получит разный машинный код.
Получается, что для него это будет уже не так критично.
То есть я думаю гаратии конечно хорошо но есть места где можно заменить их тестами и критерием приема задачи.
як я колись для себе з цим вирішив жити — просто писати якісь нотатки, концентруючи ціннісну ємність — тобто подати у вигляді «flight book» ті речі, які мені потім підкажуть/пояснять на підставі чого і яке рішення я прийняв, тренуючи лаконічність
ну і не перейматися, життя все більше людей перетворює на «контейнер», який є нескінчено адаптабельний в рамках лімітів нашої конструкції, тому ми постійно добираємо (learn) скіли (а також наприклад звички і залежності, в тому числі іноді фатальні) і з необхідності з цим управлятися ми втрачаємо (unlearn) все, що тільки можна, іноді свідомо (переформуючи і витісняючи небажані речі бажаними — наприклад кидаючи погане, змінюючи стиль розмови і контактів з іншими, викидаючи культурні пласти, серед яких нажаль народилися і з часом почали сприймати як небажані і тп)
тобто не паритися, а не натискаючи формувати стратегію і траекторію на свої дані раз кілька десятиліть, ну і їхати з нею..
Дякую!
Про flight book — це прямо в точку. Я якраз зараз теж так роблю. Веду нотатки про те, як працює .NET всередині(GC, CLR, асинхронність і інші базові механізми)
Помітила, що коли переписую це своїми словами, а не просто читаю документацію, воно реально краще складається в голові. Це ніби і є мій спосіб не дати базі розмитися
І думка про те, що unlearn це природній процес а не провал заспокоює. Мабуть, справді краще менше переживати через дрібниці і більше думати про довгий прогрес. Дякую за підтримку!
Звичайно, тепер над задачами думає ШІ. Але якщо точніше, то будь-який новий інструмент змінює спосіб мислення над задачею через призму цього інструменту.
Там само де і межа з компілятором. Він тільки допомагає створювати машинний код і лінкувати бібліотеки, чи я вже від нього залежу?
Колись щоб бути програмістом треба було знати архітектуру процесора і могти у разі потреби з транзисторів зібрати БК, АЛУ, ОЗП, регістри, тощо (і розуміти як саме працюють ці транзистори щоб правильно розміщати їх на платі). А потім розумітися на компіляторах, лексичних і семантичних парсерах, щоб під цей процесор написати компілятор для якогось C, Cobol чи Fortran. Потім розумітися в операційних системах, перериваннях процесора для забезпечення мультизадачності, розуміти як працюють планувальники задач і вручну в своїй програмі виділяти і звільняти сторінки памʼяті враховуючи ефективність ОС під яку цю програму пишуть...
Але з часом приходили нові і нові рівні абстракції — сучасний програміст рідше задумується про те як ОС планує задачі, як програма виділяє памʼять і коли звільняє, де там взагалі той компілятор (чи може це просто плагін для IDE), що таке архітектура процесора (може це просто налаштування в конфігу компілятора, а може воно вже і не треба нікому, бо код виконується на віртуальній машині)
ШІ — це іще 1 рівень абстракції в якомусь сенсі. Генератори коду завжди існували, просто тепер вони вийшли на новий рівень.
Дякую за такий розгорнутий коментар🙌
Про компілятори дуже влучне порівняння. Трохи заспокоює думка,що кожне покоління проходить через цей страх деградації через нові інструменти.
Але якщо компілятор працює за чіткими правилами, то ШІ може інколи просто галюцинувати. І отут моя головна тривога, щоб не стати тим розробником, який просто копіпастить те, чого сам не розуміє.
Виходить, що зараз головний скіл — це вміти вчасно вимкнути асистента і розібратися руками де та сама бага в логіці. Цікаво було почути такий фідбек, дякую!
Коли треба керувати невеликою командою підрядчиків на аутсорсі десь в Індії чи Індонезії, то вони, буває, можуть галюцинувати не гірше будь-якого ШІ. Але ж так було і до появи LLM і тим не менш Engineering Managers якось справлялись з цим і задачі виконувались і продукти створювались.
Це звичайно варіант. Як і варіант перевіряти в стовпчик результат обчислення калькулятора. Але, можливо, це не єдиний і не найбільш ефективний варіант. Я впевненний що для пошуку багів можна викорисовувати такі самі автоматизовані інструменти, бо як тільки система перевищує певний поріг складності, розбиратись руками може бути дуже довго і не факт що можливо.
Навички які дійсно мають значення так просто не втрачаються. Архітектура, безпека, перфоманс, дебаг... Як на мене, для підтримання форми достатньо робити ревью (залучаючи мозок) та ставити під питання кожен рядок в якому не впевнені на 100%
Ви і навичку написання текстів втратили, згенерували його ШІ
Так, використовувала ШІ для редагування тексту
Але ідея і досвід це мої власні спостереження)
> інженерне мислення і розуміння бізнесу
Это всё же разные вещи, и я бы их не объединял.
Важно стремиться понимать, как работает система. Работа с ИИ мало чем отличается от делегирования людям.
Понимание бизнеса в целом полезно, но я не понимаю о чем конкретно речь. Уточни пожалуйста что имеется ввиду.
> але не дозволяти йому повністю забирати «складне мислення»;
Можно и позволять но важно понимать что он делает и применимо ли это.
Если используешь ИИ, то, скорее всего, на ревью кода будет уходить больше времени.
Дякую за фідбек! Згодна, я трохи змішала це в одну купу. Для мене як для джуна це поки що виглядає як «все, що не просто написання коду», але ви праві, це різні скіли.
Під бізнесом я мала на увазі розуміння контексту задачі(навіщо ми це робимо і яку проблему користувача вирішуєм), а під інженерним мисленням якраз розуміння системи і того, як рішення впливають на все інше
І так, щодо рев’ю повністю згодна. Помічаю, що на перевірку згенерованого коду(щоб переконатися, що він справді придатний і не містить сюрпризів) іноді витрачаєш більше зусиль, ніж на написання з нуля. Мабуть, це і є той момент, де AI вже не економить час, а додає роботи.
Я це все більше як рефлексію писала, тому формулювання місцями вийшли трохи змішані🙂
> Під бізнесом я мала на увазі розуміння контексту задачі
Мне кажется, большее значение имеет технический контекст. Ведь для остального отсутствуют необходимые метрики, например, сколько прибыли принесет эта функция и как быстро заказчики ее ждут. Я рекомендую рассматривать задачи с инженерной точки зрения. Например, если важно быстро выйти на рынок и клиенты уже хотят фичу, следует выбирать те технологии, которые позволят сократить время.
Если клиенты в разных странах то важно делать сервис доступным в разных регионах с небольшим латенси.
Понимание общих аспектов бизнеса, таких как его структура, модель Business Model Canvas, Cash Flow и юридические тонкости, может быть весьма полезным для создания конкурентоспособного продукта, однако для IT-специалиста эти знания могут быть менее применимы в повседневной работе.
На мой взгляд основная ценность не выполянть работу всесто маркетологов а понимать импакт на проект при обсуждении с ними.
И ИИ может с этим помогать. Ну нужно понимать что спрашивать.
Гарна рефлексія! Мені подобається твій хід думок, Юліє.
А ще більше я отримую задоволення від того, що маємо таких студентів на ОП «Інтернет речей» спеціальності F2 Інженерія програмного забезпечення в НУВГП (це була хвилинка реклами :).
На мою думку, обов’язково потрібні фундаментальні знання, критичне мислення та вміння навчатися, адже так можна буде бодай спробувати перевірити, що понаписував той АІ...
Дякую, дуже приємно)
Я думаю, якщо ти уважно review код LLM то ти ніколи не втратиш навички, а навпаки здобудеш значне покращення. Чому? Бо сучасні LLM помиляються, а постійно перевіряти код, у якому десь помилка — це спосіб навчання. Отак — ти хотів працювати, а будеш ще й постійно навчатися.
Згодна, якщо підходити до цього саме так, то це дійсно крутий тренажер для мізків. Дякую за думку!
Це працює, якщо помиляєтеся ви, а не llm
Ага
Спочатку ще потрібно зрозуміти що є десь помилка, потім вже яка саме і чому.
Можливо якісь навички і здобудеш постійно перевіряючи згенерований код, але це будуть інші навички ніж написання. Недаремно навіть агентів розділяють на тих які пишуть код і тих які перевіряють.
Погоджуюсь з авторкою, що якісь навички втрачаються з часом. Сам також відчуваю, що чим більше покладаюсь на ШІ, тим більше мозок відразу хоче запитати ШІ, а не думати самостійно. Щось схоже з фізичним навантаженням, можна користуватися транспортом постійно, але все-таки люди дійшли до того, що і самостійно корисно щось робити, щоб м’язи не атрофувалися.
Думаю, що джуну більше важливіше глибока технічна база. Щоб було міцне Т в майбутньому, а не тільки шляпка 🥲 (en.wikipedia.org/wiki/T-shaped_skills)
Плюсую
«Зараз я намагаюсь робити для себе просту річ:
— використовувати AI як інструмент;
— але не дозволяти йому повністю забирати „складне мислення“;
— і час від часу робити речі вручну, навіть якщо це довше.»
Так, дуже відгукується. Я теж помітила, що інколи занадто швидко тягнусь до AI замість того, щоб спочатку самій розібратись. Тому зараз свідомо намагаюсь це балансувати
І все ж — спочатку спитайте у LLM моделі, а вже потім вирішуйте чи немає помилки у відповіді.
Ваші можливості згадування, як там що пишеться, вже не так важливі як раніше, бо всі знання людства вже завантажені у розподілені дата-центри.
P.S.
Настав час екстрагування онтологій. З метою подальшого їх використання у більш продвинутих моделях.