Дилан Андерсон оставил работу разработчика в Миннесоте, прошёл рабочее испытание и переехал в Сан-Франциско, чтобы стать первым инженером стартапа Adam (W25). Компания строит ИИ-агентов для CAD-систем, а его история хорошо показывает, что ранняя роль в AI-стартапе — это не «больше свободы», а почти полная ответственность за то, каким станет продукт и инженерная культура.
Андерсон попал в Adam через знакомых: сосед основателей спросил у своего круга, кого можно назвать сильным инженером, и получил его имя. После work trial разработчик принял предложение. Об этом сообщает Y Combinator Blog в материале от 30 октября 2026 года. Для российского рынка, где фаундеры всё чаще ищут не просто senior-разработчиков, а будущих технических партнёров, кейс полезен своей прямотой: решающим фактором оказались не бренд работодателя и не аккуратно расписанный карьерный трек.
По словам Андерсона, уже на испытательном этапе он увидел две важные вещи. Во-первых, основатели сразу дали ему автономию и доверие. Во-вторых, команда работала без привычного для крупных компаний трения: меньше согласований, меньше борьбы за границы ответственности, быстрее обратная связь. Он также счёл, что компетенции фаундеров дополняют его собственные — критичный критерий для человека, который будет принимать множество технических решений в одиночку или почти в одиночку.
Переезд в Сан-Франциско не был исключительно следствием оффера: Андерсон и так хотел оказаться ближе к центру технологической индустрии. Adam стал конкретным поводом. Это важная деталь, которую обычно теряют в романтических историях о релокации: стартап нанимает не только навыки, а кандидат выбирает среду, в которой готов жить с высокой неопределённостью. Особенно если работа связана с ИИ и инженерным софтом, где рынок, требования заказчиков и сама реализация продукта ещё могут быстро меняться.
В роли инженера номер один Андерсон занимается практически всем. Кодовую базу Adam переписывали несколько раз, а ключевые системы он строил под свой рабочий процесс и технические предпочтения. Среди собственных проектов он выделяет adam.new. Такой режим заметно отличается от разработки в корпорации: там инженер чаще добавляет компонент в существующую систему, тогда как первый инженер стартапа одновременно определяет устройство этой системы, инструменты команды и скорость, с которой продукт сможет меняться.
Но свобода здесь не означает бесконечные эксперименты ради экспериментов. Андерсон говорит, что стал гораздо внимательнее оценивать ценность каждой задачи: его действия напрямую отражаются на результатах компании. Это, пожалуй, наиболее практичная часть истории для разработчиков. На ранней стадии вопрос «интересно ли это технически?» должен идти рядом с вопросом «какую проблему пользователя или команды это решает?». Красивый рефакторинг без влияния на продукт может оказаться роскошью, на которую у небольшой компании нет времени.
Андерсон не описывает такой режим через модную риторику о жертвах и выгорании. Для него работа стала частью идентичности, потому что он создаёт продукт вместе с близкими по интересам людьми, а основатели стали для него не только коллегами. Однако у этой близости есть обратная сторона: чем теснее команда, тем выше цена слабой коммуникации, неоговорённых ожиданий и конфликтов, которые пытаются переждать вместо того, чтобы решить.
По мере роста Adam Андерсон ожидает, что его роль дополнится наставничеством и лидерством. Это знакомая траектория для раннего сотрудника: сначала он закрывает инфраструктуру, продуктовые интеграции и внутренние инструменты, затем должен научиться передавать знания другим. Не каждый сильный individual contributor хочет или умеет пройти этот переход, поэтому фаундерам стоит обсуждать его ещё при найме, а не после первой волны роста.
Совет Андерсона кандидатам звучит жёстко: до выхода в команду нужно глубоко разобраться в ценности идеи. Он предупреждает, что работа над плохой, вязкой идеей быстро превращает даже сильного инженера в циника. Для тех, кто рассматривает позицию первого инженера стартапа, полезнее спрашивать не только про стек, опционы и удалёнку, но и про конкретного клиента, его боль, скорость проверки гипотез и право спорить с фаундерами. В эпоху ИИ-агентов это особенно актуально: написать демо стало проще, а доказать необходимость продукта — по-прежнему сложно.
