За минулий рік я все повторювані задачі передавав ШІ: CRUD, модульне тестування, рефакторинг, початкову документацію. Зараз час, витрачений на ручне написання коду, скоротився майже на 40%, але час, витрачений на “чітке розуміння вимог” і “знаходження недоліків у вихідних даних ШІ”, подвоївся.


ШІ швидко видає код, але крайні випадки часто провалюються, а контекст бізнесу часто зникає. У такій ситуації ти не приймаєш рішення — ніхто не покриє твою відповідальність.
Можливо, протилежна думка: програмна інженерія не вмирає, вона розділяється на два полюси. Базові робочі місця з рукопашною працею зменшаться, але системне проектування, складна розбивка та міждисциплінарна інтеграція стануть ще дорожчими. Чи стане різниця у вмінні використовувати ШІ такою ж, як раніше — у вмінні писати код?
Але справжня різниця не у вмінні створювати складні запити, а у тому, чи розумієш ти бізнес, чи можеш оцінити компроміси, і чи наважишся перервати ШІ, коли воно брешет.
Ступінь знань у галузі CS не застаріє, навпаки — потрібна ще міцніша база. ШІ — це підсилювач, а не машина бажань. Люди без системного мислення, використовуючи ШІ, лише швидше накопичують технічний борг.
Майбутня команда може складатися з одного досвідченого фахівця та купи агентів. Але цей один має бути одночасно продуктовим, архітектурним і контролером якості. Вхідний бар’єр лише зросте.
Скільки вашої роботи змінилося через ШІ? Стало легше, чи просто зменшило кількість низькоякісних багів з 10 до 20? Обговоримо.
PROMPT3,91%
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
  • Нагородити
  • Прокоментувати
  • Репост
  • Поділіться
Прокоментувати
Додати коментар
Додати коментар
Немає коментарів
  • Закріплено