1980-е
Первым по-настоящему «народным» персональным компьютером стал IBM Model 5150, более известный как IBM PC (1981). А первой стандартной операционной системой стал Microsoft Disk Operating System (MS-DOS). В 1984 году Apple представил первый Macintosh — компьютер для массового пользователя с графическим интерфейсом и набором программ.
IBM PC создал массовый рынок разработки: всего за год после его выхода были опубликованы 750 программ — колоссальные цифры для того времени. ПК был маломощным в сравнении с типовым мейнфреймом, но стоял в каждом доме и офисе и служил для учёбы, работы и отдыха. Именно в тот момент родилась индустрия ПО, которую мы знаем.
IBM-совместимые персональные компьютеры стали универсальной платформой, а архитектура x86 — основной для процессоров на многие годы вперёд. Первый 32-разрядный процессор 80386 (i386) был представлен в 1985 году, и заложенные в него принципы без кардинальных изменений дошли до наших дней.
Первым по-настоящему «народным» персональным компьютером стал IBM Model 5150, более известный как IBM PC (1981). А первой стандартной операционной системой стал Microsoft Disk Operating System (MS-DOS). В 1984 году Apple представил первый Macintosh — компьютер для массового пользователя с графическим интерфейсом и набором программ.
IBM PC создал массовый рынок разработки: всего за год после его выхода были опубликованы 750 программ — колоссальные цифры для того времени. ПК был маломощным в сравнении с типовым мейнфреймом, но стоял в каждом доме и офисе и служил для учёбы, работы и отдыха. Именно в тот момент родилась индустрия ПО, которую мы знаем.
IBM-совместимые персональные компьютеры стали универсальной платформой, а архитектура x86 — основной для процессоров на многие годы вперёд. Первый 32-разрядный процессор 80386 (i386) был представлен в 1985 году, и заложенные в него принципы без кардинальных изменений дошли до наших дней.
1990-е
Главным прорывом 1990-х годов стало массовое распространение интернета, а вместе с ним — новых подходов, новых языков программирования, новых классов программ (веб-браузеры, клиенты электронной почты и систем обмена мгновенными сообщениями). Появилась клиент-серверная архитектура, которая унаследовала идею мейнфрейма, но добавила в неё гибкость.
На конец 1990-х годов пришёлся бум доткомов — период завышенных ожиданий, одержимости новой технологией. Именно с бумом доткомов скептики часто сравнивают хайп вокруг ИИ. Одним из символов того времени стал офисный стул Aeron от Herman Miller — популярный среди множества стартаперов, которые привлекли на волне хайпа инвестиции, но понятия не имели, как заработать в интернете (и потому прогорали).
Профессии в ИТ становились всё более массовыми, и популярность приобретали стандартные для современного человека инструменты и подходы — IDE, системы контроля версий и так далее. В те же годы были созданы ныне базовые языки разработки, такие как HTML, JS или PHP.
Главным прорывом 1990-х годов стало массовое распространение интернета, а вместе с ним — новых подходов, новых языков программирования, новых классов программ (веб-браузеры, клиенты электронной почты и систем обмена мгновенными сообщениями). Появилась клиент-серверная архитектура, которая унаследовала идею мейнфрейма, но добавила в неё гибкость.
На конец 1990-х годов пришёлся бум доткомов — период завышенных ожиданий, одержимости новой технологией. Именно с бумом доткомов скептики часто сравнивают хайп вокруг ИИ. Одним из символов того времени стал офисный стул Aeron от Herman Miller — популярный среди множества стартаперов, которые привлекли на волне хайпа инвестиции, но понятия не имели, как заработать в интернете (и потому прогорали).
Профессии в ИТ становились всё более массовыми, и популярность приобретали стандартные для современного человека инструменты и подходы — IDE, системы контроля версий и так далее. В те же годы были созданы ныне базовые языки разработки, такие как HTML, JS или PHP.
Ревущие 2000-е
На 2000-е годы пришлась целая череда связанных изменений.
Важнейшей идеей начала 2000-х годов, которая в корне изменила подход к разработке ПО стал Agile. Базовые принципы, которые в 2001 году опубликовали в своём манифесте 17 адвокатов гибких методологий (Extreme Programming, Scrum, Crystal, Adaptive Software Development) сейчас считаются «базой», а тогда звучали по меньшей мере вызывающе.
Исторически основной моделью разработки была «водопадная» (waterfall), которая предполагала чёткое планирование, документирование и последовательную разработку, тестирование и деплой программ. Метод работал, но если вводные требования были расплывчатыми или менялись, разработка могла превратиться в катастрофу, а итоговый продукт — устареть на момент выхода. Agile, завязанный на короткие итерации, обратную связь и тестирование отвечал запросу рынка.
Гибкие методологии заслуженно казались многим шаманскими практиками и годились далеко не для любого проекта. Критики справедливо указывали на недостатки — отсутствие нормальной документации и понятных рабочих инструкций, отсутствие фокуса, странные ритуалы и названия ролей. Однако принципы Agile изменили подход к разработке, сделав нас всех чуть более гибкими.
Ответом на растущий спрос на вычислительные мощности, быстрое масштабирование и оплату по факту стали облачные решения. Модели IaaS (инфраструктура как услуга) и PaaS (платформа как услуга) стали базой для SaaS (программное обеспечение как услуга) — революционной для своего времени модели дистрибуции ПО.
На пару десятилетий идея обладания собственными серверами вышла из моды (её ренессанс в последние годы связан, скорее, с выросшей стоимостью облачного хранения и вычислений). На базе облаков выросли десятки новых специальностей в ИТ.
Совокупность новых технологий расширила возможности разработчиков и сблизила направления создания ПО (Dev) и ИТ-операций (Ops), которые ранее были зонами ответственности разных отделов. DevOps вырос из идей гибких методологий, которые применили к управлению.
Ключевыми свойствами нового подхода стали циклы сборки и тестирования (Continuous integration, CI), автоматизация деплоя(Continuous delivery, CD), автоматизация управления инфраструктурой (Infrastructure as Code, IaC) и постоянный мониторинг производительности, поиск ошибок, сбор обратной связи для совершенствования продукта.
На протяжении большей части истории, архитектура ПО была монолитной. Программы были едиными артефактами, которые включали все компоненты — интерфейс, логику, слои данных. Обычно использовался один язык программирования, а весь код хранился в одном репозитории. Это было удобно для небольших проектов, но делало разработку больших сложных продуктов чрезвычайно медленной.
Микросервисная архитектура предполагала разделение функций между отдельными сервисами, связанными через API. Она позволила создавать более гибкие и легко масштабируемые проекты и дала большой толчок развитию инфраструктурных решений с открытым исходным кодом.
Первые смартфоны стали феноменом, сравнимым по масштабу с персональным компьютером. В 2007 году Apple выпустила первый iPhone, а год спустя Google представил платформу Android. К ним прилагались SDK, которые упрощали разработку, и магазины приложений, предлагавшие новую модель дистрибуции ПО. Смартфоны запустили волну mobile-first стартапов, создали спрос на кроссплатформенность, дали начало новым языкам программирования, заточенными именно под мобильную разработку.
Вслед за потешными приложениями, такими как iBeer (iBeer - Drink from your phone App - App Store), на мобильные устройства пришли (почти) полновесные офисные пакеты и другое рабочее ПО. К смартфонам добавились планшеты, умные часы, AR-очки и другие гаджеты с специфическими функциями. Всё это повышало спрос на специалистов, освоивших новые платформы и компоненты.
На 2000-е годы пришлась целая череда связанных изменений.
Гибкие методологии
Важнейшей идеей начала 2000-х годов, которая в корне изменила подход к разработке ПО стал Agile. Базовые принципы, которые в 2001 году опубликовали в своём манифесте 17 адвокатов гибких методологий (Extreme Programming, Scrum, Crystal, Adaptive Software Development) сейчас считаются «базой», а тогда звучали по меньшей мере вызывающе.
Исторически основной моделью разработки была «водопадная» (waterfall), которая предполагала чёткое планирование, документирование и последовательную разработку, тестирование и деплой программ. Метод работал, но если вводные требования были расплывчатыми или менялись, разработка могла превратиться в катастрофу, а итоговый продукт — устареть на момент выхода. Agile, завязанный на короткие итерации, обратную связь и тестирование отвечал запросу рынка.
Гибкие методологии заслуженно казались многим шаманскими практиками и годились далеко не для любого проекта. Критики справедливо указывали на недостатки — отсутствие нормальной документации и понятных рабочих инструкций, отсутствие фокуса, странные ритуалы и названия ролей. Однако принципы Agile изменили подход к разработке, сделав нас всех чуть более гибкими.
Облачные вычисления
Ответом на растущий спрос на вычислительные мощности, быстрое масштабирование и оплату по факту стали облачные решения. Модели IaaS (инфраструктура как услуга) и PaaS (платформа как услуга) стали базой для SaaS (программное обеспечение как услуга) — революционной для своего времени модели дистрибуции ПО.
На пару десятилетий идея обладания собственными серверами вышла из моды (её ренессанс в последние годы связан, скорее, с выросшей стоимостью облачного хранения и вычислений). На базе облаков выросли десятки новых специальностей в ИТ.
DevOps
Совокупность новых технологий расширила возможности разработчиков и сблизила направления создания ПО (Dev) и ИТ-операций (Ops), которые ранее были зонами ответственности разных отделов. DevOps вырос из идей гибких методологий, которые применили к управлению.
Ключевыми свойствами нового подхода стали циклы сборки и тестирования (Continuous integration, CI), автоматизация деплоя(Continuous delivery, CD), автоматизация управления инфраструктурой (Infrastructure as Code, IaC) и постоянный мониторинг производительности, поиск ошибок, сбор обратной связи для совершенствования продукта.
Микросервисы
На протяжении большей части истории, архитектура ПО была монолитной. Программы были едиными артефактами, которые включали все компоненты — интерфейс, логику, слои данных. Обычно использовался один язык программирования, а весь код хранился в одном репозитории. Это было удобно для небольших проектов, но делало разработку больших сложных продуктов чрезвычайно медленной.
Микросервисная архитектура предполагала разделение функций между отдельными сервисами, связанными через API. Она позволила создавать более гибкие и легко масштабируемые проекты и дала большой толчок развитию инфраструктурных решений с открытым исходным кодом.
There is an app for that
Первые смартфоны стали феноменом, сравнимым по масштабу с персональным компьютером. В 2007 году Apple выпустила первый iPhone, а год спустя Google представил платформу Android. К ним прилагались SDK, которые упрощали разработку, и магазины приложений, предлагавшие новую модель дистрибуции ПО. Смартфоны запустили волну mobile-first стартапов, создали спрос на кроссплатформенность, дали начало новым языкам программирования, заточенными именно под мобильную разработку.
Вслед за потешными приложениями, такими как iBeer (iBeer - Drink from your phone App - App Store), на мобильные устройства пришли (почти) полновесные офисные пакеты и другое рабочее ПО. К смартфонам добавились планшеты, умные часы, AR-очки и другие гаджеты с специфическими функциями. Всё это повышало спрос на специалистов, освоивших новые платформы и компоненты.
2010-е годы — затишье перед бурей
Контейнеризация
Как и «Фортран»(автору которого было влом писать код на языке ассемблера) , контейнеризация явно родилась из человеческой лени. Контейнеризация кратно упрощает дистрибуцию и деплой — в комплекте с приложением поставляется инструкция по автоматической сборке, все настройки и зависимости. Золотым стандартом в этой области стал Docker (2013).
Для адаптации контейнеров к микросервисной архитектуре были созданы оркестраторы, которые автоматизировали мелкие задачи для развёртывания приложений в кластерах. Самая база здесь — Kubernetes, код которого Google открыл в 2014 году.
Данные всё больше и больше
В эпоху интерактивного «веб 2.0» и масштабирования в облаках начался взрывной рост количества данных, которые мы производим. Для работы с этими данными понадобились новые подходы и новые специальности — дата-инженеры с уклоном в программирование и дата-аналитики, которые больше занимаются изучением и интерпретацией данных.
Контейнеризация
Как и «Фортран»
Для адаптации контейнеров к микросервисной архитектуре были созданы оркестраторы, которые автоматизировали мелкие задачи для развёртывания приложений в кластерах. Самая база здесь — Kubernetes, код которого Google открыл в 2014 году.
Данные всё больше и больше
В эпоху интерактивного «веб 2.0» и масштабирования в облаках начался взрывной рост количества данных, которые мы производим. Для работы с этими данными понадобились новые подходы и новые специальности — дата-инженеры с уклоном в программирование и дата-аналитики, которые больше занимаются изучением и интерпретацией данных.
В контексте рекламных платформ или маркетплейсов обработка больших данных буквально превращала их в золото, а специалистов по ним — в ценный актив.
И, наконец, ИИ
Исследования в области искусственных нейронных сетей — ровесники компьютера. Но знаковый прорыв в их практическом применении пришёлся на 2010-е, а затем в конце десятилетия на основе наработок по нейросетям были созданы современные модели искусственного интеллекта. Впервые в истории человек получил возможность напрямую взаимодействовать с прорывной технологией.
Все знаковые сдвиги в сфере разработки встречали с сомнениями и скепсисом. Высокоуровневые языки давали недостаточно чистый код. Персональный компьютер был игрушкой, неспособной на сложные вычисления. Гибкие методологии предлагали перевернуть разработку с ног на голову и заменить нормальное планирование встречами с мастером и работой с бэклогом. Хранить данные на чужом компьютере в каком-то «облаке» — что может быть менее безопасно? И так далее.
Но технологии двигались вперёд, и каждый раз появлялись новые профессии, специальности и рабочие места. Вчерашние ноу-хау становились стандартами в отрасли. А те, кто предпочитал работать по-старинке оставались на своём месте — занимались legacy-кодом. Страх того, что новая технология лишит разработчиков работы всегда оказывался напрасным. Да, современные модели могут ценой колоссального расхода ресурсов писать вразумительный код, но у технологии есть потолок — и он близок (вопреки обещаниям маркетологов).
Промпт-кодинг также укладывается в тренд на повышение уровня абстракции в программировании. Первые разработчики писали машинный код. В 1950-х появились первые высокоуровневые языки, которые сделали программирование более доступным. В 1990-х — специализированные языки для нишевых задач в вебе. В 2010-х выстрелили low-code и no-code подходы, при которых пользователь уже не писал код, а собирал программу в конструкторе. И в конце этого пути находится вайбкодинг — создание программы с использованием естественного языка.
Исследования в области искусственных нейронных сетей — ровесники компьютера. Но знаковый прорыв в их практическом применении пришёлся на 2010-е, а затем в конце десятилетия на основе наработок по нейросетям были созданы современные модели искусственного интеллекта. Впервые в истории человек получил возможность напрямую взаимодействовать с прорывной технологией.
Но настолько ли отличается хайп вокруг ИИ от прошлых сдвигов в сфере разработки?
Все знаковые сдвиги в сфере разработки встречали с сомнениями и скепсисом. Высокоуровневые языки давали недостаточно чистый код. Персональный компьютер был игрушкой, неспособной на сложные вычисления. Гибкие методологии предлагали перевернуть разработку с ног на голову и заменить нормальное планирование встречами с мастером и работой с бэклогом. Хранить данные на чужом компьютере в каком-то «облаке» — что может быть менее безопасно? И так далее.
Но технологии двигались вперёд, и каждый раз появлялись новые профессии, специальности и рабочие места. Вчерашние ноу-хау становились стандартами в отрасли. А те, кто предпочитал работать по-старинке оставались на своём месте — занимались legacy-кодом. Страх того, что новая технология лишит разработчиков работы всегда оказывался напрасным. Да, современные модели могут ценой колоссального расхода ресурсов писать вразумительный код, но у технологии есть потолок — и он близок (вопреки обещаниям маркетологов).
Промпт-кодинг также укладывается в тренд на повышение уровня абстракции в программировании. Первые разработчики писали машинный код. В 1950-х появились первые высокоуровневые языки, которые сделали программирование более доступным. В 1990-х — специализированные языки для нишевых задач в вебе. В 2010-х выстрелили low-code и no-code подходы, при которых пользователь уже не писал код, а собирал программу в конструкторе. И в конце этого пути находится вайбкодинг — создание программы с использованием естественного языка.
Главное, что изменили ИИ-инструменты — они сделали программирование доступным для любого. И это очень здорово.
Мы каждый день работаем над небольшими улучшениями, чтобы сделать Deploy-F лучше для пользователей. Если прошлые релизы касались, в первую очередь, фронта и бэка, то этот выпуск — о quality of life-улучшениях.
Раздел Templates (Шаблоны) — это заготовки кода для быстрого старта. Пока что там варианты ботов для разных мессенджеров, веб-серверы и приложения, а также базовые PHP и HTML-страницы. Они помогают преодолеть страх белого листа и экономят время.
Ready Bots (Готовые боты) — набор востребованных ботов, которых можно развернуть за несколько кликов. Они уже предварительно настроены, остаётся добавить ваши данные и запустить. Мы собрали варианты по результатам опроса пользователей: бот-магазин, расшифровщик аудиозаписей, ассистент для поиска по базе знаний, линия поддержки — и так далее.
Теперь Deploy-f не только помогает забыть о трудоёмком деплое, но и позволяет вовсе отключить голову (в хорошем смысле слова). Когда попробуете, напишите нам о своём опыте с шаблонами и готовыми ботами сюда или на ceo@deploy-f.com — если вам всё понравилось или если что-то работает не лучшим образом.
💙💙💙
Раздел Templates (Шаблоны) — это заготовки кода для быстрого старта. Пока что там варианты ботов для разных мессенджеров, веб-серверы и приложения, а также базовые PHP и HTML-страницы. Они помогают преодолеть страх белого листа и экономят время.
Ready Bots (Готовые боты) — набор востребованных ботов, которых можно развернуть за несколько кликов. Они уже предварительно настроены, остаётся добавить ваши данные и запустить. Мы собрали варианты по результатам опроса пользователей: бот-магазин, расшифровщик аудиозаписей, ассистент для поиска по базе знаний, линия поддержки — и так далее.
Теперь Deploy-f не только помогает забыть о трудоёмком деплое, но и позволяет вовсе отключить голову (в хорошем смысле слова). Когда попробуете, напишите нам о своём опыте с шаблонами и готовыми ботами сюда или на ceo@deploy-f.com — если вам всё понравилось или если что-то работает не лучшим образом.
💙💙💙
Telegram
Deploy-f Поддержка
Тех. поддержка deploy-f.com. Рабочие часы: ПН-ПТ 12:00-18:00 по МСК
Deploy as f**k pinned «Мы каждый день работаем над небольшими улучшениями, чтобы сделать Deploy-F лучше для пользователей. Если прошлые релизы касались, в первую очередь, фронта и бэка, то этот выпуск — о quality of life-улучшениях. Раздел Templates (Шаблоны) — это заготовки кода…»
Карго-культ ИИ-стартапа
В сообществе ИИ-энтузиастов часто встречается легенда об ИИ-единороге — стартапе на миллиард, за которым стоит один человек с командой ИИ-агентов. Человек предполагает (выступает визионером), а ИИ располагает и берёт на себя операционные задачи и всю предпринимательскую рутину. Сегодня мы разберёмся, насколько эта история далека от действительности — и почему современные инструменты хороши и безо всех этих сказок.
Это обман, чтобы набрать баксы !!1!
Возможно, важнейшая роль в популяризации идеи стартапа-единорога из одного человека принадлежит главе OpenAI Сэму Альтману, и это должно навести на определённые мысли. Альтман — главный в мире продавец ИИ-сервисов и инфраструктуры, который техногикам каждый год обещает общий искусственный интеллект (AGI), чувствительных пугает идеей восстания машин, а венчурных капиталистов соблазняет ИИ-единорогами.
Справедливости ради, за идеей единорога из одного человека стоит не только желание заработать, но и культура солопренёрства. У нас на глазах выросло поколение ИТ-предпринимателей-генералистов, которые способны запускать проекты малыми силами и могут взять на себя разные скопы задач и справиться благодаря сильным гибким навыкам, адаптивности и умению учиться.
В неестественной среде обитания
Потенциал идеи нужно проверять на практике. Писатель и журналист Эван Рэтлифф в материале для WIRED рассказал о своём эксперименте — стартапе, все роли в котором играют ИИ-агенты. Для этого Рэтклифф «нанял» пять сотрудников от компании, которая обещает заменять людей ИИ, и дополнил каждого сгенерированным голосом и аватаром.
С одной стороны, эта команда мечты за три месяца действительно разработала прототип приложения, спродюсировала подкаст, справлялась с исследованиями по открытым источникам и мозговыми штурмами под руководством человека. Агенты в целом хорошо показали себя в несложных задачах с чёткими вводными, прописанным процессом и ясным результатом.
Но были и фундаментальные проблемы, происходящие из самого дизайна современных ИИ. Агенты галлюцинировали, фальсифицировали данные (например, о пользовательских тестах или улучшениях), а затем верили в собственную выдумку, сохраняли её в память и начинали считать истиной и исходить в работе из ложных предпосылок.
ИИ-агенты игнорировали триггеры, не проявляли инициативу, не использовали навыки и ждали прямого указания. Но когда их начинало нести, они могли сжечь все доступные кредиты на ерунду.
В сообществе ИИ-энтузиастов часто встречается легенда об ИИ-единороге — стартапе на миллиард, за которым стоит один человек с командой ИИ-агентов. Человек предполагает (выступает визионером), а ИИ располагает и берёт на себя операционные задачи и всю предпринимательскую рутину. Сегодня мы разберёмся, насколько эта история далека от действительности — и почему современные инструменты хороши и безо всех этих сказок.
Это обман, чтобы набрать баксы !!1!
Возможно, важнейшая роль в популяризации идеи стартапа-единорога из одного человека принадлежит главе OpenAI Сэму Альтману, и это должно навести на определённые мысли. Альтман — главный в мире продавец ИИ-сервисов и инфраструктуры, который техногикам каждый год обещает общий искусственный интеллект (AGI), чувствительных пугает идеей восстания машин, а венчурных капиталистов соблазняет ИИ-единорогами.
Справедливости ради, за идеей единорога из одного человека стоит не только желание заработать, но и культура солопренёрства. У нас на глазах выросло поколение ИТ-предпринимателей-генералистов, которые способны запускать проекты малыми силами и могут взять на себя разные скопы задач и справиться благодаря сильным гибким навыкам, адаптивности и умению учиться.
Именно для таких людей мы и создаём Deploy-f. Мы не обещаем, что ваш стартап точно взлетит, но можем обеспечить надёжную инфраструктуру, простой деплой и поддержку в работе.
В неестественной среде обитания
Потенциал идеи нужно проверять на практике. Писатель и журналист Эван Рэтлифф в материале для WIRED рассказал о своём эксперименте — стартапе, все роли в котором играют ИИ-агенты. Для этого Рэтклифф «нанял» пять сотрудников от компании, которая обещает заменять людей ИИ, и дополнил каждого сгенерированным голосом и аватаром.
С одной стороны, эта команда мечты за три месяца действительно разработала прототип приложения, спродюсировала подкаст, справлялась с исследованиями по открытым источникам и мозговыми штурмами под руководством человека. Агенты в целом хорошо показали себя в несложных задачах с чёткими вводными, прописанным процессом и ясным результатом.
Но были и фундаментальные проблемы, происходящие из самого дизайна современных ИИ. Агенты галлюцинировали, фальсифицировали данные (например, о пользовательских тестах или улучшениях), а затем верили в собственную выдумку, сохраняли её в память и начинали считать истиной и исходить в работе из ложных предпосылок.
ИИ-агенты игнорировали триггеры, не проявляли инициативу, не использовали навыки и ждали прямого указания. Но когда их начинало нести, они могли сжечь все доступные кредиты на ерунду.
Проблемы, которые так просто не решить
Понятно, что судить о технологии по одному журналистскому материалу не следует. Но статья подсвечивают важную особенность ИИ-помощников. При их использовании нужно дробить реальные сложные задачи на простые, с понятными инструкциями и ожидаемым результатом. Результаты нужно проверять, инструкции — корректировать.
Склонность к ошибкам и отсутствие инициативы (если триггер не срабатывает) делают агентов недостаточно автономными. Для их надёжной работы нужен колоссальный объём менеджмента и микроменеджмента — больше, чем для людей. Они также лишены бытовой интуиции — не чувствуют, когда нужно остановиться, а когда — эскалировать.
Наша команда активно использует различные ИИ-инструменты — и помощников в кодинге, и автономных агентов для ограниченного числа рутинных задач. И казалось бы можно сослаться на собственный опыт: «мол, у нас всё работает». Но частный случай — это не статистика. В нашем профессиональном кругу есть и те, кто не получил ожидаемого выхлопа от внедрения ИИ — или вообще не нашёл ему места в своём рабочем процессе.
Зато в компаниях появились новые роли по контролю, координации и проверке работы ИИ. Но если специалист, который перешёл на роль управленца или супервайзера всё ещё имеет прочные знания и сильные навыки, ждать их от промпт-инженера или менеджера не стоит. Да и не все проблемы можно решить промптом.
А если вспоминать человеческий подход, то люди придумали две модели управления. Вертикальную — чтобы строго изолировать зоны ответственности и обеспечить контроль исполнения. И горизонтальную, которая поощряет гибкость и инициативу. У ИИ проблема и с тем, и с другим.
Понятно, что судить о технологии по одному журналистскому материалу не следует. Но статья подсвечивают важную особенность ИИ-помощников. При их использовании нужно дробить реальные сложные задачи на простые, с понятными инструкциями и ожидаемым результатом. Результаты нужно проверять, инструкции — корректировать.
Склонность к ошибкам и отсутствие инициативы (если триггер не срабатывает) делают агентов недостаточно автономными. Для их надёжной работы нужен колоссальный объём менеджмента и микроменеджмента — больше, чем для людей. Они также лишены бытовой интуиции — не чувствуют, когда нужно остановиться, а когда — эскалировать.
Сейчас часто встречается идея использовать агентов для управления агентами (которые управляют агентами), но это звучит как лечение подобного подобным.
Наша команда активно использует различные ИИ-инструменты — и помощников в кодинге, и автономных агентов для ограниченного числа рутинных задач. И казалось бы можно сослаться на собственный опыт: «мол, у нас всё работает». Но частный случай — это не статистика. В нашем профессиональном кругу есть и те, кто не получил ожидаемого выхлопа от внедрения ИИ — или вообще не нашёл ему места в своём рабочем процессе.
Зато в компаниях появились новые роли по контролю, координации и проверке работы ИИ. Но если специалист, который перешёл на роль управленца или супервайзера всё ещё имеет прочные знания и сильные навыки, ждать их от промпт-инженера или менеджера не стоит. Да и не все проблемы можно решить промптом.
А если вспоминать человеческий подход, то люди придумали две модели управления. Вертикальную — чтобы строго изолировать зоны ответственности и обеспечить контроль исполнения. И горизонтальную, которая поощряет гибкость и инициативу. У ИИ проблема и с тем, и с другим.
Кого всё-таки может заменить ИИ-агент?
Часто сторонники ИИ-автоматизации предполагают, что заменить можно кого угодно, но не их самих. Опытные программисты хорошо понимают, как сложно построить надёжный ИИ-ассистированный пайплайн для реального проекта, но верят в способность агентов заменить техподдержку, юристов, проджектов или маркетинг.
Не-кодеры тоже делают бизнес, но часто переоценивают свои компетенции и умение ИИ писать хороший код. По первым порам их истории расходятся по твиттеру и блогам, но после стартап находит в бутылочное горлышко — инфраструктуру, безопасность, финансы и комплаенс.
• Разработчиков? Да, ИИ может помочь в написании кода, и ему можно доверить некоторые аспекты DevOps. Но стоит быть осторожным: совсем недавно мы писали про связанные с ИИ риски в этой области, и мы не верим, что пока что ему можно доверить критическую инфраструктуру.
ИИ начал лучше справляться с поиском багов, но даже современные модели часто пишут уязвимый код и создают новые векторы атаки. Переложить на ИИ разработку не выйдет.
• A computer can never be held accountable, therefore a computer must never make a management decision, гласит мантра из руководства IBM 1979 года.
Вы не доверите ИИ юридическую службу, финансы, комплаенс и операции — сферы, предполагающие наличие компетентного ответственного лица.
• Может быть, ИИ может заменить техподдержку? Казалось бы, большинство тикетов можно закрыть ссылкой на инструкцию. Но кейсы Klarna и других компаний, которые были вынуждены свернуть дорогостоящие проекты перевода поддержки на ИИ-рельсы и вновь нанять старую команду, показывают — всё не так просто. В числе проблем ИИ-поддержки неспособность ответить по существу, галлюцинации, ложные обещания клиентам и просто отсутствие эмпатии.
• Даже направления типа маркетинга, дизайна или контента, которые напрямую не «генерируют кэщ» плохо поддаются ИИ-автоматизации. ИИ-тексты или картинки режут глаз и не вызывают эмоций. Ещё недавно в тренде были «фабрики контента» с обещаниями автоматизации производства текстов и видео, но платформы очень быстро научились их выявлять и пессимизировать в выдаче.
Список можно продолжать долго, но ситуация не изменится — пока что ИИ не заменит человека в критически важных для бизнеса процессов.
А ещё он, конечно же, не может заменить талантливых основателей и руководителей с развитым бизнес-чутьём, которые находят нетривиальные решения, умеют достучаться до клиента и не бросают дело на полпути (а ещё аккуратно ведут себя с кредитами, факт) .
Часто сторонники ИИ-автоматизации предполагают, что заменить можно кого угодно, но не их самих. Опытные программисты хорошо понимают, как сложно построить надёжный ИИ-ассистированный пайплайн для реального проекта, но верят в способность агентов заменить техподдержку, юристов, проджектов или маркетинг.
Не-кодеры тоже делают бизнес, но часто переоценивают свои компетенции и умение ИИ писать хороший код. По первым порам их истории расходятся по твиттеру и блогам, но после стартап находит в бутылочное горлышко — инфраструктуру, безопасность, финансы и комплаенс.
Давайте порассуждаем, кого в действительности может заменить ИИ.
• Разработчиков? Да, ИИ может помочь в написании кода, и ему можно доверить некоторые аспекты DevOps. Но стоит быть осторожным: совсем недавно мы писали про связанные с ИИ риски в этой области, и мы не верим, что пока что ему можно доверить критическую инфраструктуру.
ИИ начал лучше справляться с поиском багов, но даже современные модели часто пишут уязвимый код и создают новые векторы атаки. Переложить на ИИ разработку не выйдет.
• A computer can never be held accountable, therefore a computer must never make a management decision, гласит мантра из руководства IBM 1979 года.
Вы не доверите ИИ юридическую службу, финансы, комплаенс и операции — сферы, предполагающие наличие компетентного ответственного лица.
• Может быть, ИИ может заменить техподдержку? Казалось бы, большинство тикетов можно закрыть ссылкой на инструкцию. Но кейсы Klarna и других компаний, которые были вынуждены свернуть дорогостоящие проекты перевода поддержки на ИИ-рельсы и вновь нанять старую команду, показывают — всё не так просто. В числе проблем ИИ-поддержки неспособность ответить по существу, галлюцинации, ложные обещания клиентам и просто отсутствие эмпатии.
• Даже направления типа маркетинга, дизайна или контента, которые напрямую не «генерируют кэщ» плохо поддаются ИИ-автоматизации. ИИ-тексты или картинки режут глаз и не вызывают эмоций. Ещё недавно в тренде были «фабрики контента» с обещаниями автоматизации производства текстов и видео, но платформы очень быстро научились их выявлять и пессимизировать в выдаче.
Список можно продолжать долго, но ситуация не изменится — пока что ИИ не заменит человека в критически важных для бизнеса процессов.
А ещё он, конечно же, не может заменить талантливых основателей и руководителей с развитым бизнес-чутьём, которые находят нетривиальные решения, умеют достучаться до клиента и не бросают дело на полпути
Lab Space
Vibe Coding’s Security Debt: The AI-Generated CVE Surge
Key Takeaways Empirical research across Fortune 50 enterprises found that AI-assisted developers produce commits at three to four times the rate of their peers but introduce security findings at 10…
Друзья!
У нас временные проблемы с сетью
Ваши приложения работают и доступны, но панель управления временно не открывается
Если вам нужно что-то сделать с вашим приложением, пишите в поддержку @deployf_support, поможем🫶
У нас временные проблемы с сетью
Ваши приложения работают и доступны, но панель управления временно не открывается
Если вам нужно что-то сделать с вашим приложением, пишите в поддержку @deployf_support, поможем🫶
Тема сегодняшнего поста — альтернативные фронтенды популярных сервисов. И чтобы лучше разобраться, откуда они вообще взялись, (не)большая историческая справка.
Появление альтернативных фронтендов стало ответом на агрессивный трекинг и рекламу — основу бизнеса многих интернет-платформ. Сама веб-реклама прошла долгий век — от первого баннера на WIRED в 1994 году до расцвета веб-2.0 в 2000-х, когда корпорации выстроили рекламные сети, охватывающие весь интернет, и научились составлять детальные профили пользователей.
Замечали, что иногда реклама поразительно точно следует предмету вашего недавнего разговора? Поздравляю, теперь вы знаете, насколько инвазивным может быть трекинг в интернете. Это огромная индустрия агрессивной слежки и продажи данных об интересах пользователей.
До сих пор самое популярное решение здесь — блокировщики рекламы (будь то открытый uBlock Origin или закрытый AdGuard), которые убирают рекламу и трекеры, делая веб более комфортным. Но кому-то пришла в голову безумная альтернатива — заменить весь фронтенд и подтягивать динамическое содержимое по API. Так можно было избавиться от трекеров, перегруженности и добавить фичи, которых нет в оригинале.
Был момент, когда энтузиасты собирали альтернативные фронтенды для всех популярных платформ — ютуба, твиттера, реддита, инстаграма, тиктока и т.д., и расширения для браузеров, которые перенаправляли запросы на работающий инстанс. Сообщество криптоанархистов тепло встретило эти проекты, но их звёздный час был недолгим.
Альтернативные фронтенды зависели от API крупных платформ, и значимые изменения ломали их функциональность. Некоторые сервисы скрыли API за пейволлом, другие — просто блокировали ресурсы, от которых поступало слишком много запросов. Многие проекты остановились в развитии, внимание разработчиков захватили другие темы. Но код остался, и некоторые альтернативные фронтенды прекрасно работают и сейчас — и вы можете развернуть такой у себя.
(продолжение следует)
История
Появление альтернативных фронтендов стало ответом на агрессивный трекинг и рекламу — основу бизнеса многих интернет-платформ. Сама веб-реклама прошла долгий век — от первого баннера на WIRED в 1994 году до расцвета веб-2.0 в 2000-х, когда корпорации выстроили рекламные сети, охватывающие весь интернет, и научились составлять детальные профили пользователей.
Замечали, что иногда реклама поразительно точно следует предмету вашего недавнего разговора? Поздравляю, теперь вы знаете, насколько инвазивным может быть трекинг в интернете. Это огромная индустрия агрессивной слежки и продажи данных об интересах пользователей.
До сих пор самое популярное решение здесь — блокировщики рекламы (будь то открытый uBlock Origin или закрытый AdGuard), которые убирают рекламу и трекеры, делая веб более комфортным. Но кому-то пришла в голову безумная альтернатива — заменить весь фронтенд и подтягивать динамическое содержимое по API. Так можно было избавиться от трекеров, перегруженности и добавить фичи, которых нет в оригинале.
Был момент, когда энтузиасты собирали альтернативные фронтенды для всех популярных платформ — ютуба, твиттера, реддита, инстаграма, тиктока и т.д., и расширения для браузеров, которые перенаправляли запросы на работающий инстанс. Сообщество криптоанархистов тепло встретило эти проекты, но их звёздный час был недолгим.
Альтернативные фронтенды зависели от API крупных платформ, и значимые изменения ломали их функциональность. Некоторые сервисы скрыли API за пейволлом, другие — просто блокировали ресурсы, от которых поступало слишком много запросов. Многие проекты остановились в развитии, внимание разработчиков захватили другие темы. Но код остался, и некоторые альтернативные фронтенды прекрасно работают и сейчас — и вы можете развернуть такой у себя.
Где всё это попробовать?
Ниже — подборки сервисов, которые можно повертеть в руках, попробовать, оценить. Мы не обещаем, что код в репозиториях рабочий, но иногда у проектов всё ещё есть живые инстансы.
1) подборки альтернативных фронтендов с инструкциями по установке, некоторые даже работают
2) ресурсы энтузиастов, которые хостят альтернативные фронтенды для популярных сервисов (почёт и уважение им)
Зачем вообще это нужно?
Причины всё те же.
* Здоровое любопытство.
* Доступ к материалам конкретного ресурса без принудительной регистрации.
* Отсутствие навязчивого трекинга и агрессивной рекламы (худшее, что можно себе представить — ненавязчивая просьба оставить донат на поддержку проекта).
* Экономия ресурсов и более высокая скорость работы на маломощных устройствах.
* Прозрачные политики приватности и обработки пользовательских данных.
* Открытый исходный код, который позволяет новым людям подключаться к разработке (а также делает проект в целом более безопасным).
* Возможность самостоятельного хостинга, то есть независимость от стороннего провайдера.
GitHub
GitHub - mendel5/alternative-front-ends: Overview of alternative open source front-ends for popular internet platforms (e.g. YouTube…
Overview of alternative open source front-ends for popular internet platforms (e.g. YouTube, Twitter, etc.) - mendel5/alternative-front-ends