Сначала нам советовали подробно задавать правила в промпте. Промпты росли и постепенно превращались в:
Ты опытный программист. Пиши хороший код. Плохой код не пиши.
Потом появился следующий рецепт: сначала подготовьте подробную документацию, а уже затем поручите агенту писать код. В результате люди начали сначала генерировать агентом документацию, а потом тем же агентом — код по этой документации. Между человеком и кодом просто появился ещё один слой сгенерированного текста.
Заметил за собой такую штуку: рабочие задачи хорошие мысли приходят обычно не за ноутбуком, а когда я от него далеко — в метро, в очереди, на прогулке. Тогда, когда сесть и начать общаться с нейронкой писать код в моменте не получится. Пока дойдешь до рабочего места, пока вникнешь в контекст, пока вспомнишь, что вообще собирался делать - уже и весь фокус над задачей потеряешь. Можно, конечно и с телефона код писать, открыв Termux и судорожно набирать его, но попытки эти были не самыми успешными.
Если совсем коротко: я написал свой VPN на Rust — побайтово-корректный TLS 1.3 с заёмом чужого сертификата, гибридное постквантовое рукопожатие, пять режимов маскировки и под 700 Мбит/с на скачивание. Ниже — как это устроено изнутри и десяток шишек, на которых я учился. Но начать хочется издалека.
На Хабре есть серия статей, касающаяся заблуждений программистов о, казалось бы, простых вещах: о времени, Читать полностью »
Всем привет! Меня зовут Александр, я техлид в продуктовой компании.
Недавно один хороший знакомый набирал команду в стартап. Он приверженец подхода AI first и попросил меня помочь с наймом.
У меня за плечами большой опыт разработки. Настолько большой, что я помню, как разработчики ругали компиляторы C для микропроцессоров за неоптимизированный код и говорили, что никогда не перейдут с ассемблера. Также я помню, как программисты ругали высокоуровневые абстракции за бойлерплейт и обещали никогда не бросить C.
Где‑то прямо сейчас один программист не спит и патчит баг в библиотеке, от которой зависит половина интернета. Он делает это бесплатно. Его никто не знает. Если он уйдёт — никто не придёт.
В апреле 2024 года исследователь безопасности Андрес Фройнд обнаружил бэкдор в xz utils — утилите сжатия, встроенной в большинство дистрибутивов Linux. Атака была почти идеальной: два года социальной инженерии, один выгоревший мейнтейнер и вредоносный код в сборочных скриптах.
Внедрение корпоративных информационных систем ведется по определенным правилам, есть три классические модели имплементации: каскадная, итерационная и спиралевидная. Также доступно множество прикладных методологий внедрения, представленных ASAP, Activate SAP, OUM, MDSS, ADM и расширяющих классические модели. Принимая во внимание то, что ERP-системы представимы коробочными программными продуктами, их имплементация преимущественно ведется на основе каскадно-ориентированных методов и с использованием знаний PMBoK [1].
И мы опять заходим в новый виток развития. Я уже видел что-то похожее в прошлый раз, когда информации почти нигде не было, все учились дома сами, через эксперименты, и программисты ещё не были так жёстко разобраны на классификации. Тогда было много универсалов, которые понимали всё через личный опыт. И тогда реально решала именно экспертиза.
Итак, в системе появилось требование: считать сроки не в календарных, а в рабочих днях. Что делать и на что обратить внимание при тестировании и разработке? Какие решения принимать с точки зрения UX?
На первый взгляд - мелочь. Добавили производственный календарь, исключили выходные, готово. На практике же это превратилось в клубок вопросов:
Когда начинается отсчёт - в момент создания заявления или с начала рабочего дня?
Что делать, если заявление пришла в 23:00?
Когда именно наступает просрочка по заявлению?
Почему пользователь видит 0/5, хотя “срок уже идёт”?
