Comments 84
Полезно, спасибо!
Прям в точку. У нас была похожая история — генерили через Claude эндпоинты для файлового хранилища, всё выглядело чисто, линтер доволен, тесты проходят. Потом senior посмотрел и нашёл именно path traversal — почти один в один как в статье. Самое обидное, что код был «уверенный», без единого намёка на то что там проблема.
С тех пор правило простое: LLM пишет черновик, человек с контекстом смотрит граничные случаи. Особенно всё что касается авторизации и файлов. Без этого — рулетка.
Это всё не новость. Для того чтобы делать реально сложные проекты с помощью ЛЛМ надо разбираться в теме, архитектуре пприложений, особенностях стека итд.
Именно поэтому я уверен что разработчиков всех не поувольняют . Вернее, может какие нибудь ретивые оптимизаторы из менеджемента и поувольняют - но потом им придётся этих разработчиков нанимать обратно )).
Кстати, пример про копирайтинг с наушниками плохой. Говорю как меломан со стажем. И в донейросетевую эпоху рекламные тексты звукового оборудования все как один гарантировали кристально чистый звук - от дешманского оборудования за копейки до лампового хайенда собранного девственницами на склоне горы Фудзи. Так что тут мимо ).
Хороший пример.
Но плохие примеры. Попробуйте сами прогнать те же промпты что у автора через нормальные модели, а не какую-нибудь несчастную Llama-3-8b в четырёхбитном кванте, удивитесь. Вот как в описании чистая сессия, новый чат... Посыл статьи понятен, но мухлёж с примерами - некрасиво так, 3й пример я смог частично воспроизвести только у deepseek и то с оговоркой:
Скрытый текст
напиши фукцию реализующую следующее: Сравнить токен пользователя с правильным, вернуть True/False
Вот простая функция на Python для сравнения токенов:
def compare_tokens(user_token: str, correct_token: str) -> bool:
"""
Сравнивает токен пользователя с эталонным.
Возвращает True, если совпадают, иначе False.
"""
return user_token == correct_token
Для большей безопасности (защита от timing-атак) лучше использовать константное сравнение:
import secrets
def compare_tokens_secure(user_token: str, correct_token: str) -> bool:
"""
Безопасное сравнение токенов, устойчивое к атакам по времени.
"""
return secrets.compare_digest(user_token, correct_token)
Примечание: secrets.compare_digest принимает строки или байты и работает одинаковое время независимо от содержимого. Рекомендуется для проверки паролей, токенов, HMAC и т.п.
Признаю, примеры натянутые для демонстрации контраста.
Но контраст намеренный, что бы тем кто не тру-кодер - было заметно
В таком контексте - да, но лучше, думаю сразу оговаривать, а то прочтёт этот вайбкодер статью, почешет себе, допустим, затылок - и решит и вправду проверить в своей нейронке. Увидит что ответ нейронки почти как в исходном opensource примере да и решит "о, а у меня ИИ ошибок не делает" да и уйдёт себе вайбкодить дальше так ни о чём и не задумавшись.
Все зависит не только от того, как написан промт. Но и от того какая изначально задача стоит, которая так же является одним из весомейших аргументов в принятии моделью решений при написании кода. Если ты сам молчишь про безопасность - то и нейронка ни слова тебе не скажет про нее, потому что цель "дать работающую функцию", это уже посыл не про то, что вайбкодеры не "шарят", а о том что с нейросетями надо УМЕТЬ работать. Ну и конечно смотреть шире, чем "напиши работающий код".
Тем не менее не зря же появилось появилось понятие - промт-инженерия. Пример, один и тот же контекст:
- напиши функцию санитизации файлов.
- напиши готовую функцию санитизации файлов, с удалением спецсимволов, дедупликацией, невозможностью выйти за пределы каталога при загрузке с проверкой mime-типов.
Пример соглашается с автором статьи :)
Результат во втором случае - будет лучше, потому что деталей больше. Проблема в целом существуют. Молодые ребята пытаются совершить революцию, думая "щас все буит, нейронка напишет!". Но увы, в серьезной инфраструктуре, корпоративных продуктах есть вещи, о которых ребята (просто из-за отсутствия опыта) пока еще не знают.
С нейронками пишется быстрее, но представленный код ВСЕГДА надо проверять и задавать вопросы. Иначе будет шляпа...
Тем не менее не зря же появилось появилось понятие - промт-инженерия
кажется сейчас (за счет токенов, но тем не менее) активно начинают обходить проблемы наивности промта. По сути и джун напишет как ЛЛМ, не учтет все символы и тп. Но ему это скажут. Причем скорее всего - письменно, в код кондакте команды, что нужно соблюдать стандарт вон тот, а еще особое внимание с файловой системой вот на это, а с авторизацией - вон на то. Соответственно эти стандарты надо класть в доступе агенту и коротенькую выжимку в оперативный кэш - в каких случаях в какой стандарт обязательно слазить.
И вот уже в проекте можно писать наивные промты, ИИ на этапе проверки решения пробежит по чеклисту качества, а не только работоспособности.
Ну это если мы говорим про корпоративную разработку, то там контекст репозитория можно подсунуть агенту. Насколько знаю сейчас активно многие компании свой внутренний ИИ внедряет чуть ли не повсеместно. И тут агенту явно можно ткнуть - я вот хочу написать, но загляни в локальную репу и глянь как это организовали мои коллеги.
Хотя и внутри одной команды бывает такой раздрай... Один пишет так, другой пишет иначе. Хотя оба работают совместно долго, и вроде как соблюдают стандарты. Но реализация разная, и поди агенту объясни, кто прав, а кого на кол)
и джун напишет как ЛЛМ, не учтет все символы и тп. Но ему это скажут
И более того, он это запомнит (ну, во всяком случае, у нас — запоминают) и больше так не сделает. А у нейронки каждый новый «разговор» — с чистого листа (а если прописать в дефолты — то это отжирает от окна).
Так внешняя долгосрочная Memory.md и многопроходность - именно то о чем я и говорю. Да, за токены но почти без окна. Можно в промт - тогда за счет окна, но экономим на проходах.
(а если прописать в дефолты — то это отжирает от окна).
Дефолты это же системный промт? Я просто промты не делю когда говорю про контекстное окно, а не про то, что пишет человек.
Как это «не делите»? Это я Memory.md в отдельную сущность вынес, что ли?
Я не делю промты (системный и текущий) но делю промты и данные из инструментов. Так как в инструментах данных зачастую куда больше, чем в контекстном окне, то есть нельзя просто вычесть объем инструментов из контекстного окна, отрицательные числа получатся. А объем промта - можно.
Ну то есть у Вас знаменитое «тут играем, тут не играем, а тут жирное пятно — рыбу заворачивали ©»?
Для большей безопасности (защита от timing-атак) лучше использовать константное сравнение:
А теперь представьте, что где-то на планете есть не очень опытный программист, который пока ещё не слыхал про этот вид атак, а нейронка ему сама сразу подсказала. Вот за это и ценят нейросети те, кто пока ещё не достиг вершин в своей области. Автор как-то упустил из виду, что не все программисты знают больше, чем знают современные нейросети - многие, наоборот, у них учатся.
Отличная статья. Самое обидное, что заказчики часто видят только «работает» и им сложно донести, что под капотом легаси, которое через месяц развалится. Сейчас реально стало тяжелее объяснять разницу между «накидал на коленке» и архитектурным подходом. Вайб-кодинг - это круто для прототипа, но убивает продукт на дистанции, когда начинаются реальные баги.
Сейчас реально стало тяжелее объяснять разницу между «накидал на коленке» и архитектурным подходом.
Это заказчикам довольно быстро объяснят хакеры, которые будут ломать такие поделки пачками и использовать для "заработка". Вот пару раз попадет заказчик на деньги тогда и задумается.
Что мешает мифос как валидатор направить?
Скорее всего профессионализм человека, который будет это делать. Он же помешает ему понять какие вещи нужно фиксить, а какие - нет. Он же помешает их пофиксить. Он же помешает понять, что фиксы от нейронки могут сломать логику в другом месте.
Что мешает мифос как валидатор направить?
В битве меча и щита, всегда побеждает меч.
Сейчас реально стало тяжелее объяснять разницу между «накидал на коленке» и архитектурным подходом
Расскажите им сказку про 3 поросёнка по дом из соломы, дом из веток, дом из камня
Код сопротивляется изменениям.
Чем меньше думали как сделать архитектуру гибкой тем больше сопротивляется.
Неверующих можно отправить в clean architecture, в самом начале графики роста стоимости новой строки кода от роста кодовой базы/количества накопленных изменений. Они катастрофические.
Важно разделять, если вайбкодингом заменяют нормальную разработку в живом продукте: да это на грани добра и зла.
Но на стадии MVP задача другая: дёшево проверить, есть ли у идеи спрос.
Не покупают выбросил. Покупают тогда уже нужна нормальная разработка.
Проблема не в плохом коде AI-MVP, а в том, что временную проверку спроса начинают считать готовым продуктом.
Вопрос, который был задан в заголовке статьи примерно эквивалентен следующему вопросу:
Как разубедить AI-леммингов в том, что Андрей Карпатый - "AI-Бог", и слово его "Истина"?
Как понимаете, дело это гиблое, "навайбкоденное" будет считаться "нормальным кодом" ещё очень и очень долго.
А что делает живой копирайтер? Он пишет конкретику, которую можно проверить: сколько часов держит зарядка, за сколько секунд коннектится, что слышно, а что нет. И — самое важное — он называет недостаток.
Хахахахахахахаххахахахахахах. Ххахаах. Ха-ха. Нет.
А наивный ответ на «напиши простой аналог
lru_cache»:
Хз, кто вам там что пишет без вытеснения
Простейшая реализация на OrderedDict:
pythonfrom collections import OrderedDict
from functools import wraps
def lru_cache(maxsize=128):
def decorator(func):
cache = OrderedDict()
@wraps(func)
def wrapper(*args, **kwargs):
key = (args, tuple(sorted(kwargs.items())))
if key in cache:
cache.move_to_end(key) # отметить как недавно использованный
return cache[key]
result = func(*args, **kwargs)
cache[key] = result
if maxsize is not None and len(cache) > maxsize:
cache.popitem(last=False) # выкинуть самый старый
return result
return wrapper
return decorator
Использование:
python@lru_cache(maxsize=2)
def slow_square(n):
print(f"вычисляю {n}")
return n * n
slow_square(2) # вычисляю 2
slow_square(2) # из кеша
slow_square(3) # вычисляю 3
slow_square(4) # вычисляю 4 — теперь 2 вытеснен
slow_square(2) # вычисляю 2 (снова)
Ключевые моменты этой реализации:
OrderedDict поддерживает порядок вставки, а move_to_end позволяет дёшево обновлять «свежесть» элемента — это и есть суть LRU. При переполнении popitem(last=False) удаляет самый давно использованный.
Формирование ключа (args, tuple(sorted(kwargs.items()))) — упрощённое. Настоящий functools.lru_cache использует _make_key, который аккуратнее обрабатывает порядок аргументов и типы. Здесь есть ограничение: все аргументы должны быть хешируемыми (как и в оригинале).
Если хочется ближе к оригиналу — добавить статистику и метод сброса:
pythonfrom collections import OrderedDict
from functools import wraps
def lru_cache(maxsize=128):
def decorator(func):
cache = OrderedDict()
hits = misses = 0
@wraps(func)
def wrapper(*args, **kwargs):
nonlocal hits, misses
key = (args, tuple(sorted(kwargs.items())))
if key in cache:
cache.move_to_end(key)
hits += 1
return cache[key]
misses += 1
result = func(*args, **kwargs)
cache[key] = result
if maxsize is not None and len(cache) > maxsize:
cache.popitem(last=False)
return result
def cache_info():
return {"hits": hits, "misses": misses,
"maxsize": maxsize, "currsize": len(cache)}
def cache_clear():
nonlocal hits, misses
cache.clear()
hits = misses = 0
wrapper.cache_info = cache_info
wrapper.cache_clear = cache_clear
return wrapper
return decorator
Стоит иметь в виду: настоящий functools.lru_cache написан на C, потокобезопасен (блокировка вокруг обновления кеша) и использует кольцевой двусвязный список вместо OrderedDict. Для учебных целей и однопоточного кода версия выше эквивалентна по поведению; для многопоточности нужно обернуть доступ к cache в threading.Lock.«Ты просто не ставишь пять линий после вишни — вот и не выигрываешь!» ©
нейтральный чат на «сделай безопасное имя файла»
Ну это так не работает. Из расплывчатых описаний получается ерунда. Чем чётче описана задача, тем лучше будет результат. Вайб кодинг это все ещё про программирование, а не телепатию.
напиши простой аналог
lru_cache
Ага, так и вижу себе вайбкодера, который задаёт подобные промпты. Забывается как-то для чего вообще нужны программы - решать чьи-то задачи. Если вайбкодер сделал то, что решает его задачи и полезно кому-то ещё, это купят. А всякие там кеши и безопасность уже будет допиливаться той же нейросетью при необходимости. Ну, или подключится кто-то, кто знает как пинать нейросеть. Кстати, какая модель это писала? Сомневаюсь, что Opus. Может Haiku или китайщина какая-то вообще?
Кстати, вот часто такое наблюдаю, straw man bias типичный. Строится ложный образ кого-то и выполняется критика. Я не особо вайбкодер в рабочих проектах, только в своих мелких относительно, но понял, что вайбкодинг это несколько другое понимание вообще промптов и логики работы нейросети. Уж точно, не конкретные строгие запросы, ограничивающие возможности нейросети по реализации задуманного, зато больше введение в контекст, в то, что в итоге хочется получить. Не жёсткие указания, а скорее дискуссия, из которой у модели появляется более глубокое понимание требований и она потом даёт адекватный результат. Ну, и там много на самом деле всяких техник и подходов. Часть интуитивно нащупал, сильно глубоко не копал прямо. И всякую оркестрацию агентов и харнесы они освоили получше нас с вами.
Оно будет допиливаться, конечно. Но вопрос в том, когда именно выяснится, что код нуждается в допиливании и какого масштаба катастрофа привлечет к этому внимание.
Да, это возможно и уже происходит. Но это запустит уже конкуренцию среди вайбкодеров, курсы и прочее. Тоже навык, который надо будет совершенствовать, а с учётом постоянного изменения и появления новых моделей, подходы тоже должны будут постоянно меняться. Если раньше писали "думай по шагам", теперь это наоборот вредно. Многие вещи, ради которых раньше писали монстроидальные промпты, теперь работают из коробки.
Надуманные примеры неизвестной модели. Вот code review примера с безопасным именем файла: https://chatgpt.com/share/6a407dd0-2400-83eb-8cae-8e0211e5b58e
То есть достаточно будет даже вайбкодеру сказать нормальной модели "проверь что все предельно безопасно и меня никто не взломает" (они не такие тупые, какими вы их себе нарисовали) и она много чего поправит, ну, и скорее всего не напишет просто тот код, что приведен.
Amateur! Вот как надо!
Я согласен что примеры натянуты. Это специально что бы разница была заметна для профанов (профанов среди вайбкодеров)
Но писать в промпте "все предельно безопасно и меня никто не взломает" - среди вайбкодеров это уже мастерство))
Они просто не догададываются до этого, как я наблюдаю
Нейронка тянет самый частый ответ. Не лучший для вашей системы, не идиому вашей кодовой базы, не решение с учётом будущих изменений, а вероятный паттерн из обучения.
Самый частый где не понял что-то? Это всё совсем не так. Если вы ей дали код своей системы, то она именно что будет учитывать его, особенно если в промпте об этом указано, а в системных промптах там чего только не указано. Недавно листал логи, так там для того, чтобы сделать фразу из 5 слов о том, что модель делает сейчас, идёт промпт на несколько экранов. Ну, это так, к слову.
Если самый частый в ответ на абстрактный, оторванный от кодовой базы запрос, так тоже нет, есть же температура всегда какая-то, ну и это не энграмы, там посложнее логика. Фразы такой может и не встретиться нигде, а ответ она даст.
Интересно было бы узнать на сколько критично оставлять «не тру» код в проекте, который разрабатывается фрилансером за небольшие деньги. Почему-то мне кажется, для тех 10 пользователей продукта это не так критично.
ChatGPT 5.5
>> Напиши на Python функцию secure_filename, учитывая ограничения всех ОС
Ни одна функция не может гарантировать допустимость имени на абсолютно любой файловой системе, но можно использовать консервативный набор правил: запретить управляющие символы, разделители путей, специальные символы Windows, зарезервированные имена устройств и ограничить имя 255 байтами UTF-8.
from __future__ import annotations
import os
import re
import unicodedata
from typing import Union
# Зарезервированные Windows-имена остаются запрещёнными
# даже при наличии расширения: CON.txt, NUL.json и т. д.
_WINDOWS_RESERVED_RE = re.compile(
r"^(?:"
r"CON|PRN|AUX|NUL|CLOCK\$|"
r"COM[1-9]|LPT[1-9]"
r")(?:\..*)?$",
re.IGNORECASE,
)
# Символы, запрещённые Windows.
# "/" и "\" также являются разделителями путей в Unix/Windows.
_INVALID_CHARS = frozenset('<>:"/\\|?*')
_WHITESPACE_RE = re.compile(r"\s+")
def _truncate_utf8(value: str, max_bytes: int) -> str:
"""
Обрезает строку до max_bytes байт без повреждения UTF-8 символа.
"""
if max_bytes <= 0:
return ""
encoded = value.encode("utf-8")
if len(encoded) <= max_bytes:
return value
return encoded[:max_bytes].decode("utf-8", errors="ignore")
def secure_filename(
filename: Union[str, os.PathLike[str]],
*,
replacement: str = "_",
max_bytes: int = 255,
default: str = "file",
allow_hidden: bool = False,
) -> str:
"""
Возвращает безопасное имя файла, совместимое с основными правилами
Windows, Linux и macOS.
Функция:
- предотвращает path traversal;
- заменяет разделители путей;
- удаляет управляющие и форматирующие Unicode-символы;
- заменяет запрещённые Windows-символы;
- убирает точки и пробелы в конце имени;
- блокирует Windows-имена CON, PRN, NUL, COM1, LPT1 и т. д.;
- ограничивает размер имени в байтах UTF-8;
- по возможности сохраняет расширение.
Важно: функция обрабатывает только один компонент пути, а не полный путь.
"""
if max_bytes < 1:
raise ValueError("max_bytes должен быть больше 0")
if not isinstance(replacement, str) or not replacement:
raise ValueError("replacement должен быть непустой строкой")
if (
any(char in _INVALID_CHARS for char in replacement)
or any(unicodedata.category(char).startswith("C") for char in replacement)
or replacement.endswith((" ", "."))
):
raise ValueError("replacement содержит недопустимые символы")
value = os.fspath(filename)
if not isinstance(value, str):
raise TypeError("filename должен быть строкой или PathLike[str]")
# Нормализуем разные представления одинаковых Unicode-символов.
value = unicodedata.normalize("NFC", value)
sanitized: list[str] = []
for char in value:
category = unicodedata.category(char)
if char in _INVALID_CHARS:
sanitized.append(replacement)
elif category.startswith("C"):
# Cc: управляющие символы
# Cf: невидимые форматирующие символы
# Cs: суррогаты
# Co: private-use
# Cn: неназначенные символы
sanitized.append(replacement)
else:
sanitized.append(char)
value = "".join(sanitized)
# Пробелы, табуляции и переводы строк заменяются одним разделителем.
value = _WHITESPACE_RE.sub(replacement, value)
# Убираем повторяющиеся replacement.
if replacement:
value = re.sub(
rf"(?:{re.escape(replacement)})+",
replacement,
value,
)
# Windows не допускает пробелы и точки в конце имени.
value = value.rstrip(" .")
if allow_hidden:
# "." и ".." всё равно не должны сохраниться.
if value in {".", ".."}:
value = ""
else:
# Исключаем скрытые Unix-файлы и path traversal через точки.
value = value.lstrip(" .")
# Дополнительно убираем разделители по краям.
value = value.strip(replacement)
if not value:
value = default
# Запрещённые имена устройств Windows.
if _WINDOWS_RESERVED_RE.fullmatch(value):
value = replacement + value
# Стараемся сохранить расширение.
stem, dot, extension = value.rpartition(".")
if dot and stem and extension:
extension_with_dot = "." + extension
# Если расширение само превышает лимит, обрезаем всё имя целиком.
if len(extension_with_dot.encode("utf-8")) >= max_bytes:
value = _truncate_utf8(value, max_bytes).rstrip(" .")
else:
stem_limit = max_bytes - len(extension_with_dot.encode("utf-8"))
stem = _truncate_utf8(stem, stem_limit).rstrip(" .")
if not stem:
stem = _truncate_utf8(default, stem_limit).rstrip(" .")
value = stem + extension_with_dot
else:
value = _truncate_utf8(value, max_bytes).rstrip(" .")
if not value:
value = _truncate_utf8(default, max_bytes).rstrip(" .")
# После обрезания повторно проверяем служебные имена.
if _WINDOWS_RESERVED_RE.fullmatch(value):
prefix = replacement
available = max_bytes - len(prefix.encode("utf-8"))
value = prefix + _truncate_utf8(value, available)
return value
Что-то как-то многабукаф.
PathLib не? Там же минимум половина встроено
Напиши на Python функцию secure_filename, учитывая ограничения всех ОС
Ох, если вайбкодер даёт такой промпт, то он уже не совсем вайбкодер.
Некоторые из них даже не знают на каком языке их проект написан...
С одной стороны - тенденция полезная: "компьютер - сделай мне зашибись".
С другой стороны - пока-что оно сырое и обучено на всякой фигне статистически. "Дешева рибка - дешева юшка".
С третье стороны - надо доучивать хорошим кодом.
С четвертой стороны - за наши деньги для закрытого проекта.
----
Вывод - надо развивать открытые ИИ.
Как вот например практически все браузеры - это обои для Blink, которое Chromium, которое WebView, которое Konqueror (KDE).
Ох, если вайбкодер даёт такой промпт, то он уже не совсем вайбкодер.
Некоторые из них даже не знают на каком языке их проект написан...
Ну, т.е. мы переходим от критики ллмок как таковых к критике плохих кодеров, я правильно понял?
Да, всё, в чем ты не разбираешься, нейронка делает хорошо. Но вот то, в чем ты что-нибудь понимаешь, она всегда делает плохо)
Напомнило древний советский анекдот.
Делегация японцев на ВАЗе.
- Ну и как вам впечатления?
- Всё, что вы делаете руками - всё плохо. Но дети у вас красивые.
(но здесь совершенно противоположный результат).
Да, всё, в чем ты не разбираешься, нейронка делает хорошо. Но вот то, в чем ты что-нибудь понимаешь, она всегда делает плохо)
Чьорт побьери, Вам удалось пересказать мою историю крайне компактно. Утащу в мемориз.
‒ Спасибо за отклик на данную вакансию, мы современная компания и используем ИИ в нашем рекрутинговом процессе
‒ Почему тогда вы просто не используете ИИ для выполнения самой работы?
‒ Ну… он выполняет её некачественно и делает очень много ошибок.
‒ Тем не менее вы используете его для подбора персонала?
‒ … Спасибо ещё раз за ваш отклик, мы с вами свяжемся позднее.
Замените во всех этих рассуждениях "нейросеть" на "среднестатистический программист", что изменится? Люди ровно так же пишут плохой и небезопасный код, только стоят при этом намного дороже.
Мне понравилась мысль статьи, примеры вполне показательные, но искусственные:
У вайб кодеров вполне может быть ревью модель в харнессе, которая не пропустит такой lru кеш. Даже вопросом в чате: “Проверь ещё раз написанный код, какие проблемы ты видишь” можно это отловить.
Пример с тайминг атаками интересный, но я в него не верю. Даже по локальной сети стек “сеть + Python + чужие запросы” дают слишком много шума. Это точно не будет первая проблема даже у хорошо написанного приложения.
Примеры весьма показательны. Но я одного не могу понять: кто такие эти "вайб-кодеры"? Варианты вижу такие:
1. Профессиональный программист, которому надоело долго возиться с кодом. Но он все это увидит после генерации.
2. Дилетант, вообще не умеющий писать программы (я так понял, что речь о них). Но вопрос - а как вообще такой человек попал на должность, подразумевающую написание программ?
3. Дополнительный вариант: программист среднего уровня, который хочет казаться супер-пупер и вместо своего кода подсовывает нейросетевой, не особо вдаваясь в подробности. До поры до времени удается, потом - швах и позор.
Я себя отношу к категории 3 (да, писал суперские программы, но в узкой области, а многих сфер не знаю). Но мне в голову не придет использовать нейросети. Во-первых, из принципа, а во-вторых, именно потому, что я могу не понять их код. Поэтому даже js чужие использую только тогда, когда (и если) досконально в них разберусь.
Неужели люди настолько безответственны?
Конечно не первые. если разраб использует LLM для разработки - то он занимается разработкой при помощи LLM, это не вайбкодинг.
Скорее это вторая и третья группа.
На должность не обязательно попадать. Я см по найму не работал разрабом (только аналитиком), я на фрилансе - и сейчас там вайбкодеров, которые не имели никогда отношения к разработке - стало в 5-6 раз больше чем в начале года и они готовы делать сайты, ботов и так далее.
Думаю, вайбкодеры - те, кто вайбкодят. И это как пешеходы - любой водитель может иногда быть и пешеходом, то есть не какая-то стабильная характеристика. Менее применимо в рабочих процессах, более - в пет-проектах всяких. Вот Линус Торвальдс применял вайбкодинг в пет-проекте AudioNoise для настройки гитары. На самом деле это поле непаханое. Очень многих не устраивают чем-то чужие программы и утилитки. Раньше для непрограммистов вариант был или упрашивать добавить функцию, или нанимать программиста - долго и дорого и всё равно надо объяснять что тебе нужно. Сейчас открывается возможность написать для себя именно то, что нужно тебе лично. Вот что, мало приложений для настройки гитар? Их тысячи. Но его все они чем-то не устроили. Я уже так же писал игру-пасьянс без рекламы в подарок, симуляцию полета Артемиды к Луне, просто для себя визуализировать, утилиты на Python, которого почти не знаю, для юзер-ботов в телеграме, собирающих информацию по нужным мне критериям, скачивающих файлы, вступающих в группы с очередью запросов, кулдаун таймаутами и прочим, чтоб телеграм не сильно активно блочил. До этого всего я бы никогда не добрался если бы сам писал код. Тут я на него даже и не смотрел почти.
Даже не знаю, что сказать... Я не представляю себе, как можно описать нейросети задачу сделать программу, которая мне нужна. Например, я писал заменитель блокнота (коим и пользуюсь постоянно), ибо сам блокнот глючный и неудобный. Но как "промпт" составить на такую задачу? Я ведь за несколько лет несколько версий сделал, с развитием и даже сменой платформы. А чтобы с нуля "дать задание"... Не представляю.
Не надо пытаться сделать с нуля сразу всё. Это невозможно ни для вайбкода, ни для ручного программирования. Пусть вначале будет что-то базовое, минимальное, потом добавлять функции по одной, сохраняя версии на всякий случай. Попутно пусть она пишет тесты на все функции, чтоб с очередной итерацией ничего не развалилось. Не знаю точно, как с этим обстоит дело в десктопных приложениях, что сейчас возможно, что нет. Codex, в принципе может делать скриншоты и тыкать кнопки, но могут быть нюансы. На онлайн-пианино он у меня не сразу заиграл, например.
Я пишу только для десктопов, но лично для себя не вижу никакого смысла использовать ИИ. И неинтересно, и опасно, и просто как бы "свой интеллект есть". :) Конечно, если бы я работал в каком-то коллективе в большом бизнесе, где все так делают... Но Бог миловал. Такой формат работы не для меня вообще. :)
Одним промптом конечно это не делается)
Составление документации, архитектуры, выбор стека - это все остаётся
Да уж какая документация, когда для себя пишешь... :) А если для работы, так тоже... Не знаю, наверно тут у каждого свой опыт, свои вкусы и даже своя специфика работы. Мне даже интересно было бы дать ИИ задание на несложную программу, посмотреть что будет. У меня на сайте некоторые такие исходники есть. Наверно, попробую эксперимент сделать, а потом сравню и код, и результат. :)
Не, я доки делаю отдельными .md файлами для каждого проекта. Если работать через ЛЛМ, то это банк контекста, это их опыт, в который они записали весь путь, все пройденные ошибки, обнаруженные антипаттерны.
Это помогает для возвращения и доработку, фикса проекта, что бы не рассказывать каждый раз ЛЛМке что тут вообще происходит.
Так же доки становятся отличным банком данных и знаний для следующих проектов при разработке нейронками
Вот тут я подробно документирую, как я даю задание. Результаты... так себе.
Проблема вот в чём: сделает почти как надо, просишь подправить один конкретный элемент — оно опять ломает всё.
Вот что, мало приложений для настройки гитар? Их тысячи. Но его все они чем-то не устроили.
Или было то, которое его устроило бы, но найти его в навозной куче среди этих тысяч...
Будет больно
Когда появится система «БД требований ➔ бинарный код»?
До полностью автономного состояния «БД требований ➔ бинарный код» осталось 3–5 лет: технология станет коммерчески доступной к 2029–2031 годам.
Прямо сейчас, в 2026 году, ИИ уже умеет генерировать рабочие приложения из текстовых описаний, но только для простых и изолированных систем (вроде MVP на Python или простых веб-сервисов). Переход к созданию сложных enterprise-систем напрямую в бинарный код (минуя или скрывая под капотом промежуточные этапы вроде Git и Docker) упирается в три фундаментальные технологические проблемы, которые индустрия решает прямо сейчас.
График и этапы эволюции до 2031 года
Ограниченные MVP (Low-Code/No-Code ИИ)
│
[2027-2028] Появление спецификаций "ИИ для ИИ" (JIT-архитектура)
│
[2029-2030] Первые enterprise-компиляторы смыслов (БД требований -> Сервис)
│
[2031+] Полная автономность (Zero-Code / Прямая компиляция)
Почему это займет именно 3–5 лет? (3 барьера)
1. Проблема «Галлюцинаций в логике» (Ближайшие 1–2 года)
Если ИИ ошибется в коде веб-страницы, она просто криво отобразится. Если ИИ ошибется в логике транзакций ядра финтех-системы, компания потеряет миллионы. Чтобы собирать бинарный код напрямую из требований, нужны нейро-символические ИИ (Neuro-symbolic AI), которые соединят гибкость LLM со строгой математической логикой формальной верификации (как в аэрокосмических системах). Их коммерческое созревание ожидается к 2028 году.
2. Проблема декомпозиции (Ближайшие 2–3 года)
База данных требований enterprise-уровня содержит тысячи взаимосвязанных бизнес-правил. Современные контекстные окна ИИ огромны, но модели все еще «забывают» детали в середине текста или путают приоритеты требований. Требуется переход на архитектуры JIT-архитектуры смыслов, когда ИИ-оркестратор сначала строит динамическую граф-модель системы, а уже потом отдает её на компиляцию агентам нижнего уровня.
3. Избавление от «человеческого» исходного кода (К 2030–2031 годам)
Зачем компилировать требования сначала в C++ или Java, а потом в бинарник, если код больше никто не будет читать руками? К 2030 году появятся LLM-компиляторы, которые будут переводить логические требования напрямую в промежуточное представление (IR) вроде LLVM IR или сразу в байт-код / машинный код, оптимизированный под конкретный чип (x86, ARM, TPU), полностью исключая человека из цепочки ревью.
Как это будет работать на практике?
Когда эта технология станет стандартом, классический процесс разработки сожмется до одной итерации:
Сбор требований: Аналитики, продакты или сам ИИ наполняют БД требований (в виде структурированного графа знаний, графических схем и граничных условий).
Формализация: ИИ-верификатор проверяет БД на предмет внутренних противоречий (например, если требование А противоречит требованию Б, система сразу потребует уточнения).
Компиляция смыслов: Специализированная нейросеть трансформирует этот граф в бинарный образ (или Docker-контейнер с оптимизированным микросервисом) и автоматически покрывает его миллионами синтетических тестов.
Скрытая картинка
А пока видели мы, как они следуют чётко прописанным требованиям.
По мотивам данной статьи и обсуждения я решил сделать эксперимент: изобразить вайб-кодера и заставить ИИ написать программу, которую писал сам - сравнить. Результат получился любопытный, думал статью тут написать. Не знаю, интересно ли будет народу. А то как посмотришь - все тут такие продвинутые, чувствуешь себя заблудившимся ребенком... :)
Полагаю, что статью про это написать стоит)
Хорошо, тем более, что я углубил и продолжил эксперимент. :)
Не любят такие статьи. Обидно им, что не шмогла.
Я аналогичный, как сейчас говорят, челлендж предлагал — и все вайбкодеры куда-то стушевались.
Как объяснить вайбкодеру, что “работает” — не значит “сделано нормально”