Итак, поскольку бизнес, похоже, до сих пор не верит, что ему, по-прежнему, не обойтись без живых и толковых разработчиков, и предается влажным мечтам о тотальном вайб-кодинге лично потугами стейкхолдеров и продакт-оунеров (ахаха!), то я пока просто поделюсь несколькими реальными практиками, которые мне удалось применить в работе над пет‑проектами и которые я, как техлид, могу смело предложить для внедрения в небольших командах.

Затем, в следующих постах, я постараюсь объяснить доходчиво, почему Вам, уважаемые CEO и кофаундеры, глупо ждать очередного прорыва, -- лучше нанимайте хороших специалистов, пока хайп не сдулся (завтра ноябрь, але!). Без них "волшебный черный ящик" не заработает вам ничего.. ;)

Начну с банального рецепта, применимого моментально к любому индивидуальному разработчику в его повседневной деятельности (одной-двумя командами и без вложений!).

Первый шаг вроде бы очевиден, это конечно же установить плагин для IDE и привыкнуть к нему. Но загвоздка есть сразу -- придется прям выбирать и пробовать, ибо их слишком много, а единственная реально юзабильная их функция -- это автодополнение. Поэтому просто выберите такой, чтобы хорошо это делал в вашей любимой среде разработки и можно было переключаться между локальными и облачными API.

Но, когда привык и наигрался, то куда дальше? Где этот реальный буст в конце-то концов?

Будем искать! И вот что я пока нашел, однозначно полезного и перспективного:

• Шаг второй: LLM CLI tool — это что‑то вроде, например, aichat, установленного локально для вашей консоли. Он приносит все возможности LLM прямо в командную строку, опираясь на мощь нативных Unix‑пайпов — вот где начинается настоящая магия. 😉
  
  Например, вместо того чтобы тужится с shell-синтаксисом, ты можешь мгновенно зашорткатить себе быстрый запуск следующего шага:
  
  $ aichat -e create bash script to launch docker container with qwen-code and current or specified folder mounted to workdir as volume

• Шаг третий: Coding Agent — попробуйте, наконец, полноценного агента. Мне кажется очевидным, что агенты должны работать в изоляции, поэтому я настоятельно рекомендую подходить к снаряду сразу через контейнер. Мой текущий выбор — Qwen‑code в Docker, который я запускаю с любым локальным каталогом, смонтированным как volume, связанным с рабочей директорией.
  

Qwen‑code отлично работает в связке с открытой рядом IDE — позволяя плавно переключаться между ручным кодингом и LLM‑ассистированным процессом разработки.

Оба инструмента уже описаны на Хабре. Но, поскольку инструментов великое множество -- хотел бы обратить ваше внимание именно на эти. Спасибо.

В следующих постах, возможно, расскажу подробнее о часто возникающих кейсах и следующих шагах, вроде добавления MCP.

Неожиданный факт о JavaScript всплыл, и снова стал актуален, при разработке приложения с генеративными нейросетями.. Оказывается, в языке нет поддержки 64-битных целых. По сути, доступно только 53-бита!

JavaScript Numbers are represented as IEEE 754 double-precision floats. Unfortunately, this means they lose integer precision for values beyond +/- 2^^53.

Факт давно известный, но от того не менее неприятный. Казалось бы, ну ничего страшного -- ведь есть, вроде бы, уже поддержка встроенного объекта BigInt и она добавлена во все современные браузеры.

Но если речь идет о работе с API (как в случае с параметром seed для StableDiffusion, например) и вы хотите использовать весь диапазон (а не его половину, как в automatic1111) -- то вы неизбежно сталкиваетесь с де/сериализацией объектом JSON, который для целочисленных значений использует стандартный тип Number.

И вуаля -- кроме обходного пути с передачей числа в виде строки, решения не видно! Ни на первый, ни на второй взгляд)

Если у кого-то есть идеи как этого избежать, или я что-то недопонял -- буду признателен за комментарий!) Проект давно закончен, но хотелось бы найти "красивое" решение.

UPD: подсказали еще вариант с модификацией всех вызовов JSON.parse() и JSON.stringify() -- см. https://github.com/tc39/proposal-json-parse-with-source (но есть нюансы).