Я представляю, насколько поверхностным может казаться такой текст на Хабре, но по личному опыту могу сказать: огромное количество суперпрофессиональных, талантливых IT-бизнесменов, программистов и даже дизайнеров, не знают, как снимать скриншоты, и мучаются, пользуясь неподходящими инструментами.
да тут вообще поле непаханое...
сколько народу мучается с редакторами текста... а настройки в браузерах? А сохранение паролей?
да что там, нужен отдельный Хаб "хабро-ликбез". Даёшь тотальную ИТ-грамотность каждому суперпрофессиональному программисту и даже дизайнеру!
привязка к языкам - тоже такая себе метрика. Китайцев полно за пределами Китая, русскоязычная аудитория, спасибо ссср и иммиграции - тоже не обязательно Россия.
помимо очевидного - сокращения ФЗП, есть еще какие-то экономические выгоды от внедрения ИИ? Так, чтобы и отбить затраты на внедрение и получать большую прибыль?
Цель программы - подготовка специалистов в сфере применения искусственного интеллекта (ИИ) как в научной, так и практической областях
Скорее всего сперва будут задачи построения разных типов ИИ, с разбором параметров, потом какой-нить большой курс по генеративным ИИ, слои, их состояния, параметры и т.п.
Ну я бы так курс строил. Чтоб по итогам студент мог собрать (и объяснить, что и как он собрал) свою LLM.
соглавен, тяжело. Это правило пришло из опыта. Я начинал с мыслью "план - это артифакт для LLM, временная память, чтоб проходить по циклу, чего его читать, всё же обсудили до этого".
и таки да, 80% не требует корректировки. Но из оставшихся 20% - часть, скажем, половина - критически неприемлемо. И вот чтобы найти эти 10%, - приходится вчитываться и уточнять. Ибо потом исправлять - получается дольше и дороже.
Сейчас я условно делю своё время на 3 части - 1/3 - "детальное описание задачи (мой план)" ; 1/3 - "корректировка созданного плана работ"; 1/3 - "проверка кода"
Почитайте и статьи про "конкурентов" и комментарии к ним - при желании там можно найти кучу интересного, как улучшить вашу "программу для портфолио"...
В итоге я захотел сделать не просто набор статей, а некий учебник-пособие - краткий экскурс по всему, что касается RavenDB.
Ну в итоге получился материал, скажем так, не совсем в формате хабра. Сборная солянка всевозможных (положительных) материалов об RavenDB.
Кстати, ничего не сказано о ценовой политике и правилах лицензирования. В чём и какие недостатки, кому (в каких ситуациях) RavenDB лучше, в каких - хуже. Ну это к тому, чтоб было "всё, что касается RavenDB" - или она такая классная, что просто лучше всех во всех аспектах?
Еще раз, не умоляя ваших трудовых затрат, - попробуйте объективно посмотреть на ваш учебник - для кого он? В каком случае и кому он может быть полезным?
При вашем выборе хабов ".NET C# ASP IT-инфраструктура IT-стандарты" вкупе с заголовком - статья обещала что-то про разработку БД на c#, но ни как (почти рекламный) материал. - люди заходили, обманывались, выходили.
Но главную нашу любовь у нас не отберут — выстраивать домики с нуля по нашим чертежам, в которых всё продумано до мельчайших деталей; мы просто делегируем ИИ написание кода. Привыкнем.
буквально на этой неделе наш директор R&D проникновенно агитировал за "human first agentic dev".
Да, в принципе уже понятно, что кода мы пишем всё меньше и меньше. И время, когда "source of truth" полностью переедет в документацию, всё ближе и, наверное, это неизбежно.
Но в команде пока мы всё равно решили держать "code first" - текущие системы были разработаны людьми без агентской документации. То есть подход применяю упрощенный:
Product team ставит задачу
Я с напарником из front end обсуждаю рамки и интерфейсы
В общей документации прописываем детали реализации
Я натравливаю /plan агента на документацию и прошу план реализации для backend
Тщательно читаю план, корректирую и убеждаюсь, что план меня устраивает
Запускаю реализацию (почти ванильный агент - общие dev skills и copilot_instructions.md)
А когда действительно стараешься, вкладываешь силы, результатом становится минус карма.
Ну так оценки ставят не за старания и за объём. Я на хабы c# . net asp.net подписан - вашу статью увидел сразу. Заголовок "Как пишут базы данных на C#: RavenDb" показался интересным, - зашел.
И вышел, достаточно быстро, без оценок - не осилил вашей подачи материала. Но то, что мог прилететь минус в карму за подачу материала - вполне допускаю. У вас там всё вместе - и архитектура, и история создания, и банальности по философии баз данных, и биография автора и сравнение с другими БД, вперемешку с серьёзными графиками и шутливыми картинками.
Разбили бы материал на несколько статей, чтоб не скролить огромную простыню в поисках интересного.
это не новое. Это то, с чем сталкиваешься сразу, как только начинаешь плотно работать с LLM - у всех поставщиков ИИ чатов есть и рекомендации и документация и обучение.
Не спорю, не все начинают работать с чтения документации, но как только замечаешь просадку и понимаешь, что инструмент используется не эффективно - любой инженер полезет читать документацию. И сразу отпадает необходимость в подобных статьях, основанных на личной боли и ограниченном опыте.
И кстати, то, что "автор докопалась до цифр", это хорошо, и надеюсь, что автор понимает, что цифры отличаются у разных моделей, плюс автору будет интересно узнать, "интерфейсы чатов" добавляют свою обвязку, tool definitions съедает кучу токенов, выходные токены (которые в разы дороже входных) включают в себя и внутреннее "рассуждение" моделей и ответ "Да" может стоить гораздо больше 1 токена и т.д.
я ведущий инженер по тестированию в Рексофт. Последние два года я плотно работаю с большими языковыми моделями: интегрирую их в CI/CD, использую для генерации тестов и анализа логов.
ведущий инженер после 2 лет с LLM открывает для себя промт-инжениринг.
9 лет назад озадачился поиском часов, чтоб и полная интеграция с телефоном была (уведомления, сообщения) и датчики всякие типа пульса и шагомера и чтоб заряжать не каждый день.
В итоге нашeл часы Nokia (сейчас это бренд withings - https://www.withings.com/en-ca/collections/scanwatch-vitals ) батарея за 9 лет неснимаемой носки ёмкости почти не потеряла - заряжаюсь так же - 3-4 часа на зарядке раз в месяц. Да, экран маленький, да, не тачскрин, но это особо и не нужно - время видно на стрелках, бегущей строки хватает, вибрация чувствуется прекрасно.
тут самое сложное - найти покупателя. В принципе, поверить, что она сама нашла нескольких - можно. Потом простые клиенты кончились, появилась необходимость в маркетинге. Пришлось записывать видео о себе талантливой и раскручивать себя, чтоб искать новых Буратин, не знающих куда бы зарыть свои золотые...
Если откинуть мысль о неразумности старшего менеджмента в обеих компаниях, можно сделать вывод, что по их мнению, инструментарий созрел для массового использования.
Уже не просто чат, но готовая платформа для создания бизнес-решений?
Наша компания продаёт железки уже 30 лет. С кастомизированными andoid и linux как платформами, IoT hubs, cloud management, свой graphic programming, компиляция, - в общем зоопарк своего софта колоссальный, нужно и поддерживать и создавать.
Весной всем в R&D (человек 70, это и dev и product) выдали github copilot enterprise подписку и дали карт бланш на ИИ эксперименты.
Прогресс у всех разный - от классического чата до полноценной spec driven разработки. Но по моим ощущениям ожидания у руководства были завышенные и они пока не оправдываются и не факт, что придём к каком-то единообразию.
Здесь простой аргумент - если ваше решение безопасно "по дизайну" - это огромный плюс к продукту как к инженерному решению. И да, это - ограничение удобства отладки в пользу безопасности. И, кстати, не такое уж и сильное ограничение - как правило, внутренние идентификаторы можно считать безопасными - и по ним всегда можно восстановить картину происходящего.
Только вместе с решением в облако ушли внутренние IP-адреса, имена серверов, домены, почты сотрудников, токены и прочая служебная информация, которая в этом логе находилась.
Писать в логи чувствительную информацию - это первопричина. Нужно решать её в первую очередь. То есть, не вычищать их, а именно не писать туда ничего секретного.
Я помню рассказ Брайна Чески, что когда они только начинали Airbnb, хосты не понимали, как нужно давать описание, что и как фотографировать. Они сами ездили по хостам, делали фотографии, помогали с описанием.
Он, правда, не уточнял, насколько это помогло в развитии сервиса...
да тут вообще поле непаханое...
сколько народу мучается с редакторами текста... а настройки в браузерах? А сохранение паролей?
да что там, нужен отдельный Хаб "хабро-ликбез". Даёшь тотальную ИТ-грамотность каждому суперпрофессиональному программисту и даже дизайнеру!
ИИ появился давно. По сути любое принятие решения по введённым данным на основе экспертных данных - это уже ИИ.
И всевозможные автопилоты - это развитие этого "классического" ИИ. Эволюция, не революция.
Сейчас пришёл генеративный ИИ - создание текстов, музыки, изображений, аналитики.
Это да, это - революция. Резкая, как внезапный понос. И так же сложно её контролировать. И чем всё закончится - малопонятно...
привязка к языкам - тоже такая себе метрика. Китайцев полно за пределами Китая, русскоязычная аудитория, спасибо ссср и иммиграции - тоже не обязательно Россия.
помимо очевидного - сокращения ФЗП, есть еще какие-то экономические выгоды от внедрения ИИ? Так, чтобы и отбить затраты на внедрение и получать большую прибыль?
https://cs.msu.ru/ai - как я понимаю, - теория и практика обучения моделей.
Скорее всего сперва будут задачи построения разных типов ИИ, с разбором параметров, потом какой-нить большой курс по генеративным ИИ, слои, их состояния, параметры и т.п.
Ну я бы так курс строил. Чтоб по итогам студент мог собрать (и объяснить, что и как он собрал) свою LLM.
соглавен, тяжело. Это правило пришло из опыта. Я начинал с мыслью "план - это артифакт для LLM, временная память, чтоб проходить по циклу, чего его читать, всё же обсудили до этого".
и таки да, 80% не требует корректировки. Но из оставшихся 20% - часть, скажем, половина - критически неприемлемо. И вот чтобы найти эти 10%, - приходится вчитываться и уточнять. Ибо потом исправлять - получается дольше и дороже.
Сейчас я условно делю своё время на 3 части - 1/3 - "детальное описание задачи (мой план)" ; 1/3 - "корректировка созданного плана работ"; 1/3 - "проверка кода"
Почитайте и статьи про "конкурентов" и комментарии к ним - при желании там можно найти кучу интересного, как улучшить вашу "программу для портфолио"...
https://habr.com/ru/articles/1001214/
https://habr.com/ru/articles/1022056/
Ну в итоге получился материал, скажем так, не совсем в формате хабра. Сборная солянка всевозможных (положительных) материалов об RavenDB.
Кстати, ничего не сказано о ценовой политике и правилах лицензирования. В чём и какие недостатки, кому (в каких ситуациях) RavenDB лучше, в каких - хуже. Ну это к тому, чтоб было "всё, что касается RavenDB" - или она такая классная, что просто лучше всех во всех аспектах?
Еще раз, не умоляя ваших трудовых затрат, - попробуйте объективно посмотреть на ваш учебник - для кого он? В каком случае и кому он может быть полезным?
При вашем выборе хабов ".NET C# ASP IT-инфраструктура IT-стандарты" вкупе с заголовком - статья обещала что-то про разработку БД на c#, но ни как (почти рекламный) материал. - люди заходили, обманывались, выходили.
буквально на этой неделе наш директор R&D проникновенно агитировал за "human first agentic dev".
Да, в принципе уже понятно, что кода мы пишем всё меньше и меньше. И время, когда "source of truth" полностью переедет в документацию, всё ближе и, наверное, это неизбежно.
Но в команде пока мы всё равно решили держать "code first" - текущие системы были разработаны людьми без агентской документации. То есть подход применяю упрощенный:
Product team ставит задачу
Я с напарником из front end обсуждаю рамки и интерфейсы
В общей документации прописываем детали реализации
Я натравливаю /plan агента на документацию и прошу план реализации для backend
Тщательно читаю план, корректирую и убеждаюсь, что план меня устраивает
Запускаю реализацию (почти ванильный агент - общие dev skills и copilot_instructions.md)
Тщательно смотрю код, корректирую.
Код в репозиторий идёт чистым, БЕЗ плана.
Ну так оценки ставят не за старания и за объём. Я на хабы c# . net asp.net подписан - вашу статью увидел сразу. Заголовок "Как пишут базы данных на C#: RavenDb" показался интересным, - зашел.
И вышел, достаточно быстро, без оценок - не осилил вашей подачи материала. Но то, что мог прилететь минус в карму за подачу материала - вполне допускаю. У вас там всё вместе - и архитектура, и история создания, и банальности по философии баз данных, и биография автора и сравнение с другими БД, вперемешку с серьёзными графиками и шутливыми картинками.
Разбили бы материал на несколько статей, чтоб не скролить огромную простыню в поисках интересного.
это не новое. Это то, с чем сталкиваешься сразу, как только начинаешь плотно работать с LLM - у всех поставщиков ИИ чатов есть и рекомендации и документация и обучение.
Не спорю, не все начинают работать с чтения документации, но как только замечаешь просадку и понимаешь, что инструмент используется не эффективно - любой инженер полезет читать документацию. И сразу отпадает необходимость в подобных статьях, основанных на личной боли и ограниченном опыте.
И кстати, то, что "автор докопалась до цифр", это хорошо, и надеюсь, что автор понимает, что цифры отличаются у разных моделей, плюс автору будет интересно узнать, "интерфейсы чатов" добавляют свою обвязку, tool definitions съедает кучу токенов, выходные токены (которые в разы дороже входных) включают в себя и внутреннее "рассуждение" моделей и ответ "Да" может стоить гораздо больше 1 токена и т.д.
Там много интересного, есть куда копать...
ведущий инженер после 2 лет с LLM открывает для себя промт-инжениринг.
Ой вэй...
9 лет назад озадачился поиском часов, чтоб и полная интеграция с телефоном была (уведомления, сообщения) и датчики всякие типа пульса и шагомера и чтоб заряжать не каждый день.
В итоге нашeл часы Nokia (сейчас это бренд withings - https://www.withings.com/en-ca/collections/scanwatch-vitals ) батарея за 9 лет неснимаемой носки ёмкости почти не потеряла - заряжаюсь так же - 3-4 часа на зарядке раз в месяц. Да, экран маленький, да, не тачскрин, но это особо и не нужно - время видно на стрелках, бегущей строки хватает, вибрация чувствуется прекрасно.
тут самое сложное - найти покупателя. В принципе, поверить, что она сама нашла нескольких - можно. Потом простые клиенты кончились, появилась необходимость в маркетинге. Пришлось записывать видео о себе талантливой и раскручивать себя, чтоб искать новых Буратин, не знающих куда бы зарыть свои золотые...
Интересная тенденция получается... Амазон тоже вот двигает ИИ "в массы" https://habr.com/ru/news/1065734/
Если откинуть мысль о неразумности старшего менеджмента в обеих компаниях, можно сделать вывод, что по их мнению, инструментарий созрел для массового использования.
Уже не просто чат, но готовая платформа для создания бизнес-решений?
Мадрид бодрит, прямо таки захотелось к вам записаться на ближайшее десятилетие...
Наша компания продаёт железки уже 30 лет. С кастомизированными andoid и linux как платформами, IoT hubs, cloud management, свой graphic programming, компиляция, - в общем зоопарк своего софта колоссальный, нужно и поддерживать и создавать.
Весной всем в R&D (человек 70, это и dev и product) выдали github copilot enterprise подписку и дали карт бланш на ИИ эксперименты.
Прогресс у всех разный - от классического чата до полноценной spec driven разработки. Но по моим ощущениям ожидания у руководства были завышенные и они пока не оправдываются и не факт, что придём к каком-то единообразию.
Здесь простой аргумент - если ваше решение безопасно "по дизайну" - это огромный плюс к продукту как к инженерному решению. И да, это - ограничение удобства отладки в пользу безопасности. И, кстати, не такое уж и сильное ограничение - как правило, внутренние идентификаторы можно считать безопасными - и по ним всегда можно восстановить картину происходящего.
Писать в логи чувствительную информацию - это первопричина. Нужно решать её в первую очередь. То есть, не вычищать их, а именно не писать туда ничего секретного.
Приём не новый.
Я помню рассказ Брайна Чески, что когда они только начинали Airbnb, хосты не понимали, как нужно давать описание, что и как фотографировать. Они сами ездили по хостам, делали фотографии, помогали с описанием.
Он, правда, не уточнял, насколько это помогло в развитии сервиса...