как работник кровавого энтерпрайза могу сказать, что 478 тестов в моем продукте -- это покрытие маленькой фичи. понимаю, что у проекты и задачи у всех разные и, без шуток, рад что вы за 2е суток решили свою задачу, просто глаз за формулировку о enterprise надежности уцепился.
кроме того, кажется, что надежность этого самого энтерпрайза переоценена
соглашусь, я бы тоже наверное хотел иметь двух и дальше рулить уже под задачу.
тем не менее под текущие мои задачи хватает одной подписки на openai. за новыми модельками слежу по мере выхода, пробую, если будет какой-то качественный сдвиг - может и перееду.
имхо, мне больше sol нравится, но у кучи моих колег опус в почете. по моим ощущениям openai модели более многословные, а аnthoropic - более емкие, заточенные под лаконичный результат. но по сути, я бы сказал, что выбор из потовых моделей чисто вкусовщина.
на самом деле разные (обычно топовые из доступных).
я начал эксперементировать с анализом архитектуры с gpt-5.2 и sonnet-4.6 -- там вообще все грустно было, на мой вкус они задачи уровня тупенького мидла делали хорошо, не больше.
где-то с gpt-5.4 и opus 4.7 стало более менее, дальше лучше. Сейчас юзаю gpt-5.6 sol на среднем или высоком уровне рассуждения. Cloude чет очень дорого стоит, но бывает его подключаю когда gpt прям совсем уходит не туда.
мой флоу такой -- я юзаю UI прилагу, в ней создаю проект под задачу, в описании проекта накидываю базовоую инфу про проекту (что, зачем, почему, может минимальные пожеления по архитектуре, стек который хочу) + ссылки на полезнае материалы. далее веду внутри этого проекта чаты по задачам, новая задача новый чат. таким образом проект как-то помнит общий контекст того чего я делаю.
когда мне надо подобное архитектурное ревью, я делаю новый чат и кидаю в него архив с текущим кодом или всей прилаги или кусок кода (излированный насколько можно, но и не всю кодовую базу, ориентируюсь чисто по своим ощущениям задавая себе вопрос "а мне самому вот сколько контекста надо чтобы сделать то ревью которое я от него хочу?") и собственно прошу сделать такое ревью. именно ревью, не фиксы сразу, а только анализ, но анализ с пристрастием прям так и пишу "будь максимально строгим ревьювером уровня техлида или архитектора"
собственно потом получаю отчет по всему что он нашел, гляжу на все это глазами, выделяю реально полезные штуки (порой оно замечает то, что я бы сам никогда не заметил), выкидываю откровенную чепуху. ну и дальше этот дистилированный список отправляю агенту на фикс целиком, или если рефактиронги сложноватые и разношерстные, то кусками шаг за шагом.
не скажу что это работает без осечек, но если внимательно читать то чего оно понаписало, результаты получаются весьма неплохие.
я много пользуюсь ии для собственной разработки, более того я еще и пишу агентские фичи по работе и как по мне пока самое узкое место ии так и остается контекст. не количество токенов которое оно, увловно держит в памяти в текущий момент, а именно тот конекст который доступен пока только человеку. от банального понимания доменной модели, до накопленного предыдущего опыта который конвертируется в решения ооочень нетривиальными путями порой, которые человек даже объснить не может, но вот просто нутром чует как надо.
потому знающий человек + хорошая ии-моделька могут дать очень хороший результат. но просто тупое закидывание агента тз-шками, скорее всего приведет в лучшем случае к тех долгу.
но справедливости ради, если проект небольшой и типовой, то даже очень большая лапша в коде/структуру/архитектуре -- это и не проблема, так как оно точно так же переписывается с клодом под пивко за вечер.
нет в мире совершенства. ни живой разраб, ни ии не гарантирует отсутствие ошибок. ни то ни другое не панацея. ии -- это хороший инструмент, который в умелых руках может делать прекрасные вещи, точно так же как в кривых -- быть источником новых проблем.
Бизнесу, особенно если это не ит-бизнес, обычно очень сильно все равно как сделан сайт или бот или еще что-то из инфраструктуры. Мой опыт говорит о том, что бизнес думает задачами и цифрами. Есть задача, например сайт-витрина товаров, и на самом деле все равно будет он написан руками живого программиста, нейронкой или собран на тильде. Бизнесу важно чтобы он был, потому что зачасую его продукт не сайт, а то что на этом сайте показывают (стейки напрмер). И пока это все великолепие работает, то есть метрики которыми он оценивает реботу бизнеса сходятся, ему кристально все равно как там этот сайт сделан, столько боли у админов по поддержке и тд тп.
А когда что-то идет не так, например чтобы прикрутить онлайн оплату к сайту оказывается что нужно 100500 деняк заплатить, тут возникают вопросы, "а почему?". И если оказывается что живой разработчик берет х5 относительно нейронки и еще ерепенится будет месяц, а результат для бизнеса как будто-то тот же (прикручена оплата), то и выбор очевиден. Ведь не в каждой конторе есть СТО который объяснит, что на длинной дистанции правильно спроектированная система будет просить меньше денег на поддержку, что следующую хотелку будет делать дешевле и все в этом духе.
Сильно согласен с этим комментом. У меня есть пара проектиков которые я мог бы и сам написать, но решил для ускорения впрячь агентов. Проектики были для себя и хотелось сделать вот прям хорошо, а не просто чтобы работало. Потому хоть код писали и агенты на ревью я времени не жалел, дотошно проверял что же там железяка панаписала. И получился такой вот результат -- по хорошему ТЗ результат который работает так как написано в ТЗ -- это почти с первой итерации, но вот если глянуть КАК оно сделано, то тут то и кроется дьявол. Полученный код далек от идеального, дубли, лишние сущности, странные валидации и тд.
Но для меня ценность была в том, чтобы написать "по красоте", а не просто чтоб работал. А вот если бы мне надо было просто чтоб работало -- тут вопросов нет, чего попросил -- то и получил.
Я хоть и не девопс и не могу оценить функциональную сторону вопроса, тем не менее хочу сказать что редизайн на мой вкус вышел хорошим. Особенно мне нравится что не стали тащить легаси наследие с табличным представлением даных, а сделали карточки, как по мне отличное решение проблемы разных параметров у разных БД (плюс теперь легко добавить любую новую БД с любыми параметрами)
Возможно немного офтоп, относительно заявленой темы.
Никогда не понимал выпуск MVP как концепт. Как это должно работать? MVP - это, по определению, продукт несущий минимальную ценность, то есть определяем главную цель продукта и реализуем ее без дополнительных свистелок и перделок, то есть я как пользователь по идее могу взять такой MVP и кайфануть, причем настолько, что захочу заплатить денег. В теории звучит хорошо.
Но на практике все что называют MVP -- это прототип, бетка, для инвесторов, которой толком нельзя пользоватся в боевых условиях. То есть это не полноценный продукт в котором не добавили анимашек или кастомных фильтров, а сырое поделие тяп-ляп и в прод, из разряда -- навайбкодил за ночь и зарелизил, этим нельзя пользоватся в долгую. А занчит о какой проверке гипотезы может идти речь, если по факту пользователь может просто не продраться через баги и кривую логику, ведь делали с позации щас зарелизим, а там поправим (нет).
Лично я когда пробую новый продукт я не интересуюсь mvp это beta или любое другое сокращение, которое должно подготовить меня к тому что продукт сорой. Я просто его пробую и если что-то идет не так -- просто не пользуюсь им. Соответственно, чтобы я стал пользователем сырого продукта -- это должно быть что-то невероятно уникальное, что приносит мне сильно больше пользы, чем я трачу на "страдания от использования" или же, я УЖЕ лояльный клиент компании (возможно юзер других продуктов) и я готов инвестировать свои ресурсы на то чтобы попробовать сырой продукт, зная что "пацаны делают вещи".
В остальных случаях, когда это очередной "ИИ-помощник чего-то там", "агрегатор", etc. я просто иду на следующую ссылку в поисковике.
В моем случае, iTerm2 позволил не просто делать вкладки, но и раскрашивать их. Такая цветовая дифференциация очень удобна для меня.
По поводу потребления ресурсов -- ничего не скажу. В моей практике ни разу никакой терминал у меня не отъедал столько оперативки. Обычно я его просто не замечаю, сколько бы инстансов или вкладок не было открыто.
Полагаю, что раз это так или иначе обертка над стандартным, то iTerm потребляет ресурсов столько же сколько стандартный + еще какие-то накладные расходы на себя.
Как человек имеющий в собственности такую, могу сказать, что лично мой экземпляр за 15000 км пробега тыквой не стал. Хотя возможно 15000 — это не так уж много.
как работник кровавого энтерпрайза могу сказать, что 478 тестов в моем продукте -- это покрытие маленькой фичи. понимаю, что у проекты и задачи у всех разные и, без шуток, рад что вы за 2е суток решили свою задачу, просто глаз за формулировку о enterprise надежности уцепился.
кроме того, кажется, что надежность этого самого энтерпрайза переоценена
соглашусь, я бы тоже наверное хотел иметь двух и дальше рулить уже под задачу.
тем не менее под текущие мои задачи хватает одной подписки на openai. за новыми модельками слежу по мере выхода, пробую, если будет какой-то качественный сдвиг - может и перееду.
имхо, мне больше sol нравится, но у кучи моих колег опус в почете. по моим ощущениям openai модели более многословные, а аnthoropic - более емкие, заточенные под лаконичный результат. но по сути, я бы сказал, что выбор из потовых моделей чисто вкусовщина.
на самом деле разные (обычно топовые из доступных).
я начал эксперементировать с анализом архитектуры с gpt-5.2 и sonnet-4.6 -- там вообще все грустно было, на мой вкус они задачи уровня тупенького мидла делали хорошо, не больше.
где-то с gpt-5.4 и opus 4.7 стало более менее, дальше лучше. Сейчас юзаю gpt-5.6 sol на среднем или высоком уровне рассуждения. Cloude чет очень дорого стоит, но бывает его подключаю когда gpt прям совсем уходит не туда.
мой флоу такой -- я юзаю UI прилагу, в ней создаю проект под задачу, в описании проекта накидываю базовоую инфу про проекту (что, зачем, почему, может минимальные пожеления по архитектуре, стек который хочу) + ссылки на полезнае материалы. далее веду внутри этого проекта чаты по задачам, новая задача новый чат. таким образом проект как-то помнит общий контекст того чего я делаю.
когда мне надо подобное архитектурное ревью, я делаю новый чат и кидаю в него архив с текущим кодом или всей прилаги или кусок кода (излированный насколько можно, но и не всю кодовую базу, ориентируюсь чисто по своим ощущениям задавая себе вопрос "а мне самому вот сколько контекста надо чтобы сделать то ревью которое я от него хочу?") и собственно прошу сделать такое ревью. именно ревью, не фиксы сразу, а только анализ, но анализ с пристрастием прям так и пишу "будь максимально строгим ревьювером уровня техлида или архитектора"
собственно потом получаю отчет по всему что он нашел, гляжу на все это глазами, выделяю реально полезные штуки (порой оно замечает то, что я бы сам никогда не заметил), выкидываю откровенную чепуху. ну и дальше этот дистилированный список отправляю агенту на фикс целиком, или если рефактиронги сложноватые и разношерстные, то кусками шаг за шагом.
не скажу что это работает без осечек, но если внимательно читать то чего оно понаписало, результаты получаются весьма неплохие.
я много пользуюсь ии для собственной разработки, более того я еще и пишу агентские фичи по работе и как по мне пока самое узкое место ии так и остается контекст. не количество токенов которое оно, увловно держит в памяти в текущий момент, а именно тот конекст который доступен пока только человеку. от банального понимания доменной модели, до накопленного предыдущего опыта который конвертируется в решения ооочень нетривиальными путями порой, которые человек даже объснить не может, но вот просто нутром чует как надо.
потому знающий человек + хорошая ии-моделька могут дать очень хороший результат. но просто тупое закидывание агента тз-шками, скорее всего приведет в лучшем случае к тех долгу.
но справедливости ради, если проект небольшой и типовой, то даже очень большая лапша в коде/структуру/архитектуре -- это и не проблема, так как оно точно так же переписывается с клодом под пивко за вечер.
нет в мире совершенства. ни живой разраб, ни ии не гарантирует отсутствие ошибок. ни то ни другое не панацея. ии -- это хороший инструмент, который в умелых руках может делать прекрасные вещи, точно так же как в кривых -- быть источником новых проблем.
Бизнесу, особенно если это не ит-бизнес, обычно очень сильно все равно как сделан сайт или бот или еще что-то из инфраструктуры. Мой опыт говорит о том, что бизнес думает задачами и цифрами. Есть задача, например сайт-витрина товаров, и на самом деле все равно будет он написан руками живого программиста, нейронкой или собран на тильде. Бизнесу важно чтобы он был, потому что зачасую его продукт не сайт, а то что на этом сайте показывают (стейки напрмер). И пока это все великолепие работает, то есть метрики которыми он оценивает реботу бизнеса сходятся, ему кристально все равно как там этот сайт сделан, столько боли у админов по поддержке и тд тп.
А когда что-то идет не так, например чтобы прикрутить онлайн оплату к сайту оказывается что нужно 100500 деняк заплатить, тут возникают вопросы, "а почему?". И если оказывается что живой разработчик берет х5 относительно нейронки и еще ерепенится будет месяц, а результат для бизнеса как будто-то тот же (прикручена оплата), то и выбор очевиден. Ведь не в каждой конторе есть СТО который объяснит, что на длинной дистанции правильно спроектированная система будет просить меньше денег на поддержку, что следующую хотелку будет делать дешевле и все в этом духе.
Сильно согласен с этим комментом. У меня есть пара проектиков которые я мог бы и сам написать, но решил для ускорения впрячь агентов. Проектики были для себя и хотелось сделать вот прям хорошо, а не просто чтобы работало. Потому хоть код писали и агенты на ревью я времени не жалел, дотошно проверял что же там железяка панаписала. И получился такой вот результат -- по хорошему ТЗ результат который работает так как написано в ТЗ -- это почти с первой итерации, но вот если глянуть КАК оно сделано, то тут то и кроется дьявол. Полученный код далек от идеального, дубли, лишние сущности, странные валидации и тд.
Но для меня ценность была в том, чтобы написать "по красоте", а не просто чтоб работал. А вот если бы мне надо было просто чтоб работало -- тут вопросов нет, чего попросил -- то и получил.
Я хоть и не девопс и не могу оценить функциональную сторону вопроса, тем не менее хочу сказать что редизайн на мой вкус вышел хорошим. Особенно мне нравится что не стали тащить легаси наследие с табличным представлением даных, а сделали карточки, как по мне отличное решение проблемы разных параметров у разных БД (плюс теперь легко добавить любую новую БД с любыми параметрами)
Возможно немного офтоп, относительно заявленой темы.
Никогда не понимал выпуск MVP как концепт. Как это должно работать? MVP - это, по определению, продукт несущий минимальную ценность, то есть определяем главную цель продукта и реализуем ее без дополнительных свистелок и перделок, то есть я как пользователь по идее могу взять такой MVP и кайфануть, причем настолько, что захочу заплатить денег. В теории звучит хорошо.
Но на практике все что называют MVP -- это прототип, бетка, для инвесторов, которой толком нельзя пользоватся в боевых условиях. То есть это не полноценный продукт в котором не добавили анимашек или кастомных фильтров, а сырое поделие тяп-ляп и в прод, из разряда -- навайбкодил за ночь и зарелизил, этим нельзя пользоватся в долгую. А занчит о какой проверке гипотезы может идти речь, если по факту пользователь может просто не продраться через баги и кривую логику, ведь делали с позации щас зарелизим, а там поправим (нет).
Лично я когда пробую новый продукт я не интересуюсь mvp это beta или любое другое сокращение, которое должно подготовить меня к тому что продукт сорой. Я просто его пробую и если что-то идет не так -- просто не пользуюсь им. Соответственно, чтобы я стал пользователем сырого продукта -- это должно быть что-то невероятно уникальное, что приносит мне сильно больше пользы, чем я трачу на "страдания от использования" или же, я УЖЕ лояльный клиент компании (возможно юзер других продуктов) и я готов инвестировать свои ресурсы на то чтобы попробовать сырой продукт, зная что "пацаны делают вещи".
В остальных случаях, когда это очередной "ИИ-помощник чего-то там", "агрегатор", etc. я просто иду на следующую ссылку в поисковике.
zsh-z прикольный плагин, но мне хватает истории команд + автодополнения, потому решил не раздувать список плагинов тем, чем не пользуюсь
В моем случае, iTerm2 позволил не просто делать вкладки, но и раскрашивать их. Такая цветовая дифференциация очень удобна для меня.
По поводу потребления ресурсов -- ничего не скажу. В моей практике ни разу никакой терминал у меня не отъедал столько оперативки. Обычно я его просто не замечаю, сколько бы инстансов или вкладок не было открыто.
Полагаю, что раз это так или иначе обертка над стандартным, то iTerm потребляет ресурсов столько же сколько стандартный + еще какие-то накладные расходы на себя.