Кодування за допомогою ІІ-асистентів стало звичною практикою для розробників, проте визначення кінцевої мети та суті самого коду залишається фундаментальним завданням людини. Запит до ІІ несе у собі вибір мети, релевантної інформації та прийнятних результатів. Концепція обчислювального мислення (computational thinking) робить ці вибори явними, пов'язуючи їх із поведінкою програми.
У дискусії про ІІ та абстракції Мартін Фаулер та Унмеш Джоші розмежовують пошук нових корисних абстракцій та застосування вже існуючих. Обидві діяльності включають дизайнерські рішення, які виявляються у підсумковій реалізації.
Обговорення The Pulse від AlphaWire із Конрадом Вольфрамом описує обчислювальне мислення як чотириетапний процес: визначення питання, подання проблеми, обчислення та інтерпретація результату. Вольфрам підкреслює, що саме обчислення є лише частиною цієї ширшої діяльності. Стосовно розробки ПЗ це розмежування поміщає згенерований код між рішеннями про постановку задачі та оцінкою отриманого результату.
визначення проблеми
Вимоги до програмного забезпечення формулюють бажаний результат, а обчислювальна проблема надає цьому наміру необхідну точність до роботи. На цьому етапі визначаються мета, сфера застосування та обмеження. Формулювання питання встановлює, яка інформація є релевантною і які аспекти повинні зберігатися при перекладі проблеми в код.
Опис бажаної поведінки також вимагає критеріїв оцінки відповіді. Успішне виконання підтверджує, що інструкції були виконані за заданих умов, але гарантує правильність вибору вихідного питання чи відповіді нього. Оцінка програми, отже, включає аналіз як її поведінки, і використаних з метою оцінки очікувань.
Визначення проблеми може змінюватися у процесі розробки. Робота над реалізацією виявляє неочевидні неоднозначності. Уточнення питання є частиною процесу розробки, поряд із написанням та редагуванням коду. Точність не вимагає попереднього дозволу всіх деталей реалізації, але вимагає, щоб важливі терміни мали загальне значення, межі були чіткими, а передбачуваний результат вимірним.
Перетворення наміру на модель
Подання пов'язує заявлене питання з обчисленням. Воно ідентифікує об'єкти, з якими взаємодіє програма, пов'язану з ними інформацію та відносини, які вона має підтримувати. Явне найменування цих концепцій формує словник коду, який можна обговорювати незалежно від конкретної мови програмування.
Генерація коду є частиною створення цього уявлення. Код висловлює вибори щодо даних та операцій, а його виконання ці операції здійснює. Структура програми і поведінка, що спостерігається, роблять модель доступною для вивчення, обговорення і перегляду в процесі розробки.
Унмеш Джоші використовує ІІ-асистента для переписування одного і того ж коду різними мовами, включаючи Go та C++, щоб дослідити альтернативи реалізації. Ці «мовні проекції» дозволяють йому вивчати різні способи вираження рішення, навіть незнайомими йому мовами. Згенерований код стає матеріалом у розвиток дизайну.
Джош також описує, як різні підходи до програмування підтримують його роботу. Для обробки даних він вважає за корисне мислити ланцюжками перетворень над потоками даних. Для інтерактивних додатків він мислить у термінах об'єктів, які поєднують збережену інформацію з операціями, що її використовують.
Для навчання ці вибори відокремлюють розуміння правил мови від розуміння дизайну. Імена, дані та операції виражають погляд на проблему. Пояснення їх взаємозв'язків показує, як реалізація відповідає своєї мети, навіть якщо її синтаксис змінюється.
Обчислювальне мислення із ітераційним переглядом. Джерело зображення: Створено за допомогою ІІ
Інтерпретація результату
Обчислення робить висновок з обраного уявлення. Інтерпретація пов'язує цей висновок із метою, яка стала початком роботи. У програмному забезпеченні результат включає поведінку програми разом з доказами, використовуваними для її оцінки.
Інтерпретація виводу також включає визнання обсягу моделі. Результат стосується інформації та відносин, які були представлені. Питання поза цим обсягом вимагають іншого подання чи переглянутого питання; вони можуть бути вирішені простим повторним виконанням тієї ж обчислювальної процедури.
Тести висловлюють деякі очікування щодо поведінки програми. Вони надають докази щодо цієї поведінки в умовах, які вони охоплюють. Вони не встановлюють автоматично, що вибрані очікування охоплюють все, що програма має виконати. Код-рев'ю досліджує вибори реалізації; тести перевіряють задану поведінку. Порівняння цих перевірок із початковою метою — це судження про програмне забезпечення в цілому.
Процес Вольфраму дозволяє повернутися до питання чи подання. Результат, який викликає перегляд, є частиною процесу, а чи не його кінцем. Перегляд моделі змінює те, що обчислюється, тоді як перегляд питання змінює те, що обчислення має відповісти. Робота об'єднує ці вибори, реалізацію та інтерпретацію через повторне дослідження.
Вибір того, що збудувати
Огляд технічних працівників METR, опублікований у травні 2026 року, проводить аналогічну різницю між швидкістю виконання завдання та цінністю проведеної роботи. У ньому взяли участь 349 технічних фахівців, включаючи 87 інженерів-програмістів, опитаних з лютого до квітня 2026 року. Учасники представляли випадкову вибірку, а не репрезентативний перетин технічних працівників. Їхні оцінки описують їх сприйняття допомоги ІІ; це не контрольовані виміри приросту продуктивності.
Дослідники поділяють час, витрачений завдання, від корисності отриманої роботи. Вони також розглядають зміни у складі завдань, якими займаються люди. Вимірювання швидкості залежить від того, які саме види діяльності враховуються; вклад залежить від цього, яких результатів ці види діяльності досягають. Таким чином, швидка реалізація передбачає подальше судження про те, чи просуває обране завдання ціль програмного забезпечення.
Люди, відповідальні за програмне забезпечення, вирішують, що робить результат корисним. Згенерований код надає їм реалізацію до роботи; обчислювальне мислення поєднує його поведінку з метою, якою це кодування має служити.