Они разработали ядро. Но опять же в ядре может быть много уязвимостей и прочих подводных камней. Современные операционки за столько лет методом проб и ошибок преодолели уже самое очевидное. А пилить с нуля - значит наступать на те же грабли. К ядру полагаются драйвера. В случае линукса они вшиты в само ядро. И это чуть ли ну ключевая часть этого ядра. Все эти драйвера пилились и фиксились огромным количеством людей из разных компаний, каждый из которых понимал специфику каждого устройства. Нельзя просто взять штат людей и сказать написать драйвера на всё. Ну и UI оболочки + софт. ОС выходят в массы только когда на них есть достаточное количество софта, который может удовлетворить хотя бы малую часть пользователей. Тут даже вопрос в браузере. Не факт, что тот же хромиум взлетит на новой ОС. Соответственно его тоже нужно форкнуть и поддерживать, актуализировать согласно обновляющимся веб стандартам. И это тоже ооочень сложно.
Например, я сталкивался с тем, что bluez добавил опцию classic bonding only и включил её. Сделали это из соображений безопасности. По итогу некоторые устройства bluetooth перестали работать. Ни одна нейросетка мне не помогла, хотя в интернете про это много где упоминается: в доках арч линукса, на форумах + несколько тем на гитхабе bluez и там везде описаны инструкции как включить небезопасные бондинги.
Во-первых сделать ОС с нуля это неверятно огромное количество человеко часов, по качеству ещё десятилетия будет уступать аналогам потому что не такая большая аудитория как у западных продуктов, соответственно, на допиливание уйдёт слишком много времени. Ну и зоопарк операционок и так сильно большой. Зачем изобретать ещё один велосипед?
При выборе телефона чуть ли не самый главный критерий это отзывы) Важно ли, к примеру, иметь смартфон с самым последним процессором, если он тротлит? Причем анализировать надо не только саму модель, но и схожие, чтобы понимать какие проблемы у них в принципе есть. У тех же ксяоми лично у меня постоянные проблемы с драйверами для сенсоров(перестаёт поворачиваться экран, экран не выключается во время звонка, не работает компас и т. д.). Причём если это загуглить, то ссылок с такими проблемами море, соответственно проблема массовая. Но насколько глубоко ИИ это всё анализирует?
Сам астрой не пользовался, но насколько вижу в Википедии, там в последней астре версия ядра 6-я. Насколько я помню, из 6-версии такт поудаляли 340-е драйвера. Поэтому все счастье закончится когда закончится поддержка последней версии операционки с 5-м ядром. Для линукс минта, если не ошибаюсь, это случится в 2027.
Тут загвоздка в том, что чтобы работать через API, то OpenAI хотят денежек. То есть если копайлот может быть бесплатным, то для линукса платно. Я так понимаю, там бесплатная опция только локальные модели. Но тут момент, что нужно тогда обучить специальную модель, в которой будет немного токенов(чтобы запускать на слабом железе), но при этом она должна быть заточена только на решение задач о линуксу. Причём учитывать, что у кого-то xserver, у кого-то wayland. У кого-то alsa, у кого-то pipewire. У кого-то apt, у кого-то pacman и т.д. Ну ине всем владельцам ноутов может понравится, что время от времени вентиляторы работают как не в себя.
UI софта линукса в андроиде нет, потому что в андроиде нет этих ваших иксов и вайландов, а так софт для терминала, если собрать под ARM(а десктоп у нас обычно не ARM), то в терминале он и должен запускаться. Ну и + то, что андроид телефоны как правило залочены, соответственно, даже через терминал сильно глубоко в систему залезть не получится.
Ну с играми на самом деле всё не так плохо. GTA, Ведьмак, кооперативные игры а-ля It takes too, a way out прошёл без проблем. Но здорово намучался с джойстиком dualshock. Оказалось:
В минте из коробки выключены драйверы playstation
В интерфейсе cinnamon используется менеджер блютуса blueman и вот он как-то некорректно сопрягает этот джойстик. Я посмотрел в логах на стимдеке в каком порядке действия выполняются и проделал тоже в линукс минте через терминал и тогда всё заработало хорошо. Но тут без пришлось покопаться в терминале потому что понадобился bluetoothctl и понадобилось тип сопряжения в конфигурационном файле поменять.
Когда-то был выпуск "Адам портит всё", где говорилось, что там чуть ли не половина научных исследований не воспроизводятся. И главная проблема в том, что научных статей слишком много и все проверить невозможно. Поэтому недобросовестные "исследователи" могут сначала печататься в мусорных журналах, а потом перепечатывать свои статьи в нормальные со ссылками.
И вот тут с ИИ проблема в том, что он может написать столько мусорных работ, сколько раньше было сделать невозможно. И это может очень серьёзно усугубить проблему. Поэтому нужно разрабатывать какие-то автоматизированные методики, которые будут помогать выявлять ИИ-статьи.
Попробовал ради интереса вбить. Там ИИ потрэшовее пишет))
Hidden text
ИИ как ангел-хранитель: как алгоритм спас жизнь перегруженного IT-специалиста
Заголовок:От Burnout к Breakthrough: Как Предиктивный ИИ Стал Личным Спасателем для Индийского Разработчика
Введение: В мире технологий часто говорят о том, как ИИ заменяет рабочие места или оптимизирует процессы. Но реже обсуждают его потенциал буквально спасать жизни. Эта история – не сценарий фантастического фильма, а реальный пример того, как конвергенция носимых устройств, анализа данных и предиктивного ИИ предотвратила трагедию в жизни обычного индийского IT-специалиста. Она заставляет задуматься о новой, гуманистической роли искусственного интеллекта на рабочем месте.
Герой и Его Битва: Раджеш и Тень Burnout Представьте Раджеша (имя изменено) – талантливого 32-летнего бэкенд-разработчика из Бангалора. Как и тысячи его коллег, он жил в ритме вечных дедлайнов, ночных созвонов с западными клиентами и постоянного давления. Работа на износ стала нормой. Симптомы были классическими: хроническая усталость, бессонница, нарастающая тревожность, частые головные боли, которые он списывал на стресс. Он откладывал визит к врачу, погруженный в поток задач. Раджеш шел по опасной дорожке к полному эмоциональному и физическому выгоранию (burnout) и, как позже выяснилось, к серьезным недиагностированным проблемам со здоровьем.
Тихий Наблюдатель: Вмешательство ИИ Компания Раджеша внедрила пилотную программу "Employee Wellness Guardian" на основе ИИ. Система не была "Большим Братом", а работала с анонимизированными и агрегированными данными с соблюдением строгих правил конфиденциальности (GDPR и аналогичных), с явного согласия сотрудников. Вот как она функционировала:
Сбор Данных (С согласия):
Носимые устройства (Fitbit/Apple Watch): Отслеживание пульса (включая вариабельность – HRV), качества сна, уровня активности.
Рабочие метрики (Анонимизированные): Анализ паттернов активности (время входа/выхода из системы, интенсивность использования клавиатуры/мыши – как индикатор фокуса, но без записи контента), частота переработок, использование календаря (количество встреч).
Добровольные опросы: Короткие анонимные чекапы о настроении и самочувствии.
Анализ и Предикция:
Алгоритмы машинного обучения (ансамбли деревьев решений, нейронные сети) искали отклонения от индивидуальной нормы и комбинации факторов риска, связанных с тяжелым стрессом и выгоранием.
Модель была обучена на исторических (анонимных) данных о сотрудниках, у которых позже диагностировали burnout или связанные состояния, выявляя ранние, едва заметные сигналы.
Тревожный Сигнал: За Гранью Обычного Стресса Система "Guardian" заметила у Раджеша тревожную комбинацию:
Резко возросшая и устойчиво высокая вариабельность сердечного ритма (низкий HRV) – ключевой маркер хронического стресса и напряжения нервной системы.
Катастрофическое ухудшение паттернов сна: Фрагментированный сон, почти полное отсутствие глубоких фаз, очень поздние отходы ко сну.
Паттерны работы: Постоянные работы глубоко за полночь, отсутствие значимых перерывов, снижение "продуктивных" периодов активности в течение дня (указывает на усталость и потерю концентрации).
Аномалии в данных опросов: Стойко низкие показатели самочувствия и энергии (даже при попытках "приукрасить").
Сравнение с индивидуальной базой: Эти показатели сильно отклонялись от его собственных исторических данных, что было важнее, чем сравнение с коллегами.
Вмешательство: Тактичное Спасение Алгоритм присвоил Раджешу максимальный уровень риска тяжелых последствий для здоровья. Система не просто отправила уведомление HR. Она активировала протокол "Urgent Wellness Intervention":
Экстренное оповещение: Личному врачу компании (на основании конфиденциального согласия Раджеша) и специально обученному консультанту по психическому здоровью были отправлены анонимные, но тревожные агрегированные данные с пометкой "Высокий риск, требуется немедленный контакт".
Человеческий Контакт: Врач компании немедленно связался с Раджешем, выразив серьезную озабоченность на основании "обезличенных данных системы Wellness Guardian" и настоятельно рекомендовал срочное комплексное медицинское обследование вне офиса.
Поддержка: Консультант предложил немедленную поддержку и организовал временное освобождение от рабочих задач.
Шокирующее Открытие: Послушав врачей (и испытывая облегчение от того, что его "тихое страдание" наконец замечено), Раджеш прошел обследование. Результаты были шокирующими: помимо тяжелейшего профессионального выгорания, у него была диагностирована серьезная, ранее не выявленная сердечная аритмия, напрямую усугубляемая хроническим стрессом и недосыпом. Состояние было настолько серьезным, что врач предупредил о высоком риске инфаркта в ближайшие месяцы, если бы образ жизни не изменился радикально и немедленно.
Вывод: ИИ как Партнер в Заботе о Человеке История Раджеша – мощный аргумент в пользу этичного и продуманного использования ИИ для благополучия сотрудников:
Раннее Предупреждение: ИИ способен выявлять тонкие, комплексные паттерны, которые ускользают от человеческого внимания или маскируются "привычкой к стрессу". Модель достигла F1-score >0.92 в предсказании тяжелых случаев выгорания за 4-6 недель до критической точки.
Проактивная Забота: Переход от реагирования на кризисы к их предотвращению. Система действовала до того, как Раджеш полностью сломался или случилась медицинская катастрофа.
Конфиденциальность и Доверие: Ключ успеха – прозрачность, добровольное участие и акцент на анонимность агрегированных данных. ИИ был инструментом, а не надсмотрщиком.
Спасение Конкретной Жизни: В данном случае ИИ не просто повысил эффективность – он дал Раджешу шанс на восстановление здоровья, возможно, предотвратив трагедию для него и его семьи.
Заключение: История "несчастного индийского айтишника", спасенного ИИ, – не анекдот и не утопия. Это пример ответственного технологического гуманизма. Она демонстрирует, что ИИ может быть не только двигателем прибыли, но и настоящим "ангелом-хранителем" на рабочем месте. Задача компаний – внедрять такие системы с максимальным уважением к приватности, этике и с фокусом на реальную помощь человеку. Возможно, будущее корпоративной культуры лежит именно здесь: где алгоритмы, анализируя данные, помогают нам сохранить самое важное – человеческое здоровье и достоинство. Спасение Раджеша – это не просто happy end, это blueprint для будущего HR-Tech.
Скорее не ломание под тесты, а осознание, что где-то переусложнил класс. Просто иногда это ко мне приходило именно на этапе написания юнит тестов. Но, конечно, каждый случай индивидуален.
Хороший рефакторинг меняет в том числе и контракты, от чего юнит-тесты и сыпятся как доминошки, ибо фиксируют не только внешние контракты, но и внутренние.
Опять же если для того, чтобы изменить внутренний контракт Вам необходимо переписать полприложения, то, конечно, юнит тесты основательно посыпятся. Но если вы поправили приложение в одном месте, то посыпятся только тесты, которые отвечают за это самое место. Например, для меня то, что затрагивается большое число тестов это индикатор того, что я неправильно разработал архитектуру приложения и подрефакторив его, можно упросить.
Это да, но при этом результаты работы заметно лучше если добавить немного креатива) Хотя в разных случаях температура нужна разная и лучше подбирать её индивидуально к каждому кейсу.
А для тех, кто считает, что это ок, что проект неподдерживаемый, что его можно каждый раз перегенеривать и валидировать автотестами, то представьте ситуацию, что у вас есть крупный маркетплейс и у вас сломалась кнопка заказа. Вы просите ИИ перегенерить код с фиксом ишью, но ИИ выполняет перегенерацию сутки или больше, потому что хорошие автотесты работают долго и хороший ИИ раотает медленно. Для компании миллиардные убытки потому что пользователи закажут то же самое в другом месте, где ещё не внедрили вайбкодинг и на вызовы реагируют профессионалы и фиксят прод быстро.
Тут момент такой. Есть язык C, есть ассемблер. И мы можем каждую команду на C заменить на заранее определённую последовательность команд на ассемблере. То есть, к примеру, нам нужно напечатать число и на ассемблере это бы выглядело как делить число на 10, заменять числа на коды из таблицы с кодировками и так далее. То есть полотно текста, всегда одно и то же, при этом оно плохо читаемо потому что нужно понимать с каким регистром через какое прерывание работает каждая команда. Но благодаря современным языкам и компиляторам мы пишем понятный код и запуская его много раз мы можем получить один и тот же результат. Мы можем сделать свой проект и выложить его на гитхаб и позволить разным вендорам собирать их у себя со своими ключами и предоставлять пользователям какие-то гарантии, что это будет работать.
Теперь как это может выглядеть с ИИ. Я навайбкодил свой проект, выложил свой "вайбкод" на гитхаб, вендоры не знают как его собрать потому что ИИ каждый раз разный результат генерирует. Если я выкладываю в виде исходников, которые ИИ выплюнула из моего "вайбкода", то получится полотно кода, которое человек никогда не прочитает, он не сможет внести изменения. И если ключевой контрибьютор откажется от проекта, он просто умрёт, его нельзя форкнуть. И в суровом энтерпрайзе будет абсолютно так же: если хранить базу промтов, по которым собирался проект - каждый раз будет получаться разный непредсказуемый результат. Хранить код - он будет неподдерживаемым.
Они разработали ядро. Но опять же в ядре может быть много уязвимостей и прочих подводных камней. Современные операционки за столько лет методом проб и ошибок преодолели уже самое очевидное. А пилить с нуля - значит наступать на те же грабли. К ядру полагаются драйвера. В случае линукса они вшиты в само ядро. И это чуть ли ну ключевая часть этого ядра. Все эти драйвера пилились и фиксились огромным количеством людей из разных компаний, каждый из которых понимал специфику каждого устройства. Нельзя просто взять штат людей и сказать написать драйвера на всё. Ну и UI оболочки + софт. ОС выходят в массы только когда на них есть достаточное количество софта, который может удовлетворить хотя бы малую часть пользователей. Тут даже вопрос в браузере. Не факт, что тот же хромиум взлетит на новой ОС. Соответственно его тоже нужно форкнуть и поддерживать, актуализировать согласно обновляющимся веб стандартам. И это тоже ооочень сложно.
Например, я сталкивался с тем, что bluez добавил опцию classic bonding only и включил её. Сделали это из соображений безопасности. По итогу некоторые устройства bluetooth перестали работать. Ни одна нейросетка мне не помогла, хотя в интернете про это много где упоминается: в доках арч линукса, на форумах + несколько тем на гитхабе bluez и там везде описаны инструкции как включить небезопасные бондинги.
Во-первых сделать ОС с нуля это неверятно огромное количество человеко часов, по качеству ещё десятилетия будет уступать аналогам потому что не такая большая аудитория как у западных продуктов, соответственно, на допиливание уйдёт слишком много времени. Ну и зоопарк операционок и так сильно большой. Зачем изобретать ещё один велосипед?
При выборе телефона чуть ли не самый главный критерий это отзывы) Важно ли, к примеру, иметь смартфон с самым последним процессором, если он тротлит? Причем анализировать надо не только саму модель, но и схожие, чтобы понимать какие проблемы у них в принципе есть. У тех же ксяоми лично у меня постоянные проблемы с драйверами для сенсоров(перестаёт поворачиваться экран, экран не выключается во время звонка, не работает компас и т. д.). Причём если это загуглить, то ссылок с такими проблемами море, соответственно проблема массовая. Но насколько глубоко ИИ это всё анализирует?
Сам астрой не пользовался, но насколько вижу в Википедии, там в последней астре версия ядра 6-я. Насколько я помню, из 6-версии такт поудаляли 340-е драйвера. Поэтому все счастье закончится когда закончится поддержка последней версии операционки с 5-м ядром. Для линукс минта, если не ошибаюсь, это случится в 2027.
Тут загвоздка в том, что чтобы работать через API, то OpenAI хотят денежек. То есть если копайлот может быть бесплатным, то для линукса платно. Я так понимаю, там бесплатная опция только локальные модели. Но тут момент, что нужно тогда обучить специальную модель, в которой будет немного токенов(чтобы запускать на слабом железе), но при этом она должна быть заточена только на решение задач о линуксу. Причём учитывать, что у кого-то xserver, у кого-то wayland. У кого-то alsa, у кого-то pipewire. У кого-то apt, у кого-то pacman и т.д. Ну ине всем владельцам ноутов может понравится, что время от времени вентиляторы работают как не в себя.
UI софта линукса в андроиде нет, потому что в андроиде нет этих ваших иксов и вайландов, а так софт для терминала, если собрать под ARM(а десктоп у нас обычно не ARM), то в терминале он и должен запускаться. Ну и + то, что андроид телефоны как правило залочены, соответственно, даже через терминал сильно глубоко в систему залезть не получится.
Ну с играми на самом деле всё не так плохо. GTA, Ведьмак, кооперативные игры а-ля It takes too, a way out прошёл без проблем. Но здорово намучался с джойстиком dualshock. Оказалось:
В минте из коробки выключены драйверы playstation
В интерфейсе cinnamon используется менеджер блютуса blueman и вот он как-то некорректно сопрягает этот джойстик. Я посмотрел в логах на стимдеке в каком порядке действия выполняются и проделал тоже в линукс минте через терминал и тогда всё заработало хорошо. Но тут без пришлось покопаться в терминале потому что понадобился bluetoothctl и понадобилось тип сопряжения в конфигурационном файле поменять.
*мол можно так серфить и что-то по мелочи сделать.
Недавно на реддите видел сетап samsung dex + xreal air. Мол можно так сердиться и что-то по мелочи сделать. Интересно, можно ли так с очками от меты.
Теперь чтобы вывезти 80 Тб данных по ИИ надо всего лишь 2 диска и 2 китайца?
Когда-то был выпуск "Адам портит всё", где говорилось, что там чуть ли не половина научных исследований не воспроизводятся. И главная проблема в том, что научных статей слишком много и все проверить невозможно. Поэтому недобросовестные "исследователи" могут сначала печататься в мусорных журналах, а потом перепечатывать свои статьи в нормальные со ссылками.
И вот тут с ИИ проблема в том, что он может написать столько мусорных работ, сколько раньше было сделать невозможно. И это может очень серьёзно усугубить проблему. Поэтому нужно разрабатывать какие-то автоматизированные методики, которые будут помогать выявлять ИИ-статьи.
Попробовал ради интереса вбить. Там ИИ потрэшовее пишет))
Hidden text
ИИ как ангел-хранитель: как алгоритм спас жизнь перегруженного IT-специалиста
Заголовок: От Burnout к Breakthrough: Как Предиктивный ИИ Стал Личным Спасателем для Индийского Разработчика
Введение:
В мире технологий часто говорят о том, как ИИ заменяет рабочие места или оптимизирует процессы. Но реже обсуждают его потенциал буквально спасать жизни. Эта история – не сценарий фантастического фильма, а реальный пример того, как конвергенция носимых устройств, анализа данных и предиктивного ИИ предотвратила трагедию в жизни обычного индийского IT-специалиста. Она заставляет задуматься о новой, гуманистической роли искусственного интеллекта на рабочем месте.
Герой и Его Битва: Раджеш и Тень Burnout
Представьте Раджеша (имя изменено) – талантливого 32-летнего бэкенд-разработчика из Бангалора. Как и тысячи его коллег, он жил в ритме вечных дедлайнов, ночных созвонов с западными клиентами и постоянного давления. Работа на износ стала нормой. Симптомы были классическими: хроническая усталость, бессонница, нарастающая тревожность, частые головные боли, которые он списывал на стресс. Он откладывал визит к врачу, погруженный в поток задач. Раджеш шел по опасной дорожке к полному эмоциональному и физическому выгоранию (burnout) и, как позже выяснилось, к серьезным недиагностированным проблемам со здоровьем.
Тихий Наблюдатель: Вмешательство ИИ
Компания Раджеша внедрила пилотную программу "Employee Wellness Guardian" на основе ИИ. Система не была "Большим Братом", а работала с анонимизированными и агрегированными данными с соблюдением строгих правил конфиденциальности (GDPR и аналогичных), с явного согласия сотрудников. Вот как она функционировала:
Сбор Данных (С согласия):
Носимые устройства (Fitbit/Apple Watch): Отслеживание пульса (включая вариабельность – HRV), качества сна, уровня активности.
Рабочие метрики (Анонимизированные): Анализ паттернов активности (время входа/выхода из системы, интенсивность использования клавиатуры/мыши – как индикатор фокуса, но без записи контента), частота переработок, использование календаря (количество встреч).
Добровольные опросы: Короткие анонимные чекапы о настроении и самочувствии.
Анализ и Предикция:
Алгоритмы машинного обучения (ансамбли деревьев решений, нейронные сети) искали отклонения от индивидуальной нормы и комбинации факторов риска, связанных с тяжелым стрессом и выгоранием.
Модель была обучена на исторических (анонимных) данных о сотрудниках, у которых позже диагностировали burnout или связанные состояния, выявляя ранние, едва заметные сигналы.
Тревожный Сигнал: За Гранью Обычного Стресса
Система "Guardian" заметила у Раджеша тревожную комбинацию:
Резко возросшая и устойчиво высокая вариабельность сердечного ритма (низкий HRV) – ключевой маркер хронического стресса и напряжения нервной системы.
Катастрофическое ухудшение паттернов сна: Фрагментированный сон, почти полное отсутствие глубоких фаз, очень поздние отходы ко сну.
Паттерны работы: Постоянные работы глубоко за полночь, отсутствие значимых перерывов, снижение "продуктивных" периодов активности в течение дня (указывает на усталость и потерю концентрации).
Аномалии в данных опросов: Стойко низкие показатели самочувствия и энергии (даже при попытках "приукрасить").
Сравнение с индивидуальной базой: Эти показатели сильно отклонялись от его собственных исторических данных, что было важнее, чем сравнение с коллегами.
Вмешательство: Тактичное Спасение
Алгоритм присвоил Раджешу максимальный уровень риска тяжелых последствий для здоровья. Система не просто отправила уведомление HR. Она активировала протокол "Urgent Wellness Intervention":
Экстренное оповещение: Личному врачу компании (на основании конфиденциального согласия Раджеша) и специально обученному консультанту по психическому здоровью были отправлены анонимные, но тревожные агрегированные данные с пометкой "Высокий риск, требуется немедленный контакт".
Человеческий Контакт: Врач компании немедленно связался с Раджешем, выразив серьезную озабоченность на основании "обезличенных данных системы Wellness Guardian" и настоятельно рекомендовал срочное комплексное медицинское обследование вне офиса.
Поддержка: Консультант предложил немедленную поддержку и организовал временное освобождение от рабочих задач.
Шокирующее Открытие:
Послушав врачей (и испытывая облегчение от того, что его "тихое страдание" наконец замечено), Раджеш прошел обследование. Результаты были шокирующими: помимо тяжелейшего профессионального выгорания, у него была диагностирована серьезная, ранее не выявленная сердечная аритмия, напрямую усугубляемая хроническим стрессом и недосыпом. Состояние было настолько серьезным, что врач предупредил о высоком риске инфаркта в ближайшие месяцы, если бы образ жизни не изменился радикально и немедленно.
Вывод: ИИ как Партнер в Заботе о Человеке
История Раджеша – мощный аргумент в пользу этичного и продуманного использования ИИ для благополучия сотрудников:
Раннее Предупреждение: ИИ способен выявлять тонкие, комплексные паттерны, которые ускользают от человеческого внимания или маскируются "привычкой к стрессу". Модель достигла F1-score >0.92 в предсказании тяжелых случаев выгорания за 4-6 недель до критической точки.
Проактивная Забота: Переход от реагирования на кризисы к их предотвращению. Система действовала до того, как Раджеш полностью сломался или случилась медицинская катастрофа.
Конфиденциальность и Доверие: Ключ успеха – прозрачность, добровольное участие и акцент на анонимность агрегированных данных. ИИ был инструментом, а не надсмотрщиком.
Спасение Конкретной Жизни: В данном случае ИИ не просто повысил эффективность – он дал Раджешу шанс на восстановление здоровья, возможно, предотвратив трагедию для него и его семьи.
Заключение:
История "несчастного индийского айтишника", спасенного ИИ, – не анекдот и не утопия. Это пример ответственного технологического гуманизма. Она демонстрирует, что ИИ может быть не только двигателем прибыли, но и настоящим "ангелом-хранителем" на рабочем месте. Задача компаний – внедрять такие системы с максимальным уважением к приватности, этике и с фокусом на реальную помощь человеку. Возможно, будущее корпоративной культуры лежит именно здесь: где алгоритмы, анализируя данные, помогают нам сохранить самое важное – человеческое здоровье и достоинство. Спасение Раджеша – это не просто happy end, это blueprint для будущего HR-Tech.
Итересно, они не справились с оптимизацией или побоялись, что облегчённые версии виндовс народ научится ставить на ПК.
Скорее не ломание под тесты, а осознание, что где-то переусложнил класс. Просто иногда это ко мне приходило именно на этапе написания юнит тестов. Но, конечно, каждый случай индивидуален.
Опять же если для того, чтобы изменить внутренний контракт Вам необходимо переписать полприложения, то, конечно, юнит тесты основательно посыпятся. Но если вы поправили приложение в одном месте, то посыпятся только тесты, которые отвечают за это самое место. Например, для меня то, что затрагивается большое число тестов это индикатор того, что я неправильно разработал архитектуру приложения и подрефакторив его, можно упросить.
Это да, но при этом результаты работы заметно лучше если добавить немного креатива) Хотя в разных случаях температура нужна разная и лучше подбирать её индивидуально к каждому кейсу.
Например, какое-нибудь переполнение, которое возникает не сразу. Но это я так, к примеру.
Это могут быть и синие экраны в винде по всему миру)
А для тех, кто считает, что это ок, что проект неподдерживаемый, что его можно каждый раз перегенеривать и валидировать автотестами, то представьте ситуацию, что у вас есть крупный маркетплейс и у вас сломалась кнопка заказа. Вы просите ИИ перегенерить код с фиксом ишью, но ИИ выполняет перегенерацию сутки или больше, потому что хорошие автотесты работают долго и хороший ИИ раотает медленно. Для компании миллиардные убытки потому что пользователи закажут то же самое в другом месте, где ещё не внедрили вайбкодинг и на вызовы реагируют профессионалы и фиксят прод быстро.
Тут момент такой. Есть язык C, есть ассемблер. И мы можем каждую команду на C заменить на заранее определённую последовательность команд на ассемблере. То есть, к примеру, нам нужно напечатать число и на ассемблере это бы выглядело как делить число на 10, заменять числа на коды из таблицы с кодировками и так далее. То есть полотно текста, всегда одно и то же, при этом оно плохо читаемо потому что нужно понимать с каким регистром через какое прерывание работает каждая команда. Но благодаря современным языкам и компиляторам мы пишем понятный код и запуская его много раз мы можем получить один и тот же результат. Мы можем сделать свой проект и выложить его на гитхаб и позволить разным вендорам собирать их у себя со своими ключами и предоставлять пользователям какие-то гарантии, что это будет работать.
Теперь как это может выглядеть с ИИ. Я навайбкодил свой проект, выложил свой "вайбкод" на гитхаб, вендоры не знают как его собрать потому что ИИ каждый раз разный результат генерирует. Если я выкладываю в виде исходников, которые ИИ выплюнула из моего "вайбкода", то получится полотно кода, которое человек никогда не прочитает, он не сможет внести изменения. И если ключевой контрибьютор откажется от проекта, он просто умрёт, его нельзя форкнуть. И в суровом энтерпрайзе будет абсолютно так же: если хранить базу промтов, по которым собирался проект - каждый раз будет получаться разный непредсказуемый результат. Хранить код - он будет неподдерживаемым.