Запуск бета-версии интеллектуального агента по оценке проектов
Откройте для себя 'Умную Оценку Проекта (Beta)' - нашего интеллектуального агента-аналитика, который поможет вам структурировать требования и получить предварительную оценку проекта в один клик. Ускорьте старт проекта и избегайте бесконечных дискуссий.
Авторы: slavb18
Вайб-кодинг: от идеи до работающего прототипа за пару часов
Сегодня скорость важнее бесконечных архитектурных дискуссий. Мы запустили бета-версию Умной Оценки Проекта - инструмента, который за пару минут структурирует хаотичные требования и прикидывает масштаб работ.
Самое интересное здесь не только в функционале, а в том, как это было сделано. Это чистый vibe coding.
Инструментарий: Google AI Studio
Прототип был создан в Google AI Studio. Основная фишка такого подхода - вы "кодите" в диалоге с моделью, которая тут же позволяет запускать и тестировать код. Есть и другие решения вроде Lovable, но AI Studio оказалась под рукой и отлично справилась.
Процесс максимально простой:
- Генерируем логику в AI Studio.
- Коммитим в GitHub.
- Деплоим на Vercel.
Архитектура (точнее, её отсутствие)
Давайте будем честны: структура кода здесь "ужасная".
- Нет DI (Dependency Injection).
- Принципы SOLID даже не пробегали мимо.
- Сопровождать такой код в долгосроке - та еще задача.
Но для прототипа это идеальное решение. Весь фронтенд живет в одном огромном файле App.tsx, а бэкенд - в server.ts. Это не про "правильный код", а про "работающее решение". Как прототип - он полностью выполняет свою задачу.
Чтобы строить серьезные системы с RBAC, сложными админками и высокой надежностью, по-прежнему нужны глубокие инженерные скиллы. Но для проверки гипотезы - вайб-кодинга более чем достаточно.
Технические грабли: PDF на Vercel
Одна из проблем, с которой пришлось столкнуться: локально парсинг PDF работал идеально, а на Vercel (в Serverless функциях) - наотрез отказался. Пришлось "погуглить" и адаптировать импорты.
Пример того, как выглядит бэкенд-обработчик (просто, прямолинейно, без лишних абстракций):
app.post('/api/extract-text', upload.single('file'), async (req, res) => {
try {
if (!req.file) throw new Error('Файл не получен');
const { originalname, buffer } = req.file;
const extension = originalname.split('.').pop()?.toLowerCase();
let text = '';
if (extension === 'pdf') {
const { PDFParse } = await import('pdf-parse');
const parser = new PDFParse({ data: buffer });
const result = await parser.getText();
text = result.text;
await parser.destroy();
} else {
text = buffer.toString('utf-8');
}
res.json({ text });
} catch (error: any) {
res.status(500).json({ error: error.message });
}
});
И обработка требований через LLM:
app.post('/api/ai/detail', async (req, res) => {
const { requirement } = req.body;
const response = await ai.chat.completions.create({
model: 'gpt-4o',
messages: [
{
role: "system",
content: 'Decompose requirements and return JSON: { "detailedDescription": "...", "estimate": "XS | S | M | L | XL" }'
},
{ role: "user", content: `Name: ${requirement.name}\nDescription: ${requirement.description}` }
],
response_format: { type: 'json_object' }
});
res.json(JSON.parse(response.choices[0].message.content));
});
JSON-боль и LiteLLM
Еще один нюанс всплыл при переходе с прямой работы с Gemini на работу через прокси-шлюз LiteLLM (для подключения моделей OpenAI и других).
В изначальной "навайбкоженной" версии на чистом Gemini проблем с парсингом JSON почти не было. Но как только в цепочке появился прокси-шлюз, начались странности: лишние переносы строк внутри значений, "битые" кавычки и другие артефакты, которые ломали стандартный JSON.parse.
Чтобы не тратить время на бесконечные правки промптов, мы выделили решение в отдельную открытую библиотеку:
Это небольшая надстройка над мощным инструментом @qraftr/json-repair. Почему не использовать его напрямую? Потому что даже он иногда пасует перед специфическими "глюками" LLM-шлюзов (например, когда строка обрывается посередине или содержит неэкранированные литералы). Наша утилита добавляет слой эвристик, который "склеивает" такие куски до того, как они попадут в основной парсер.
Итог
Главное изменение рынка сейчас не в самом факте появления AI. А в том, что разница в скорости между командами стала x5-x10. Пока одни спорят, какой фреймворк "правильнее", другие используют вайб-кодинг, чтобы проверить гипотезу и собрать обратную связь.
Ждем вашего фидбека! В долгосрочных планах - интеграция в ai-native цикл SDLC от идеи и формирования команды до релиза.