Цифровая трансформация

Фронтир ИИ Недавно натолкнулся на статью о том, что вышел Grok 4.6, который при Extra High настройках Reasoning’а обходится дешевле, чем Fable 5 Max, Opus 5 Max и GPT-5.6 Sol Max. После беглого прочтения этой статьи у меня появилось стойкое ощущение дежавю. В конце 90-х годов прошлого столетия существовало неимоверно огромное количество компиляторов. Домашние задания мы делали с помощью самых стандартных Borland С++ и/или Turbo С++. Но если надо было сделать что-то более серьёзное, то мы использовали совершенно другие компиляторы. Например, в Paragon Software, где я работал системным программистом, было установлено, что всё компилируется только с помощью Watcom C/C++, потому что он создаёт быстрый код. А курсовую по машинной графике мы компилировали исключительно с помощью djgpp (кто-нибудь помнит этот компилятор?), поскольку сам Джон Кармак выбрал этот компилятор для своего Quake за возможность работы с protected mode через DPMI. Про всякие Cygnus/Cygwin, Mingw32 и прочие EGCS’ы я лучше помолчу. Прошло около 30 лет. Большая часть компаний, выпускавших компиляторы, либо разорились, либо были поглощены. Сейчас у нас есть набор устоявшихся компиляторов (gcc, clang, msvc), которые, в основном, выбираются не за их супер-оптимизированный код, а за возможность создание программы для той или иной операционной системы. Так и сейчас я наблюдаю, как различные тестеры сравнивают насколько быстрее, дешевле, глубже, чётче, развёрнутее и т.д. (можно ещё 100500 критериев придумать) одна модель превосходит другую в зависимости от размера, количества параметров, настроек ризонинга, контекстного окна, качества претрена и инференса и т.п. И даже если разобраться во всём этом «по гамбургскому счёту», то завтра выйдет новая модель, и всё снова изменится. Мой подход прост: набор моих задач не требует наличия какого-то супер-пупер уникального свойства, которое есть только у определённой модели со специфическими параметрами. Если честно, в слепом тестировании я не отличу код, выдаваемый Luna Medium, от кода, сгенерированного Sol Extra High. Аналогично, я не отличал экзешники, скомпилированные ваткомом, от экзешников, собранных с использованием djgpp. Поэтому я пользуюсь тем, что есть под рукой и что решает мои задачи. Гнаться за самым-пресамым ризонингом – смысла не вижу. Главное сейчас – не оказаться на обочине прогресса, игнорируя ИИ полностью. Но и пытаться быть на острие, как это модно сейчас называть, фронтира – не стоит, если, конечно, вы не профессиональный разработчик ИИ-моделей. С учётом скорости изменений лет через пять всё устаканится, и останется 3-4 модели, каждая из которых будет решать свой класс задач. P.S. Для тех, кому слова Watcom и Quake – не пустой набор символов, вот ссылка на атмосферный пост про программирование и игры в конце 90-х. #AI #DigitalTransformation #LifeLongLearning Ссылка на оригинал поста: shorin.me/...ier

Первый пошёл! В конце прошлого года я посетил ежегодное закрытое облачное мероприятие Группы Астра. Напомню, что меня туда пригласил Виктор Коноплёв – мой соклубник по сообществу ИТ-управленцев «я-ИТ-ы». Пообщавшись с Виктором, мы много интересного узнали друг о друге. Оказалось, что Виктор ведёт подкаст, посвящённый, как бы странно это ни звучало, информационным технологиям и людям, которые эти самые информационные технологии создают и развивают. Виктор пригласил меня принять участие в записи одного из выпусков. Я согласился, поскольку мне было интересно, что же это за зверь такой – подкаст. Раньше я только в записи интервью участвовал, о чём я в своё время уже писал. Как говорится, не прошло и года, как мы всё-таки записали этот подкаст (см. фото). Надеюсь, что первый мой подкаст не выйдет комом. С Виктором мы пообщались на следующие темы: - Мой карьерный трек; - Специфика цифровизации таких консервативных учреждений, как библиотеки; - Нюансы применения авторского права в России; - Особенности функционирования ФГИС «Национальная электронная библиотека»; - Цифровая трансформация автопрокатного рынка в нашей стране. Теперь осталось лишь немного подождать, пока будут сделаны монтаж, транскрибация, вычитка субтитров и прочие необходимые действия. Только после этого запись подкаста появится везде и всюду. Что ж, ждём! А чтобы ждать было не так грустно, предлагаю посмотреть записи моих интервью, которые я давал телеканалу «Про Бизнес»: - В передаче «IT-трансформация» в 2014 году: olegshorin.com/...ion - В передаче «ИТ-Директор» в 2016 году: olegshorin.com/...tor #DigitalTransformation #Networking #Shorin Ссылка на оригинал поста: shorin.me/...out

CodeBab.ai – помощник для код-ревью На прошлой неделе в клубе «Цифровые лидеры бизнеса» прошла интереснейшая лекция от коллег из компании Friflex. Напомню, Friflex – это компания, в которой мы часто собираемся на так называемые «офисники». Лекция была посвящена проблеме код-ревью. Дело в том, что раньше код писался разработчиками вручную, а потом валидировался более опытным тимлидом (см. фото №1). Теперь же код генерируется в огромаднейших масштабах с помощью ИИ, а валидировать весь этот вал продолжает человек. И именно этот человек становится узким горлышком в системе поставке кода (см. фото №2). Генеральный директор Friflex Пётр Чернышев и его коллега Юрий Петров, который является руководителем агентной и кроссплатформенной разработки, рассказали нам о сервисе CodeBab.ai, который был ими разработан внутри компании. Суть этого сервиса заключается в том, что это глобальный оркестратор различных агентов, ставящийся поверх gitlab, который перед тем, как передать merge request тимлиду, проверяет его с помощью специальных промтов на соответствие различным правилам. В итоге тимлиду попадает на проверку только тот код, который уже прошёл предварительную «проверку на вшивость». Решение вполне рабочее, оно справляется с поставленной задачей. Но я считаю, что оно не является идеальным, так как с использованием CodeBab.ai качество кода повышается, но количество запросов на слияние хоть и уменьшается, но не сильно – то есть не устраняется первоначальная причина задержек при code review. А значит, при дальнейшем росте количества разработчиков, надо будет опять что-то придумывать. Как мне кажется, произошёл существенный слом в парадигме программирования, из-за этого привычный механизм ветвления кода стал давать сбои. И мы пытаемся придумать какое-то стороннее решение, позволяющее прежнему механизму хоть как-то функционировать. Я думаю, что изящное решение должно каким-то образом поменять саму логику ветвления кода с последующими merge request’ами. Мне почему-то сразу вспомнилась история про замену ручного труда станками. И последующее гениальное решение Форда по созданию конвейера. Немного поразмышляв, я понял, что в данном случае аналогия не применима, потому что конвейер Форда заточен на последовательные действия. А разработка ПО – параллельный процесс, осуществляемый множеством разработчиков, и терять этот параллелизм ради адаптации под конвейерное решение – глупо. В общем, пока что я ничего гениального не придумал, но задачка эта засела у меня в мозгу, и я к ней периодически мысленно возвращаюсь. Как-нибудь на досуге почитаю научные исследования на эту тему, потому что мне, как выпускнику кафедры Системного программирования ВМК МГУ, интересно следить за эволюционным развитием языков программирования в целом, и за прогрессом в области командной разработки в частности. #AI #Algorithm #Management Ссылка на оригинал поста: shorin.me/...-ai