Написал задачу, закрыл ноутбук: агент спланировал, поспорил с ревьюером и прислал PR в Telegram

Регресс-тесты до/после - агент может их генерировать, если прописано в скилле. Но оракула нет: тесты будут ровно такими, какими он сам их напишет на основе твоего описания. Часть регрессий ловит, часть пропускает - не серебряная пуля, а костыль, который лучше, чем ничего.

Швы по Физерсу - у модели нет интуиции, чтобы вытаскивать зависимости из legacy и грамотно расставлять characterization-тесты на текущее поведение. Максимум, что скилл умеет форсить: "перед изменением X напиши тест на то, как оно работает сейчас".

E2E-сценарии - ваше "откуда?" ровно в точку. Ниоткуда. Либо ты их дал в постановке, либо они уже есть в проекте, либо их не будет. Handoff не изобретает бизнес-кейсы из воздуха, и это скорее фича, чем баг - выдумывать E2E он и не должен.

Согласование умолчаний - plan-polisher гоняет план через критерии качества, туда прописывается "выяви неоднозначности и уточни". Работает вероятностно: иногда задаёт правильные вопросы, иногда додумывает молча. Полного покрытия implicit requirements не будет - ни у агента, ни у джуна на первом проекте.

Быстрая петля без человека - зависит от твоего CI и тестов, а не от агента. Если у тебя suite гоняется 40 минут с флаками, никакой автопилот это не починит, он просто будет сидеть в этой петле с тем же успехом, что и ты.

Главное, что стоит развести: Human-on-the-Loop "не равно" - "ушёл и забыл". Финальный Approve на тебе, PR ты всё равно читаешь глазами. Экономится не ревью, а ручное переключение между этапами план -> имплемент -> ревью -> фикс замечаний -> снова ревью. Кофе пьёшь не пока едет критичный фикс в прод, а пока крутится рутинная фича, которую ты потом всё равно просмотришь.

Кстати, кофе тоже неплохо пить, когда итерации review -> implement агент гоняет сам, а не ты вручную пушишь его обратно в IDE после каждого замечания.

P.S. да использовал хэндофф на 4-х проектах, попивая кофеёк и играя в онлайн игры ;)

Нужно ли в PHP перед вызовом функций ставить обратный слэш?

Все супер! а я бы еще добавил к статьи просто упоминание, когда это не обязательно, чтоб разжевать уже до конца:)

- В глобальном пространстве имен: Если файл не содержит namespace ...; в начале, то все функции и константы по умолчанию ищутся в глобальном пространстве. strlen() и \strlen() будут работать одинаково.

- Для функций, импортированных через use function (PHP 5.6+):

namespace MyApp;

use function \json_encode;

function doSomething() {
    json_encode(...); // Вызов импортированной глобальной функции без \
}

namespace MyApp\Utils;

function json_encode($data) {
 // ... кастомная реализация (плохая практика для такого имени, но технически возможно и даже попадался на такое) ...
 }

function process() {
 $data = ['a' => 1];

// Вызов КАСТОМНОЙ функции json_encode из текущего пространства MyApp\Utils:
$resultCustom = json_encode($data);

// Вызов ВСТРОЕННОЙ PHP функции json_encode (с помощью `\`):
$resultBuiltin = \json_encode($data);

// ... разные результаты ...
}

А самое главное Статические анализаторы (Psalm, PHPStan) - могут предупредить о потенциальных конфликтах имен или неоднозначных вызовах.