Information
- Rating
- 1,354-th
- Location
- Рига, Латвия, Латвия
- Date of birth
- Registered
- Activity
Specialization
Фулстек разработчик, Архитектор программного обеспечения
Ведущий
JavaScript
HTML
CSS
Node.js
Vue.js
Веб-разработка
Progressive Web Apps
PostgreSQL
MySQL
GitHub
Полностью согласен. Я вообще пришёл к выводу, что человек не должен ревьюить код агента. Агент тупо быстрее на порядки. Я иду по пути проверки результата: работает - значит, не важно, как оно там внутри сложено. В следующую итерацию агент может переписать код вдоль и поперёк, главное - чтобы код выполнял свою функцию.
Я не говорю, что я вообще не смотрю на то, что делает агент. Как раз смотрю. Мне важно понимать, почему агент "вырвался из загона контекста". Кстати, он в сессии, зачастую, и сам может об этом рассказать, если его спросить. А потом важно переставить заборчики контекста так, чтобы он в следующий раз не вырывался.
У такого пути тоже есть свои ограничения, но, мне кажется, хорош любой путь, который позволяет дойти до границ. Главное - не за'loop'иться. Вот там-то границ как раз и нет :)
Мне кажется, что контроль результата работы LLM - это "путь тестирования". Тесты могут сказать, что работает неправильно, но они не говорят, как сделать, чтобы работало правильно.
IMHO, задача "парного кодирования с LLM" - держать агентов в определённых рамках и не давать им "проявлять творчество". Лично я ставлю на контекст (spec driven).
У всего есть свои пределы. Просто вы ещё не дошли до пределов вайб-кодинга, а Андрей Карпаты уже да. Причем где-то за месяц: в феврале - придумал, а в марте - дошёл.
Да. И это приведёт к тому, что подача материала и "мясными", и "силиконовыми" изменится. Потому что изменяется "приём" материала. Я, например, уже давно не читаю посты - я их сканирую. Пост по ссылке я просканировал и примерно могу сказать о чём там. И с большинством статей на Хабре я делаю так же. И вы, полагаю, тоже читаете не всё, а только то, что вас зацепило. И у вас есть свои алгоритмы быстрого анализа статей "на совместимость".
У меня был такой интересный случай лет 7-10 назад. На одном из местных новостных сайтов была опубликована реклама компании, в которой работала тогда моя жена. Я читал новости на ноуте, а она подошла и сказала: "О, наша компания новую рекламу запустила!". А я такой: "Где?!". Она: "Вон, на странице!". Вот я пялюсь на страницу и не вижу никакой рекламы. Пока она мне пальцем не показала - прямо в центре экрана, здоровый такой блок. В фирменных цветах и большой надписью с названием компании.
Мораль - мой мозг привык отключать рекламу в новостях и не увидел её, когда вдруг мне понадобилось.
Тренируйте свой мозг, чтобы он позволял вам эффективно действовать в условиях информационного насилия, и не впадайте в депрессию ;)
Ну, у меня тоже не мгновенно. Но зато тоже свыше полутора метров.
Вот это я и называю "не беспокоиться по мелочам".
При том, что профаны были всегда и будут всегда, а нервы нужно уметь беречь, если хочешь задержаться в профессии :)
Дружище, я с конца 90-х в профессии и до сих пор не выгорел. А тут у коллеги проблема на проблеме - задолбался, бесят те, бесят эти, ИИ ещё этот.
Нельзя всё время работать, нужно иногда и отдыхать. Я, например, именно так и делаю время от времени. Поэтому и не задолбался, и не бесят, и с ИИ общий язык нахожу.
А с геморроем - это к проктологу. Операция и не дорогая, и не сложная. Не тяните.
Это просто нехватка витамина D. Хандра навалилась, депрессия... Вам бы к тёплому морю, коллега. К солнцу и шуму прибоя...
Невольно провёл связь с публикацией "Последний романтик".
IMHO, требования IT-индустрии как раз и заключаются в том, что разработчиков можно было бы заменить операторами.
Давным давно, когда деревья были большими, программисты могли рассказать, что будет делать программа, глядя на дырки на куске картона. Правда, программы тогда были маленькие. Очень маленькие. И большинству недоступные. Совсем.
Сейчас приходит время одноразовых вещей - персональные мемы, персональные видосики, персональная "прожарка за 2025-й год" от ChatGPT... Время, когда каждый станет оператором своей собственной кнопки "Сделать красиво". Каждый сможет стать разработчиком :)
А тех, кто всё ещё будет уметь напрямую говорить с компьютерами на их языке станут называть как-то по-другому. Может быть - магами?
5 и 6 - тут мне может быть интересно.
У коллеги @nin-jin своеобразная траектория эволюции. Например, то, что я называю "global namespace pollution", коллега называет "true IoC".
Я из Риги говорил с сестрой в Пскове буквально пару дней назад. Она ездила туда с родителями по их пенсионным делам. У неё в кармане лежал телефон с российской симкой, раздавал инет на её телефон и с него мы уже связывались. Видимость и звук были вполне приемлемые. Она в этот момент шла по улице.
Тут вся ценность в том, что можно поднять свой сервер на любом ноуте или виртуалке - нужен только постоянный IP для сигнального/STUN/TURN-серверов (можно всё на одной виртуалке держать). И порты можно на них ставить произвольные, если что.
WebRTC.
Клиент работает в любом браузере. STUN можно использовать любой (например: stun.l.google.com:19302) или свой поднять. TURN, при необходимости, также можно свой поднять - coturn, но во многих случаях он просто не нужен.
Вот простой проект Svyazist, который разрабатывается в два лица (я и Codex-агент). Можно пробовать тут (сам сервер в неметчине). Между РФ и Латвией работает - проверено.
Сделано на коленке и для собственных нужд, но разобраться можно. Чай, не бином Ньютона.
P.S.
там может быть непонятно, как начинать сеанс связи - работаю над этим. Ссылку нужно скопировать и переслать второй стороне, а потом нажать "Начать звонок", чтобы войти в сессию со своей стороны. Для другой стороны достаточно просто войти по ссылке и разрешить доступ к микрофону и камере. На смартфонах используется Shared API для передачи ссылки.
У меня, получается, есть два типа промптов.
1) Ссылочные промпты: в запросе указываю докуменатцию, на которую надо ориентироваться, и что нужно исправить.
2) Детальные промпты: совместно с ChatGPT обсуждаю документы контекста и прошу его сформулировать постановку задачи для Агента:
Скрытый текст
Обновление цветовой темы веб-приложения «HomeCall»
Цель
Применить к веб-интерфейсу новую палитру, основанную на галапагосском зелёном (Pantone 18-5725 TSX), и переработать стили для лучшей визуальной доступности пожилых пользователей.
Обновления касаются UI-стилей, не архитектуры и не namespace.
Требования к цветовой схеме
1. Основной акцентный цвет
Использовать галапагосский зелёный (18-5725 TSX) как главный акцентный цвет приложения.
Рекомендуемый HEX-эквивалент:
#0E6251
2. Градиенты
Ввести мягкие градиенты на:
фон домашнего экрана,
большую кнопку «Связать»,
возможные акцентные элементы.
Рекомендуемые градиенты:
Фон (горизонтальный или вертикальный):
от
#002D2A(очень тёмный зелёно-чёрный)к
#0E6251(галапагосский зелёный).Кнопка (центр светлее, края темнее):
от
#0FAF8F(осветлённая версия галапагосского)к
#0E6251(основной).Градиенты должны быть мягкими, без резкого перехода.
3. Дополнительная палитра (поддерживающие цвета)
Для сеньоров важна высокая контрастность, плавность восприятия и отсутствие “слепящих” оттенков.
Текст
Основной текст:
#EAF2F1(почти белый с лёгким зелёным оттенком — мягче на глаз).Вторичный текст / хинты:
#B8C7C3.Иконки
Акцентные иконки на кнопках:
#FFFFFFили#F0F7F6.Иконка настроек:
#EAF2F1.Статусы
Информация:
#6ECFC0Предупреждение:
#E9A944Ошибка:
#D95C4AВсе статусы должны иметь мягкие тени и хорошо смотреться на тёмном фоне.Разделители и линии
Использовать прозрачный белый:
rgba(255,255,255,0.08).4. UX для пожилых пользователей
Агент должен обеспечить:
высокую контрастность текста и кнопок;
достаточный отступ вокруг элементов;
отсутствие мелких шрифтов ниже 15–16 px;
мягкие тени для улучшения различимости.
5. Изменения в коде
Агент должен:
Обновить глобальные CSS/SCSS файлы, подключённые к интерфейсу, под новую палитру.
Переработать градиенты кнопки «Связать» и фона домашних экранов.
Проверить контрастность всех надписей на тёмном фоне.
Обновить цвета статусов, используя новую палитру.
Проверить SVG-иконки (телефон, шестерёнка, статусы):
заливки должны соответствовать новой схеме;
никаких “кислотных” оттенков.
Сохранить существующие namespace-модули
HomeCall_— ребрендинг касается только UI.6. HTML-файлы
Проверить файл
web/ui/enter.html.Рекомендация: переименовать в
web/ui/home.htmlдля консистентности.После переименования — обновить ссылки на HTML-файл.
Ограничения
Запрещено изменять существующие отчёты в
ctx/agent/report/**.Новый отчёт — создавать по правилам контекста (не задавать конкретное имя в постановке).
Результат
После выполнения:
домашняя страница должна выглядеть «глубокой», спокойной, дорогой;
интерфейс должен легко читаться пожилыми пользователями;
кнопка «Связать» должна выделяться, но не слепить;
палитра должна быть консистентной во всём UI.
Во втором случае я делаю конкатенацию документов из соответствующего каталога контекста (например,
ctx/rules/web/ui/) и чатик на основании этих документов делает постановку задачи агенту.В целом получается такой итерационный процесс, когда ты с удивлением смотришь на результат работы агента, а потом находишь и правишь в документации контекста те места, которые позволили агенту нагенерить ерунду.
Совершенно очевидно, что таким образом нельзя создавать приложения типа MS Office - слишком велик объём документации даже в иерархии, но своя ниша у такого способа разработки ПО явно есть.
BDSM — Bot Driven Software Management
ADSM — Agent Driven Software Management
Если в основе бота/агента лежит LLM, то суть не изменяется. Но название - да. Название меняется. Как и отношение людей к тому, что стоит за тем или иным названием.
Но до сути надо ещё докопаться, а название - оно вот, перед глазами.
Я рассматривал оба варианта. Но народу зашло с "А".
У меня только отчёты агентов по работам фиксируются. Сами запросы есть в логах моей учётки (облачная версия) или в IDE (консольная версия). Могу выложить, если интересно. Но я стараюсь задавать рамки агенту скорее через контекст, чем через запрос.
Хотя некоторые запросы довольно развесистые получались - я их делал через GPT. Анализировал через него кодовую базу, корпус документов, обговаривал детали итерации и просил поставить задачу для агента. Но в некоторых случаях я просто правил документы контекста и просил агента привести код к новой версии документов.
Да, у меня довольно плотное общение идёт с чатиком перед постановкой задачи - в целях экономии токенов Codex-агента.
Значит, надо генерить короткие тексты. Внимание читателя - это ресурс. Который быстро исчерпывается. Эту идею, кстати, мне нейронка подсказала.
Текст публикации начал читать, потом у меня закончился ресурс и я переключился на выводы. Обычно там самое полезное. Не ошибся.
Я уже писал публикацию в таком стиле - сначала выводы, а потом уже размышления, почему так. Пересмотрел её сейчас, нужно ещё жестче ужимать смыслы. Можно даже нейронкой, у неё это хорошо получается. Попробую как-нибудь...
Это у 5.1 такая защита от создания God Object :)))
Какой толк вообще от всего, если Тепловая смерть Вселенной наступит с вероятностью 100%? Но коммент свой вы всё-таки написали.
Полагаю, у всех есть поводы делать то, что они делают, просто остальные не все и не всегда могут эти поводы понять. Вернее, все всё понимают лишь на доступном им уровне. Включая и вас, и меня, и автора публикации.