Якщо ШІ туди ще не вліз, то значить треба вивчати. Можливо навіть в цій інженерії і майбутнє українських інженерів.

Ну бути ревьювером згенерованого кода тяжче. Вже передбачаю нові вакансії “Junior AI generated-code reviewer”, “Team Lead Fullstack ChatGpt (5y+), Gemini (3y+), DeepSeek (1y+)”

Просто. Умови сіньора та і будь якого рівня — розвиток скілів.

В оцінці потрібно ще врахувати такі фактори:
— наростання кодової бази і її вплив (архітектурний вплив)
— конфлікт змін в кодовій базі (архітектурний вплив)
— рефакторінг по-крупному (архітектурний вплив)
— білд-проекта (більше тестів — більше очикування)
— інтеграційне тестування
— до-задачі (близько 20%) що з"являться пізніше, але без яких не зробити нічого
— навчання як когось, так і себе (близько 5%)
— дуже великий вплив є від інтеграції з іншими сервісами, особливо з такими, про які навіть не чув
— кількість сторонніх залежностей
— популярність фреймворка в основі, його гнучкість, (щоб не шукати по 2 дня, як забрати той зайвий елемент, щоб ще все працювало і щоб не патчити в вендорах)
— на сільки стабільний код (тут взагалі може бути похибка в психіці, або вам прийде задача на маленькі правки, від яких на вас звалять ще пів нерабочої системи, яку замовник сам намагався поправити по FTP)

Ще би я відділив задача на інтелектальні, типові, ризикові і рутинні.
Інтелектальні — це ті, що починаються з *пошукайте самі* ... як розпізнати на фото всі обєкти, які в русі, парсери, криптографія, зберігання інформації, архітектура проекта, технологічні підходи. Тому такі задачі в оцінці будуть виглядати коротко, але з підозріло великим числом годин, через що часто на них концентрують увагу замовники і багато питають, але через брак часу на дослідження вони виглядають як чорний ящик.
Типові — формочки, таблички, crud (80% задач такі, їх багато і їх легко розписувати в оцінці, але через них нивелюється оцінка інтелектуальних задач)
Ризикові — це інтеграції з якимось сервісом, чи надія на бібілотеку, яка дуже популярна, міграція данних в нову структуру.
Рутинні — це наповнення данними.

В залежності від проекта тут можна просто множити на якийсь відсоток, щоб було швидко (якщо легасі проект — можна сміливо просто збільшувати в 2-3 рази, бо це полюбому ні специфікації не знайдеш, або ще попадеш на апгрейд всіх залежностей з заміною на альтернативи).

Ще треба розуміти, що замовник хоче одне, пише друге, оцінку роблять для третього, домовляються за четверте, получається п"яте, тому сказати, що на проекта А ми витратитили N — годин, і на такий самий проект B ми витратимо теж N годин — буде не точно =)

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