Наскільки AI реально пришвидшив роботу інженерів? Опитування

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

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

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

Цікавить саме досвід Software, AQA, Data та DevOps Engineers будь-якого рівня в Україні й за кордоном.

Ділюсь посиланням на анкету: aiadopter.dev

Публічні результати чекайте вже в листопаді.

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному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

В тыщу раз! Правда за год потратили токенов на 22 ляма. Но зато x1000. Кода, багов и фиксов :)

эффективные менеджеры поняли, что таски можно закрывать сгенерированным гавном и кодспагетти, который проходит поверхностный код ревью, на то что это месиво дополнительно пожирает ресурсы всем плевать. У девопсов тоже самое — жирные баш скрипты и хелм чарты, напоминающие простыни машинного кода. Код покрывается километрами юнит тестов, которые даже включает абсолютно невалидные бизнес-кейсы и игнорирует принцип defence programming — типа все данные провалидировали, джсон валидный, но все равно внутри километры проверок и раздутых тестов

AI реально пришвидшив роботу інженерів?

AI дозволив мені досить швидко свічнутись в паралельний трек по роботі, який я до цього знав лише теоретично ( ML / DS ) і знайти ще одну фултайм роботу і це все вивозити.

Кожен день молюсь і дякую за АІ.

Скільки годин на тиждень AI вам економить?

браво, в принципе этого вопроса достаточно чтобы вернуть ответ как результат теста

Процес написання коду — однозначно пришвидшив. Загалом процес розробки — важко сказати. Просто тепер змінилися «пропорції коктейлю», з якого складається інженерна робота. Якщо раніше це було: 80% часу пишемо код, 10% рев’ю і девтести і 10% мітинги, то зараз — 10% генеруємо код, 10% мітинги і 80% — перевіряємо, що все написано ок і працює ок, перш ніж віддати на рев’ю та тестування.

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

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

80% — перевіряємо, що все написано

АІ тобі може згенерувати, а потім пояснити, тобі розбір генерованого коду це не те ж саме, що копання в самописному коді якогось джуно-мідла.
АІ відразу пише чистенький, самодокументований код, із гарними іменами змінних і всіма Best Practices від Дядька Боба, а у випадку чого, сам же АІ цей код людською мовою і пояснить і приклади наведе і коментарями покриє.
Ніби читаєш щось середнє між науково-фантастичною книжкою і документацією.

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

і явно намічається наступна зайва ланка під оптимізацію у ШІ конвеєрі програмування — читач

Ланка яка виконує роль читача, також діє як оркестратор і часто продакт-менеджер.

Хоча я погоджуся, що читання кожної окремої стрічки коду буде поступово відходити і ми будемо оперувати поняттями «очікуваного результату» або щось типу того.

Але інженерна робота від того не зникне, вона просто буде видозмінюватись і переміщуватись на вищі рівні абстракції.

і з кожним переміщенням бульбашка програмування буде потрохи здуватися, нп навіть як один продакт-менеджер замість групи кодерів

Мені здається, в подібних розмовах присутня велика степінь маніпуляції та не розуміння питання.

Що таке бульбашка програмування?
Чи була бульбашка програмування на асемблері 40-50 років тому і чи здулася вона? Може й так, якщо говорити такими термінами, але потім надулась і здулась бульбашка програмування на С. Потім на джаві, С++ (дискусійно, нове переродження в АІ та мілтеку), С# і подібному.

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

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

Поточна ШІ-перебудова не перша і не остання.
А це ще навіть не AGI, не фізична роботизація (вже на підході) і не кіборгизація людини по вживленню нейроінтерфейсів а-ля нейролінк та інтеграція людського та синтетичного мізків. У нас ще буде дуже багато всього.

Що таке бульбашка програмування?

масовий наплив народу в айті (точніше у програмування) за заробітками, з будь-яким бекграундом та будь-яким профілем освіти чи без оного — чим не gold rush програмування?

чи була бульбашка програмування на асемблері 40-50 років? на С

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

У нас ще буде дуже багато всього

завжди щось буде, чи багато, чи небагато, але буде