Эксперименты с вайб-кодингом
Недавно попалась на глаза интересная фраза: «настоящая микросервисная архитектура — это когда любой компонент проще взять и переписать с нуля, чем разбираться в коде прежней реализации». Подумалось, что написание таких микросервисов и есть идеальный вариант применения вайб-кодинга, т.е. кода, сгенерированного полностью с помощью ИИ. Задумал сделать аналог IntB на микросервисах, но с рядом отличий: вместо чёткой иерархии раздел-тема-сообщение, каждая из которых хранится в отдельной таблице, будут просто сущности, связанные отношениями различных типов (как задумывал, когда начинал делать MLFW), и вместо числовых ID для них и пользователей будут использоваться UUID в целях универсальности.
Начать решил с микросервиса рассылки уведомлений. Написал такой prompt:
Напиши микросервис на Go, отвечающий за отправку уведомлений, связанных с различными сущностями. Идентификатор сущности — строка произвольного вида. Микросервис должен предоставлять методы API для того, чтобы подписчик мог подписаться на уведомления, отписаться от них, и собственно отправки уведомления всем подписчикам на конкретную сущностью. Каждый подписчик идентифицируется тремя параметрами: GUID подписчика в системе в целом, канал доставки и адрес получателя. Каналы доставки могут быть такие: EMail, Telegram, push-уведомление в браузере, публикация в Livejournal. Адрес получателя — соответственно, адрес электронной почты, если канал — Email, номер пользователя в Telegram, URL для отправки PUSH в случае броузера и адрес журнала + хеш пароля для Livejournal. Предусмотреть возможность в дальнейшем добавления новых каналов доставки.
Для хранения данных может использоваться одна из следующих СУБД: PostgreSQL, MySQL, SQLite. Особое внимание портируемости, чтобы базу данных можно было легко перенести с одной из перечисленных СУБД на другую.
Скормил его локальному Qwen3 Coder 30B, тот написал вполне годный код по структуре, но вместо реализации конкретных отправок ограничился функциями-заглушками:
// Примеры реализаций отправки уведомлений (в реальной системе эти методы будут реализованы полноценно)
func sendEmail(email, message string) error {
// Логика отправки email
log.Printf("Sending email to %s: %s", email, message)
return nil
}
func sendTelegramMessage(userID, message string) error {
// Логика отправки Telegram сообщения
log.Printf("Sending Telegram message to user %s: %s", userID, message)
return nil
}
// и т.д.
Все попытки заставить его это доработать хотя бы только для EMail ни к чему не привели даже при наличии явного указания «реализуй это в таком-то методе»: либо он выдавал примерно тот же самый код с заглушками, либо писал отдельный проект, где реализовывал эту самую функцию отправки.
Потом то же самое решил проделать с DeepSeekом. Тот вроде для SMTP и Telegram реализацию сделал, а для ЖЖ оставил заглушку, но по сравнению с Qwen Coder слишком уж переусложнил структуру проекта.
Ребята, давайте жить спокойно!
Я написал ash скрипт на ~1200 строк (половина - комментарии) для чтения логов в файл с ротацией, awk конвейером, FIFO и кучей разных мелких штук за пару дней (неделя? или около того) с помощью qwen. Все от идеи до кода я сделал с qwen и парой других ии.
Я никода до этого не работал так плотно с линуксом и вообще никогда не писал bash скрипты длинее 3 строк.
Так же я начал делать DSL для автоматической генерации awk скриптов, но чё-та подзабил...
В общем за ии кодом будущее. Уже мечтаю, как программы и кастомные ОС будут подключаться к терминалам через динамически генерируемые API...
Столь ленивому существу как я просто фзически интереснее объяснять ии какой код я хочу.
Qwen в этом плане получше DeepSeek будет. Дипсик слишком усложняет, практически не думая зачем по-настоящему. Qwen же больше про подумать: qwen3 обладает гибридным движком рассуждений.
P.S. О черт! Теперь я сам как LLM говрю.
У вас нет прав для отправки сообщений в эту тему.

