Трансерфинг реальности в it конторе

Дорогие друзья! Вот и я сделал свой SAAS с помощью AI. https://b2b.some-programator.ru/

Простите за долгие перерывы. Но, который раз пытаюсь восставать из пепла.
https://telegra.ph/Yagni-10-03.

А вдохновил меня на это замечательный товарищ, с которым очень давно знакомы. В частности его пост https://t.me/llmfolks/196. Он очень хорошо следит за технологиями и показывал chatgpt в декабре 2022 года, примерно сразу после того как он вышел.

Недавно обзавелся телефоном с esim. Очень крутая штука. Особенно для стран где либо сложно/дорого купить симку сразу по приезду. Кидаю рефералочку.

TJUEVLEC


https://trykolet.app.link/app-referral

Конфликт зависимостей наглядно

ИИ был нужен для того, чтобы этот паблик ожил

Для демонстрации приведу пример потери детерминированности, который произошел со мной в одном проекте. У меня есть query builder(что-то, вроде doctrine query builder), для гибкости и поддержания проекта мне периодически приходится переводить sql запросы, которые я ручками создал, в формат query builder. Я написал промпт вроде "Смотри вот документация, прочитай ее, мне нужно, чтобы ты переводить sql формат в эту вещь". Если бы я писал программу на типичных ЯП, мне бы пришлось писать анализатор sql запросов(или взять готовый), и на основании выходных от анализатора генерировать новую структуру. В лучшем случае это заняло бы несколько часов, но при этом результат был бы однозначным, я бы точно получал запрос query builder. Тут я за 5 минут накатал промпт(который по сути является программой транслятором), который в целом работает неплохо, но сначала он не совсем ту документацию прочитал, потом посчитал что метод в одной библиотеке не реализован(а он был реализован), пришлось явно его все указывать, просить обновлять контекст и тд. И сейчас я не уверен что он будет однозначно работать. Но для моих задач этого достаточно. Вопрос в том, что когда вы делайте что-то похожее с финтех транзакциями, и пишите промпт "У меня есть json с платежной транзакцией переложи мне его в postgresql" я бы таким пользоваться не стал, не стал бы рисковать(и не только в финтехе, а мало-мальском продакшене)

По итогу, есть возможность того, что бизнес это скушает и будет кушать дальше. А соотвественно программы и программирование, могут деградировать, а решения на естественных языках будут продаваться лучше, что будет влиять в том числе на производительность(как, например, популяризация electron).
Как я вижу рекламируется именно это применение. Рекламируется то, что программисты вам будут не нужны(Иначе говоря создадут, транслятор YN, который, способен однозначно перевести текст, в точную
исполняемую программу), рекламируется что это УЖЕ происходит(Лично я получил генератор неплохого кода, который помогает справляться с рутиной, с которой мне очень скучно справляться, я не вижу приложения, которое уже делает. Если такое изобрели, посоветуйте, кучу пет-проектов висит). При этом факт такой, что я пока не встретил человека(в том числе крупных компаниях), который использует нейронки для полноценного вайбкодинга(только в статьях, без подтверждений такое вижу). В реальности слышу больше истории про побочные эффекты именно такого подхода. При этом слышу истории людей, которые очень грамотно их используют для написания большей части кода, где они задают кучу контекста и постепенно правят за нейронкой неудачные места. И я в том числе так делаю, не сказать что полноценно это делаю но мне действительно она сокращает время, а где-то наоборот удлиняет.

Я призываю разумно использовать преимущество и недостатки нейронок и делать упор на то, чтобы сокращать рутину, а не вайбкодить.

При этом каждый язык в данном случае что-то теряет. При переходе от с++ в php мы теряем явные механизмы освобождения/выделения памяти, в замен на то что язык становится проще. Также в python/php отсутсвует необходимость(хоть и пытаются
это частично решить type hint) следить за несоответствием типов на этапе запуска(ошибка будет только тогда, когда будет проблемное место). В отличие от более строгих языков go/c++/java если типы данных не соответствуют, то мы все равно можем запустить эту программу. Иначе говоря при переходе к более простым языкам, мы что-то теряем. Контроль над типами, контроль над памятью и тд. Делается в первую очередь для того, чтобы уменьшить время разработки фичей для бизнеса(так называемый time to market). Именно поэтому чаще всего в проектах малого, среднего, да и крупного бизнеса мы часто сталкиваемся с php/python/javascript/go, так как на нем меньше time to market. При том что с точки зрения хорошей архитектуры и упора на долгосрочные проекты, могут быть решения гораздо лучше, но вы видим именно их. Это не совсем общее правило. Но суть в том, что бизнесу нужны проекты, которые работали вчера. И практика показывает, что приложения, которые работают, пусть с багами, даже критическими, работают и приносят пользу. Поддержание и развитие таких проектов может сопровождаться проблемами, но это работает. (Также есть хорошие практики, как писать
такие приложения и эту боль уменьшить + знания об архитектуре, паттернах, технологиях написания хорошего кода, очень спасает в таких ситуациях). С точки зрения технического специалиста, хочется взяться за голову видя то, что происходит, но моя практика показывает такую тенденцию.

И если мы говорим о естественном языке программирования, мы говорим о языке, который теряет контроль над детерминированностью. Возьмем cursor/claude code, представим что их модернизировали настолько, что вайбкодинг будет плюс минус на этом возможен(во что я не верю). То есть иначе говоря, я загоняю километры текста с описанием, например, телеграмм бота, который умеет делать фичи и на выходе получаем бинарник, ставим его на сервер и он работает как я хочу(+/- хотя бы) без необходимости лезть в исходный код(но код, который напишет claude будет основан на каком-то языке программирования, иначе говоря на языке Y(N-1) уровня, если YN - наш естественный язык).

Дело в том, что даже если это будет работать +/- верно, если я запущу эту же программу второй раз, мы получим совершенно другой код. И переходе из YN-1 в YN, мы на этот раз теряем детерминированность. Иначе говоря транслятор будет всегда генерировать разный код под капотом, что может привести к плачевным последствиям(я не сильно уточнял что происходило, но краем уха слышал про утечки данных, случайное удаление проекта в том числе с git репозитория и прочие приколы. Я также сталкивался в работе с claude с глюками. Например, claude code вместо того, чтобы править тесты, правил код и подгонял его под тесты, когда увидел что тест не проходит. Я прикалываюсь, что его точно обучали люди, потому что такое только человек умеет). Программы делают ровно то, что им говорят, и она не считается с тем, что ожидает человек. При этом, трансляция из языка yN -> y0(с промежуточными шагами yN->yN-1 и тд), скрывает очень много деталей и программисту на языке yN, не знакомым с языком YN-1(что абсолютно нормально) визуально кажется, что происходит магия. И если традиционные языки программирования хотя бы обладают детерминированностью(иначе говоря работают по строго определенным законам, которые можно отследить), то естественные языки программирования такой особенностью обладать не будут(с технической точки зрения они обладают, но под капотом у нейронок используются вероятности и прочая история, которая каждый раз будет разной, а соответственно и результаты будет разные).

Поделюсь своими размышлениями по поводу того, что естественный язык благодаря ИИшкам станет полноценным языком языком программирования. С одной стороны есть основания так считать, ибо когда я пишу контекст к cursor/claude code, я говорю "делай так, а так не делай", "Если то, иначе это" и прочие хаки, которые ретранслируются из естественного языка в токены для анализа, и соответственно исполняются в программе-анализаторе ИИ(в нашем случае агент встроенный в вашу ide и который под капотом делает доп запросы в AI модель, либо в вашу локальную если вы подняли какой-нибудь llama). Этому даже посвященные целые области. Такие как context/prompt engineering и многие другие области. Если рассматривать мое отношение, несмотря на то что claude/cursor и многие другие неплохо генерирует код, и действительно помогают в разработке, говорить о естественных языках программирования либо далеко. Либо это будет
с оговорками и не похоже на то, что под этим подразумевают(Это конечно, тоже интересно. Я в данном случае подразумеваю, что на входе у нас будет спека, а на выходе полностью рабочее приложение).

И если рассматривать на что это может быть похоже. В книге(да и уверен и не только там), очень хорошо демонстрируется как появляются новые языки программирования https://www.litres.ru/book/endru-tanenbaum/arhitektura-komputera-66738078/.

Есть язык программирования "уровня" Y0(в книге не совсем так, но суть примерная такая), программу на котором понимает исходный компьютер(в нашем случае машинный код). Он составлен ровно так, как требует этого исходная машина. Он будет больным для восприятия и хорош ровно настолько, насколько хорошо инженеры могут совладать с законами физики и будет запускаться напрямую. Далее пишется язык уровня Y1, который будет более человеческим. И для него будет либо написана программа на языке Y0, которая будет принимать на вход текст программы Y1, переводить его в Y0(грубо говоря транслятор), а затем исполнятся на машине y0, либо будет написана программа на языке Y0, которая будет исполнять программы на языке Y1(грубо говоря интерпретатор). И это утверждение верно для N уровней. Иначе говоря современные языки программирования это надстройки, над предыдущими. Если лет 30 назад, с/с++ считался языком высокого уровня(Y2), то сейчас пишуется много языков, для которых написаны интерпретаторы(чаще чем трансляторы) на языке с++(Например, php, python, nodejs). И как правило чем больше N в языке YN, тем дружелюбнее язык(но не обязательно. Это соблюдается на низких уровнях, особенно на Y0, так как сложно инжерно построить, например, java машину, которая на аппаратном уровне исполняет java код. При этом на высоких уровнях может быть построен более заморочный язык, просто потому что так решил создатель. Пример brainfuck)

Читая посты про ИИ, на тему того что скоро будем программировать на естественных языках вместо традиционных ЯП. Жду пост через годик-полтора. "Эх ИИшка не всегда четко понимает что я хочу. Вот бы был какой-то способ сказать точно что мне надо от программы"

ЗСД - это api gateway

Меня раздражало очень много AI-мусора в интернете. И увидел видео этого человека, который спокойно рассказал как работает вайб-кодинг https://www.youtube.com/watch?v=eXp8TC0Sm6o&lc=Ugy2KHB2eRegbpM8UUJ4AaABAg и то что это не "волшебная палочка", при этом реально крутой инструмент упрощающий работу. (Лично я юзаю claude code, но у cursor есть бесплатные лимиты, чтобы пощупать)

На ютубе наткнулся на видео про vim и по какой-то причине я его решил посмотреть, хотя давно уже оставил идею сделать универсальную ide на нем(шутка про то что emacs все таки меня одолел, но нет). И вот рекомендовали предустановленные настройки для neovim(какой-то популярный проект, не чувак с ютуба конфиг в описании оставил). Открываю, а там это. А я всегда знал что это заговор

P.S. Если бы мне сказали, что я должен програмировать в консоли, я бы однозначно выбрал vim. Более того иногда его использую, чтобы на сервере править, хотя сейчас прихожу к тому что vscode по ssh настроить. Не всегда, но так делаю

У меня были бы подозрения на индусов, но это было в другой ИИ + уж очень быстро он все генерирует

- Фронтенд, сделанный «из г и палок», он поправил очень хорошо внешне(но с точки зрения css и js очень не очень)
- Все текстовые строки автоматически вынесены в локализацию (раньше я мучился с этим целый день).
- Я попросил выделить раздел для отображения markdown — и он сгенерировал неплохой шаблон для будущего контента.
- Сложные существующие задачи он не брался решать. Т.к. при попытке сделать, у меня не получилось заставить его вникнуть в контекст проекта. (Например, если вы не используете модели Laravel или применяете их через репозитории, он создаст отдельный метод, использующий шаблонный код с моделями Laravel, что затрудняет внесение изменений в готовый проект. Скорее всего, причина в том, что его так обучили).

Итог: Я доволен новой ИИ от Jetbrains. Но если говорить глобально, я считаю, что речь лишь о смене подхода к разработке, а не о скорой замене программистов или массовом сокращении штата. Даже про замену «Крудошлепония» говорить рано. Чтобы код был качественным и поддерживаемым, всё равно нужна квалификация; ИИ разве что ускоряет поиск решений и гугление. Утверждение же, что появление ИИ уменьшит требования к знаниям и навыкам разработчика, коренным образом неверно. Хотя не исключаю сценария, когда код настолько деградирует, что ИИ-поделки станут нормой. Подобно электрону, который внедряется в desktop приложения, потому что с помощью него запилить быстрее и проше.

Это относится к прикладному веб-программированию и «перекладыванию JSON-ов». В более ответственных областях ситуация, думаю, ещё серьёзнее и там в целом будут интересные истории вроде не соотвствие тому что делает ИИ агент с документации и это будет очень критично(аппаратное программирование и ТП).

Моё мнение не изменилось: спасибо, коллегам, которые написали этот полезный инструмент, который поможет в работе, но и наделять его функциями, которые он не делает/делает не так хорошо как заявляется не хочу.

Я с большой неохотой погрузился в тему программирования с помощью генеративного ИИ. Само по себе это направление меня не смущало, но утомляло то, как его пиарят. Стоило ChatGPT научиться по текстовому описанию выдавать что-то похожее на рабочий код, как СМИ дружно стали трубить: «ИИ уже скоро заменит программистов». Это казалось странным, ведь код, который тогда генерировал ИИ, был далёк от ожидаемого результата и даже не всегда был рабочим(причем могла быть просто опечатка). Было видно, что он годится разве что для автоматической «копипастилки», за которой нужно убирать ошибочный мусор.

ИИ неплохо генерировал обычные тексты и он исполнил мою мечту превращая письма из «Вы что совсем там ох...» в «Добрый день, коллеги! …».
В сети я часто натыкался на заголовки: «С помощью ChatGPT я автоматизировал свой бизнес», «С помощью ИИ я написал проект по текстовому описанию». До недавнего времени я не мог ни подтвердить, ни опровергнуть эти заявления. Коллеги и ученики присылали мне статьи о некоем «ИИ, который уже умеет писать код», но проекты оказывались либо скаком, либо обёрткой над ChatGPT, выдающей код посредственного качества.

С восторгом ребёнка мне показали Cursor. Я попробовал и действительно увидел нечто намного лучшее из того, что пробовал раньше. Но чтобы получить что-то близкое к адекватному коду, мне всё равно приходилось тщательно контролировать процесс и тратить много времени на пояснения контекста.

Не могу сказать, что я провёл часы за официальными руководствами, но мне так и не встретилось много людей, которые могли бы внятно объяснить, что конкретно они делали с помощью Cursor.

Мне удалось развернуть Laravel-проект: автоматически сгенерировались миграции и модели. Когда дело дошло до бизнес-логики и алгоритмов, требующих сложной логики (например, запись к врачу с учётом фильтров), — остались лишь комментарии "// TODO". Уверен, что при более чётких инструкциях ИИ справился бы лучше, но подробностей требовалось много. Полученный код был неподдерживаемым, хотя я описывал, каким хочу его видеть. Возможно, есть специалисты, которые смогли бы ставить запросы лучше, но я не располагаю историей переписки, чтобы это показать.
После такого опыта я перестал активно пользоваться Cursor и вернулся к генерации шаблонного кода и автоматизации поиска решений в Google — это уже проверенный и надёжный инструмент.

Недавно я решил дать шанс Junie от JetBrains, который меня впечатлил на презентации. Опыт оказался гораздо более удачным.

В новом проекте я пошагово описывал задачи:
- У меня есть такие-то сущности с такими-то полями — сделай миграции и сиды.
- Создай сервис (Service layer), который будет обращаться к репозиторию, дергающему модели, и возвращать DTO.

Результат:

- По моим ощущениям, за гораздо меньшее число запросов я получил код, близкий к желаемому.
- Были места, где генерация шла «в полный трэш» — например, при создании enum он использовал устаревшие обёртки над классами (возможно, это особенность JetBrains: у меня по-дефолту выставлена пятая версия PHP, хотя некоторые фишки с 7+ (типизированные свойства) доступны).
- Ошибки фиксились одним-двумя уточняющими запросами, но код всё равно требовал рефакторинга, что, честно говоря, меня впечатлило.

Однако для реального проекта он всё ещё далёк от идеала: создаётся ощущение, что задачу решают «самым костыльным способом». На серьёзном ревью такой код не прошёл бы.
+Все же я достаточно подробно описывал что хочу.

В готовом проекте:

https://t.me/skillbox_media_code/2251 - ждем второй том мертвых душ с началом "40 лет и зим словно под морфием, за 3 сотки ассигнаций, я вывозил нечистоты"

Просто жизнь, когда доверил проект джуну: Он его нормально сделал, сдали, заказчик доволен.