Я витрачаю менше часу на написання коду, ніж будь-коли раніше
Я створюю більше програмного забезпечення, ніж будь-коли раніше.
ШІ не зменшив мою інженерну роботу. Він змінив те, як виглядає інженерія.
П'ять років тому я вимірював продуктивність кількістю рядків коду або об'єднаними pull requests. Я думав, що написання більшої кількості коду означає створення більшої цінності. Я помилявся. Це було просто найпростіше, що можна було виміряти.
Сьогодні мій робочий день виглядає інакше. Я витрачаю менше часу на набивання коду. Я витрачаю більше часу на:
• Перегляд коду, згенерованого ШІ • Проєктування системних архітектур • Визначення бізнес-правил • Моделювання даних • Валідацію припущень • Створення пайплайнів оцінювання
Вузьким місцем у розробці програмного забезпечення ніколи не була швидкість друку. Вузьким місцем є розуміння.
Ви повинні розуміти користувачів, бізнес, системи та компроміси. Саме ці рішення визначають, чи виживе програмне забезпечення.
Код — це результат. Інженерія — це процес прийняття рішень.
ШІ чудово справляється з реалізацією. Але він не може відповісти на такі запитання:
• Чи має цей сервіс володіти цими даними? • Де має відбуватися валідація? • Як нам відновлюватися після збоїв? • Як нам проводити аудит автоматизованих рішень?
ШІ усуває перешкоди, а не інженерів. Він прибирає рутинну роботу, таку як написання серіалізаторів або міграцій. Це дозволяє вам вирішувати проблеми, а не перекладати рішення на синтаксис.
Нещодавно я розробив Transaction Intelligence System. Я думав, що найскладнішою частиною буде модель ШІ. Я помилявся.
Складна робота полягала у:
• Проєктуванні структур даних • Створенні синтетичних наборів даних • Визначенні бізнес-таксономій • Побудові пайплайнів розв'язання сутностей (entity resolution)
ШІ прискорив написання коду, але він не усунув необхідність розуміти бізнес.
Генерація програмного забезпечення тепер коштує дешево. Розуміння складності все ще коштує дорого.
Виклик полягає в інтерпретації того, що не записано. Ви повинні знаходити приховані бізнес-правила, регуляторні обмеження та потреби безпеки. Вони існують у розмовах та досвіді, а не в документації. Жодна модель не може вивести знання, які не представлені.
ШІ винагороджує хорошу архітектуру. Він не замінює її.
Якщо ваша система має чіткі зони відповідальності та модульні сервіси, ШІ стає продуктивним. Якщо ваші основи слабкі, ШІ просто швидше генерує складність.
Я не припинив займатися інженерією. Я почав інженерію на вищому рівні.
Менше часу на набивання коду. Більше часу на проєктування. Менше часу на налагодження синтаксису. Більше часу на валідацію припущень.
Саме туди рухається професія.
Source: https://dev.to/uigerhana/i-spend-less-time-writing-code-than-ever-before-395b
Optional learning community: https://t.me/GyaanSetuAi