Получить люлей можно и за меньшее; однако деплой (тесты, коммит, сборка, развёртывание) почти никогда не делается за минуту, даже когда за минуту и можно успеть исправить код. На практике на исправление даже 1 буквы в опечатке нужно закладывать ~полчаса - и это если тесты не запускать.
, без спецификации языка, стандарта, библиотек и фреймворков, и сразу с кучей некомпетентных в разработке носителей (пусть "стажёров"). Интересная ситуация.
И вот насколько будет детальным изначальный запрос настолько качественный получится результат.
Но как определить, когда достаточно деталей? Даже с искусственными ЯП, с чёткими спецификациями, описания часто недостаточно для всех нюансов.
Возможно, проблемы не в архитектуре, а в том, что решили нанять консультанта, чтобы... заменить архитектора?
Консультант (хоть ИИ, хоть не ИИ), не имея полного контекста, может выдать для общего случая правильное решение. Однако при попытке его реализовать будут всплывать нюансы, вплоть до невозможности требуемого исправления. И не консультант будет отвечать)
Я видел подобный случай. В компании разработали некий механизм "карт", довольно похожий на то, что есть в других подобных системах, и заказчики успешно использовали его уже несколько лет. Однако был нюанс - движок поддерживал "карты" без ограничения размера, и поэтому при создании в принципе не требовалось указывать границы "карты", этот этап полностью отсутствовал. В отличие от подобных систем, которые разрабатывались на 15-25 лет раньше, когда компьютеры были намного слабее, и были вынуждены иметь это ограничение как неотъемлемое свойство "карты" и обязательный этап при создании "карты". "Важный" консультант (который, кстати, не был разработчиком таких систем) ругался, удивлялся отсутствию "необходимого" (нет) этапа и сначала даже требовал добавить искусственное ограничение. Но в отчёт это уже не пошло.
Не утверждаю, что консультант всегда неправ. Но он может ошибаться, не имея полного контекста.
В корпорации (или просто в крупной системе) любая задача занимает минимум пару часов: открыть тикет, перевести в "выполняется", сделать работу, все перезапустить, протестировать, (повторить при необходимости несколько раз), перевести тикет в "выполнено".
Кроме точности резисторов, те АВМ имели точность вывода порядка 1% - что рассмотришь на осцилографе или вольтметре. Мягко говоря, не слишком точно.
А по поводу аналоговых вычислений в чипах памяти - уж очень соблазнительно вынести вычисления ближе к месту хранения. Думаю, всё к этому идёт. И не все последние модели имеют триллионы параметров - тот же qwen3.8 запускался на 30 млрд.
Почти то же самое. При записи по индексу в другой массив данные будут повреждены, а при чтении из другого массива - прочитается то, что читать не следует. Почти как с указателями, только они могут сбоить при доступе к неаллоцированной памяти, а индексы - при доступе за пределы другого массива.
Не было "первого человека", нет такой единственной мутации, которая переключает вид из Homo Erectus в Homo Sapiens. Новый вид появляется плавно, и начало выделить невозможно. Ну если только не считать от Адама и Евы.
Кроме этого, невозможно достоверно определить последовательность рождения людей, т.к. где-то могут быть незарегистрированные случаи. К тому же, рождение не фиксируется с точностью до секунды, чтобы можно было достоверно ранжировать людей по времени.
В итоге в этой вашей "последовательности" нет ни начала, ни следующего элемента.
Я немного исказил гипотезу (предположил противоположное - это выделено жирным), чтобы убрать «ваш» оптимизм, и загнал весь промпт в perplexity:
Технологии распространяются из центра на периферию с задержкой; люди медленно осваивают новое; следовательно, техническая сфера будет сжиматься, а не расширяться, и спрос на программистов, наладчиков, безопасников — падать.
Результат такой:
Вывод по гипотезе
Гипотеза частично подтверждается, но в целом не подтверждается.
<…>
Более точная формулировка, согласованная с данными: техническая сфера не сжимается, а перестраивается: рутинные роли сокращаются, комплексные и безопасностно-интеграционные — расширяются.
Разница в том, что в ответе вам сокращается возможность входа, а в ответе мне - рутинные задачи (сходство есть). А в целом ваша гипотеза похожа на правду, даже если убрать некоторый оптимизм в запросе.
Бывают и длинные удлинители (трамвай, троллейбус, электрифицированные ж/д), и ёмкие аккумуляторы (но только последние лет 10). Всеобщая зависимость от бензина - результат выбора этой альтернативы лет 120 назад. Были и другие варианты - спирт, электричество.
Переписать только половину приложения, получив 2 полуработающих приложения? Нет.
Вероятно, более правильно было бы использовать паттерн миграции "strangler fig": новое приложение проксирует запросы к старому, постепенно заменяя его функции. Это классика для микросервисов, сгодится для CLI, но вот для GUI это труднореализуемо.
Соглашусь с большинством тезисом, но поспорю здесь:
Размер рынка сбыта ПО ограничен
Ограничение есть в каждой конкретной отрасли, особенно в автоматизации (хотя можно повторно внедрять "улучшенную" автоматизацию), но большие известные продукты сами создавали свои отрасли и новые потребности. Хотя объём рынка ограничен в каждый момент времени, этот (общий) рынок периодически скачкообразно расширяется, прирастая новыми "территориями".
Обычно разрабатываются менее ответственные системы, и тратить ресурсы на обеспечение их полной безопасности - излишне.
Получить люлей можно и за меньшее; однако деплой (тесты, коммит, сборка, развёртывание) почти никогда не делается за минуту, даже когда за минуту и можно успеть исправить код. На практике на исправление даже 1 буквы в опечатке нужно закладывать ~полчаса - и это если тесты не запускать.
Далее будет "нейросети не умеют в аналитику", "нейросети не умеют учитывать эмоции пользователя", "нейросети не несут ответственности", ...
, без спецификации языка, стандарта, библиотек и фреймворков, и сразу с кучей некомпетентных в разработке носителей (пусть "стажёров"). Интересная ситуация.
Но как определить, когда достаточно деталей? Даже с искусственными ЯП, с чёткими спецификациями, описания часто недостаточно для всех нюансов.
Насколько помню, на ESP32 были интерпретаторы python и lua. И прошивку для них можно залить хоть через wifi.
Upd. Не сразу заметил абзац про мотивацию использования ebpf.
Даже с использованием LLM пока ещё бывает необходим рефакторинг, чтобы код не превращался в месиво. Возможно, в будущем это поменяется.
Подсказка: LLM тоже умеют рефакторить.
И решение о рефакторинге пока ещё принимается человеком. Если он, конечно, знает о рефакторинге и видит необходимость.
Возможно, проблемы не в архитектуре, а в том, что решили нанять консультанта, чтобы... заменить архитектора?
Консультант (хоть ИИ, хоть не ИИ), не имея полного контекста, может выдать для общего случая правильное решение. Однако при попытке его реализовать будут всплывать нюансы, вплоть до невозможности требуемого исправления. И не консультант будет отвечать)
Я видел подобный случай. В компании разработали некий механизм "карт", довольно похожий на то, что есть в других подобных системах, и заказчики успешно использовали его уже несколько лет. Однако был нюанс - движок поддерживал "карты" без ограничения размера, и поэтому при создании в принципе не требовалось указывать границы "карты", этот этап полностью отсутствовал. В отличие от подобных систем, которые разрабатывались на 15-25 лет раньше, когда компьютеры были намного слабее, и были вынуждены иметь это ограничение как неотъемлемое свойство "карты" и обязательный этап при создании "карты". "Важный" консультант (который, кстати, не был разработчиком таких систем) ругался, удивлялся отсутствию "необходимого" (нет) этапа и сначала даже требовал добавить искусственное ограничение. Но в отчёт это уже не пошло.
Не утверждаю, что консультант всегда неправ. Но он может ошибаться, не имея полного контекста.
В корпорации (или просто в крупной системе) любая задача занимает минимум пару часов: открыть тикет, перевести в "выполняется", сделать работу, все перезапустить, протестировать, (повторить при необходимости несколько раз), перевести тикет в "выполнено".
Кроме точности резисторов, те АВМ имели точность вывода порядка 1% - что рассмотришь на осцилографе или вольтметре. Мягко говоря, не слишком точно.
А по поводу аналоговых вычислений в чипах памяти - уж очень соблазнительно вынести вычисления ближе к месту хранения. Думаю, всё к этому идёт. И не все последние модели имеют триллионы параметров - тот же qwen3.8 запускался на 30 млрд.
Эти не так. SSD уже несколько лет могут выдавать 10-15 ГБ/с.
Почти то же самое. При записи по индексу в другой массив данные будут повреждены, а при чтении из другого массива - прочитается то, что читать не следует. Почти как с указателями, только они могут сбоить при доступе к неаллоцированной памяти, а индексы - при доступе за пределы другого массива.
Эээ... Нет.
Не было "первого человека", нет такой единственной мутации, которая переключает вид из Homo Erectus в Homo Sapiens. Новый вид появляется плавно, и начало выделить невозможно. Ну если только не считать от Адама и Евы.
Кроме этого, невозможно достоверно определить последовательность рождения людей, т.к. где-то могут быть незарегистрированные случаи. К тому же, рождение не фиксируется с точностью до секунды, чтобы можно было достоверно ранжировать людей по времени.
В итоге в этой вашей "последовательности" нет ни начала, ни следующего элемента.
Я немного исказил гипотезу (предположил противоположное - это выделено жирным), чтобы убрать «ваш» оптимизм, и загнал весь промпт в perplexity:
Результат такой:
Разница в том, что в ответе вам сокращается возможность входа, а в ответе мне - рутинные задачи (сходство есть). А в целом ваша гипотеза похожа на правду, даже если убрать некоторый оптимизм в запросе.
(думает 15 секунд...) 15150 .
А сколько платите?Бывают и длинные удлинители (трамвай, троллейбус, электрифицированные ж/д), и ёмкие аккумуляторы (но только последние лет 10). Всеобщая зависимость от бензина - результат выбора этой альтернативы лет 120 назад. Были и другие варианты - спирт, электричество.
Свет - свекла - сахар - спирт.
Однако не нужно забывать, что бензин используется в основном для передвижения, а двигатели бывают и электрические.
Переписать только половину приложения, получив 2 полуработающих приложения? Нет.
Вероятно, более правильно было бы использовать паттерн миграции "strangler fig": новое приложение проксирует запросы к старому, постепенно заменяя его функции. Это классика для микросервисов, сгодится для CLI, но вот для GUI это труднореализуемо.
Особенно хорошо переписывать на раст с питона)
Это пока нет ИИ в отделе продаж и в отделе закупок.
Соглашусь с большинством тезисом, но поспорю здесь:
Ограничение есть в каждой конкретной отрасли, особенно в автоматизации (хотя можно повторно внедрять "улучшенную" автоматизацию), но большие известные продукты сами создавали свои отрасли и новые потребности. Хотя объём рынка ограничен в каждый момент времени, этот (общий) рынок периодически скачкообразно расширяется, прирастая новыми "территориями".