Almost-Right Tax: прихований податок на майже-правильну роботу AI

О 23:14 розробник Дмитро копіює функцію в редактор. GitHub Copilot видав її за вісім секунд — чисто, з коментарями, у стилі решти кодової бази. Функція дедублює записи у DataFrame: df.drop_duplicates(keep='last_modified'). Виглядає правильно. Поводиться правильно — ані червоного підкреслення, ані warning’у. Дмитро вставляє її в модуль і запускає тести. Зелено. Він тягнеться до кружки з холодним чаєм, ставить галочку в тікеті й відкриває наступний.

О 00:31 той самий Дмитро вдивляється в stack trace продакшну. Курсор блимає в кінці червоного рядка, чай давно вистиг. TypeError: drop_duplicates() got an unexpected keyword argument 'last_modified'. Параметра keep='last_modified' в Pandas не існує. Ніколи не існувало. Copilot вигадав його з бездоганною впевненістю: синтаксис коректний, логіка зрозуміла, назва інтуїтивна — і абсолютно неробоча. Тридцять сім хвилин пізніше — після документації, Stack Overflow і трьох перечитувань рядок за рядком — виправлення займає чотири символи. keep='first'. Кінець.

Рахунок виглядає так: 8 секунд кредиту, 77 хвилин боргу. Але в ранковому стендапі цей борг ніде не зʼявиться. Зʼявиться інше: «Команда використовує AI, продуктивність зросла».

Джин Амдал у 1967 році довів те, що суперкомпʼютерники знали інтуїтивно: якщо паралелізувати 90% задачі нескінченно, а 10% лишити послідовними, максимальне теоретичне прискорення системи — рівно 10×, і ані краплі більше. Система рухається зі швидкістю своєї найповільнішої ланки, скільки б ядер ти не доклав до решти. Це закон, а не рекомендація. AI-кодинг щойно перевідкрив його на власній шкурі: генерація масштабується нескінченно, верифікація — ні. Генерація — це 90, що паралелізується. Верифікація — це 10, що лишилось послідовним і людським.

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

---

Дзеркало, яке бреше з упевненістю синьйора

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

Саме це трапилось у рандомізованому контрольованому дослідженні METR у 2025 році. Шістнадцять досвідчених розробників, 246 реальних задач на великих open-source репозиторіях, які вони знали роками. Перед початком вони ставили прогноз: «AI мене прискорить на 24%». Після того, як власноруч пройшли через сповільнення, оцінка зсунулась мало: «AI мене прискорив на 20%». Реальний вимір секундоміра, який не має почуттів: AI їх сповільнив на 19%.

Це не марґінальна похибка. Це системна брехня дзеркала — і найстрашніше тут не число, а те, що розробники пережили сповільнення на власній шкірі й все одно вийшли з відчуттям прискорення. Тіло переконане, що летіло; хронометр каже, що плелося. Між цими двома показниками — розрив у 39 процентних пунктів, і весь цей розрив сплачується наосліп.

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

Тут є друга, тихіша аномалія, яку легко проґавити. Stack Overflow Developer Survey 2025 фіксує: близько 46% розробників активно не довіряють точності AI-інструментів, і лише 3% довіряють їм «повністю». Тобто майже половина галузі возить у кожному PR пасажира, якому не довіряє кермо — і все одно везе. Це не недовіра, яка зупиняє; це недовіра, яка змушує перевіряти кожен поворот заднім числом. А кожна така перевірка — рядок у невидимому рахунку.

Парадокс відчуття — перша ознака того, що ми міряємо не те. Але він лише передмова. Справжня проблема живе на рівень нижче: у тому, куди саме переїхало вузьке місце.

---

Куди переїхало вузьке місце

Ось сцена, яку знає кожен сеньор у команді, що перейшла на Copilot.

П’ятниця, 16:45. Андрій відкриває чергу pull requests. Дванадцять запитів. Три місяці тому, до впровадження AI-інструментів, у п’ятницю ввечері було чотири-пʼять, іноді шість. Команда продуктивна: коміти прискорились, тікети закриваються частіше, менеджер на ревʼю спринту показував красивий графік із крутою висхідною лінією. Але Андрій дивиться на чергу, рахує запити очима по два — і вже знає, що піде додому о девʼятій, а не о шостій, як обіцяв удома.

Бо є нюанс, якого не видно з графіка менеджера: AI-генерований код не можна читати так, як код від колеги. Колезі довіряєш контексту, намірам, знанню кодової бази — пробігаєш по diff, бачиш підпис автора, якому віриш, і мержиш. Модель не має ні контексту, ні намірів, ні відповідальності. Тому кожен AI-PR вимагає того, що в галузі називають white-box review — читати кожен рядок, перевіряти кожен виклик, питати «а звідки модель знає, що цей параметр існує», а не пробігати по diff і довіряти підпису. Автором є модель. Автор не несе відповідальності. Андрій несе.

Faros AI зібрав телеметрію понад 10 000 розробників у 1 255 командах і зафіксував, що саме відбулось: +98% змержених pull requests і +21% закритих задач. Звучить як перемога. Але разом із тим — +91% часу на рев’ю pull requests і жодного значущого приросту на рівні організації. Формулювання звіту безжальне: «no significant correlation between AI adoption and improvements at the company level». Не «менший приріст», а «відсутній». Команда виробляє вдвічі більше — компанія не рухається швидше ні на крок. Командний виграш згорів у bottleneck downstream.

Класична теорія обмежень Голдратта описує саме це: конвеєр, що прискорився перед пробкою, не прискорив систему — він збільшив чергу перед пробкою. Можна виробляти втричі більше деталей у цеху, але якщо склад відвантажує з тією самою швидкістю — деталі просто накопичуються, займають прохід, і логіст починає спотикатися об ящики. AI-кодинг зробив те саме: підняв throughput генерації, не торкнувшись пропускної здатності верифікації. Галузеві аналітики Trace3 описують цей розрив прямою фразою: код виїжджає в продакшн на рекордній швидкості, тоді як внутрішні процеси й решта SDLC лишились позаду в пилюці.

Андрій іде додому о 20:23. П’ятниця не відбулась.

---

Скільки коштує «майже»

Повернімося до Дмитра о 23:14. Розкладімо чек по копійках.

Copilot генерує функцію за 8 секунд. Це реальна вартість: 8 секунд машинного часу, хмарних обчислень і підписки. Далі починається інша бухгалтерія — та, яку ніхто не веде.

Дмитро кидає функцію в редактор і не перечитує її уважно — виглядає правильно, синтаксис знайомий, назва параметра інтуїтивна. Зелені тести. Це перший непомічений платіж: довіра, видана авансом тому, хто її не заслужив. Потім — продакшн, stack trace, діагностика. Дмитро заходить у документацію Pandas, потім на Stack Overflow, потім перечитує функцію рядок за рядком, потім сумнівається в собі, бо параметр виглядає настільки розумним, що мав би існувати. 37 хвилин. Виправлення — 'first' замість 'last_modified' — це 4 символи й 10 секунд друку. Решта 36 хвилин і 50 секунд — це і є податок на майже-правильне.

Визначення, яке варто запам’ятати: податок на майже-правильне — це час і увага, які доплачуєш за те, щоб відрізнити код, який виглядає правильним, від коду, який є правильним.

Дані з реальних досліджень роблять цей рахунок конкретним. За повідомленнями галузевої преси, рев’ю однієї AI-пропозиції коштує сеньйору помітно більше уваги, ніж читання людського коду — кратно більше за одиницю. AI-код дорожчий рев’юеру — і ця ціна сплачується не там, де ведеться облік.

Помножте це на тиждень. За опитуванням Zapier/Centiment (2026, 1100 enterprise-користувачів AI), працівники витрачають у середньому 4,5 години на тиждень на виправлення помилок AI — більше половини робочого дня, списані з графи, якої немає в жодному дашборді. Не на написання, не на дизайн, не на думання над архітектурою. На перечитування того, що машина видала за секунди, з питанням «а це взагалі правда?».

Ось у чому архітектурна брехня: генерація і верифікація живуть у різних кошиках бюджету. Генерацію оптимізують, вимірюють, хваляться нею на стендапах. Верифікація — «просто частина роботи», невидима рядком у звіті. Це класична інверсія 90/10: AI робить 90% видимої роботи за 10% часу, а решта 10% — верифікація — спокійно з’їдає 90% реальних годин, тільки в кошику, який ніхто не зважує. Коли AI здешевлює генерацію і подорожчує верифікацію, він переносить вагу між кошиками. А оскільки один кошик видимий, а другий ні — здається, що все стало дешевше.

AI не економить твій час — він переносить рахунок у графу, яку ніхто не вимірює.

Це і є майже-правильне у всій красі. Не «погано», не «зламано» — просто майже. Майже-правильне проходить перший погляд. Майже-правильне проходить diff. Майже-правильне виглядає як прискорення — рівно доти, доки не зʼявляється stack trace.

---

Чому unit-тести проспали

Зелена смуга — це найдорожча брехня в сучасній розробці.

Ось сцена, яку архітектор бачив принаймні раз: усі тести зелені. Покриття 87%. CI пройшов. Код у main. В продакшні — тихий, непомітний баг, що рахує не те: неправильно обчислює знижку для крайового кейсу, некоректно обробляє timezone на межі переходу на літній час, хибно перевіряє права доступу для користувача без ролі. Тести не мали шансів: вони перевіряли те, що автор вважав граничними умовами, а не те, чим вони є насправді. AI-автор не знає кодової бази. AI-автор не знає, які кейси важливі. AI-автор упевнено пише тести до власного коду — і тести підтверджують код, а не поведінку. Машина перевіряє саму себе й, звісно, схвалює.

Дані роблять цю проблему конкретною. Дослідження 2023 року на датасеті ROBUSTAPI — 1208 реальних Java-задач, де код викликає сторонні API — зафіксувало: 62% коду, згенерованого GPT-4, містить API misuse. Не теоретичний — конкретний: невірний порядок викликів, проігнорований return-код, неправильно зрозуміла семантика методу. Дослідження Science China Information Sciences (Springer, 2025) зафіксувало, що найпоширеніша підкатегорія дефектів кодогенерації — пропущені перевірки крайових умов (53,2%): саме той клас помилок, що тихо проходить тести. А окрема категорія — помилки у сторонніх бібліотеках: Pandas, NumPy, Django, SQL-драйвери. Функції, яких не існує. Параметри, яких немає. Поведінка, яку модель «вивела» з назви, а не з документації — рівно як keep='last_modified' у Дмитра, тільки помножене на півсотні бібліотек, кожна зі своїм характером.

CodeRabbit (2025) підсумовує: AI-генерований код має 1,7× більше дефектів, ніж написаний людиною, і концентруються вони саме в логічних помилках. Тобто саме там, де unit-тести найменш ефективні: вони тестують функцію, а не взаємодію; happy path, а не граничні кейси; те, що розробник або модель вважали важливим, а не те, що спалить у виробництві. Логічна помилка не кидає виняток. Вона просто рахує 99 замість 100, місяць за місяцем, поки хтось не звірить вручну.

Майже-правильне настільки небезпечне саме тому, що воно проходить green bar. Неправильне ловлять компілятори і тести — воно падає голосно й одразу. Правильне говорить само за себе. Майже-правильне — це third state: виглядає як правильне, але не є ним, і ця різниця виявляється пізно, коли ціна вже зросла, а контекст уже забутий.

Зелений колір перестав бути діагнозом. Він став заспокійливим.

---

Борг, який AI не прибирає за собою

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

GitClear проаналізував 211 мільйонів рядків коду і зафіксував: частка клонованого коду зросла з 8,3% у 2021 до 12,3% у 2024. Окремо — частота блоків, дубльованих дослівно («copy/pasted»), зросла у 2024 році восьмикратно. Не тому, що розробники стали ліниві: просто AI генерує функцію дешевше, ніж читати і переробляти існуючу. Копіювати швидше, ніж рефакторити. Новий модуль — копія сусіднього з трьома зміненими рядками, і ніхто не виносить сміття, бо порожня тарілка з’являється за секунди. Навіщо мити, коли можна взяти нову.

Одночасно refactoring впав з 25% активності команд у 2021 до менш ніж 10% у 2024. Ті самі дані GitClear. Це не просто цифра — це сигнал того, хто прибирає після вечірки. Раніше команди витрачали чверть зусиль на «прибрати за собою»: перейменувати, консолідувати, спростити, викинути мертвий код. Тепер — менше 10%. AI пише, але не прибирає; і чим більше пише, тим більше залишається неприбраного. Чверть колишньої гігієни просто випарувалась, бо нову страву видно, а вимитий посуд — ні.

Технічний борг — єдине, що зростає пропорційно до «продуктивності» і ніколи не зʼявляється в метриках, якими хваляться на стендапах. Він живе в репозиторії, набрякає з кожним AI-PR, і одного дня ти витрачаєш три дні на те, щоб зрозуміти, чому в кодовій базі пʼять майже-однакових функцій парсингу дати — і яка з них «правильна», а які чотири тихо розходяться в крайових кейсах.

Ось вам і панч номер два: AI — чудовий кухар і катастрофічний прибиральник. Він готує нові страви швидше, ніж ти встигаєш помити попередній посуд. Але рахунок за миття нікуди не дівається — він просто капіталізується.

Податок на майже-правильне — це не лише про рев’ю одного PR. Це про накопичення ентропії, яка робить кожен наступний рев’ю дорожчим, кожну наступну функцію складнішою у розумінні, кожен наступний баг — глибшим у кореневій причині. Борг — це не одна несплачена квитанція. Це відсотки, що капають на тіло, поки ти святкуєш зростання throughput.

---

Коли податок прострочують — і платять у проді

О 3:14 ночі не дзвонять, щоб сказати, що процес дав збій. Дзвонять, щоб сказати, що продакшн впав.

Сцена узагальнена, але не вигадана: команда впроваджувала AI-assisted розробку з усією коректністю — code review, автотести, CI/CD, всі ворота на місці. Код пройшов усі ворота. Виїхав у продакшн. І зробив щось несподіване — тихо, непомітно, у конкретному граничному кейсі, який жоден тест не покривав, бо ані розробник, ані модель не знали, що він існує. Аутаж. Дашборди червоні, канал інцидентів дзвенить, хтось у піжамі відкриває ноутбук на кухонному столі. Post-mortem наступного дня: «Ніхто не дебажив погано — всі дотримались процесу». Саме в цьому і суть: процес не встигав за темпом генерації. Він був спроєктований для людської швидкості виробництва, а не для AI-темпу.

CSA Research Note (2026, на даних Apiiro по Fortune-50 репозиторіях) фіксує: AI-генерований код додавав понад 10 000 нових security-знахідок на місяць — десятикратний стрибок порівняно з груднем 2024. Це не означає 10 000 вразливостей у продакшні: більшість знахідок відсіюється сканерами й рев’ю. Але те, що проходить — проходить із вищою щільністю прихованих дефектів, ніж код, написаний людиною. І та сама команда верифікації, що захлинається в чергах рев’ю, тепер має ще й це. Аналітики Trace3 описують їхній стан без евфемізмів: security- і review-команди тонуть.

Прострочений податок на майже-правильне не зникає. Він капіталізується і зʼявляється о 3-й ночі — у вигляді аутажу, security-інциденту або, найгірше, тихого накопичення помилок, які ніхто не помічає, поки вони не зробили вже достатньо шкоди. Це не вина конкретного розробника. Це не вина AI. Це системна помилка архітектури контролю, яка не масштабувалась разом із темпом генерації.

Питання не моральної відповідальності — питання спроєктованого процесу. Систему не переробили, коли вхідний потік виріс у рази. Тому вона тримає навантаження доти, доки не перестає. А коли перестає, рахунок приходить одразу за весь несплачений період, з пенею.

---

Чому горлечко не розшириш — закон, а не лінь

Уявіть видавництво, де принтер прискорили в десять разів. Він тепер виводить сторінки швидше, ніж очі встигають читати рядки. Коректор — один. Живий. З двома очима і одним мозком, який стомлюється до обіду. Стоси сторінок ростуть швидше, ніж він рухається по тексту — паперова дюна напирає на край столу. Видавництво не стало в десять разів ефективнішим — воно стало в десять разів завантаженішим на вході і так само заторможеним на виході. Єдиний спосіб реально прискоритися — найняти дев’ять нових коректорів, і навіть тоді ти не отримаєш 10×, бо нові коректори не відразу знають стиль, мову, контекст видання, і перші місяці пропускають те, що старий ловив очима з третього погляду.

Саме це Амдал довів математично у 1967-му, і саме це відбувається в AI-розробці зараз. Генерацію можна масштабувати нескінченно: агенти, паралельні потоки, кластери, автономні системи, які пишуть тисячі рядків на годину, не питаючи дозволу. Верифікацію — ні. Не тому, що «команда лінується» або «процес поганий». А тому, що white-box review — це принципово послідовна людська операція. Читання коду не паралелізується між ревʼюерами без координаційних витрат, які самі по собі зʼїдають здобуток: двоє рев’юерів на один PR витрачають не половину часу кожен, а повний час кожен плюс синхронізацію.

Леонардо Стерн, інженер Agoda, сформулював це без прикрас: white-box рев’ю AI-коду, де людина читає кожен рядок, не масштабується, коли агенти видають тисячі рядків на годину. І коротше, у фразу, яку варто повісити над кожним стендапом: кількість рев’юерів неможливо збільшити в десять разів так само легко, як кількість агентів.

Ти можеш найняти більше розробників. Але розробник — не функція, яку масштабують горизонтально. Досвід, розуміння контексту, здатність помітити «щось тут не так» за пів секунди до того, як зрозумієш чому — це накопичується роками і не реплікується за квартал onboarding’у. Коли агент виробляє тисячу рядків на годину, а сеньйор перевіряє двісті — це не проблема ефективності, яку розв’яже ще один тренінг. Це вбудована асиметрія між кремнієм, що множиться, і нейронами, що ні.

Тут закон Амдала замикається з лідом: генерація — це 90% системи, що паралелізується. Верифікація — це 10%, що лишились послідовними. Скільки б ядер ти не додав до першого, система рухається зі швидкістю другого. Принтер може гудіти втричі гучніше — дюна паперу від цього тільки виросте.

Податок на майже-правильне прогресивний: ставка росте зі складністю системи. На простій задачі, у незнайомій мові, для прототипу — ставка близька до нуля. На складному репозиторії з роками накопиченого контексту, у виробничому коді з крайовими кейсами — ставка 100% і вище. METR вимірював саме другий сценарій: досвідчені розробники, складні знайомі репозиторії, реальні задачі. Тому і −19%.

---

Чесність: кому AI таки виписав знижку

Джуніор-розробниця Марія за вечір зібрала робочий прототип REST API з автентифікацією і базовою документацією. Рік тому це коштувало б їй тиждень — тиждень читання документації, копання в чужих прикладах, спотикання об конфігурацію, якої ніхто не пояснює. Цього вечора AI провів її за руку. Вона теж галюцинувала API-параметри — точніше, AI галюцинував за неї, але кожна помилка ловилась за хвилини й була навчальним кроком, а не виробничим ризиком: прототип нікого не обслуговує о 3-й ночі. Для неї AI справді був копілотом: підказував, прискорював, компенсував відсутність шаблонів у голові, які сеньйор накопичив за десятиліття.

Це теж правда. І вона живе поруч із тією правдою, що METR виміряв −19%.

Треба бути чесними: Almost-Right Tax — це не «AI марний». Це податок, що має ставку. І ставка залежить від контексту так само, як прибутковий податок залежить від доходу.

METR досліджував специфічний сценарій: досвідчені розробники, великі open-source репозиторії, задачі, де ціна контексту максимальна. Саме там ставка висока — бо модель не знає системи, а розробник змушений верифікувати кожен рядок з нуля, тримаючи в голові роки накопичених домовленостей, яких немає в коді. Faros AI фіксує реальний team-level lift: +21% задач — це не статистичний шум. Ці задачі реально вирішуються, реально закриваються, реально їдуть у прод. Просто вони розчиняються downstream, у вузькому місці, яке нікуди не ділося.

На простих задачах, де boilerplate переважає, ставка низька. На прототипах з нуля, на незнайомій мові, для джуніора без шаблонів у голові — ставка близька до нуля, іноді від’ємна: AI реально прискорює, і METR цього не спростовує, бо METR цього й не вимірював. На складних виробничих системах з роками акумульованого контексту і крайовими кейсами, які ніколи не описані в документації, — ставка 100%+.

Хто стверджує, що AI завжди сповільнює, бреше так само, як хто стверджує, що завжди прискорює. Правда не посередині — вона в ставці. Правда в тому, щоб знати, який кошик платить і який отримує.

Тому counter-pressure до тези виглядає так: Almost-Right Tax існує, але він не плаский. Він прогресивний, і прогресивний у правильному напрямку: б’є по тих, хто вже добре заробляє (досвідченим розробникам на складних задачах), і майже не торкається тих, хто тільки починає (джуніорів на простих задачах). Це не знімає проблему — але визначає, де вона гостра, а де ні. Найдорожча помилка тут — застосувати плоску ставку: дати AI там, де ставка 100%, бо «він же прискорив Марію».

---

Як перестати платити наосліп

На наступний стендап можна винести два різних набори метрик.

Перший: commit frequency, lines added, tasks closed, PR count. Виглядає добре. Показує, що команда «прискорилась». Не показує нічого про те, де час насправді живе.

Другий: cycle time від тікету до продакшну, PR review hours окремим рядком, рев’ю-навантаження на сеньйорів. Виглядає інакше. Показує, де вузьке місце. Показує, де живе Almost-Right Tax.

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

Метрика	Що показує	Що приховує
Commits / day	Темп генерації	Час верифікації
Tasks closed	Командний throughput	Downstream bottleneck
PR count	Видача	Черга рев’ю
Lines of code	Обсяг	Якість і борг
Cycle time (тікет → прод)	Системна швидкість	—
PR review hours	Вартість верифікації	—
Refactoring %	Здоров’я кодової бази	—

Перші чотири рядки — метрики, якими хваляться. Останні три — метрики, які показують реальність. Almost-Right Tax живе у різниці між ними, у тому проміжку, де графік лестить, а п’ятниця згоряє.

Практичний переклад цього в рішення — не «відмовся від AI», а «знай ставку і плати свідомо».

Де ставка низька — віддавай AI без жалю: boilerplate, початкові структури, знайомі паттерни, перші чернетки документації, прототипи у незнайомій мові. Тут AI справді дешевший за розробника, і верифікація легка — Марія тому свідок.

Де ставка висока — тримай людину в центрі: архітектурні рішення, крайові кейси у виробничих системах, безпекові компоненти, логіка з тривалим контекстом. Тут вартість «майже» надто велика, а пасажир, якому не довіряє 46% галузі, не повинен сидіти за кермом.

Refactoring поверни в процес як першокласну операцію — не «якщо буде час», а заплановану частину спринту. GitClear зафіксував падіння з 25% до менш ніж 10%; це не просто число, це сигнал, що кухня перестала мити посуд. Технічний борг накопичується пропорційно до темпу генерації і ніколи сам не прибирається — посуд не миється від того, що ти готуєш швидше.

Вимірюй PR review hours окремо — як рядок у бюджеті, а не «частину роботи». Якщо рев’ю зайняло на 91% більше часу (дані Faros), це не «нормальна операційна ефективність» — це видиме, вимірюване навантаження, яке потребує або більшої ємності, або зменшення вхідного потоку.

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

---

Almost-Right Tax не скасовується. Питання лише, чи ти його бачиш у рахунку, чи він списується автоматично — з твоєї п’ятниці, з продакшну о 3-й ночі, з ілюзії, що ти прискорився. AI не виписав тобі знижку. Він переписав рахунок дрібним шрифтом — у графу, яку ти не читаєш.