Небольшое лирическое отступление …

В этой статье я буду высказывать СВОЕ мнение, я не обязываю вас учить один из этих языков, просто основываясь на своем опыте и изучении этих языков, я даю совет какой стоит учить , и какой бы я учил язык в начале. А теперь приступим!!

На какие типы разделить языки программирования??

Ваще языки программирования можно разделить на :

Уровень абстракции или же близость языка к нашему компухтеру :

Низкоуровневые языки( старее наших дедов) : Ассемблер и машинный код. Если их кто то и учит то у них демоны в голове))

Высокоуровневые: Go, Rust, Kotlin, JavaScript, Swift и многие другие.

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

Выбор высокоуровневого языка..

1. Мой фаворит Go или Golang - это простой и быстрый сиподобный язык, разработанный гугл. Востребованный, но мало желающих, платят ооочень много. Так еще и достаточно прост в обучении. ТОП1
2. С++ . Ты что самый крутой?: Молния маквин в мире программирования, C++ дает нам гораздо больше контроля над памятью, хотя современные возможности языка позволяют во многих случаях обходиться без ручного управления., но плюсы являются языком с высоким порогом входа, поэтому не очень подходит для ньюгенов. Кроме того, за десятилетия развития C++ превратился в перегруженного монстра и его синтаксис слишком запутан.

3. Java — это объектно-ориентированный язык с компиляцией в промежуточный байт-код для выполнения внутри JVM(виртуальная машина джавыы). Так же он кросплатформлен , и имеет автоматическое управление памятью. На нем пишут приложения для банков , авторизации, а так же Майкнкрафт( можно читы делать на джаве ))

4. Мать его Python. Python — это высокоуровневый интерпретируемый язык программирования с динамической типизацией, ориентированный на скорость написания кода и читаемость синтаксиса. Один из самых простых языков для начала, нужен для автоматизации и Машин лернинга ( восстание машин)

5. JavaScript. Без него интернет бы выглядел как страница из 2005 года.

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

Если хотите стать веб-разработчиком, то JavaScript придется изучить. Без него никуда. Сейчас вместе с ним обычно изучают TypeScript, потому что он помогает писать более надежный код. Для работы с ии тоже нужен Тайп скрипт желательно, она лучше понимает его .

Так же js является единственным языком которыц работает в браузере(кул факт).

6. Rust. C++, но после похода к психиатру.

Rust — современный язык программирования, который тоже очень быстрый. Его главная фишка — безопасность работы с памятью. Там компилятор буквально не даст тебе написать кучу ошибок, которые в C++ спокойно скомпилируются и потом будут ломать тебе жизнь.

Но есть нюанс. Изучать Rust с нуля тяжело. Он заставляет думать не так как мы привыкли, поэтому новичку я бы его не советовал. Зато если осилите — будете зарабатывать много баблишка и быть кул программистом.

7. C#. Любимчик любимых майкрософт(нет).

Если хочешь делать игры на Unity (пока он еще живет) или разрабатывать программы под экосистему Microsoft, то C# — отличный выбор.

Синтаксис похож на Java, язык достаточно приятный, есть автоматическое управление памятью и огромная экосистема. Для новичков тоже вполне подходит.

8. Kotlin. Наследник Джавы на Андроидфонах.

Если хотите писать приложения для Android, то сейчас лучше смотреть именно в сторону Kotlin. Он современнее Джавы, код получается короче и понятнее, а Google активно продвигает именно его.

Хотя Java на Android тоже никуда не делась.

А что насчет PHP?

Да, мемы про PHP живут дольше некоторых языков программирования. Но прикол в том, что огромное количество сайтов до сих пор работает именно на нем. Тот же WordPress написан на PHP.

Хорош для веб разработки. Просто хайпа вокруг него уже нет.

ИТОГИ

По итогу этой статьи я советую вам изучать Golang, один из самых простых ЯП, но востребованный в нынешнее время, с высокой зарплатой, а это важно для нас, но!!

Самое главное — не искать идеальный язык. Его не существует.

Первый язык нужен не для того, чтобы остаться с ним на всю жизнь. Он нужен, чтобы понять, как вообще работает программирование: что такое переменные, функции, циклы, классы, алгоритмы и структуры данных.

Когда разберешься в этом, выучить второй язык будет в разы проще. Не бойтесь ошибаться, не бойтесь гуглить и не бойтесь чувствовать себя глупыми. Через это проходит абсолютно каждый чувачок.

Почему Нейросети вообще глючат?

Есть иллюзия, которая почти неизбежно возникает при работе с сильными моделями. Пока Claude , GPT или любой другой продвинутый ИИ уверенно пишет, объясняет и рассуждает, кажется, что перед нами почти законченный цифровой интеллект: собранный, логичный, последовательный. Но стоит дать ему задачу чуть сложнее, чуть длиннее, чуть более неоднозначную, и начинают вылезать странности. Он забывает вводные. Путает зависимости. Выдумывает несуществующие API. Уверенно советует то, что сломает проект. Иногда ошибается в вещах, которые джуну кажутся почти очевидными.

Отсюда и главный вопрос: почему даже самые мощные модели ошибаются в простых вещах?

Потому что они не думают как человек.
Они не всегда понимают задачу целиком, не умеют сами по себе нормально отделять важное от второстепенного и часто просто выбирают ответ, который выглядит наиболее вероятным. Если не задать модели понятный порядок работы, она начинает спешить: где-то додумывает, где-то упрощает, где-то выдает уверенный, но не самый точный ответ. Поэтому проблема обычно не в том, что модель “тупая”. Проблема в том, что ей не дали нормальную структуру: сначала понять задачу, потом составить план, потом сделать, потом проверить себя.

Именно в этом месте возникает ключевая мысль всей статьи: проблема ИИ не только в интеллекте модели, а в архитектуре ее работы.

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

Как говорил Andrew Ng, несмотря на весь хайп вокруг AI, современные модели все еще очень ограничены по сравнению с человеческим мышлением. И на практике это видно сразу: без нормальной структуры работы нейронка легко начинает ошибаться даже в простых вещах.

А теперь что же делать чтобы этого избежать?

Раздел 1. Анатомия мыслительного процесса ИИ

LLM — это статистическое предсказание, а не логический блок

Самое важное, что нужно держать в голове: большая языковая модель не думает так, как думает мы, люди. Ее базовая механика — это предсказание следующего токена. Не следующей великой идеи, не следующего логического вывода, а именно следующего наиболее вероятного фрагмента текста с учетом всего контекста, который был до этого.
Если чуть глубже, это связано с тем, как вообще устроены LLM. Они обучаются не “думать” в человеческом смысле, а предсказывать следующий токен на основе предыдущего контекста. За счет архитектуры transformer модель хорошо улавливает связи внутри текста, паттерны рассуждений, стиль и структуру. Но это все еще не встроенная логика и не механизм проверки фактов. Поэтому нейронка может звучать очень убедительно, даже когда где-то ошибается.

Это звучит почти обесценивающе, но на деле именно из этой простой механики и рождается впечатляющая сложность. Когда модель натренирована на гигантском массиве текстов, кода, документации, диалогов и рассуждений, предсказание следующего токена начинает вести себя как нечто, очень похожее на мышление. Но важно подчеркнуть: похожее — не значит реальное.

В этом и заключается корень большинства ошибок. Модель не знает, что такое истина в философском смысле. Она не понимает правильность как инженер понимает правильность архитектуры. Она лишь строит вероятностную траекторию ответа. Если траектория выглядит убедительно, это еще не делает ее надежной.

Есть хорошая формулировка, которую я прочитал в одной книге: убедительность и истинность — это разные свойства высказывания. Для LLM это особенно важно. Она часто умеет звучать разумнее, чем реально проверяет себя.

Отсюда первый практический вывод: не доверяйте красивому ответу только потому, что он красиво звучит.

Контекстное окно vs. внимание

Второй важный момент — это различие между контекстным окном и вниманием.

Многие думают так: если у Клода большое контекстное окно, значит, можно просто закинуть туда весь проект, все логи, всю документацию, пачку RFC, полрепозитория и ждать идеального понимания. На практике это работает хуже, чем хотелось бы.

Контекстное окно — это объем информации, который модель может запоминать и использовать. Но внимание — это то, как она реально распределяет вычислительный фокус внутри этого объема. И вот с вниманием начинается самое интересное. Когда вы скармливаете модели слишком много разного рода материала, вы не усиливаете ее, а часто создаете шум. В результате она либо цепляется за нерелевантные куски, либо размазывает фокус, либо пропускает важные детали для нашего проекта.

Поэтому установим для себя правило: лучше дать меньше контекста, но дать его точнее.

Если вы работаете с кодом, Claude не нужно показывать весь репозиторий, чтобы поправить одну фичу в конкретном модуле. Ему нужны:

• релевантные файлы;
• интерфейсы, с которыми связан модуль;
• тесты;
• документация по текущему паттерну реализации;
• ограничения задачи.

Никто не решает локальную проблему, читая весь код мира. Человек тоже работает через отбор значимого. С моделью нужно делать то же самое.

Промт как фундамент

Третья опора — системные инструкции. Именно они часто определяют, как Claude будет интерпретировать свою роль: как генератор кода, как критик, как осторожный помощник, как исполнитель, как ревьюер.

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

Почему это важно? Потому что модель всегда старается угадать, какой тип поведения сейчас наиболее уместен. И промт задает ей высокоуровневую стратегию. По сути, это аналог рабочего темперамента внутри сессии.

Если говорить языком книг о менеджменте и сложных системах, то поведение агента определяется не только его способностями, но и устройством среды, в которой он принимает решения. Для Клода такой средой и является набор системных инструкций и локальных правил проекта.

Раздел 2. Этап планирования

Никакого кода без ТЗ

Запрос «напиши фичу» почти гарантированно ведет к багам. Не потому, что модель обязательно плохая, а потому, что фича без требований — это не задача, а туман.

Когда человек слышит «сделай фичу», он автоматически достраивает требования из опыта, контекста компании, архитектурных норм, ожиданий команды. Модель тоже будет что-то достраивать, но делает это статистически, а не организационно. Она заполняет пробелы наиболее правдоподобными решениями. А правдоподобное решение — это не всегда то, что вам нужно.

Поэтому перед любым действием модели нужен этап формализации. Пусть даже короткой. Но задача должна быть описана через:

• цель;
• ограничения;
• критерии готовности;
• риски;
• затронутые части системы.

В инженерной работе это особенно критично. Если не задать рамку, ИИ начинает оптимизировать не то. Может быстро написать код, но не тот код. Может закрыть симптом, но не причину. Может сделать красиво, но вразрез с архитектурой проекта. Герберт Саймон говорил:
"решение почти всегда ограничено тем, как была сформулирована сама задача."
Если по простому, то это означает какой вопрос ты задал, такой диапазон ответа ты и получишь.

Chain-of-Thought: заставить модель проговорить шаги

Один из самых полезных паттернов при работе с Claude — заставить его сначала проговорить план действий словами. Не код, а именно логику маршрута.

Идея Chain-of-Thought в прикладном смысле проста: модель работает лучше, когда ей дают право и обязанность развернуть промежуточное рассуждение. Это не столько магия, сколько способ снизить количество скачков через логические ступени.

Например, вместо:

Исправь баг в авторизации

лучше так:

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

Что это дает:

• модель разделяет гипотезы и факты;
• не прыгает сразу к первой правдоподобной правке;
• демонстрирует ход мысли;
• делает решение проверяемым.

Это особенно полезно в коде, потому что самый дорогой баг — не тот, который ИИ не заметил, а тот, который он уверенно починил так, что стало хуже.

Практика: TODO.md или spec.md

Одна из лучших привычек в работе с ИИ над проектом — вести внутри репозитория короткий файл, который играет роль рабочей карты задачи. Это может быть TODO.md, spec.md, task.md, implementation-plan.md — название не так важно. Важно, чтобы файл:

• фиксировал, что именно надо сделать;
• описывал границы изменений;
• перечислял задействованные модули;
• содержал чеклист шагов;
• обновлялся по мере продвижения.

Это хорошо работает, потому что важные детали по задаче не теряются в переписке. Чат может разрастись, что-то забудется, что-то смешается с другими сообщениями. А spec.md дает модели понятную точку опоры: что именно нужно сделать, где границы задачи и на что вообще смотреть.

Это невероятно сильный прием. По сути, вы строите для ИИ внешнюю опору.

Например шаблон такого файла может выглядеть так:

Task: Refactor auth session refresh Goal Исправить race condition при одновременном обновлении токена.
Constraints - Не ломать текущий API - Не менять контракт фронтенда - Сохранить обратную совместимость Files of Interest - src/auth/session.ts - src/auth/token-store.ts - tests/auth/session.test.ts
Plan - [ ] Изучить текущую реализацию refresh
- [ ] Найти точку race condition
- [ ] Написать тест, воспроизводящий баг
- [ ] Исправить логику
- [ ] Обновить тесты
- [ ] Сделать self-review

Даже такой простой файл уже сильно дисциплинирует работу модели.

Раздел 3. Этап реализации и контроля

Атомарные изменения или же маленькие изменения.

Одна из самых частых ошибок при работе с Claude Code — просить его сделать сразу большой, многослойный, архитектурно значимый кусок работы за один проход. Теоретически это возможно. Практически это почти всегда повышает риск.

Гораздо лучше работают атомарные изменения. То есть маленькие законченные шаги:

• сначала подготовить тест;
• потом изменить один модуль;
• потом обновить интерфейс;
• потом прогнать проверку;
• потом сделать следующий шаг.

Почему это важно? Потому что в маленьком изменении легче понять:

• что именно делает модель;
• где она ошиблась;
• какой эффект вызвала правка;
• как откатиться;
• как провести ревью.

Если мыслить инженерно, то надежность рождается из локальности изменений. Огромный патч сложнее проверять и человеку, и машине. Маленькие патчи проще объяснить, протестировать и встроить в проект.

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

TDD: сначала тест, потом код

Для Claude Code тестоориентированный подход — одна из лучших дисциплин.

Потому что тест заставляет модель не просто «что-то придумать», а зафиксировать наблюдаемое поведение системы. Это переводит задачу из режима свободной генерации в режим формальной проверки.

Правильный цикл выглядит так:

1. Описать ожидаемое поведение.
2. Попросить Claude написать тест, который это поведение проверяет.
3. Убедиться, что тест падает.
4. Только потом просить исправить код так, чтобы тест прошел.
5. После этого прогнать смежные тесты.

Почему это работает? Потому что модель больше не гадает по описанию, а видит конкретный результат: тест либо проходит, либо нет.

Есть такая фраза: то, что нельзя проверить, слишком рано называть решением.
В работе с иишками это особенно верно.

Пример запроса для Клода:

Не исправляй код сразу. Сначала напиши минимальный тест, который воспроизводит баг. Убедись, что он падает. Затем предложи наименьшее исправление, которое сделает тест зеленым. После этого оцени, не задело ли изменение смежное поведение.

Раздел 4. Рефлексия: Миграционный надзор

Self-Correction

Самое ценное, что можно заставить делать модель после реализации, — это критиковать саму себя. Не в общих словах, а по понятным критериям.

Паттерн выглядит так:

Проверь свой предыдущий ответ на наличие логических несостыковок, архитектурных рисков, лишней сложности и неподтвержденных предположений. Затем предложи улучшенную версию.

Почему это работает? Потому что первая версия ответа почти всегда оптимизирована под правдоподобие, а вторая может быть оптимизирована под качество. ИИ, как ни странно, часто довольно неплохо находит слабые места в своем же решении, если перевести его в режим ревьюера.

Но есть важная тонкость: нельзя просить проверь себя слишком общо. Лучше задавать ось проверки:

• логика;
• безопасность;
• производительность;
• соответствие паттернам проекта;
• избыточность;

Чем конкретнее критерии, тем полезнее рефлексия.

Review Mode

Очень мощный режим работы с Клодом — попросить его сначала выступить не как исполнитель, а как ревьюер собственного плана.

Например:

Сначала предложи план реализации. Потом отдельно раскритикуй его как senior engineer с точки зрения безопасности, производительности и поддержки в будущем. Только после этой критики предложи доработанный вариант.

В этот момент вы фактически создаете внутри одного инструмента две роли:

• автора;
• архитектурного надзора.

Это полезно, потому что у модели меняется рамка задачи. Она перестает просто продолжать свой же текст и начинает искать слабые места. А это уже очень близко к человеческой инженерной практике.

Борьба с галлюцинациями

Одна из самых неприятных особенностей ИИ — уверенное изобретение того, чего нет. Небольшая деталь, несуществующая библиотека, выдуманная функция, устаревший API, «известный паттерн», который на самом деле никем не используется. Все это особенно опасно в коде, потому что звучит правдоподобно.

Если модель уверена, что какая-то библиотека существует, нужно не спорить с ней на уровне интонации, а заставить проверить реальность. Например:

• npm info package-name
• поиск по официальной документации
• чтение package.json
• поиск по локальному коду
• проверка импорта в проекте
• web-поиск по официальным источникам

Правильный промпт здесь выглядит так:

Если ты ссылаешься на библиотеку, команду, API или фреймворк, сначала проверь, что это реально существует и совместимо с нашим стеком. Если подтверждения нет, не подавай это как факт.

Это очень важный сдвиг. Вы приучаете модель не просто отвечать, а помечать уровень уверенности и отделять подтвержденное от предположительного.

Как говорил Талеб: самая опасная ошибка — не незнание, а незнание, замаскированное под уверенность.

Раздел 5. Реализация в Claude Code

1. Инициализация: запуск из корня проекта

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

Правильный старт задает правильную картину. Наш клодик должен понимать:

• где находится проект;
• какой стек используется;
• как устроены директории;
• где лежат тесты;
• где конфигурация сборки;
• есть ли локальные правила или инструкции.

2. The Feedback Loop

Самый надежный цикл работы с Claude Code выглядит так:

Запрос -> Черновик плана -> Ваше одобрение -> Исполнение -> Тесты -> Рефлексия

Это, по сути, и есть архитектура мышления ИИ в прикладном виде.

Почему этот цикл так хорош:

• вы не даете модели сразу перепрыгнуть в код;
• сначала видите ход мысли;
• можете остановить неверное направление до реализации;
• заставляете связывать код с тестируемым результатом;
• добавляете этап архитектурной самопроверки.

Если коротко: вы строите для ИИ процесс, в котором ошибка становится заметной раньше.

3. /stats и контроль контекста

Любая длинная сессия с ИИ деградирует, если не следить за объемом и качеством контекста. Даже сильная модель начинает хуже держать нить, если диалог разрастается, в нем появляется много промежуточных утверждений, старых версий решений, противоречащих указаний и лишнего шума.

Поэтому полезно следить за состоянием сессии: сколько контекста уже занято, насколько диалог разрос, не пора ли открыть новый чат, вынеся важное в spec.md

Здесь действует правило мышления: память хороша, пока она организована; неорганизованная память превращается в шум.

Если вы видите, что контекст разросся, лучше сделать так:

• зафиксировать текущее состояние в коротком файле;
• перезапустить работу в чистом чате
• заново дать инфу
• продолжить с ясного плана.

Что в итоге реально снижает количество глюков

Если собрать все в одну практическую систему, получится довольно простая, но мощная схема.

Нейронка работает заметно надежнее, когда:

• ей дают четкое ТЗ вместо расплывчатого пожелания;
• ее заставляют сначала планировать, а не сразу кодить;
• контекст отбирается, а не сваливается в нее целиком;
• изменения делаются атомарно;
• тест выступает как внешний критерий истины;
• после реализации включается режим рефлексии;
• длинная сессия периодически очищается и структурируется.

Если формулировать совсем коротко, то нейросеть становится полезнее не тогда, когда вы просите ее быть умнее, а тогда, когда вы строите ей более умный процесс работы.

И вот это, пожалуй, центральная мысль моей статьи. Качество ИИ рождается не только из мощности модели. Оно рождается из дисциплины контекста, этапа планирования, внешних проверок и правильно организованной рефлексии.

Вывод

Главная ошибка в работе с нейросетями — ждать, что одна мощная модель сама обеспечит точность, логику, последовательность и архитектурную аккуратность. На практике такого почти не бывает. Даже сильные модели ошибаются в простом, потому что их базовый режим — вероятностное продолжение с опорой на контекст.

Поэтому надежная работа с Claude Code или любой другой LLM строится не вокруг одного идеального промпта, а вокруг архитектуры мышления. Сначала постановка задачи. Потом план. Потом реализация по шагам. Потом тесты. Потом рефлексия. Потом проверка спорных мест. Это и есть тот каркас, который превращает нейронку из впечатляющего собеседника в реально полезный инструмент.

А на это все, всем спасибо за прочтение данной статьи, я очень старался над ней, поэтому буду рад вашему фидбеку

TGKKK
https://t.me/funtrona
https://t.me/funtrona
https://t.me/funtrona

Twitter
https://x.com/p0stbless
https://x.com/p0stbless
https://x.com/p0stbless

Всем привет, с вами postbless, часто люди ищут какой - то хороший бесплатный инструмент для вайбкода, но находят лишь инструменты, где либо маленькие лимиты, либо есть другие нюансы. Я нашел для вас нейросеть, которая работает идеально, я сам ей активно пользуюсь, и многие люди из комьюнити так-же пользуются Квеном. А теперь приступим к гайду.

Часть 1.QWEN CODE - НИЗАКОННО ЭТО НИХРЕНА

Что же ты такое ?

Qwen Code — это бесплатный AI-агент, который работает в нашем терминале. Помимо того, что он бесплатный, он еще и с открытым кодом на гитхабе. На данный момент я считаю квен одним из лучших бесплатных инструментов для вайбкода. Ведь за бесплатно , нам дают огромные лимиты, которые не закончатся даже если ты херачишь проект 10 часов подряд. Так же квен постоянно обновляется, недавно вышла версия qwen 3.6, которая показала шикарные результаты.

Плюсы:

• Реально бесплатный: Дает огромные лимиты. Для среднего проекта этого хватит за глаза.
• Ум лучше чем у блондинки: В кодинге и логике модели Qwen 3 сейчас на уровне Claude 3.5 и GPT-4o. Из за своей архитектуры , квен очень хорошо понимает контекст, особенно в модели 3.6.
• Работа с UI: Хорошо справляется с фронтендом (например React, Tailwind), может анализировать скриншоты и фиксить верстку.

Минусы:

• Проблемы со сложными процессами: Иногда крашится когда вы пытаетесь запустить бесконечные процессы тип npm run dev или какие нибудь сложные процессы.
• Требовательность к железу (для локалки): Конечно он не требует какой нибудь видюхи 4090, но на печке с 2012 не поработаешь комфортно(
• Не идеальный интеллект: В чисто гуманитарных вопросах или креативном письме он может уступать Claude, так как заточен именно под код и логику.

ГАЙДИК НА УСТАНОВКУ

Единственное требование для установки — Node.js версии 20 или выше.
Как узнать?

node --version

Если нету — качаем с nodejs.org и идём дальше.

Способ 1: Быстрая установка
-------------------------------------------

На винде (запускать CMD от имени администратора):

    curl -fsSL -o %TEMP%\install-qwen.bat https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen.bat && %TEMP%\install-qwen.bat

На маке:

    curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen.sh | bash

После установки обязательно перезапускаем терминал.

Способ 2: Через npm

    npm install -g @qwen-code/qwen-code@latest

Чтобы проверить всё ли скачалось проверяем в терминале:

qwen --version

Если вывело версию — то квен готов.

ПЕРВЫЙ ЗАПУСК И ЗНАКОМСТВО

Для того чтобы Qwen заработал, мы должны открыть терминал, и ввести qwen. Это должно выглядеть вот так:

После этого , наша иишка готова к работе.

О режимах работы

p.s Для изменения режима достаточно нажать Tab или ввести команду /approval-mode- и выбрать нужный режим

1. Режим планирования

Я считаю его самым безопасным. Он только читает код и даёт советы для него. Ничего не меняет, ничего не запускает. Идеально подходит для построения плана проекта.

Когда использовать:
— Изучаешь незнакомый проект
— Планируешь большие изменения
— Хочешь понять что он будет делать, прежде чем разрешать ему применять что-либо

2. Режим принятия правок.

Нейронка меняет файлы сама, без подтверждения. Но если надо ЗАПУСТИТЬ команду — спрашивает.

Когда использовать:
— Когда рефакторишь
— Когда доверяешь ей файлы, но не хочешь чтобы запускалась какая то хрень.

3. Режим Yolo

Делает ВСЁ сам. Меняет файлы, запускает команды, делает коммиты. Ничего не нужно подтверждать.

Когда использовать:
— CI/CD пайплайны
— Автоматизация рутины
— Когда точно знаешь что произойдёт

Краткий вывод по первой части

По - сути , этого уже достаточно для нормальной работы. Осталось лишь научиться хорошо писать промпты.
КСТАТИ у KUDRICHA вышла прекрасная статья про то, как правильно писать промты, советую прочитать.

ЧАСТЬ 2. ФУНКЦИОНАЛ И МСP СЕРВЕРА

Qwen как и другие нейросети в терминале имеент slash команды. Вот самые полезные и важные из них , которые я советовал бы запомнить

О СЛЭШ КОМАНДАХ

На самом деле этих команд гораздо больше, но я разобрал только самые важные и нужные из них.

Как подключить MCP сервера в Qwen

Для того чтобы добавить, нужно сначала выбрать mcp , который мы хотим установить, я советую сервис https://mcpmarket.com/.

Способ 1. Через CLI:

      1 qwen mcp add shadcn npx shadcn@latest mcp

Или если есть HTTP сервер:

qwen mcp add --transport http my-server http://localhost:3000/mcp

Cпособ 2. Вручную

Открываем путь /.qwen/settings.json и добавляем:

     1 {
     2   "mcpServers": {
     3     "имя-сервера": {
     4       "command": "npx",
     5       "args": ["server-name@latest"],
     6       "timeout": 30000
     7     }
     8   }
     9 }

Для HTTP сервера с авторизацией:

      1 {
      2   "mcpServers": {
      3     "remote-server": {
      4       "httpUrl": "http://localhost:3000/mcp",
      5       "headers": {
      6         "Authorization": "Bearer your-token"
      7       }
      8     }
      9   }
     10 }

ВЫВОД

Всем спасибо за то , что прочитали мою статью. Пока я буду пользоваться qwen-ом , и вам советую. За свою цену, то есть за бесплатно, это лучший продукт , который только может быть. Подписывайтесь на
Твитер

https://x.com/p0stbless

https://x.com/p0stbless

https://x.com/p0stbless

Тгк

https://t.me/funtrona

https://t.me/funtrona

https://t.me/funtrona

Всем привет, с вами postbless, в вайбкоде я совсем недавно, но активно изучаю эту нишу. В этой статье я бы хотел рассказать о том, что узнал на данный момент времени, а также какие материалы я собрал за это время. Ну чтож, приступим.

Принцип работы

Нейронная сеть — это математическая модель, работа которой имитирует принципы организации и функционирования биологических нейронных сетей мозга. Если упростить, это программа, состоящая из множества слоев «узлов» (нейронов). В общем она не работает по жестко прописанным алгоритмам (если А, то Б). Вместо этого нейросеть обучается на огромных массивах данных, находя в них закономерности. Каждый нейрон в сети принимает данные, обрабатывает их и передает следующему слою, пока не получится итоговый результат.
Теперь кратко о их видах
p.s
Видов нейросетей огромное количество, и чтобы описать каждую, понадобится статьи 3, поэтому я выделил самые основные, и самые интересные по моему мнению, если захотите прочитать поподробнее, можете прочитать статью Кисы
1. Мультимодальные модели (Multimodal AI)

Это нейросети, которые могут не просто читають текст, а буквально видеть, слышать и говорить. Ты можешь скинуть им скриншот ошибки в коде, надиктовать голосом вопрос и получить в ответ готовое видео или схему.

• Примеры: Gemini 3 Flash, GPT-4o, Claude 3.5.
• Фишка: Понимают контекст во всех форматах сразу.

2. Трансформеры и LLM

Основа современных чат-ботов. Эти модели заточены под работу с огромными объемами информации. Их главная задача — предсказать следующий элемент в цепочке (будь то ваше слово в предложении или строка кода в твоем проекте).

• Сферы: Написание чистого кода, глубокая аналитика данных, создание сложных текстов.
• Фишка: Невероятная логика и «память» на детали внутри диалога.

3. Диффузионные модели (Diffusion Models) — «Цифровые художники»

Если раньше нейронки просто копировали стили, то эти создают контент буквально из «белого шума». Они постепенно убирают помехи с картинки, пока не получится шедевр. Сейчас они вышли за рамки просто фото и вовсю генерят видео и 3D-объекты.

• Примеры: Midjourney, Stable Diffusion, Sora (видео), Pika.

Какие ИИ использовать в 2026 году?

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

О терминах

Чтобы понимать дальше сказанное , вам нужно прочитать базовые термины, которые я буду использовать в статье.

Контекст - это активный объем данных (возможно вы слышали, объем измеряется в токенах), который модель обрабатывает одновременно для генерации ответа. Технически это как окно оперативной памяти, внутри которого работает механизм внимания: нейронка вычисляет математические связи между всеми словами в этом массиве. Если информация выходит за пределы установленного лимита (контекстного окна), она физически перестает участвовать в расчетах, и модель теряет к ней доступ при формировании следующего слова. Сейчас большинство хороших моделей используют контекстное окно лимитом в 1 лям токенов. Заполнить их возможно, если ты вайбкодишь огромный проект, но так же в нейросетях , например в Claude , есть функция сжатия контекста, понимание что сжать, что удалить, а что оставить в окне.
Из контекста выливается деградация нейросети.
Деградация нейросети — это замыливание внимания, когда при росте объемов данных, которых мы прислали модели, модель начинает хуже различать важные детали в массиве информации. При высоком проценте деградации нейросеть начинает отдавать приоритет только началу и концу, середина же остается размытой. Получается чем больше запросов вы совершаете , тем больше нейросеть деградирует.
Интересный факт: если в нашем контексте проскочила одна неточность или баг, то это становится частью «фундамента» для всех последующих расчетов нейронки. То есть наше рабочее пространство превращается в среду, где нейросеть начинает ловить глюки и забывать наши исходные правила.

О MCP серверах

MCP сервера позволяют нейросети напрямую подключаться к внешним инструментам и вашим данным. Технически это работает как универсальный переходник: вместо того чтобы вручную копировать текст или файлы в чат, вы даете модели доступ к сервисам через специальные серверы. Это позволяет ИИ в реальном времени обращаться к базам данных, API, локальным файлам или браузеру, самостоятельно подтягивая нужную информацию.

О скиллах

Скиллы — это готовые инструкция для нашей нейросети, которые ты ей подкладываешь, чтобы она не гадала, как делать задачу, а работала по нашим правилам. По сути тебе не нужно писать ей правила, а можно просто найти скилл, в котором и так это написано. Это сохраняет наше время. Вообще технически это просто текстовые файлы формата .md, которые лежат в специальной папке нашего проекта. Когда ты запускаешь ИИ-агента то он первым делом сканирует этот файл и юзает правила из этих файлов в свою активную память.

Github и как работать с ним

GitHub — это крупнейший веб-сервис и облачная платформа для хостинга IT-проектов и их совместной разработки. Если простыми словами , то это просто облачный диск, где хранится ваш код, и изменения вашего кода.

Как его использовать?

1. Подготовка

Выбираешь, какие файлы хочешь отправить. Точка означает все наши измененные файлы

git add .

2. Коммитим

Создаешь чекпоинт и кратко описываем, что именно мы изменили.

git commit -m "обновил дизайн дашборда "

3. Пушим

Закидываешь всё это в облако гитхаба.

git push

Все эти действия проводим в терминале папки, в которой лежит проект.
Если вы не привязали папку в гитхабе , то для начала

Нам сначала нужно подружить папку с GitHub (или же инициализировать:

1. git init — создать пустой репозиторий в папке.
2. git remote add origin [ссылка-на-ваш-гитхаб] — привязать адрес.
3. git branch -M main — назвать главную ветку.

О хостингах

1. Хостинги для Фронтенда (Vite, React)

Это сервисы для быстрой публикации интерфейса. Они подключаются напрямую к вашему GitHub и обновляют сайт каждый раз, когда вы делаете git push.

• Vercel: Лидер индустрии. Идеально оптимизирован под современные фреймворки. Очень быстрый за счет сети Edge-серверов по всему миру.
• Netlify: Главный конкурент Vercel. У него отличная бесплатная версия, которая позволяет использовать проект в коммерческих целях (в отличие от бесплатного тарифа Vercel).
• Cloudflare Pages: Самый быстрый вариант с точки зрения доставки контента. Дает безлимитный трафик даже на бесплатном тарифе.

2. Хостинги для Бэкенда и базы данных(Node.js, Python, PostgreSQL)

Нашему проекту нужно где-то хранить данные пользователей или запускать сложные скрипты, которые нельзя выполнить в браузере:

• Railway: Самый простой «облачный» сервис. Мы просто даете ссылку на репозиторий, и он сам определяет, как запустить ваш сервер или базу данных.
• Render: Отличная альтернатива старым сервисам вроде Heroku. Поддерживает авто-развертывание и дает бесплатные базы данных на короткий срок для тестов.

Вообще можно и на одном хостинге сделать , но разделение дает огромный плюс в безопасности и масштабируемости. Если наш фронтенд упадет из-за наплыва пользователей, база данных на бэкенде останется в сохранности. Это обезопасит наши данные.

Модели нейросетей

На сегодняшний день есть уже много хороших нейросетей, но я бы советовал вам связку Gemini и Claude, да вам придется потратиться на подписку Gemini( она относительно не дорогая, около 1900 - 2500 рублей в месяц, если захотите порыскать вот ссылка на ggsel , там должно быть дешевле.

Так же вам нужно будет купить подписку на Claude , да дорого , но зато качественно, и я вам гарантирую , что если у вас руки не из одного места растут, то в вашем коде будет ни одной ошибки. Так же Claude являются новаторами, часто вводят фичи, которых нет у конкурентов, этим и обусловлена цена, и выбор именно этой нейронки. Pro стоит около 20$. Для тех, кому Pro мало, есть Claude Max: $100 в месяц (лимиты в 5 раз выше Pro) или $200 в месяц (в 20 раз выше Pro с нулевой задержкой). Этот тариф выбирают те, кто вайбкодит в Claude по 10 часов в день или работает с очень большими объёмами данных.

Теперь я хочу затронуть тему API ключей

Вообще API-ключ — это уникальный идентификатор, который работает одновременно как наш логин и пароль для программы.

Если прям по глупому , то это пропуск, который наше приложение предъявляет стороннему сервису (например, Alchemy или CoinMarketCap), чтобы получить от него данные.

Вы спросите для чего они нужны?

• Идентификация: Сервис понимает, кто именно обращается к его серверам.
• Контроль лимитов: Большинство сервисов дают, например, 10 000 бесплатных запросов в день. Ключ помогает им вести счет.
• Безопасность и платные услуги: Если вы подписаны на платный тариф, ключ подтверждает ваше право на расширенные функции.

Главное правило: Никогда не пиши ключи прямо в коде

Если вы напишете апишку в файле, например const API_KEY = "12345", а потом мы сделаем git push,и наш ключ окажется на Гитхабе. И эти ключи просто спизукрадут

Для хранения ключей используют файл .env

Что такое .env файл?

Это обычный текстовый файл в корне нашего проекта, который выглядит так:

PlaintextVITE_ALCHEMY_KEY=ваш_ключ_здесь
DB_PASSWORD=пароль_от_базы_данных

Как им пользоваться:

1. Создаемфайл .env.
2. Добавляем именно .env в файл .gitignore, чтобы Git его игнорировал и никогда не отправлял на GitHub.

Безопасность

Последнее что я хотел бы затронуть, это безопасность при вайбкоде.

Первое правило бойцовского клуба. Проверяйте архитектуру.

Нейросети часто ошибаются в безопасности, даже если код работает идеально. Не проси ИИ написать «систему регистрации» одной фразой. Лучше сам определи стек.

Критический код: Авторизацию, платежи и работу с приватными ключами крипто-кошельков пиши максимально осознанно, проверяя каждую строчку. Желательно посмотреть гайды на всю эту тему, чтобы не лохануться

Второе правило бойцовского клуба. Защита от херовых библиотек

ИИ может придумать несуществующую библиотеку или предложить старую версию с дырами.

После того как ИИ добавил новые import в твой проект, загляни в package.json. Убедитесь, что эти библиотеки реально существуют и имеют много скачиваний.

Третье правило бойцовского клуба. Автоматические Рентген-сканеры

Поскольку при вайбкоде ты фигачишь код пачками, ты физически не сможешь прочитать всё.
Советую установить в проект автоматические сканеры (например, Snyk или SonarQube). Они будут подсвечивать опасные места (например, SQL-инъекции или небезопасный JavaScript) сразу после того, как ИИ их предложит.

Четвертое правило бойцовского клуба. Принцип чистого гита.

При создании проекта проект может разрастись очень быстро, и мы можем потерять контроль, чтобы этого избежать:

Делай коммиты (git commit) после каждой успешно выполненной подзадачи. Если иишка вдруг сойдет с ума и перепишет пол-проекта с ошибками, то мы сможем мгновенно откатиться назад.

Выводы

А на этом все , с вами был я, postbless, спасибо за прочтение статьи, еще увидимся!

https://x.com/p0stbless мой твиттер
https://t.me/funtrona мой телеграмм канал, с полезной инфой)
Всем удачи!

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

Claude Sonnet 4.5 Opus (Anthropic)

Claude( Ai от компании Anthropic) является одним из самых сильных инструментов. Его цена 100$/200$ в зависимости от того, сколько лимитов вы выберете( доступны x5 лимиты / x20) Так же имеет свой CLI-инструмент Claude Code для работы с вашим кодом.

Плюсы:

Минусы:

Вердикт

Если у вас есть деньги на Max x20 подписку , тогда берите , вы точно не прогадаете , и будете писать свои проекты с комфортом. Так же компания очень часто вводит новые фичи, которые никто не вводил до них, это точно жирный плюс.

Cursor - IDE

Cursor является форком VS Code (полностью совместимый с экосистемой VS Code), но со встроенным глубоким ИИ на уровне ядра редактора. Это не просто плагин — это отдельный редактор, где AI понимает твой проект целиком.

Плюсы

Минусы

Вердикт

Если есть огромное количество денег, и желание попробовать что то новое, можете взять подписку . По моему мнению цена не соответствует качеству, поэтому если у вас и есть деньги , лучше приобрести подписку в Claude code.

Antigravity - одно из лучших бесплатных решений.

Antigravity - интегрированная среда разработки с поддержкой AI разработанная Google.

Плюсы

Минусы

Вердикт

Antigravity — один из лучших бесплатных AI-редакторов кода на рынке, которым я пользуюсь по сей день. Unicode так же советовал ее)

Qwen - самое вкусное на последок.

Qwen — это семейство моделей от Alibaba Cloud, главный китайский конкурент ChatGPT, Claude и Gemini. Так же имеет свой Qwen cli.

Плюсы

Минусы

Вердикт

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

Конец

Всем спасибо за внимание , не забывайте подписываться на мои соцсети!!

https://t.me/funtrona - TGK
https://x.com/p0stbless - twitter
с вами был Postbless.