Читал и плюсанул :) У TeqFW код публичный - https://github.com/teqfw/ Можете попробовать протащить бэкдор. Будет любопытно посмотреть. Базовый пакет teqfw/di, но он не очень большой. Лучше в teqfw/cli пытаться встроиться или в teqfw/db.
Так-то у меня агенты пишут тикеты и агенты их резолвят. А бэкдоры - это забавы "кожаных" :)
main - это всего лишь ветка в репо. У агента на VPS свой репозиторий. Если все тесты прошли, то изменения коммитятся и пушатся в origin. Если что-то проскочило, что не отлавливается тестами - нужно учесть это "что-то" в новом тесте. Но это и с Pull Request'ами также может быть.
Я как-то начинал делать CMS и прикрутил OpenAI compatible API для перевода страниц (через DeepSeek сам это делал). Потом оказалось, что проще просить агентов самим переводить тексты и адаптировать их под соответствующий язык, чем делать то же самое программно через API. Я переводил с русского на английский и испанский.
А потом вообще оказалось, что агентам дешевле работать с markdown, чем с html (внезапно!!). Я (вернее, агенты) прикрутил marked для конвертации md -> html. Сейчас доступны оба формата для страниц:
Сам подход с построением сайта - agent-first (llms.txt явялется аналогом sitemap.xml, но для агентов). Я вообще считаю, что проще дать адрес такого сайта своему агенту / модели и попросить их вкратце рассказать, что это и с чем едят. А уже потом с ними углубляться в детали этого сайта.
Мне вообще кажется, что "нейрослоп" изменит принципы индексации. Вот пример - https://mindstream.app.wiredgeese.com/?publication=905698 Эта же статья в пересказе нейронки и сопоставленная с вектором моих интересов (так я на неё и попал).
А ему и не надо. Спецификации, тесты и код направлены на то, чтобы удовлетворять потребности конечного пользователя. Если ему что-то не заходит, то надо менять код, тесты и спецификации. Можно даже сказать, что конечные пользователи в массе своей и составляют "неформализованную спецификацию". Всё остальное - лишь приближение к ней.
Отладчик - это не print и не try-catch. print и try-catch это логирование. Отладчик действительно очень мощная штука для изучения среды исполнения. Но, как я и сказал, нужен только в том случае, если вы не понимаете, как и почему работает код. Чем дольше вы работаете с какой-либо средой исполнения, тем меньше вам нужен отладчик. Когда вы понимаете код, философию конкретного ЯП, вам уже достаточно print и try-catch.
А вам не всё равно, что лежит в массиве по индексу 3? Поставьте try-catch и увидете в логах, что и как. Вы же на прод с отладчиком не лезете по каждой ошибке. ПишИте нормальный код, если понимаете как. Если не понимаете как - да, тогда используйте отладчик.
Код дебажат только те, кто его не понимают и собираются понять.
Я об этом и написал.
Вы не понимаете свой (или чужой) код - вам нужен дебаггер, т.к. вы собираетесь понять "что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось".
Если бы вы понимали, что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось, вам бы отладчик был не нужен.
Или если бы вы не собирались понять - тогда тоже отладчик не нужен.
А то, что данные пришли неожиданные, ну, так бывает иногда в некоторых ЯП.
Код дебажат только те, кто его не понимают и собираются понять. Зачем дебажить код, если он и так понятен? Или если ты его в принципе не собираешься понимать?
Тестировщики, например, код вообще никогда не дебажат. Им это в принципе не надо.
На VPS агент делает те же тесты в main до пуша в origin.
На входе и на выходе.
Совершенно с вами согласен. Если код всем устраивает, то не следует требовать от него большего.
Раскройте, пожалуйста, вашу мысль. Почему мой сайт - это не моя работа, и почему Alex Gusev - не моё имя?
Читал и плюсанул :) У TeqFW код публичный - https://github.com/teqfw/ Можете попробовать протащить бэкдор. Будет любопытно посмотреть. Базовый пакет teqfw/di, но он не очень большой. Лучше в teqfw/cli пытаться встроиться или в teqfw/db.
Так-то у меня агенты пишут тикеты и агенты их резолвят. А бэкдоры - это забавы "кожаных" :)
А вы токсичный чел, коллега :)
И что? Я уверен, что и на "Dhwtj" опус с хайку примерно так же ответят. И много на кого ещё. Это не повод не подписывать свою работу.
Почему?
Да, совершенно верно. И в этой моей деятельности PR стали не нужны.
Разница в том, что агенты видят мои спеки, а другие люди - нет.
main- это всего лишь ветка в репо. У агента на VPS свой репозиторий. Если все тесты прошли, то изменения коммитятся и пушатся в origin. Если что-то проскочило, что не отлавливается тестами - нужно учесть это "что-то" в новом тесте. Но это и с Pull Request'ами также может быть.Потому что агентам проще работать с текстом.
Я как-то начинал делать CMS и прикрутил OpenAI compatible API для перевода страниц (через DeepSeek сам это делал). Потом оказалось, что проще просить агентов самим переводить тексты и адаптировать их под соответствующий язык, чем делать то же самое программно через API. Я переводил с русского на английский и испанский.
А потом вообще оказалось, что агентам дешевле работать с markdown, чем с html (внезапно!!). Я (вернее, агенты) прикрутил
markedдля конвертации md -> html. Сейчас доступны оба формата для страниц:https://cms.teqfw.com/ru/index.md - для агентов
https://cms.teqfw.com/ru/index.html - преобразование md2html для людей
https://cms.teqfw.com/ru/ - md для тех, кто его понимает (агенты), для остальных html
Сам подход с построением сайта - agent-first (llms.txt явялется аналогом sitemap.xml, но для агентов). Я вообще считаю, что проще дать адрес такого сайта своему агенту / модели и попросить их вкратце рассказать, что это и с чем едят. А уже потом с ними углубляться в детали этого сайта.
Мне вообще кажется, что "нейрослоп" изменит принципы индексации. Вот пример - https://mindstream.app.wiredgeese.com/?publication=905698 Эта же статья в пересказе нейронки и сопоставленная с вектором моих интересов (так я на неё и попал).
Да, так и получается. Мало того, другие люди ещё и потребности свои изменяют после получения искомого. Приходится подстраиваться всё время.
А ему и не надо. Спецификации, тесты и код направлены на то, чтобы удовлетворять потребности конечного пользователя. Если ему что-то не заходит, то надо менять код, тесты и спецификации. Можно даже сказать, что конечные пользователи в массе своей и составляют "неформализованную спецификацию". Всё остальное - лишь приближение к ней.
Отладчик - это не
printи неtry-catch.printиtry-catchэто логирование. Отладчик действительно очень мощная штука для изучения среды исполнения. Но, как я и сказал, нужен только в том случае, если вы не понимаете, как и почему работает код. Чем дольше вы работаете с какой-либо средой исполнения, тем меньше вам нужен отладчик. Когда вы понимаете код, философию конкретного ЯП, вам уже достаточноprintиtry-catch.Я сам использую отладчики, когда не понимаю код (даже статья об этом есть). И не использую, когда код понимаю.
Если это звучит высокомерно... ну ладно.
А вам не всё равно, что лежит в массиве по индексу 3? Поставьте try-catch и увидете в логах, что и как. Вы же на прод с отладчиком не лезете по каждой ошибке. ПишИте нормальный код, если понимаете как. Если не понимаете как - да, тогда используйте отладчик.
Я об этом и написал.
Вы не понимаете свой (или чужой) код - вам нужен дебаггер, т.к. вы собираетесь понять "что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось".
Если бы вы понимали, что лежит в каждом элементе и на каком этапе данные стали не такими, как ожидалось, вам бы отладчик был не нужен.
Или если бы вы не собирались понять - тогда тоже отладчик не нужен.
А то, что данные пришли неожиданные, ну, так бывает иногда в некоторых ЯП.
https://ru.wikipedia.org/wiki/Тестирование_по_стратегии_чёрного_ящика
Код дебажат только те, кто его не понимают и собираются понять. Зачем дебажить код, если он и так понятен? Или если ты его в принципе не собираешься понимать?
Тестировщики, например, код вообще никогда не дебажат. Им это в принципе не надо.
А компании решили, нужны ли им такие пользователи :)))
Мы с ИИ ещё в январе 2025 года это обсуждали. Я даже на Хабре это опубликовал, но тогда была другая политика по "нейрослопу".