-
Сообщений
15 794 -
Зарегистрирован
-
Посещение
-
Время онлайн
86д 13ч 28м 4с
Все публикации пользователя Just.Doit
-
1 - не как можно быстрее, а до быстроты нужного уровня - у тебя есть некая SLO, обоснованная выбранным балансом между качеством/скоростью и сложностью реализации 2 - я не знаю что конкретно ты алгоритмом называешь. я так понимаю что-то типа литкода или алгоритма который ты условно можешь в виде функции написать на инмемори данных (ну или несколько запросов и манипулирование данными). обычно нон фанкшнл реквайрементс (латенси/трупут) достигаются дизайном - выбранными БД, выбранным паттерном взаимодействия, выбранными условностями в бизнеслогике, выбранным количеством серверов или дублированием данных, и тп. алгоритмы тут редко играют роль по моему опыту мне кстати кажется с таким неплохо может справиться ии в плане на уровне - выдать решение которое ты как эксперт проверишь и если что чутка доработаешь либо добавишь промпт на улучшение ну тоесть он не автономен будет, но подспорьем если ты чутка пониимаешь что надо
-
сколько в ней сотен человек? лол это многое объясняет почему Гемини такой хуевый понаберут с продоты а потом пропты обрабатывают хуже китайской опенсорсной поделки кажется для порядка 95+% бекендов не надо дрочить алгоритмы и быстродействие выше дефолтного не нужно ну по крайней мере это мое впечатление из моего пузыря кажется даже в гуглах рядовые продуктовые челики берут готовые паттерны и применяют скэлабл решения, не дроча алгоритмы в самой работе алгоритмы нужны для разработчиков движков бд, сетевых протоколов и тп. коих подавляющее меньшинство, и уже не совсем бекенды а скорее системное программирование
-
ну если ты будешь читать что реально дает ллм в профессии разраба то ты увидишь что: - ллм прославился статьей что это ведет к деградации кода, и предрекают для многих продуктов фазу переписыванить с говно-ллм кода на нормальное - что в лучшем случае ллм позволяет заменить туповатого джуна, либо автоматизировать какую-то рутину (типа сделать саммари по коммитам, или портирование кода) - нормальный код который решает бизнес проблему и является поддерживаемым ллм не пишет почти никогда. нужно много контекста и много итераций. он ускоряет заполнение тривиальных промежутков в коде (примерно то что мог бы сделать джун на уровне синтаксиса и языковых конструкций но не бизнес валуе) - хайп скорее про то что - оно вообще хоть что-то умеет делать, похожее на правду. и иногда даже работающее почти с первого раза - это ахуеть. только с точки зрения того как это помогает в твоей работе будучи синьер разрабочтиком тоже ничего особенного - автоматизация некоторых более менее тривиальных шагов. ===== то что техписы не обсуждают - возможно они просто тупые. Ноу оффенс, но я редко встречал толковых техписов. в целом писатели обычно дауны, которые не осилили точные науки но смогли найти себя в гуманитарных науках, тк там не обязатльно быть умным чтобы сходить за чела который шарит вы в 2к25 обычно даже версионирование нихуя не осилил и пересылаете файлы типа "Статья Х - вер.2.1 (3) - ФИНАЛЬНАЯ ПОСЛЕ ПРАВОК.docx" по емейлу блять я легко вижу примерыы когда можно ускорить какую-то рутину в работе писталей - сгенерировать примеры по доке, предложить несколько вариантов формулировок, сделать микроресерч чтобы написать более полную статью, как мниимум нагенерировать формулировки, ассоциативные и связанные понятия, синонимы и тп - это не сделает тебе готовый продукт, но ускорит некоторые фазы. в разрабокте также
-
что за хуйню ты несешь чатгпт пользуются сейчас ВООБЩЕ ВСЕ едигнственно что чатпгт делает - ОНО ГЕНЕРИРУЕТ ТЕКСТ все пользуются тем текстом который им генерируется и все ПИСАЮТСЯ ОТ СЧАСТЬЯ от того текста который им сгенерирован и который они конечно же читают судя по всему ты подразумеваешь не "текст" как text, как набор слов и предложений связных а как публикации типа научных, либо документацию с определенным уровнем качества но это не просто ТЕКСТ, это продукт, с уровнем качества, с критериями пользы для конечного пользователя и с такими метриками как репутация и тп точно также и код это либо просто текст, как набор символов которые компилируются ( и там нету никаких репутаций в принципе, также как и пользы саомй по себе - это просто инструкции на ЦПУ), либо это продукт, который решает бизнес проблему. и во втором случае ллм точно также принвосит почти 0 импакта в реализацию продукта. тк компилируемый код это не продукт (обычно). вы путаете что текст/документация у техписов это продукт но код у программистов это не продукт сам по себе обычно, это низкоуровневые детали имплементации. примерно как выбранный шрифт или величина отступа в документации все тоже самое с софтверными продуктами елси ты выпустил фичу которая засрала порнухой сайт с детсикими книжками - у тебя репутация в 0 и ты бизнес зарыл считай Какой-то реально троллинг. троллинг это утверждать что ллм хуево умеет генерировать текст
-
все тоже самое с софтверными продуктами елси ты выпустил фичу которая засрала порнухой сайт с детсикими книжками - у тебя репутация в 0 и ты бизнес зарыл считай
-
они просто в трауре что их заменили нахуй
-
ллм единственное что делает в принципе - генерит текст. оно в рпинципе ничего другого не умеет и в это ей нет равных и она прям таки ОХУЕННО генерит текст
-
еще раз - доку можно снять с публикации и отдать юзерам предыдущую версию (если речь идет про первую - то ты юзерам тоже ничего не откатишь, если это первая рабочая версия) - у доки есть возможность тестирования через проверку синтаксиса и прочтение тобой или выделенным человеком (жена, нанятый вычитывальщик) - у доки есть возможность быть максимально всрато технически организованной (быть latex или скриншотами, вставленными в пдф) и ими можно будет пользоваться
-
ты не понял смысла ты берешь узкое понятие кода как конкретный снипет для какого-то бекенд приложения и документацию как текст с какой-то пользой финальному юзеру это несравнимые вещи мы либо сравниваем вещи одного порядка - продукты, несущие пользу пользователям. и тогда дизайн это чаасть этого продукта, который кстати точно также генерится нейросетями. и кстати дизайн это код в конечном счете - ксс. либо мы сравниваем мелкие составные части - конкретный сниппет кода, пользу которого невозможно оценить. но в плане текстов это равноценно хз чему. это равноценно одному предложению, верно составленному по правилам языка. не понятно какую пользу это предложение несет тк это малая составная часть документа. если сравнивать таким образом. то софтверные системы еще сложнее чем документация, и их еще более невозможно "легко сгенерить в ллм и быстренько проверить что они несут валуе" предлагаешь на каждый высер ллм проводить 2х недельно регрессионное тестирование всех компонент системы?!
-
тоже самое с кодом, если ты долбаеб или работаешь по практикам 50 летней давности собственно с текстом точно также есть тестирование в виде рецензий и краудсорсинга (для чего-то типа переводов), точно также переписать ты можешь всегда. переопубликовать текст ты тоже можешь всегда. хз в чем проблема у тебя
-
дак мы сравниваем не код для программистов с доками для юзеров мы либо сравниваем код для юзеров с доками для юзеров либо я хз можно сравнивать код для прогарммистов с доками для техписов (когда техпис думает об переиспользуемости доков, а не о том насколько это для юзеров норм) ни одна ллм не генерирует софтверного продукта, даже близко к приемлемому уровню чтобы нести какую либо пользу, чтобы можно было 1015 минус шлифануть и отдать пользователям код это и есть дизайн
-
ну чел, это тебе в дурку надо опять же, аналоигя в коде будет про то что софтверный продукт "не интуитивно понятен и вообще все делает не так" у меня мама бухгалтер и она постоянно бухтит так на бух программы тоже самое все
-
я же точно также могу скзатаь что если текст "если пользователь использует и доволен - все збс" почему сразу будет говном, я не понял можно и так и так из ллм получить что код которым пользователь не будет доволен и его нужно дорабатывать точно также как в кейсе с документцией также как и у кода факт того что код компилируется и запускается не говорит что он становится фичей, которой можно пользоваться (с какой либо пользой)
-
критерии обозначь, что значит будет говном просто тебе кто-то скажет что и код говно елси он не написан на асме и не выполняется за наносекунду (про гарбаж коллектор я вообще молчу)
-
и вот если мы говорим про код, как про продукт то проверить что он решает бизнесовую задачу это тоже часто нетривиальная и субьективная задача. особено если это не просто скачать файл (точно также как в кейсе с документацией документация это не просто описание АПИ, а что-то что объясняет доходчиво), а повысить конверсию через снижение количества ботов потому что вы сравниваете не то я пытаюсь донести что код, который не падает - не обяхательно выполняет свою функцию точно также как документ в котором нет грамматических/орфографических/пунктационных ошибок не обяхательно выполняет свою функцию сравнение должно быть на одном уровне абстракций и в одинаковых условиях
-
код тут не текст программы а софтверный продукт потому что в доке у него это тоже не просто текст, в соответствии с правилами языка это продукт, который несет валуе. я пытаюсь вам вот это показать когад вы говорите про текст вы подразумеваете что в нем есть польза и он эффективно решает коммуникационную задачу. когда вы берете код вы думаете только о том что эксепшены не падают. но совсем не понятно как он решает свою продуктовую задачу
-
если не виснет и других проблем нет - то код рабочий точно также как рабочая дока, в том смысле что человек может ее прочитать и узнать что-то полезное с определенной эффективность потребления информации (но это уже скорее бизнес метрика, и код тоже не понятно насколько хорошо решает бизнесовые проблемы даже если он при этом работает без багов)
-
чушь кидаешь другу - просишь прочитать - вот тебе тестирование попал не попал - это уже бизнес метрики. в коде точно также ты можешь выпустить фичу и только на АБ тесте проверить "попал/не попал" ТОЖЕ САМОЕ С СИСТЕМАМИ только над системами трудятся 1к человек. а у тебя доку которую ты в 2-3 рыла можешь написать так что софт в этом плане сложнее гораздо шах и мат
-
мне кажется вас путает то что вы к коду относитесь как к тексу (который может или не может читать человек), который можно проверить через компиляцию а сравниваете с документацией которая должна хорошо решать какую-то проблему в контексте конкуренции ну дак код это не просто текст, это решение бизнес проблемы с помощью софта. и код который компилируется == документация которая прошла автоматическую проверку знаков препинания и орфографии. понять решают ли они какую-то бизнесовую/продуктовую проблему невозможно на основе этого чел изначально говорил "ну вот доку я должен прочитать чтобы понять что она вообещ имеет смысл". для меня очевидно что ты тут доку имеешь ввиду как некий продукт или решение бизнес проблемы точно также код,выплюнутый ЛЛМ невозможно проверить на то как он решает бизнес проблему просто прогнав тесты. в крайних случаях тебе нужно аб тест провести. самопроверка заключается либо в доскональном прочтении либо в проыткивании на стенде. я и бы сказал это еще более долгое и ресурсоемкое занятие чем сделать документцаию хотя чел утверждает что "сделать рабочий код с помощью ллмки гораздо проще чем рабочую документацию" - мне кажется это полная чушь чел. я тебе точно также скажу ты выкидываешь доку, там говно, ты смотришь по метрикам, идешь и фиксишь доку. все продолжают читать тебя как автора ТОЖЕ САМОЕ ВСЕ лол есть целые исследования
-
ну чел тот скрипт делал за несоклько итераций с правкой ошибок точно также ты берешь сгенерированную документацию и за несколько итераций доводишь его до уровня что она выполняет поставленную задачу. и дальше точно также этот текст выполнит задачу для юзера 1 и для юзера 2 и тп в чем "принципиальная" разница - я не пойму код рабочий == документация рабочая и то и то нельзя просто в 2 клика сгенерить в нейросетке. можно итеративно довести до ума. и какие-то минимальные навыки нужны чел утверждал что сделать "рабочий" код в нейросетке проще чем "рабочую" документацию я не вижу разницы чем проще. я бы сказал доку проще написать. нужно почти 0 навыков сверх 9 классов приходской чтобы писать текст который выполняет задачу донесения информации. не поверишь но СЕЙМ ЩИТ С КОДОМ (софтверным продуктом) если у тебя в коде слип луп который виснет на минуту на каждую страницу - пользователи сьебут
-
на том уровне на каком он хочет - со стилистикой и логической связнастью - не уверен что прям сразу видно. но я наверное соглашусь что чтобы проверить 80% параметров качества текста не нужно так уж много хардскилов, скорее всего хватит навыков со школы + общей эрудиции. а вот проверить 80% параметров качества кода - уже нужно шарить в программировании хотя если на уровне смоук теста и ручного тестирования - тоже можно сказать что программу можно потыкать как макака и сказать что работает/не работает
-
одноразовая простая фича на отьебись - это точно также можно сделать доку одноразово на отьебись. в целом меседж в слаке это тоже уже может считатья за доку однразовую (текст который призван донести инфу) я не вижу разницы на таком уровне абстракции погоди мы говорим про то что ты сам тестируешь свой продукт ты говоришь что я, как разраб, могу проверить на стейдже ты как техпис можешь прочитать и проверить документ если мы говорим про тестирование на ЦА - то и тут и там тебе нужны люди. которые пойдут и протестят как ты соберешь с них фидбек - уже дело десятое я тебя точно также могу спросить - я вот выпустил фичу, а вдруг она у людей не работает, как понять? посылать группу людей в черном? нет блять, собирать метрики. которые точно также собираются по поубликациям (просмотры, лайки, репосты, фидбек в комментариях, апвоуты/карма) НЕТ НИКАКОЙ РАЗНИЦЫ
-
ну чел я поинмаю что такое норм документация я к тому и веду что ты сравниваешь написание кода на коленке который нахуй никому не нужен и "можно проверить запустив в ИДЕ" с продакшн документацией и не видишь что написание документации на коленке ничем не отличается от написания кода на коленке точно также написание кода в прод ничем не отличается от написания серьезной документации более того - продуктовая и "бизнесовая" документация точно также может быть сделана на отьебись - все зависит от конкретных требований по качеству. ТОЖЕ САМОЕ С КОДОМ. у тебя никто не примет нагенеренное говно от ЛЛМ. и будут делать это точно также люди. в публикациях, если мы про научные журналы - там тоже зависит от журнала. гдето высокие стандарты качества, гдето мурзилки которые астрологию за науку выдают. это можно сравнить с оупенсурс проектом потипу линукса, где тебя линус выебет за ллм лапшу, и либой на гитхабе с 2мя звездами. в общем, ВСЕ ТОЖЕ САМОЕ документация тоже работает если выполняет свою основную функцию и говнодокументация точно также выполняет ее потому что если тебе сказали использовать АПИ, то какая бы не была уебищная документация, ты пойдешь ее читать и пытаться сделать интеграцию. и даже если ты страдаешь но результат достигнут, то "документация работает", точно также как "работает" говнокод я согласен что есть разница что документацию вынужден читать человек и неоптимальным будет его экспериенс, и это несколько отличается от того что неоптимальным будет перформанс, по крайней мере с эмоциональной точки зрения.
-
ну тоже самое я могу тебе сказать - что тебе мешает проверить что текст рабочий?
-
дак она не работает ты та м что-то предлагал в иде прогнать иде не может проверить что фича работает даже если рпедставить что ты имел ввиду юниттесты - то они тоже не проверяют что фича работает. именно ей и явялется (ну не совсем. дока для других команд о том какие и как мы данные шлем и почему) правда как это относится к обсуждению - хз ты не правильно рассуждаешь есть рабочий код и есть рабочая дока определение рабочего кода - выполняет функцию (бизнеслогику фичи) на проде плюс минус как задумано определение рабочей доки - выполняет функцию донесения инфы до человеков (ЦА) плюс минус чтобы было понятно и то и другое не делается легко с помощью нейросетки. в кодинге нет какой-то магической иде которая проверит что у тебя код в проде будет работать как задумано на реальных юзерах то что чел предлагает проверить в иде (компилияция и/или юнит тесты видимо) сравнимо с автопроверкой синтаксиса и пунктуации, которые в ворде уже 50 лет сущетсвуют у чела почему-то есть какая-то магическая вера в том что код очень легко проверить на работоспособность - ну типа если скомпилировалось, значит работает...? ты не представляешь. но у нас тоже нету возможности загнать код в иде и проверить что код рабочий (выполняет функцию на проде)