Генерация кода с использованием современных LLM, LLM в разработке программного обеспечения.
Вопросы, на которые вас поможет ответить данная статья:
Как современные LLM помогают ускорить процесс написания кода? Как использовать LLM для генерации функций и оптимизации программных решений? Можно ли интегрировать LLM в рабочие процессы для автоматизации написания кода? Какие ограничения существуют при использовании LLM для написания кода? Какие подходы наиболее эффективны при применении LLM для создания сложных программ?
В этой статье мы займемся практикой, которая, как известно, лучший критерий истины.
Современный рынок IDE, поддерживающих LLM, полон разнообразных решений. Бесплатный Copilot, различные инструменты от Amazon (Q), «Гигакоды» от Сбера, которые можно интегрировать как плагины, и специализированные IDE, такие как Codeium, Qodo, Blackbox, Continue и Cursor, дают разработчикам много опций. Даже JetBrains предлагает свой собственный AI для интеграции в их IDE. Есть также open-source решения, такие как Aider, которые работают через консоль, генерируя описания и коммиты для каждого изменения. Хотя Aider может быть полезным, он оставляет желать лучшего из-за общей нестабильности. Replit, в свою очередь, позволяет создавать проекты целиком, но эффективность его доработки оставляет вопросы.
Лично я использую платную подписку на Cursor (20 долларов в месяц), так как чат в нем позволяет обращаться к более мощным моделям и задавать любые вопросы. В то же время, бесплатные версии ChatGPT и Copilot прекрасно справляются с мелкими задачами, что позволяет компенсировать расходы на платные планы. Если не учитывать подписку OpenAI за 200 долларов, все эти инструменты остаются относительно недорогими по сравнению с теми временем, которое они позволяют сэкономить.
Как это все выглядит?
Обычная VS Code, которая подхватывает большинство ваших плагинов и настроек. Но по Cmd+i открывается окно, в котором три вкладки — Chat, Composer, Bug finder. Как работает Bug finder, я так и не понял, потому что при открытии окна начинает бесконечно крутиться Computing changes, ну и фиг с ним.
Chat — это просто диалог с LLM, куда можно добавить в качестве контекста ваш код:
Composer — это как раз инструмент работы с кодом. У него можно выбрать модель:
В Cursor можно добавлять изображения, что полезно, если вы хотите сверстать что-то визуально (о верстке HTML поговорим позже). Также можно перетаскивать файлы, такие как примеры кода или документы — они будут попадать в контекст общения с нейросетью. Есть возможность переключаться между двумя режимами: normal и agent.
В режиме normal нейросеть предоставляет только текстовые ответы и предлагает изменения в коде. В режиме agent она становится более интерактивной: может перемещаться по файлам, искать в них нужную информацию, запускать команды в консоли (например, сборки или тесты) и возвращать результаты.
Запуск команд нуждается в подтверждении человеком, так что автоматически он rm -rf / не запустит, если вы не проглядите (это можно отключить, «enable yolo mode» в настройках).
В настройках есть вкладка Docs:
Туда можно кинуть ссылку на доки какой-то специфичной либы, которую LLM не знает, или знает плохо, IDE ее скачает(и страницы, на которые она ссылается), проиндексирует, и потом в чате можно будет сослаться на нее через @ и Docs
Еще в настройках есть поле для ввода ваших правил:
У меня, например, там то, что надо в коде писать все на английском, а сообщения в чате писать на русском, без этого оно либо пыталось в лог писать на русском, либо текст в чате на английском. Правда, после добавления этого начало выдавать в конце сообщений что-то типа:
Пришлось добавить туда еще и «делай так, но не пиши об этом». Первое правило бойцовского клуба, да.
Кроме того, Cursor поддерживает автоматическую генерацию описаний к коммитам. Конечно, они не всегда идеальны, но, согласитесь, это намного лучше, чем просто писать «update», когда лень формулировать что-то более осмысленное.
Эти возможности вполне достаточны для того, чтобы начать работать с Cursor. Там есть бесплатный триал, на котором можно поэкспериментировать. Я помню, как когда-то появился Copilot, который на фоне автокомплита и методов из библиотек (и даже по сравнению с TabNine) казался настоящей магией: он настолько хорошо предсказывал завершение строк, что возникало ощущение, будто код писал твой коллега-программист.
Сейчас с Cursor у меня схожее ощущение. Хотя ChatGPT тоже может писать код, он больше похож на подчиненного на удаленке: ты ему пишешь письмо, вставляешь кусок кода, он его исправляет и отправляет обратно. Потом ты вставляешь это в проект, запускаешь, видишь, что что-то не так, отправляешь кусок логов, и процесс повторяется.
В какой-то момент у ChatGPT появился Canvas (есть даже описание на русском), с помощью которого стало возможно работать с этим «коллегой» в режиме расшаренного экрана. Но, к сожалению, это все еще ограничивается одним файлом. С простым скриптом все супер, но как только проект становится больше, начинаются сложности.
И я даже не говорю о разделении проекта на несколько файлов, фиг с ним, можно классы на время разработки держать в одном файле, а потом разбить, если хочется красоты.
Нет, он тупо начинал портить код в других местах файла, забывая методы, упрощая логику и так далее.
Плюс, канвас — это все же не IDE, там нет линтера, анализатора, прыжков к месту обьявления, терминала. Да, ты редактируешь код с коллегой, но все равно потом приходится вставлять его в IDE и запускать отдельно.
И вот Cursor — это прям такой же прогресс по сравнению с ChatGPT, как ChatGPT по сравнению с Copilot.
«Ты просишь сделать что-то простое, но в итоге получаешь работу, которая делает только часть того, что ты ожидал. Это как заказать кофе с молоком и сахаром, а получить лишь молоко, которое нужно дополнительно смешать с порошковым сахаром, а еще добавить ложку, чтобы не горчило. Кажется, ты что-то не так сказал, но даешь шанс переделать, и снова не то!»
Так и с LLM. Ты говоришь: «Напиши мне бота, который делает X», он пишет, и вроде бы все работает, но что-то всегда не так. Ты начинаешь уточнять, исправлять логику, добавлять новые фичи, и процесс снова повторяется, как с той пиццей. В начале все кажется очень удобным, но с ростом проекта начинаются проблемы с точностью исполнения. Например, ошибка в логике обработки запроса, незавершенность функций, или, как ты пишешь, когда алгоритм упрощает решение и начинает портить код в других местах.
Но с такими инструментами, как Cursor, это ощущение уходит. Появляется больше контроля, меньший риск ошибок, и меньше времени уходит на исправления. Хотя еще на старте ты все равно исправляешь — он, как помощник, не всегда может предугадать твою конечную цель, но с ним легче находить пути к решению.
Когда это начинает работать, то возникает ощущение как в этой шутке:
Ты правильно заметил, что LLM могут отлично работать на начальных этапах разработки, но когда проект становится более сложным, появляется масса нюансов. Вначале — это все еще впечатляюще, ведь ты можешь быстро набросать функционал, собрать прототип. Однако по мере роста приложения начинаются проблемы, связанные с накоплением технического долга. LLM могут предложить подходящие решения на уровне алгоритмов, но им не хватает способности контролировать сложную логику и архитектуру в долгосрочной перспективе.
Программирование не ограничивается только написанием кода. Нужно управлять архитектурой, оптимизацией, поддерживаемостью кода. В конце концов, функционал, который кажется простым на старте, превращается в нагромождение решений, которые начинают ломаться при изменении каких-либо условий, и LLM не могут обеспечить нужный уровень гибкости. Разумеется, когда ты работаешь с небольшими проектами, которые не требуют долгосрочной поддержки, это не так критично. Но как только код начинает «расти», неизбежно появляется сложность, с которой даже хорошо обученная модель может не справиться.
LLM еще не может заменить опытного разработчика, который понимает архитектуру системы и может принимать решения, минимизируя технический долг. Система «ставим задачу и тыкаем кнопочку» удобна, но имеет свои ограничения. На начальных этапах — это отличное дополнение для ускорения работы, но когда речь идет о реальных, долгосрочных проектах, важно наличие человека, который будет контролировать и направлять развитие системы, следя за качеством кода.
Этот опыт с LLM действительно интересен в контексте быстрого прототипирования, но для больших проектов требуется более комплексный подход. Может, с развитием моделей и инструментов мы увидим более глубокую интеграцию, где LLM не будет генерировать код только по шаблону, а будет в состоянии работать с архитектурой, управлять долгосрочным развитием и поддерживать баланс между функциональностью и поддерживаемостью.
Нет.
Мы получили PoC:
1)за какие-то 3 часа времени
2)не используя никаких спецов, только свои навыки, и то уровня «шарящего продакта-мидла» — запускали код в консоли, копировали ошибки в окошко и проверяли работу с точки зрения пользователя.
Важнее было понимать, что именно мы хотим получить, чем то, как именно надо это кодировать.
Т.е. нам реально не надо знать какой-то язык программирования, если у нас есть базовые навыки скрипт-кидди (т.е. даже не джуна, а просто пользователя, который умеет запускать код скачанный с гитхаба).
Ты правильно подметил, что использование LLM позволяет не только сэкономить время, но и значительно упростить процесс разработки, особенно на стадии прототипирования или для небольших проектов. Для тебя курсор стал инструментом, который эффективно сокращает время на написание кода, что позволяет заниматься не только непосредственно программированием, но и более важными вещами, такими как архитектура и проектирование.
Однако важный момент, который ты затронул, это уже упомянутые ограничения LLM в контексте более сложных проектов и работы с рефакторингом. Несмотря на то что модели могут помогать в создании небольших модулей или PoC, они сталкиваются с трудностями при работе с более сложными архитектурами и рефакторингом кода из-за цикломатической сложности. В результате для поддержания и развития проекта на высоком уровне всё равно нужно участие опытных специалистов.
Как ты отметил, стратегия «разбиваем на части и работаем с каждым модулем поочередно» — это отличный подход, который позволяет сэкономить время и добиться более высокого качества в сравнении с тем, что могло бы выйти за один проход. Этот метод помогает наращивать функционал шаг за шагом, предотвращая «разрастание» технического долга, который неизбежно возникает при отсутствии четкой архитектуры.
Примечательно, что ты сравниваешь процесс с тем, как можно тренировать свои архитектурные навыки и микро-архитектуру, управляя разбиением кода на модули. Это позволяет использовать LLM как эффективный инструмент для обучения и быстрого прототипирования, в то время как для более серьезных и сложных проектов потребуется уже опыт и глубокое понимание разработки.
Твои проекты, например, с ботами — отличный пример того, как можно работать с LLM для создания полезных инструментов за минимальное время, при этом экономя значительные ресурсы, которые бы потребовались для полноценного ручного кодирования. В итоге, ты находишь баланс между использованием возможностей LLM и необходимостью контроля за качеством кода и архитектуры.
DayOne — это iOS-дневник, из которого я некоторое время назад перенёс свои записи в облако. В процессе миграции возникла необходимость для сотни фотографий извлечь координаты и время поста, поскольку по какой-то причине эти данные отсутствовали в EXIF метаданных.
Решение задачи оказалось простым и быстрым: проект был одноразовым, требовалось всего лишь извлечь информацию из SQLite базы данных, сопоставить название файла с его датой и временем, и записать эти данные в EXIF метаданные соответствующих фотографий. Сложные случаи обрабатывать не требовалось, поэтому я просто писал в чат возможные проблемы, проверял результат и снова вносил корректировки.
Единственная трудность заключалась в необходимости разобраться с форматом базы данных, что потребовало несколько минут внимания. Это была бы задача, с которой LLM справилась бы не так эффективно, так как время, затраченное на её разбор, было бы больше, чем затраты на самостоятельное понимание структуры.
Вдобавок, мне удалось реализовать генерацию изображений с текстом дневниковых записей, так как я переезжал из текстового формата в облачное хранилище с картинками. Записей было меньше, чем фотографий, поэтому я просто создал изображения для записей, добавив в метаданные соответствующие даты.
Однако, на этом этапе я потратил немало времени, поскольку LLM не справилась с графикой. В этом разделе я подробнее расскажу, как это было. Для примера, я дал задачу: «сделай картинку с маленьким превью фотографии записи и текстом под ней». LLM сделала это, но когда я захотел уменьшить картинку, чтобы убрать лишнее пространство по бокам, мне пришлось потратить дополнительные десять минут, объясняя, что именно мне нужно. Даже когда я отправлял саму картинку, модель всё равно не поняла. В итоге было быстрее исправить вручную, хотя я продолжал надеяться на автоматизацию.
И, несмотря на этот момент с превью, проект оказался отличным примером того, как LLM может эффективно решить задачи. Качество кода в данном случае не имело значения, так как проект не требовал долгосрочной поддержки. Это был типичный случай работы с бойлерплейт-кодом (например, открытие базы данных, итерация по записям, выборка по ключу из другой таблицы и сравнение), который легко описывается на естественном языке. Большинство специфичных задач, например, работа с SQLite, также решались моделью без проблем, в отличие от того времени, когда я тратил массу времени на поиски решений в интернете.
Ранее такие задачи решались с использованием кода с Stack Overflow, но LLM значительно улучшила этот процесс. В частности, в задачах, связанных с перекладыванием данных в формат JSON, модель почти незаменима.
В си для эмбедеда умеет гораздо хуже, к сожалению.
Постоянно пытается добавить что-то сверх описанного функционала, переусложняет или иногда вообще несет чушь: способен написать ESP.reboot(), и тут же после этой функции — сохранение конфигурации в файл. Если его спросить, «ты ваще нормальный?», ошибку скорее всего найдет, но изначально допускает.
Со всем, что касается непосредственно железа — лажает. Причем, почему-то постоянно хочет накрутить сверху каких-то дополнительных фич (чем совершенно не страдает в питоне). Просишь сохранить переменную в файле, он туда накрутит каких-то проверок, логов на каждый чих, вывод этой переменной на экран, и всего такого прочего, вплоть до загорания светодиода при чтении этой переменной, хотя первоначальная задача была очень простой и решается в две строки.
Еще оно адски путается в плюсах. В каком-то софте, который я адаптировал под что-то свое, была функция переменной, которая настраивалась в веб-конфигураторе. Я захотел сделать такую же, но для яркости светодиода, просто по образцу какой-то другой переменной. Но сделано это было на плюсах, и оно в нем запуталось (подозреваю, задача решалась проще, но я забил). Благо, оно после генерации умеет проверять ошибки линтера, так что это была история на 15 вариантов, которая шла минут, наверное, пять — оно писало вариант, видела ошибки линтера, писало снова, опять видело ошибки, и так далее. Потом сдалось и сделала без конфигуратор.
Впрочем, когда дело не касается вот прям самого эмбедеда, а просто пишется какая-то логика на си, то все норм:
Впрочем, логика изначально была тут довольно простой.
В другой части оно надолго застрял на парсинге JSON: там была библиотека TG-бота, которая выдавала сырой JSON ответа, и оно никак не могло понять, почему же она выдает просто текст, а не отдельный элемент, несмотря на все отладочные выводы, в которых была видна строка json. Когда я уже психанул и сказал «ну распарсь этот json сам», то все получилось с первого раза.
Помните, что в Cursor есть функция Docs? Вот тут-то она нам пригодится.
Тем более, что у svelte в документации есть раздел для LLM!
Ну, в целом эта документация — просто несколько файлов в Md, в которых с разной детализацией описана вся документация, это удобно, но никакой супер-инновации в этом нет.
Идею планировщика можно понять по этому скрину
Планировщик — это такая диаграмма ганта, но не в рабочих днях, а в абсолютном времени вплоть до минут, и без сложных зависимостей, просто один-два потока, но с возможностью изменения таймзоны в процессе (потому что часто для путешествий используется). У нас есть какие-то жестко закрепленные события (вылет самолета), и события-длительности, типа регистрации, поездки в аэропорт и сборов. И мы присоединяем вторые к первому и видим, во сколько нам надо начать собираться, чтобы успеть в аэропорт. Бонусом — медленно ползущая полоска текущего времени, чтобы видеть, насколько мы в графике в текущий момент (если мы все еще в такси, а полоска уже на «регистрации», значит что-то пошло не так).
Почему-то именно в таком виде я не нашел ни одного приложения, и захотел написать сам. Но вот сделать это с помощью LLM я не смог: на этой задаче она былинно слажала. Все хорошо, документация по svelte нормальная, документация по библиотеке пришлось покрутить руками, но тоже получилось, с JS проблем не возникло…
А вот с интерфейсом возникло.
Оказалось, что LLM — слепой часовщик программист. Она может делать какой-то интерфейс, но испытывает огромные трудности с сопоставлением внешнего вида интерфейса и кода. Нет, в современном HTML/CSS я тоже их испытываю, но я могу поиграться в отладчике хрома и почитать доки прицельно по каждой фиче, а LLM просто пуляет наугад. Задачи за пределами стандартных, условно «а теперь подвинь вот эту плашку чуть вправо» уже вызывают проблемы, потому живой человек делает это, основываясь на обратной связи:
— Так двигается? А так? Хорошо, а если через отступ другого элемента зайти? Ой, поехало остальное. Ладно, откатим. Может, положить в див? Ага, так лучше, но надо еще чуть-чуть подвинуть, потому что див теперь учитывает границу другого элемента… Вот, красота.
LLM так не может, нет обратной связи, которая бы позволяла итеративно приближаться к результату. Человек, если сталкивается с поехавшей версткой, может по пикселю двигать границу и найти то значение, за которым все разьезжается, и дальше либо остановиться на нем, либо начать копать дальше. LLM после слов «все поехало» выбирает наугад один из вариантов и предлагает попробовать еще раз. Это в итоге не экономит время, а зачастую удлиняет разработку.
Вторая проблема — очень сложно обьяснить LLM некоторые изменения текстом. Попробуйте чисто текстом обьяснить графическое изменение. У вас что-то получится, конечно, но как вы поймете после попыток LLM это воплотить, в вашем описании слишком много свободы. Можно нарисовать, да, но LLM умеет превращать картинки в код, но не умеет наоборот — она сможет сделать интерфейс с нуля по картинке, но вот картинка с нарисованными изменениями в существующем интерфейсе поставит ее в тупик, потому что для внесения этих изменений надо сначала мысленно представить разницу между версиями, а потом еще и найти привязки в коде, где эту разницу надо вставить.
В итоге даже вот эта версия интерфейса потребовала много-много попыток, и делать это было довольно больно. Если бы проблемы были с кодом на питоне/жс, я бы просто написал его сам, но вот в HTML/CSS я умею совсем чуть-чуть, поэтому довел до хоть сколько-нибудь рабочего состояния и забил. Кстати, если вы фронтендер, который умеет в UI, и вам понравился концепт, то напишите мне, что ли, хочу сделать из этого что-то, что можно использовать (я могу даже денег дать).
Абсолютно та же проблема была с переводом картинок в текст: базово все получилось с первом попытки, и это заняло 10% времени, а вот задачи «а теперь сделай отступ вокруг текста, нет, чуть левее, и выровняй фотку по центру» заняли остальные 90%, и не потому, что они сложные, а потому, что LLM не понимает, как выглядит текущее состояние.
1)В архитектуру LLM не умеет. Продумывайте разделение проекта на части заранее, относите новые фичи к какому-то классу в отдельном файле и удаляйте из контекста ненужные файлы. Вот если нужна статистика, прям указывайте на файл stats.py и давайте задачу писать в нем. Так оно не будет иметь возможности ошибиться.
Если межблочное взаимодействие — то кладите в контекст эти два файла, и больше ничего.
2)Вам нужны знания о том, как работает язык на котором вы пишите. Вам придется ревьюить код и говорить «это решение говно», без этого получится фигня.
И даже «у тебя код нечитабельный, сделай вот так, по правилу на каждой строчке» тоже иногда надо говорить
3)Не надейтесь что промпт «ты умный кодер-сеньор» сработает. Попросить конечно можно, но велика вероятность что он просто перейдет в режим энтерпрайза и начнет генерировать тонну очень хорошо абстрагированного кода, который поддерживать ничуть не проще, чем лапшу.
4)Хорошо работают примеры: берете кусок кода, переделываете его, не обращая внимания на запятые и ошибки линтера, просто чтобы он примерно показывал то, что вы имеете ввиду и тыкаете LLM носом в этот пример. Ошибки в коде LLM правит отлично, а вот какой именно код вам нужен, чтобы его было удобно сопровождать дальше — знаете только вы.
Наверное, в какой-то момент будет можно дотренировать модель на вашем стиле кода, чтобы таких проблем было меньше. С другой стороны — в этом проекте LLM подсказала мне пару решений, о которых я теоретически знал, но почему-то никогда не применял, а оказывается, это ощутимо экономит время и строки. Если бы LLM писал в моем стиле, то эти решения и не применил бы никогда.
5)Не давайте заполнять requirements.txt (или раздел библиотек в platformio.ini)!
LLM туда ставит старые версии, которые любят падать с очень невнятными ошибками из глубинных кишок библиотеки, которые не гуглятся, и о которых LLM ничего тоже не может сказать внятного. Если она добавляет библиотеки в requirements.txt, удаляйте версии, оставляйте просто названия, потом в конце разработки зафризите версии.
7)Пишите тесты. Тесты LLM пишет хорошо, надо просто описывать словами класс тестов, и потом править мелочи, это реально делает тесты менее нудными на порядок. Тесты хорошо спасают от того, когда LLM забывает что-то где-то поправить вслед за своими изменениями, уровня «реализацию изменил, в одном вызове функции изменения забыл учесть». LLM сама это поправит, если ее пнуть в нужном направлении вида «тест сломался, смотри». Я тоже делаю такие ошибки, когда что-то пишу, но как будто сильно реже.
8)Иногда вы просите LLM что-то исправить, и она делает не то, что надо. Вы уточняете запрос, она правит, и опять не то, и опять не то, и с каждым разом она делает все хуже и хуже или просто начинает бегать между 2-3 вариантов по кругу, так и не понимая что именно вы хотите. Насколько я понимаю, это происходит из-за того, что в последнем контексте слишком много ключевых слов, которые ведут ее не туда.
Тут помогает вернуться к снапшоту с первым запросом, который она не смогла сделать и переформулировать его более основательно, добавив в него все те уточнения, которые вы писали ей дальше
9)Избегайте сложных запросов, которые включают в себя сложные многоуровневые фичи или функционал из разных областей. Это работает в начале проекта, но становится плохоуправляемым когда кодовая база вырастает.
Условно, в начале проекта вы можете сказать «сходи в базу SQLITE достань оттуда название файла и дату и проставь в EXIF файла дату поста», но вот дальше лучше не перечислять в одном запросе «а теперь переименуй файлы в формат даты, добавь конвертацию из другого часового пояса, и убери из лога сообщения про EXIF», а делать это отдельными запросами, иначе велика вероятность, что она забудет какой-то пункт или просто сделает его на отъебись, потому что распылит «внимание» (насколько я понимаю, реально внимание, там есть какой-то механизм, который фокусируется на определенной части промпта).
Вряд ли оно сделает что-то плохое, скорее просто забудет про один-два пункта. Но может и запутаться в функционале, если там будут похожие пункты вида «отключи логи для записи в EXIF, но добавь логи про запись в БД»
10)LLM — слепой часовщик программист. Если вам нужен базовый интерфейс «вот страничка, на ней сделай 10 полей для ввода и кнопку сохранить, и выведи вот эти параметры, но не давай их изменять, и сделай это на твиттер-бутстрап», то она справится. Добавить туда еще десять полей — тоже без проблем. Но вот при необходимости поля эти подвигать, чтобы сделать красиво (я даже не говорю о pixel-perfect верстке, просто хоть сколько-нибудь красиво), вы столкнетесь с большими проблемами.
11) LLM плохо пишет комментарии. Я уже хихикал вот тут над этим: все в классическом стиле бесполезных комментариев. Еще очень часто вместо комментариев, что именно тут происходит (даже таких бесполезных как те, над которыми я хихикал выше), она пытается описать изменения: вместо «# повторная задержка» пишет в строке, которую поменял «# добавил тут повторную задержку». Замечательно, я и так вижу, что ты эту строку поменял, мне-то зачем в истории комментариев потом читать что ты что-то добавил?
12)Периодически ломает README. Дело в том, что весь ответ LLM представляет собой md, и на него ориентируются парсеры курсора, чтобы понять, где текст в чате, а где код, который надо вставить в файле. Это работает в 99% нормально, пока вместо кода мы не просим сгенерировать тоже маркдаун, и это зачастую приводит к интересным последствиям.
13)Очень не хватает здоровой критичности к моим сообщениям у модели. Я могу что-то не увидеть в коде, и там где живой человек скажет мне «ты что, дурак, там в коде уже это есть», LLM ответственно пойдет что-то делать, и иногда сломает нужную функциональность. Тоже самое происходит, когда я через чур уверен, где баг: я пишу «у тебя баг в парсинге профилей, присылаются повторно», и LLM послушно идет ковыряться в парсинге, что-то правит, радостно отчитывается, а баг-то остался, потому что он не в парсинге, а в отправке. Хочется, чтобы в этот момент модель послала меня на фиг, и сказала «ты дурак штоле, вон у тебя в отправке фигня нарисована».
Не удается подключить iPhone к автомобилю через CarPlay? В этой статье мы объясним, почему это…
Хотите настроить громкость для сообщений, звонков и мультимедиа на iPhone по отдельности? В этой статье…
Хотите повысить безопасность своей веб-версии WhatsApp? В этой статье мы покажем, как добавить пароль для…
Ищете способы расшифровать видео с YouTube в текстовый формат? В этой статье мы представляем 7…
Если кнопка Camera Control на вашем iPhone 16 случайно открывает камеру, это может быть очень…
Хотите использовать камеру вашего iPhone 16 или iPhone 16 Pro на полную мощность? В этой…