Після кодгенерації: навички, які все ще мають значення для інженерів

Використовуйте це як оновлену версію ідей з статті „Штучний інтелект може писати ваш код. То що вам робити зараз?“ для співробітників-операторів: чіткі етапи, впорядковані блоки коду та примітки з відновлення, які залишаються після передачі завдань. Огляд працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний запис, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не погоджуйтесь на мовчазне часткове виконання завдань.

Код стає дешевшим

Оскільки код стає дешевшим, необхідно визначити вхідні дані, виконавця кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат на ранньому етапі запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних середовищ. Коли це дозволяють бюджетні обмеження, додавайте тест на базову сумісність, який перевіряє критичний шлях у процесі CI за допомогою фікстур, а не реальних платних API.

Add JWT authentication.
Create login and refresh-token APIs.
Add PostgreSQL persistence.
Write integration tests.
Run the test suite.
Fix failures.

Anthropic показує нам, куди це приведе

Оскільки Anthropic показує нам, куди рухатися, необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь граф. Коли дозволяє бюджет, слід додавати тест на працездатність, який перевіряє критичний шлях у процесі CI за допомогою фікстур, а не реальних платних API.

Is the architecture correct?

Is authentication secure?What happens under 10,000 requests?Can this transaction fail halfway?Will this leak memory?What happens when Redis is unavailable?What happens when the database is slow?Did the AI introduce a race condition?

А потім сталося щось набагато більше

Перш ніж змінювати код, необхідно визначити вхідні дані, власника кроку та критерії завершення. Оператори повинні мати можливість знову виконати крок з відомої точки контролю, не намагаючись вгадати прихований стан. Необхідно документувати як шлях успішного виконання, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Коли дозволяють бюджетні обмеження, слід додати тест на базову функціональність, який перевіряє критичний шлях у середовищі CI за допомогою фікстур, а не реальних платних API. Вважайте цей етап контрактом між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового завершення роботи.

Найбільша помилка, яку можуть припуститися розробники

Під час роботи над темою «Найбільша помилка, яку можуть припуститися розробники», спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успішне виконання та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність під час подальших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із результатами функціоналу. Відображення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-середовища до спільних. Напишіть короткий посібник: як змінювати ключі, як спорожнювати чергу та як скасовувати останнє введення даних.

@GetMapping("/users")
public List<User> getUsers() {
    return userRepository.findAll();
}

То що ж повинні навчитися розробники зараз?

Під час роботи над питанням «Що ж мають навчитися розробники зараз?» спочатку запишіть умови використання: необхідні вхідні дані, сигнал про успішне виконання та що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Напишіть короткий посібник: як змінювати ключі, як спорожнювати чергу та як скасовувати останнє завантаження даних.

Write this.
Refactor this.
Explain this.
Test this.
Fix this.
Convert this.

Don't build it this way.
Here's why.
Here's the simpler architecture.
Here's the failure mode you missed.
Here's what we should measure in production.

Штучний інтелект не скасовує потребу в мисленні

Навіть коли використовуєте ШІ, це не скасовує потреби у роздумах — спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успіх та що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Документуйте як шлях успішної роботи, так і шлях відновлення. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації. Напишіть короткий посібник: як змінювати ключі, як спорожнювати чергу, як скасовувати останню операцію обробки даних. Навіть коли використовуєте ШІ, це не скасовує потреби у роздумах — спочатку запишіть умови використання: необхідні дані вхіду, сигнал про успіх та що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як договір між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безповідомного часткового виконання завдань.

Prompt → Copy → Commit → Next task

Новий інженер програмного забезпечення

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

Якби ви були розробником сьогодні

Якщо ви розробник, сьогодні найкраще працювати, сприймаючи проект як вимірювану структуру. Запишіть один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, щоб оператори могли їх перевіряти, не читаючи весь код. Визначте версії залежностей та зафіксуйте хеш образу, який використовувався під час демонстрації. Відтворюваність краща за „колективні знання“.

Чек-лист операцій

Під час роботи за чек-листом спочатку сформулюйте контракт: необхідні вхідні дані, сигнал про успіх та наслідки часткового збою. Цей чек-лист допомагає зберігати чесність у подальших змінах коду.

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

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

Документуйте як шлях успішної роботи, так і шлях відновлення одночасно. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

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

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

Перед підвищенням версії стеку заморозьте версії, зафіксуйте ідеальний запис дій для критичного шляху та підтвердьте кроки скасування. У спільних середовищах необхідні обмеження на частоту запитів, перевірки прив’язки та чіткий власник для обміну секретами. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.

Примітка до пакету 34004c5d2824: не включайте ключі постачальників у репозиторій, встановіть ліміт токенів на сеанс та зберігайте транскрипції поруч із фіксами для оцінки, щоб подальша заміна моделей залишалася порівнянною.