Інженер без Swift за 10 тижнів випустив застосунок
Автор ніколи не писав Swift і не знав iOS, але з першого дня кодив разом із Claude Code. Перший коміт — 16 червня, реліз Dashi Dance в App Store — 25 серпня, одразу 15 мовами. Репозиторій — понад 4400 комітів.
Головна знахідка: рядки в інструкціях агента не рятують від повторних помилок, навіть коли файл виріс за тисячу. Рятує механізм — hook, що блокує проблемні команди агента до виконання, або тест-гейт. Друга звичка — вимагати доказів, а не фраз «виглядає правильно»: пікселі, тест, що падає без фіксу.
Процес важливіший за швидкість генерації
Головний висновок автора: отримати від агента код швидко — не проблема. Проблема — зупинити його від впевненого написання неправильного коду. Тому фічі в проєкті майже ніколи не починалися з короткого промпту. Спочатку — спека (specs), потім обговорення, доки автор не погоджувався з нею, потім план із задачами, і лише після цього — реалізація, яку звіряли з планом постфактум.
На момент статті в репозиторії було понад 90 специфікацій, понад 110 планів, CI, юніт- і UI-тести та окремий пайплайн для локалізації й публікації в App Store. Автор пояснює це так: агент не пам'ятає вчорашній день, тому пам'ять доводиться тримати в репозиторії.
Другий приклад: баг, який пояснили п'ятьма неправильними теоріями
Перший тап на Play рухав відтворення за 0,44 секунди, другий — за 0,03. Команда перебрала п'ять теорій (сесія камери, API миттєвого відтворення Apple, прогрів декодера, ланцюг аудіоефектів, що будується ліниво, і «прогрів» цього ланцюга) — кожна виглядала переконливо. Спрацював не аргумент, а експеримент: два однакових кліпи, один без звукової доріжки. Без звуку відтворення стартувало за 60–234 мс, зі звуком — стабільно за 442–698 мс на кожному прогоні. Різницю давав запуск аудіопайплайна самої iOS, до якого код застосунку не мав стосунку. Баг «полагодили», просто врахувавши цю затримку у вирівнюванні, а не намагаючись прибрати її з коду.
Схожа історія з правилом «доказ, а не фраза»: дев'ять окремих рев'ю одного й того ж diff-у пропустили регресію в інтерфейсі, бо рецензент, який читає код, фізично не бачить того, що покаже UI-тест. Тепер якщо змінено вʼю — автоматично запускаються її UI-тести, без винятків.
Третій приклад: агент як провідник у незнайомій галузі
Кожна з шести колірних тем застосунку мала два акцентні кольори, які не повинні виглядати однаково. Спочатку виміряли контраст за WCAG — і найгірша пара, фіолетовий та кольору бичачої крові, показала 1,02:1, практично ідентичні значення. Але будь-хто бачив, що це два різні кольори: контраст WCAG вимірює лише яскравість, а питання «чи виглядають кольори однаково» — це про перцептивну відстань, для якої є окрема метрика, CIEDE2000. Перевимірявши нею, реальні проблемні пари знайшлися в темній темі, в інших темах. Виправлення зсунуло світлоту, не чіпаючи відтінок, і тепер тест валить збірку, якщо будь-яка пара падає нижче порогу.
Із локалізацією (15 мов без агентства перекладів, LLM перекладає прямо зі скриптів поруч із кодом, термінобаза тримає єдині назви елементів на кшталт «A/B Loop») автоматичні перевірки ловили биті плейсхолдери й залишений англійський текст, але пропускали смислові помилки: французький переклад слова «Choreo» вийшов як «Chorée» — це неврологічна хвороба хорея; спрощена китайська для 17 рядків використала слово «зберегти» зі значенням «сховище», хоч сама кнопка називалася інакше; японська сторінка довідки дублювала цілий розділ, і всі перевірки при цьому були зеленими. Автор читає англійську й китайську сам, для решти дванадцяти мов покладається на перевірки, другу модель, що шукає розбіжність сенсу з оригіналом, і відгуки танцюристів — і каже, що це його все ще трохи непокоїть.
Де прийом не рятує
Симулятор iOS швидкий і поблажливий — і може створити враження, що застосунок готовий. Пʼять багів проявилися лише на реальному пристрої: зависання iPad після зміни системного розміру тексту, украдені дотики в збільшеній відео-панелі, ефект згасання поверх кнопки Share, видимий тільки на телефоні з високою safe area, повернення попереднього стікера при швидких тапах і краш при тапі на сповіщення з повністю закритим застосунком — шлях, який жоден автотест не міг покрити.
Дисципліна фактчекінгу поширилася і на публічні пости про розробку: чернетка одного допису стверджувала, що в плеєрі «чотири елементи для тапу», спираючись на скриншот, панель керування якого насправді мала вісім. Перед тим як довіритися результату агента, варто перевірити: чи є число (кадри, пікселі, diff) замість фрази «виглядає правильно»; чи є тест, що падає без фіксу; чи протестовано на реальному пристрої, а не лише в симуляторі; чи перевірено переклад другою моделлю або носієм мови, а не лише автоматичним чек-листом.