Вы всегда можете увеличить размерность пространства - и там задать какую хотите метрику чтобы что угодно оказалось рядом, или наоборот далеко. Я нахожу в этой работе известные пересечения с классической теорией Вапника-Червоненкиса. В пространстве достаточной размерности, по нескольким примерам вы (статистически) всегда можете провести гиперплоскость которая "достаточно хорошо" разделит примеры на два класса. Свойство выпуклости может оказаться интересным дополнением, потому что В&Ч дают скорее верхнюю границу для количества примеров. Реальные сетки успешно учатся на много меньшем (порядки) размере данных. Выпуклость хорошо объясняет - почему...
Соглашусь. Это два разных инженерных решения. Но я не знаю, какое из них проще в реализации. Камера высокого разрешения позволяет легко находить цели, но чтобы прицелиться - вам нужна точная механика (я не уверен что простые авиамодельные сервы, например, подойдут). Скорее всего, придется городить обратную связь по положению - или с камеры по положению пятна, или с зеркал.
Решение с вращающимися зеркалами крайне простое механически (обороты относительно невелики - сотни оборотов в минуту). Подшипники при такой нагрузке могут работать десятки тысяч часов - доказано компьютерными вентиляторами. Нет необходимости в обратной связи по положению - зондирующий луч гарантированно идет по той же траектории что и боевой: если вы стреляете с одинаковой задержкой (T1, T2) - то в каждом цикле попадаете в одно и то же место. Но придется повозиться с детекцией комара в модулированном отраженном сигнале.
Дальше, наверное, только решение конструктора - с чем он предпочитает бороться. Я, например, больше боюсь безлюфтовой механики и точных приводов с обратной связью...
А кто говорит что лазер должен работать на 100% мощности постоянно ? Ток же можно регулировать через голову... Работает голова на 5 или 10 процентах мощности в зондирующем режиме. При обнаружении комара, он берется на сопровождение на проходе и вычисляется момент выдачи импульса на поражение на следующем проходе. А зеркала вращаются с постоянной скоростью и непрерывно - самый лучший режим для механики, никаких переменных нагрузок...
Если мы разворачиваем луч вращающимися зеркалами - то при постоянной скорости вращения нам надо только датчик который постоянно и предсказуемо дает один импульс на оборот на каждом зеркале. Запустив таймер в микроконтроллере по фронту этого импульса - мы в каждый момент времени будем знать углы поворота зеркал относительно реперной точки. Таким образом, координата комара будет задана двумя временами (T1, T2). И нам, в целом, даже не очень интересно переводить это через скорости вращения зеркал в более привычные углы сферической системы. Можно так и рассчитывать в системе (T1, T2) - потому что на следующем сканировании мы будем по комару производить боевую работу в момент (T1+t1, T2+t2), где (t1, t2) вычисленный вектор (в тех же координатах) видимого углового перемещения комара из предыдущих наблюдений. А фотодиод скорее всего смотрит в те же самые линзы (и тогда он гарантированно смотрит по тем же координатам), либо вообще с широким углом зрения (нам важно поймать модуляцию лазерного луча - длина волны известна - комариными крыльями на частоте 200-600 гц). Если поймали модулированный сигнал - значит лазер прямо сейчас светит на комара.
Камера высокого разрешения не нужна. Комар детектируется по модуляции отраженного излучения взмахами крыльев - достаточно фотодиода и полосового фильтра (аналогового, цифрового - уже неважно). Вы стреляете по любой цели которая а) модулирует отраженный свет в диапазоне 200-600 Гц и б) Попадает в разрешенный диапазон угловых скоростей (чтобы не лупить почем зря по какой-нибудь волосинке которую треплет сквозняк из окна). Разумеется, при этом исключается атака стационарных комаров - но вроде не должно быть проблемой...
Кстати да - классическая задача радиолокации "сопровождение на проходе". Даже несколько проще, потому что с одним излучателем нас не интересует в разумных пределах расстояние до цели - задача двумерная в сферичеких координатах. Каждый проход вычисляются корреляции отметок с нескольких предыдущих, определяется вектор движения цели, и на следующем проходе включается (с гораздо меньшими допусками!) боевой режим.
А кто мешает поставить один главный блок и два-три вспомогательных по углам комнаты ? Тогда мощность единичного излучателя упадет в те же два-три раза. Основной блок выполняет сканирование объема лазером на низкой мощности и ловит модуляцию отраженного излучения в частотном диапазоне взмахов крыльев насекомого характерного размера. Выбрав цель, базовый модуль берет ее на сопровождение в непрерывном режиме, и сообщает об этом вспомогательным модулям. Те просто наводятся на самое яркое пятно в заданном секторе и сопровождают его. Когда все три устройства вышли на режим сопровождения, дается импульс. При этом на цели импульсы складываются (и это единственное место в пространстве где они сложившись - опасны).
Кроме того, требование "перемещение не быстрее 1 м/c" намекает что уничтожение комара будет происходить не миллисекундными импульсами, а скорее всего на относительно низкой мощности и долго. И я бы не стал жечь крылья. Вполне достаточно нанести существенные повреждения ногам/хоботку/телу (а они прекрасно поглощают излучение, и в силу геометрии не смогут сбросить энергию в массивную тушку) - так что у комара возникнет масса других неотложных дел, чтобы он прекратил приставать к людям...
Дурацкая еще идея (но это надо считать) - вообще делать устройство без следящей системы. Просто вращающиеся зеркала и механическая развертка в двух плоскостях. Лазер в дежурном режиме работает на малой мощности и запоминает участки на которых возвратное излучение модулировалось крыльями насекомых. На следующем сканировании - в этих участках (+-допуск по обеим координатам) дается боевой импульс. Если повезло - накрыли. Не повезло - значит не повезло: у нас нет задачи снять комара с воздуха первым же выстрелом. Пусть летает по комнате дальше - поймаем его на следующем цикле сканирования, или через один. Более того, нам не надо даже взрывать его изнутри одним импульсом - достаточно просто наносить какие-то повреждения при попадании. Если мы обеспечиваем сканирование хотя бы с частотой 10-15 герц по объему - через 5-10 секунд комар забудет что он сюда прилетел кушать (или ему будет нечем...).
Да, но у компьютера нет рук, и он сам никогда не играл... Но посмотрим - может быть действительно если обучить его на многих партиях и многих исполнениях, он сможет чисто на выявленных закономерностях "сделать похоже"...
Фортепиано - чуть ли не единственный музыкальный инструмент игра на котором гарантированно не требует каких-либо особых навыков или таланта. Нажми на кнопку - получишь результат. Понятно дело, что виртуозно играть на фортепиано дано немногим. Но опыт имущих классов российской (и не только) империи доказывает - любой аристократ (т.е. даже мозги в голове не гарантируются) при правильной дрессировке преподавателем и родителями может средне-паршиво играть на фортепиано. Там это было совершенно массово, и в обязательном порядке...
Ну, во-первых фактура для диктанта выбирается такая, чтобы средний ученик музшколы ее смог записать. :-) Во-вторых, мне все-таки кажется что учащийся муз.школы дошедший до этого момента - уже имеет достаточную практику игры на инструменте, и пишет не "что слышу, то пишу", а прикидывает как бы он это сыграл - и на этой основе "как бы я это записал чтобы потом сыграть". Если же диктант проводится на тему "Савка и Гришка сделали дуду..." - то это понятно любой кого жизнь приложила об музыкальную школу запишет хоть на слух, хоть по памяти, хоть вверх ногами, хоть задом наперед...
Вот вы убейте меня - но я не верю в то, что можно из звукового файла вернуть обратно нотную запись (если это не чижик-пыжик одной рукой, и мы не читерим распознавая произведение и потом вытаскивая из запазухи честно спиратченые ноты...). Ноты это же не просто информация о том, в какой момент какую клавишу нажали! Это же еще и момент когда ее отпустили (а это пересекается с педалью!). Информацию о многих голосах в одной руке (которая в оригинале передавалась лигами) из звука не восстановить - там вообще неизвестно каким пальцем какой руки ноту брали. Изменения ритма в одном такте (см Таривердиева, например) - откуда оно поймет ?! Плюс живой музыкант не играет как метроном или музыкальная табакерка - на записанные инструкции композитора накладывается личная интерпретация. Как они собираются осеивать одно от другого ? А выделить атаки нот - тут ИИ не надо. Товарищ Фурье давно всем объяснил как выделять спектры...
Мне кажется что китайцы или не хотят производить полностью готовые изделия, или не умеют, или просто прикалываются. И это не зависит от цены. Я на примере 3д-принтеров видел: отличный аппарат, хороший корпус, линейные рейльсы (причем, приличного качества), собрано без перекосов, все катается, и... дребезжащий endswitch который не дает ему нормально печатать (исправление стоит ~$2 - меняем на оптический). Или сделать один из проводов до головы на 8см короче остальных чтобы голова не доставала до дальнего угла... Или экструдер который не позволяет разгоняться хорошей кинематике CoreXY. Или кривой софт, который борется с резонансами не на тех частотах где они есть. Парадокс в том, что исправление стоит копейки (а в условиях завода вообще ничего не стоит - пользователь не заметит изменение цены на копейку)...
При этом, то что реально стоит денег (и невозможно сделать на коленке или даже в мастерской) - сделано нормально, вопросов нет. Но положить какашечку на тортик вместо вишенки - как здрасьте... Ментальность один в один с советским велосипедным заводом: и металл годный, и подшипники ГПЗ положили, и седушку кожаную на пружинах сделали - такая красота, что аж глаза режет! Ну давайте хотя бы болты крепления багажника молотком криво забьем.. :-)
Покупать на алике можно и нужно! Просто не надо ждать что вы покупаете готовое изделие... Как в старые добрые советские времена - вы покупаете набор для творчества! В этом наборе вы найдете кучу добротных компонентов, из которых сможете с небольшими услиями собрать именно то, что вам нужно. Ну а то что не с той стороны отверстия насверлили - это не беда. Когда мне, пацану, купили первый взрослый велосипед - первое что мы сделали с отцом - это его полностью разобрали, вымыли песок из подшипников, прошли метчиком резьбы куда винты забивали молотком, выпрямили держатели крыльев - и он был огонь-машина! А если вы хотите просто отдать денег, включить и поехать, то это всякие буржуйские боши-сименсы. Эти, дай им волю, и еду за вас есть будут...
А почему вы считаете, что чтение и разбор кода после LLM займут сильно меньше времени, чем просто его реализация ? В современных фреймворках "тупая" часть тестирования (моки, ассерты) уже реализована: знай себе инициализируй объекты да проверяй результат... Еще раз - я не против ИИ помогающего писать тесты. Я против ИИ, которому ставят KPI по покрытию (и отбирают тесты целенаправленно на увеличение покрытия). Я (возможно с развитием ИИ это изменится) стою на том, что happy-path тесты должен писать разработчик (потому что ИИ понятия не имеет о бизнес-контексте). А вот анализ покрытия и идентификацию бизнес-кейсов которые не покрыты текущими тестами - вполне можно доверить ИИ. Но эти кейсы должен глазами посмотреть разработчик (т.е. они должны быть сгенерированы в человеко-читаемом виде!), возможно их отредактировать - и потом уже пусть ИИ их реализует (если может). А когда мы показываем человеку PR в котором уже сгенерирован десяток тестов - то или теперь ему придется восстанавливать по коду - какие бизнес-кейсы имелись в виду (и почему), или человек просто перекрестится и нажмет 'Approve' не вдаваясь в подробности...
На самом деле, есть два существенно разных сценария. Вариант 1: перед нами некое легаси, которое надо перетащить на новую версию фреймворка, или запихнуть в облако, или что-то там еще. Мы знаем что оно сейчас работает - это подтверждается практикой. Однако, как во всяком легаси - часть тестов сломана, часть закомментирована, и уже никто не знает почему. Если мы хотим прибить к столу текущий функционал и убедиться что мы его не сломаем в процессе миграции - наверное робот - лучший вариант. Приколотит так что потом зубами не оторвешь. :-)
Если же у нас Вариант 2: идет итерация разработки - то я с вами согласен: инструктировать LLM написать тест который "builds and passes" на непроверенный код - это только создавать себе иллюзию тестирования. Я так в одном проекте видел сервис с зелеными тестами, который в принципе не запускался (функции взаимодействия с БД дописать забыли - но с моками-то все было в порядке!)...
Тогда почему вы выкидываете тесты по критерию "не увеличивает coverage" ? Если у вас идентифицирован корректный (ранее не тестированный) бизнес кейс - и он не увеличивает покрытие (например, вызывая все те же функции - но в другом порядке) ? А-а... нет, я знаю! Это такая корпоративная шизофрения: говорить правильные вещи, а делать все-равно то, за что дают плюшку по KPI... :-(
У нас были приняты саммари типа таких: "JIRA-XXXX: increased default initial timeout on service connect", "JIRA-YYYY: do not send error details if the receiver signals overflow (error-reporter-client version bump)". Весь смысл в том, что посмотрев на заголовок - вы можете решить: читать этот коммит, или пропустить. Но никакого списка измененых/добавленных/измененных сущностей/файлов разумеется тут нет. Для этого есть git diff, git bisect и остальные команды... Можно спорить - отвечают ли эти заголовки на вопрос "почему?" или "что?" - но это именно высокоуровневое саммари.
Что за новая дичь - писать отчет по проделанной работе в commit message ? Commit message должен отвечать на вопрос "Зачем изменения?", а не "Какие изменения?". Кто захочет узнать что именно вы изменили - сделает git diff...
Как бы это понятнее объяснить... Представьте себе что вы открываете оглавление книги. Одна ситуация - вы видите понятные и короткие названия глав: "Детство в деревне. // C отцом на охоте // Найденыш // etc". Другое когда там начинается: "В деревне Миндюкино было 3999 обывателей, двое умерло, один приехал из города", "От околицы 300 метров до опушки, далее WSW полтора километра к одинокой сосне"... Формально - описано одно и то же. Но если вы читаете нормальное оглавление - вы можете понять что вы уже видели, куда смотреть не имеет смысла (если вы ищете конкретный фрагмент в книге), а куда надо закопаться! А когда коммит-месседж используют как помойку - ну извините!...
Вот что случается когда корпоративное мышление (точнее - отсутствие такового и замена мозга на KPI) получает доступ к LLM! Что вы носитесь с метриками покрытия как с карго-культом ?! Я уже устаю воевать с этой тупостью: покрытие - это метрика, а, блдж, не цель! Она не может быть ни плохой, ни хорошей. Если у вас низкое покрытие - то надо не LLM запускать чтобы она сделала покрытие (напоминаю, можно легко сделать тест который на 100% покрывает кусок кода, и никогда не падает - для этого достаточно ничего не ассертить!) - а садиться и разбираться почему так! То-ли архитектура не позвляет писать юнит-тесты, то-ли нет нетривиальной логики, то-ли еще какая причина...
Мы тоже делаем тесты при помощи LLM - но при этом кучу времени и экспериментов потратили на то чтобы а) Отсечь файлы на которые юнит-тесты писать не надо даже пытаться; и б) Заставить систему сначала описать тест-кейс словами в формате given-when-then, и только потом его реализовывать. Чтобы тестировались какие-то реальные кейсы, а не тупо набивались проценты покрытия...
А когда при помощи LLM набиваются проценты покрытия в угоду корпоративным KPI - то LLM вам просто к столу прибивает детали реализации. Когда вы потом начнете это рефакторить - будете плакать горючими слезами. Потому что в нормальных юнит-тестах прибито к столу требуемое (!) поведение системы. Которое если сломалось - значит где-то что-то в другом углу упадет. А после LLM - тестами система заморожена в текущем состоянии. Поди пойми, что связано с реальным поведением системы, а что - нет ?... И тогда будет второй этап - вы после изменений удалите красные тесты и попросите систему восстановить процент покрытия. Только вот ИИ без разницы что вы там написали в новом коде - он прибивает к столу некорректное поведение так же эффективно как правильное. В конце вы сможете насладиться выкидыванием тестов оптом на помойку (потому что теперь никто не знает какое поведение они фиксируют), и начать руками заново...
Я вас разочарую. бОльшая часть "малого и среднего бизнеса" в РФ - это банальный купи-продай. Нет, есть конечно и инновационные компании, и крутые - но их надо буквально искать с микроскопом. Ментальность этого бизнеса тоже своеобразна. Он живет в атмосфере постоянной нехватки ресурсов (в этом его отличие от больших компаний) - поэтому крутится. Но налюбит на деньги он вас так же охотно: прогадит сроки, сделает криво, кинет по гарантии, и т.д.
Вы всегда можете увеличить размерность пространства - и там задать какую хотите метрику чтобы что угодно оказалось рядом, или наоборот далеко. Я нахожу в этой работе известные пересечения с классической теорией Вапника-Червоненкиса. В пространстве достаточной размерности, по нескольким примерам вы (статистически) всегда можете провести гиперплоскость которая "достаточно хорошо" разделит примеры на два класса. Свойство выпуклости может оказаться интересным дополнением, потому что В&Ч дают скорее верхнюю границу для количества примеров. Реальные сетки успешно учатся на много меньшем (порядки) размере данных. Выпуклость хорошо объясняет - почему...
Соглашусь. Это два разных инженерных решения. Но я не знаю, какое из них проще в реализации. Камера высокого разрешения позволяет легко находить цели, но чтобы прицелиться - вам нужна точная механика (я не уверен что простые авиамодельные сервы, например, подойдут). Скорее всего, придется городить обратную связь по положению - или с камеры по положению пятна, или с зеркал.
Решение с вращающимися зеркалами крайне простое механически (обороты относительно невелики - сотни оборотов в минуту). Подшипники при такой нагрузке могут работать десятки тысяч часов - доказано компьютерными вентиляторами. Нет необходимости в обратной связи по положению - зондирующий луч гарантированно идет по той же траектории что и боевой: если вы стреляете с одинаковой задержкой (T1, T2) - то в каждом цикле попадаете в одно и то же место. Но придется повозиться с детекцией комара в модулированном отраженном сигнале.
Дальше, наверное, только решение конструктора - с чем он предпочитает бороться. Я, например, больше боюсь безлюфтовой механики и точных приводов с обратной связью...
А кто говорит что лазер должен работать на 100% мощности постоянно ? Ток же можно регулировать через голову... Работает голова на 5 или 10 процентах мощности в зондирующем режиме. При обнаружении комара, он берется на сопровождение на проходе и вычисляется момент выдачи импульса на поражение на следующем проходе. А зеркала вращаются с постоянной скоростью и непрерывно - самый лучший режим для механики, никаких переменных нагрузок...
Если мы разворачиваем луч вращающимися зеркалами - то при постоянной скорости вращения нам надо только датчик который постоянно и предсказуемо дает один импульс на оборот на каждом зеркале. Запустив таймер в микроконтроллере по фронту этого импульса - мы в каждый момент времени будем знать углы поворота зеркал относительно реперной точки. Таким образом, координата комара будет задана двумя временами (T1, T2). И нам, в целом, даже не очень интересно переводить это через скорости вращения зеркал в более привычные углы сферической системы. Можно так и рассчитывать в системе (T1, T2) - потому что на следующем сканировании мы будем по комару производить боевую работу в момент (T1+t1, T2+t2), где (t1, t2) вычисленный вектор (в тех же координатах) видимого углового перемещения комара из предыдущих наблюдений. А фотодиод скорее всего смотрит в те же самые линзы (и тогда он гарантированно смотрит по тем же координатам), либо вообще с широким углом зрения (нам важно поймать модуляцию лазерного луча - длина волны известна - комариными крыльями на частоте 200-600 гц). Если поймали модулированный сигнал - значит лазер прямо сейчас светит на комара.
Камера высокого разрешения не нужна. Комар детектируется по модуляции отраженного излучения взмахами крыльев - достаточно фотодиода и полосового фильтра (аналогового, цифрового - уже неважно). Вы стреляете по любой цели которая а) модулирует отраженный свет в диапазоне 200-600 Гц и б) Попадает в разрешенный диапазон угловых скоростей (чтобы не лупить почем зря по какой-нибудь волосинке которую треплет сквозняк из окна). Разумеется, при этом исключается атака стационарных комаров - но вроде не должно быть проблемой...
Кстати да - классическая задача радиолокации "сопровождение на проходе". Даже несколько проще, потому что с одним излучателем нас не интересует в разумных пределах расстояние до цели - задача двумерная в сферичеких координатах. Каждый проход вычисляются корреляции отметок с нескольких предыдущих, определяется вектор движения цели, и на следующем проходе включается (с гораздо меньшими допусками!) боевой режим.
А эхолокация тоже прикольно!
А кто мешает поставить один главный блок и два-три вспомогательных по углам комнаты ? Тогда мощность единичного излучателя упадет в те же два-три раза. Основной блок выполняет сканирование объема лазером на низкой мощности и ловит модуляцию отраженного излучения в частотном диапазоне взмахов крыльев насекомого характерного размера. Выбрав цель, базовый модуль берет ее на сопровождение в непрерывном режиме, и сообщает об этом вспомогательным модулям. Те просто наводятся на самое яркое пятно в заданном секторе и сопровождают его. Когда все три устройства вышли на режим сопровождения, дается импульс. При этом на цели импульсы складываются (и это единственное место в пространстве где они сложившись - опасны).
Кроме того, требование "перемещение не быстрее 1 м/c" намекает что уничтожение комара будет происходить не миллисекундными импульсами, а скорее всего на относительно низкой мощности и долго. И я бы не стал жечь крылья. Вполне достаточно нанести существенные повреждения ногам/хоботку/телу (а они прекрасно поглощают излучение, и в силу геометрии не смогут сбросить энергию в массивную тушку) - так что у комара возникнет масса других неотложных дел, чтобы он прекратил приставать к людям...
Дурацкая еще идея (но это надо считать) - вообще делать устройство без следящей системы. Просто вращающиеся зеркала и механическая развертка в двух плоскостях. Лазер в дежурном режиме работает на малой мощности и запоминает участки на которых возвратное излучение модулировалось крыльями насекомых. На следующем сканировании - в этих участках (+-допуск по обеим координатам) дается боевой импульс. Если повезло - накрыли. Не повезло - значит не повезло: у нас нет задачи снять комара с воздуха первым же выстрелом. Пусть летает по комнате дальше - поймаем его на следующем цикле сканирования, или через один. Более того, нам не надо даже взрывать его изнутри одним импульсом - достаточно просто наносить какие-то повреждения при попадании. Если мы обеспечиваем сканирование хотя бы с частотой 10-15 герц по объему - через 5-10 секунд комар забудет что он сюда прилетел кушать (или ему будет нечем...).
Да, но у компьютера нет рук, и он сам никогда не играл... Но посмотрим - может быть действительно если обучить его на многих партиях и многих исполнениях, он сможет чисто на выявленных закономерностях "сделать похоже"...
Фортепиано - чуть ли не единственный музыкальный инструмент игра на котором гарантированно не требует каких-либо особых навыков или таланта. Нажми на кнопку - получишь результат. Понятно дело, что виртуозно играть на фортепиано дано немногим. Но опыт имущих классов российской (и не только) империи доказывает - любой аристократ (т.е. даже мозги в голове не гарантируются) при правильной дрессировке преподавателем и родителями может средне-паршиво играть на фортепиано. Там это было совершенно массово, и в обязательном порядке...
Ну, во-первых фактура для диктанта выбирается такая, чтобы средний ученик музшколы ее смог записать. :-) Во-вторых, мне все-таки кажется что учащийся муз.школы дошедший до этого момента - уже имеет достаточную практику игры на инструменте, и пишет не "что слышу, то пишу", а прикидывает как бы он это сыграл - и на этой основе "как бы я это записал чтобы потом сыграть". Если же диктант проводится на тему "Савка и Гришка сделали дуду..." - то это понятно любой кого жизнь приложила об музыкальную школу запишет хоть на слух, хоть по памяти, хоть вверх ногами, хоть задом наперед...
Вот вы убейте меня - но я не верю в то, что можно из звукового файла вернуть обратно нотную запись (если это не чижик-пыжик одной рукой, и мы не читерим распознавая произведение и потом вытаскивая из запазухи честно спиратченые ноты...). Ноты это же не просто информация о том, в какой момент какую клавишу нажали! Это же еще и момент когда ее отпустили (а это пересекается с педалью!). Информацию о многих голосах в одной руке (которая в оригинале передавалась лигами) из звука не восстановить - там вообще неизвестно каким пальцем какой руки ноту брали. Изменения ритма в одном такте (см Таривердиева, например) - откуда оно поймет ?! Плюс живой музыкант не играет как метроном или музыкальная табакерка - на записанные инструкции композитора накладывается личная интерпретация. Как они собираются осеивать одно от другого ? А выделить атаки нот - тут ИИ не надо. Товарищ Фурье давно всем объяснил как выделять спектры...
Мне кажется что китайцы или не хотят производить полностью готовые изделия, или не умеют, или просто прикалываются. И это не зависит от цены. Я на примере 3д-принтеров видел: отличный аппарат, хороший корпус, линейные рейльсы (причем, приличного качества), собрано без перекосов, все катается, и... дребезжащий endswitch который не дает ему нормально печатать (исправление стоит ~$2 - меняем на оптический). Или сделать один из проводов до головы на 8см короче остальных чтобы голова не доставала до дальнего угла... Или экструдер который не позволяет разгоняться хорошей кинематике CoreXY. Или кривой софт, который борется с резонансами не на тех частотах где они есть. Парадокс в том, что исправление стоит копейки (а в условиях завода вообще ничего не стоит - пользователь не заметит изменение цены на копейку)...
При этом, то что реально стоит денег (и невозможно сделать на коленке или даже в мастерской) - сделано нормально, вопросов нет. Но положить какашечку на тортик вместо вишенки - как здрасьте... Ментальность один в один с советским велосипедным заводом: и металл годный, и подшипники ГПЗ положили, и седушку кожаную на пружинах сделали - такая красота, что аж глаза режет! Ну давайте хотя бы болты крепления багажника молотком криво забьем.. :-)
Покупать на алике можно и нужно! Просто не надо ждать что вы покупаете готовое изделие... Как в старые добрые советские времена - вы покупаете набор для творчества! В этом наборе вы найдете кучу добротных компонентов, из которых сможете с небольшими услиями собрать именно то, что вам нужно. Ну а то что не с той стороны отверстия насверлили - это не беда. Когда мне, пацану, купили первый взрослый велосипед - первое что мы сделали с отцом - это его полностью разобрали, вымыли песок из подшипников, прошли метчиком резьбы куда винты забивали молотком, выпрямили держатели крыльев - и он был огонь-машина! А если вы хотите просто отдать денег, включить и поехать, то это всякие буржуйские боши-сименсы. Эти, дай им волю, и еду за вас есть будут...
А почему вы считаете, что чтение и разбор кода после LLM займут сильно меньше времени, чем просто его реализация ? В современных фреймворках "тупая" часть тестирования (моки, ассерты) уже реализована: знай себе инициализируй объекты да проверяй результат... Еще раз - я не против ИИ помогающего писать тесты. Я против ИИ, которому ставят KPI по покрытию (и отбирают тесты целенаправленно на увеличение покрытия). Я (возможно с развитием ИИ это изменится) стою на том, что happy-path тесты должен писать разработчик (потому что ИИ понятия не имеет о бизнес-контексте). А вот анализ покрытия и идентификацию бизнес-кейсов которые не покрыты текущими тестами - вполне можно доверить ИИ. Но эти кейсы должен глазами посмотреть разработчик (т.е. они должны быть сгенерированы в человеко-читаемом виде!), возможно их отредактировать - и потом уже пусть ИИ их реализует (если может). А когда мы показываем человеку PR в котором уже сгенерирован десяток тестов - то или теперь ему придется восстанавливать по коду - какие бизнес-кейсы имелись в виду (и почему), или человек просто перекрестится и нажмет 'Approve' не вдаваясь в подробности...
На самом деле, есть два существенно разных сценария. Вариант 1: перед нами некое легаси, которое надо перетащить на новую версию фреймворка, или запихнуть в облако, или что-то там еще. Мы знаем что оно сейчас работает - это подтверждается практикой. Однако, как во всяком легаси - часть тестов сломана, часть закомментирована, и уже никто не знает почему. Если мы хотим прибить к столу текущий функционал и убедиться что мы его не сломаем в процессе миграции - наверное робот - лучший вариант. Приколотит так что потом зубами не оторвешь. :-)
Если же у нас Вариант 2: идет итерация разработки - то я с вами согласен: инструктировать LLM написать тест который "builds and passes" на непроверенный код - это только создавать себе иллюзию тестирования. Я так в одном проекте видел сервис с зелеными тестами, который в принципе не запускался (функции взаимодействия с БД дописать забыли - но с моками-то все было в порядке!)...
Тогда почему вы выкидываете тесты по критерию "не увеличивает coverage" ? Если у вас идентифицирован корректный (ранее не тестированный) бизнес кейс - и он не увеличивает покрытие (например, вызывая все те же функции - но в другом порядке) ? А-а... нет, я знаю! Это такая корпоративная шизофрения: говорить правильные вещи, а делать все-равно то, за что дают плюшку по KPI... :-(
У нас были приняты саммари типа таких: "JIRA-XXXX: increased default initial timeout on service connect", "JIRA-YYYY: do not send error details if the receiver signals overflow (error-reporter-client version bump)". Весь смысл в том, что посмотрев на заголовок - вы можете решить: читать этот коммит, или пропустить. Но никакого списка измененых/добавленных/измененных сущностей/файлов разумеется тут нет. Для этого есть git diff, git bisect и остальные команды... Можно спорить - отвечают ли эти заголовки на вопрос "почему?" или "что?" - но это именно высокоуровневое саммари.
Что за новая дичь - писать отчет по проделанной работе в commit message ? Commit message должен отвечать на вопрос "Зачем изменения?", а не "Какие изменения?". Кто захочет узнать что именно вы изменили - сделает git diff...
Как бы это понятнее объяснить... Представьте себе что вы открываете оглавление книги. Одна ситуация - вы видите понятные и короткие названия глав: "Детство в деревне. // C отцом на охоте // Найденыш // etc". Другое когда там начинается: "В деревне Миндюкино было 3999 обывателей, двое умерло, один приехал из города", "От околицы 300 метров до опушки, далее WSW полтора километра к одинокой сосне"... Формально - описано одно и то же. Но если вы читаете нормальное оглавление - вы можете понять что вы уже видели, куда смотреть не имеет смысла (если вы ищете конкретный фрагмент в книге), а куда надо закопаться! А когда коммит-месседж используют как помойку - ну извините!...
Вот что случается когда корпоративное мышление (точнее - отсутствие такового и замена мозга на KPI) получает доступ к LLM! Что вы носитесь с метриками покрытия как с карго-культом ?! Я уже устаю воевать с этой тупостью: покрытие - это метрика, а, блдж, не цель! Она не может быть ни плохой, ни хорошей. Если у вас низкое покрытие - то надо не LLM запускать чтобы она сделала покрытие (напоминаю, можно легко сделать тест который на 100% покрывает кусок кода, и никогда не падает - для этого достаточно ничего не ассертить!) - а садиться и разбираться почему так! То-ли архитектура не позвляет писать юнит-тесты, то-ли нет нетривиальной логики, то-ли еще какая причина...
Мы тоже делаем тесты при помощи LLM - но при этом кучу времени и экспериментов потратили на то чтобы а) Отсечь файлы на которые юнит-тесты писать не надо даже пытаться; и б) Заставить систему сначала описать тест-кейс словами в формате given-when-then, и только потом его реализовывать. Чтобы тестировались какие-то реальные кейсы, а не тупо набивались проценты покрытия...
А когда при помощи LLM набиваются проценты покрытия в угоду корпоративным KPI - то LLM вам просто к столу прибивает детали реализации. Когда вы потом начнете это рефакторить - будете плакать горючими слезами. Потому что в нормальных юнит-тестах прибито к столу требуемое (!) поведение системы. Которое если сломалось - значит где-то что-то в другом углу упадет. А после LLM - тестами система заморожена в текущем состоянии. Поди пойми, что связано с реальным поведением системы, а что - нет ?... И тогда будет второй этап - вы после изменений удалите красные тесты и попросите систему восстановить процент покрытия. Только вот ИИ без разницы что вы там написали в новом коде - он прибивает к столу некорректное поведение так же эффективно как правильное. В конце вы сможете насладиться выкидыванием тестов оптом на помойку (потому что теперь никто не знает какое поведение они фиксируют), и начать руками заново...
Я вас разочарую. бОльшая часть "малого и среднего бизнеса" в РФ - это банальный купи-продай. Нет, есть конечно и инновационные компании, и крутые - но их надо буквально искать с микроскопом. Ментальность этого бизнеса тоже своеобразна. Он живет в атмосфере постоянной нехватки ресурсов (в этом его отличие от больших компаний) - поэтому крутится. Но налюбит на деньги он вас так же охотно: прогадит сроки, сделает криво, кинет по гарантии, и т.д.