Я думаю, малореально. И я могу понять тех, кто тебе откажет. Всё просто.
1. Ты неконтролируем в принципе. Окей, у тебя дома стоит камера. А на улице что тебе мешает встретиться с агентом КГБ и слить инфу? Вообще ничего.
2. Полиграф в реалтайме? ))) Покупать его за свои деньги будешь? И полиграфисту ЗП тоже за свой счёт платить будешь, который будет сидеть рядом? ))))
3. В любой стране люди, работающие со стратегической и секретной инфой — невыездные. А ты хочешь прям ремоутом работать )

Какие есть варианты навскидку: наверное, работать с несекретными открытыми данными. Например, OSINT или что-то аналогичное. DeepState, как вариант. И то — с ограничениями на реалтаймовую инфу, которая может представлять интерес для противника.
Ну или работа «втёмную», без доступа к реальной инфе. Например, писать код для контроллера без инфы о том, куда его потом поставят и с какой целью. Но для такого потребуется развитая система ограничения пермишенов, как в банках, к примеру. Очевидно, что в стартапе такого нет. Поэтому вариант крайне малореалистичен. В армию — вариант ещё менее реалистичен. Ибо бюрократия. И нет у них в штатном расписании «ремоут» солдат.

Ну и + требований по архитектуре сильно меньше. Вне зависимости от типа проекта и внешних требований, архитектура тестового фреймворка будет ± одинаковая, различия будут только для доступов (например, могут ли тесты читать / писать в базу) и выбранного тулсета.

Я тоже пишу как практик (пишу автотесты).
Насчёт юнит-тестов с КПД 5% — решается скиллами.
Например, у меня прописана тестовая пирамида между API и UI тестами, критерии полноты для каждого из подвидов тестов (для API — список обязательных проверок, для UI — каждый контрол должен быть задействован хотя бы 1 раз), стратегии выбора локаторов для UI тестов и т.д., поэтому вместо непонятно чего получается вполне осмысленный результат. Кроме того, сначала пишутся мануальные тесты, которые можно легко прочесть и, если там бред (хотя бред закончился 4 месяца назад, когда я всё это отстроил) — можно легко указать на это клоду. Покрытие автоматизацией требований ~98%

Устарело примерно на год. Тот же Opus генерит вполне рабочие решения начиная с 4.6.
Они не только нормально компилируются, но и работают согласно требованиям.
Ща вопросы скорее в архитектурных подходах и качестве кода, чем в том, что получается фигня. Ну и надо не забывать писать тесты, как юнит, так и более высокого уровня.

Оч спорно.
1. Я вижу обратную тенденцию (работаем на США / Европу). Практически все хотят AI фичи даже там, где вообще непонятно, как их впилить.
2. С точки зрения разработки, без AI вообще тяжело поддерживать высокий темп. То, что раньше пилилось несколько месяцев всей командой — ща можно запилить за 2..3 дня максимум.

1. Утилитка, которая находит кадры панорамок и группирует их в отдельную папку (так проще потом засунуть в фотошоп и смерджить в 1 панорамку).
2. Claude Code плагин, который покрывает все QA фазы тестирования, начиная от анализа требований и заканчивая написанием автотестов. На вход — таска в джире и / или PR, на выходе — все необходимые артефакты (анализ требований, мануальные тесты, матрица покрытия, автоматизированные тесты).
3. UI тулза, на базе 2, которая мониторит PR’ы и, если находит новый, автоматически запускает агента с задачей написать автотесты.

Ага, видел. И юзал.
junit.jupiter.execution.parallel.mode.default и
junit.jupiter.execution.parallel.mode.classes.default

Теперь задачка на догадлиаость.
У тебя скажем есть как-то наконфиженный threadPool = 10 (как это сделать — отдельный квест, ибо невозможно, ну да ладно). И есть скажем 5 классов.
Класс 1 — 1 тест
Класс 2 — 1 тест
Класс 3 — 3 теста
Класс 4 — 2 теста
Класс 5 — 3 теста.
Если ты поставишь оба параметра выше в concurrent — получится прогнать их все в 1 проход или нет?

4 — это вообще полный писец, там претензий будет пунктов 10 как минимум :D
Это как раз по 5-й.

А зачем юзать JUnit для системных тестов, если есть TestNG, который намного лучше и удобнее именно для тестировщика?
1. Есть нормальный сетап @BeforeSuite / AfterSuite; чего в принципе нет у JUnit.
2. Нормальная работа с кол-вом потоков. Сказал — 5, будет работать именно 5, а не «как JVM наконфиженв».
3. Не столь принципиально, с учётом Allure, но всё же... Репортинг у JUnit — отвратный. Он не показывает Passed, только Failed / Skipped, что приводит к необходимости устного счета :)
4. У JUnit нет возможности сконфижить parallel = all, чтоб получить максимальную параллельность выполнения, только parallel = class или parallel = method.

JUnit всегда был рассчитан именно на запуск юнит-тестов, которые жёстко привязаны к классу. Для системных тестов, которые зачастую привязаны к логике аппликухи, а не к её структуре, он не является лучшим решением ИМХО.

Юзаю AI на ежедневной основе с полной интеграцией в QA процессы. Архитект — Opus5, ревьювер — тоже. Исполнитель — Sonnet5

Що було найскладнішим на старті?

Отсутствие специализированной литературы на тот момент. Книжек по программированию хватало, а по QA — ещё не было, массово они стали появляться через пару лет только.

І якби починали зараз — що зробили б інакше?

Всё. Сейчас моим способом — прочитать, что есть на форумах, понять, пройти пачку собесов и получить оффер сразу на миддла — пройти невозможно, просто не пригласят на собес без строчки «прошёл 10тыщ разных курсов».

Золоті часи, коли можна було «з вулиці» прислати резюме і отримати роботу закінчились ще у 2021-му.

2 раза устраивался в Испании на работу. Оба раза без всякого «нетворкинга», ибо никого тут не знаю особо. LinkedIn работает норм.

а ці дауни таки дзвонять в офіс і просять з’єднати саме з твоїм керівником

Вот поэтому ремоут рулит :)

а просто signin bonus, которий отримав хтось «при кориті»

Обычно его выплачивают после испыталки

**Обмін.** Чи отримує щось той, хто «допоміг»? Якщо так — це вже не рекомендація.

Во многих конторах есть реферальные программы, где тот, кто рекомендовал — получает от конторы деньги. Коррупцией не является. Я б дополнил пункт «от рекомендуемой персоны»

Ну... Ты ж на ДОУ пишешь, т.е., предполагается, что твоя аудитория — не психологи и бухгалтеры. Хотя, я периодически начинаю в этом сомневаться :)

Если были точные steps to reproduce — можно было попросить его написать красный тест и пофиксить проблему, через TDD.
Но вообще странно, что в логах молчок. Я не оч знаю специфику react, но неужели он ничего не выводит вообще в случае падения рендерера?

Попробую, как сделаю

Ага, мы общались, спасибо )

Хм... А почему бы не использовать норм агент и дать ему задачу «пофикси баг»?
Зачем бросание в чатик без контекста проекта?