Фронтенд

Devin - первый "полноценный" junior AI-разработчик

Чуть больше года назад интернет взбудоражила новость о повялении первого AI-инженера по имени Devin. Некоторые отнеслись к идее скептически, в том числе и я, тогда казалось, что это больше похоже на хайп. Хотя инвесторы поверили в идею, стартап привлек 175 млн. $ (а чуть ранее 21 млн.$). В марте этого года был еще один раунд, но сумму не нашел.

Но на днях посмотрел интервью с основателем Cognition (компания, которая создала Девина), и изучил их прогресс, и теперь кажется, что за этим явно что-то есть.

Вообще, лучше любого интервью и пресс-релизов расскажут клиенты, а их, судя по сайту, довольно много. Какие-то компании я знаю, какие-то нет. Как пример, среди них есть Nubank (крупнейший банк в Латинской Америке), их CTO говорит, что благодаря Devinу ускорились в 8 раз при миграции и рефакторинге старого кода, и это на проектах с миллионами строк.

А вот CTO Microsoft Кевин Скотт называет Devin "absolutely amazing tool".
Также посмотрел демо одного из их клиентов. У него комбинация: сначала прототипирует с помощью v0 (это аналог Bolt), затем использует связку Devin и Cursor для полноценного запуска, но надо отметить, что у него инженерный бэкграунд, потому все получается легко и просто, я как не разработчик, точно бы так не смог.

Что он умеет сейчас?

-Понимает бэклог и может сам брать задачи в Jira
-Сам пишет и запускает тесты
-Делает pull requests с комментариями
-Разворачивает окружение и деплоит код
-Общается с командой в Slack
-Задает уточняющие вопросы

В общем, это не просто GitHub Copilot, который дописывает строчки, или даже Bolt, который делает часть работы. Это полноценный член команды.
В компании сейчас всего 15 разработчиков, но каждый из них "тимлид" с 5 Девинами в команде. По словам основателя, за год Devin эволюционировал от уровня "студента старшего курса по информатике" до "джуниор-инженера". К концу года они планируют, что половина кода компании будет написана AI, сейчас это 25 %. И если прогресс пойдет такими темпами, "мидл-инженер" это вопрос месяцев.

Конечно, пока Devin подходит не для всех задач. По словам фаундера, лучше всего работает с "структурированными задачами": миграции, рефакторинг, автотесты. А вот где нужно больше креативности и архитектурных решений, там пока рулит человек.

Я только не очень разобрался с тарификацией. Есть тариф Pay As You Go, надо закинуть от 20$. Следующий тариф начинается от 500$ полагаю, что это примерно один разработчик, но правда тариф называется Team. В любом случае, 500$ даже за одного джуна выглядит неплохо.
Я думаю, CTO всех компаний стоит приглядеться к подобным решениям и нанять хотя бы одного "стажера" на пару месяцев, чтобы потестировать, тем более он, не выгорает, не "токсичит", но скорее всего жестко "тупит" 🙂.

P.S. Про другие интересные стартапы можно почитать на моем канале StartupHunt. 

Приглашаем вас на бесплатный вебинар «TypeScript за час: основы, плюсы и практика». Познакомим вас с TypeScript. Расскажем, зачем он появился, в чём его преимущества и как он помогает писать понятный и надёжный код. Подойдёт и новичкам, и практикам.

⁉️ На вебинаре вы сможете задать вопросы спикеру.

📅 Дата: 13.05.2025

⏰ Время: 17:00-18:00 (Мск)

На вебинаре:

✔️ История возникновения TypeScript

✔️ Преимущества использования TypeScript

✔️ Пример написания кода на TypeScript

👨‍🎓 Спикер: Кучин Евгений — разработчик на Java и JavaScript.

✍️Записаться на вебинар

Возможно, вам будет интересен курс «Язык программирования TypeScript». Вы освоите TypeScript, изучив типизацию, интерфейсы и классы. Узнаете, как использовать статическую типизацию, интегрировать TypeScript с существующим JavaScript и настраивать окружение разработки. Это поможет сделать ваш код более безопасным и структурированным.

Старт: 19 мая

Цена: 14 900 8 940 ₽ (-40%)

✍️ Записаться на курс

Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability

Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.

Главные проблемы классического подхода:

1. Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.

2. Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.

3. Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.

Решение — Observability:

Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.

Пример кода

Отслеживание конверсии платежей в .NET-сервисе:

// Отслеживание конверсии платежей  
using App.Metrics;  
public class PaymentService  
{  
    private readonly IMetrics _metrics;  
    public PaymentService(IMetrics metrics) => _metrics = metrics;  

    public void ProcessPayment()  
    {  
        try  
        {  
            // Логика обработки платежа...  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);  
        }  
        catch  
        {  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);  
        }  
    }  
} 

Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.

📖 Нужны подробности? Читайте статью на хабре: «Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения»

Научите, как пользоваться Хабром

К примеру, открыл я сайт. Увидел статью (оказалось пост)

Решил поставить комментарий под постом. Просит залогиниться. Жму залогиниться...

И всё, нет поста. Потерялся видимо в моих "рекомендациях". Необоснованные трудности для пользователя на пустом месте.

При этом пост не имеет простой ссылки открываемой кликом по заголовку или тип того

Решил вопрос, нажав - поделиться, скопировал. Залогинился. Вставил ссылку. Перешёл....

Мне кажется не такой должен быть пользовательский путь

Как тестировать фронтенд?

Для меня уже нет вопроса - нужны ли тесты на фронтенде? Личный опыт подсказал, что нужны, как и согласованный цельный подход к архитектуре. Тому есть несколько причин:

• Без unit-тестов и автоматических e2e-тестов ручное тестирование занимает много времени. К тому же человек, скорее всего, при регрессионном тестировании что-то пропустит, и баги попадут в production. Особенно это актуально для больших проектов с большой кодовой базой.

• Без автоматических тестов страшно рефакторить код. А если нет выстроенной архитектуры с соблюдением low coupling/high cohesion, то этот страх вполне оправдан. А без регулярного пересмотра кода приложение рано или поздно превратится в большой комок грязи.

• У unit-тестов есть интересный побочный эффект. Если пользоваться подходом TDD и писать тесты сразу вместе с кодом (и даже перед написанием кода), то качество модулей и архитектуры в целом повышается. Это происходит, потому что с позиции написания теста мы думаем не только о том, как нам побыстрее завершить работу над модулем, но и о том, как этот модуль будет выглядеть снаружи, удобно ли будет его использовать внутри других модулей, так как тест в этом случае служит ещё и образцом вызывающего модуля.

• Тесты - это дополнительная документация к коду. Причём такую документацию не получится держать в неактуальном состоянии, иначе упавшие тесты не пропустят код в production при наличии настроенного шлюза проверки качества в CI/CD пайплайне.

Это всё прекрасно и, как показывает практика, работает, как ожидается, но остаются вопросы.

• Как тестировать уровень представления приложения? Например, в случае с каким-нибудь фреймворком с использованием React это будут React-компоненты, виджеты, представляющие отдельные элементы пользовательского интерфейса. Тестировать там, по сути, нужно функцию. Передали ряд аргументов (пропсов или состояний) - получили одно представление. Передали другие аргументы - другое. Зависимость результата от набора аргументов - однозначная. Чтобы это проверить, можно использовать тесты со скриншотами. Я предпочитаю snapshot-тесты, они дают больше контроля, но работают довольно медленно и могут быть хрупкими, если недостаточно грамотно отделять слой представления от логики.

• А что со временем написания кода вместе с тестами? Будем ли мы вовремя успевать сдавать новые модули и радовать наших пользователей и руководство? Я думаю, что это не совсем правильные вопросы. Спрашивать надо о том, сколько будут стоить ошибки, попавшие на production из-за отсутствия тестов? Если ваше приложение - landing page с минимумом логики, то вряд ли цена ошибки будет высока. В небольшой кодовой базе её будет легко локализовать и исправить. А если вы работаете с финансами и у вас миллионы пользователей? В этом случае цена ошибки на production будет намного выше.

• Как донести необходимость тестов до команды и правильно включить автоматизацию тестирования в процесс разработки? Это на самом деле серьёзный вопрос. Не все разработчики понимают, зачем вообще тесты на фронтенде и обоснование их необходимости может вылиться в не слишком продуктивный холивар. А если продавливать такое решение сверху, то без понимания и принятия командой этого решения будут попытки обойти систему и снижение мотивации. Мне когда-то в подобной ситуации помогла практика парного программирования и выстраивание инженерной культуры в команде (совместное чтение технической литературы, архитектурные встречи с использованием white board).

А какие практики для тестирования применяете вы?

Yahoo - давно забытый гигант, пытающийся вернуть былую славу

На днях появилась занятная новость, Google могут заставить продать Chrome. И вот среди потенциальных покупателей вдруг всплыло имя Yahoo. Реакция в сети была примерно такая: "Ого, а они вообще ещё живы?" Спойлер: живы! И, что ещё интереснее, Yahoo переживает некий "ренессанс", до былой славы пока далеко, но в родной Америке они по-прежнему большие ребята. По трафику новостей №1, в спорте №2, в email №2, а в финансах снова №1. 8 из 10! американцев хотя бы раз в месяц заходят на сервисы Yahoo. Неплохо для "призрака прошлого" 👻.

Немного истории. Yahoo появилась в 1994 году, когда многие из нас даже не знали, что такое интернет. На пике капитализация компании превышала 125 млрд. $, а Google им в своё время предлагали купить себя за... 1 млн. $. Отказались. А ведь мы могли Яхить, а не Гуглить. Тем интереснее возможность текущей покупки, тут явно будет сумма на несколько порядков выше.

Потом долго были на вершине, и началось стремительное падение. Ошибок было много: неудачные покупки вроде Tumblr, упущенные тренды вроде мобильных приложений, бесконечная чехарда с руководителями... В итоге Yahoo в 2017 году продали Verizon за символические 4,5 миллиарда долларов.

И вот теперь - вторая молодость. Новый CEO Джим Ланзон в недавнем интервью рассказал, что, когда он пришёл, каждый продукт Yahoo требовал апгрейда. Аудитория огромная, но всё выглядело устаревшим, а монетизация слабой.

Что они делают сейчас:

• Сокращение штата, закрытие старых рекламных платформ.

• Новые версии всех ключевых продуктов (новости, спорт, финансы, почта).

• Найм новых лидеров.

• Развитие сильных направлений и внедрение AI-решений.

• Ищут новые источники дохода помимо классической рекламы.

По сути, Yahoo снова строят компанию внутри старого бренда.

В современном интернете Yahoo воспринимается как "винтаж", а конкуренция за внимание пользователей безумная. Тем не менее, если им удастся превратить этот "камбэк" в устойчивый рост, Yahoo точно попадёт в учебники по бизнесу, как из один примеров перезапуска 💪

P.S. Про другие интересные стартапы можно почитать на моем канале StartupHunt. 

Substack - "переизобретение" интернета с помощью e-mail.

Представьте: на дворе 2017 год. Соцсети на пике — у главной соцсети почти 2 млрд. пользователей, у WhatsApp 1,5 млрд, у YouTube 1 млрд. MAU. Все бегут за видео, сторис и мемами, умными лентами. И вдруг… два молодых парня говорят: «А давай сделаем бизнес на e-mail», на технологии, которой почти 50 лет, которой уже не первый год предвещают закат. Звучит как идеальный способ провалиться. Но это начало очень классного стартапа Substack.

Идея была простая: вернуть интернету "человеческий голос". Без «лайкни, подпишись, оставь комментарий». Substack стал местом, где писатели, журналисты и просто умные люди могли напрямую говорить с аудиторией. Без редакторов, без рекламных отделов, без алгоритмов, решающих, кто что увидит. Только автор и его читатель.

Один из сооснователей, Хэмиш Маккензи, говорил:

Главное, что мы увидели, было то, что писатели, у которых была аудитория, на самом деле не имели власти над своей судьбой. Они были во власти платформ и изданий, которые их нанимали. Мы хотели создать систему, в которой писатели могли бы иметь прямые отношения со своими читателями и могли бы владеть своей судьбой

Вот что делает Substack особенным:

• У каждого автора — собственная платформа.

• Возможность брать деньги напрямую с подписчиков.

• Контроль над аудиторией: ты знаешь, кто тебя читает и можешь говорить с ними без посредников.

• Простой инструмент публикации — сначал был только емейлы, значительно позже появились подкасты и видео.

• Комьюнити и дискуссии.

Я сам подписан на несколько рассылок. Две из них платные, и я отдаю за это 300$ в год. Кто бы мне сказал в 2017 году, что я буду платить такие деньги за e-mail — я бы посмеялся. А теперь это мой любимый контент, стараюсь все прочитать.

И я не один. У Substack сейчас > 3 млн платных подписчиков (это оценка по состоянию на 2023 год). За всё время стартап привлёк около 100 млн. $Последняя оценка — 600 млн $, выручка за 2023 — 29 млн. $ Да, это не миллиарды соцсетей, но это деньги за "живой" контент.

Substack переизобрёл интернет не с помощью новой технологии, а с помощью старой идеи: говорить по делу с теми, кто тебя действительно слушает.
А еще недавно один из основателей был на подкасте (https://a16z.com/podcast/building-substack-reinventing-culture-through-subscriptions/) a16z, выпуск получился очень интересным.

P.S. Про другие интересные стартапы можно почитать на моем канале StartupHunt. 

Positive Technologies использует ITSM-систему SimpleOne

Компания Positive Technologies, лидер в области результативной кибербезопасности, мигрировала на российскую систему управления ИТ-услугами от SimpleOne, входит в корпорацию ITG. ITSM-система позволила организовать поддержку более 10 000 пользователей и 60 бизнес-процессов. Проект реализовали команды системных интеграторов ITGLOBAL.COM, корпорация ITG, и «Медиа-тел»‎.

Positive Technologies является ведущим разработчиком продуктов, решений и сервисов, позволяющих выявлять и предотвращать кибератаки до того, как они причинят неприемлемый ущерб бизнесу и целым отраслям экономики. В компании возникла потребность в модернизации системы управления клиентской поддержкой, до этого использовалось зарубежное программное обеспечение. После анализа российского рынка ITSM-решений эксперты Positive Technologies выбрали SimpleOne ITSM.

«SimpleOne позволила реализовать гибкие процессы поддержки, учитывающие специфику продуктов и сервисов в сфере кибербезопасности. Особенно важным для нас стало внедрение функциональности по управлению лицензиями, инсталляциями и продуктами, реализованной на базе модуля CMDB», — отмечает Олег Замощин, директор сервисного центра Positive Technologies.

Интеграция SimpleOne ITSM от начала активного внедрения до запуска системы в промышленную эксплуатацию заняла 6 месяцев. В ходе проекта команды клиента и интеграторов дополнительно реализовали уникальные решения, например, систему управления многоуровневыми SLA для разных продуктов и категорий клиентов. Для бесшовного процесса обработки обращения была настроена двусторонняя интеграция с клиентским порталом Positive Technologies. Теперь клиенты могут отправлять заявки на обслуживание, получать информацию о лицензиях и давать обратную связь.

«Хотя изначально планировалось использовать максимально коробочное решение, гибкость платформы позволила реализовать все пожелания без компромиссов. Мы существенно доработали пользовательский интерфейс, добавив визуализацию элементов управления и настроив удобную навигацию», — комментирует Владимир Лялеко, директор центра управления ИТ-услугами «Медиа-тел».

SimpleOne ITSM используют все сотрудники Positive Technologies, занимающиеся поддержкой продуктов и лицензий, а также частично специалисты R&D-департамента. Более 10 000 пользователей взаимодействуют с системой через клиентский портал. Объем обращений достигает 40 000 в месяц.

«Решение SimpleOne оказалось оптимальным вариантом, отвечающим всем потребностям компании к гибкости и функциональности. Уверен, что внедренная система поможет Positive Technologies и далее поддерживать высокое качество сервиса», — отметил Василий Белов, исполнительный директор ITGLOBAL.COM.

«В современных условиях компании уделяют все большее внимание сервисным процессам. Важно не только поставить качественный продукт, но и организовать его дальнейшую поддержку на высочайшем уровне. Мы как вендор решений понимаем это очень хорошо, поэтому и разрабатываем продукт, который способен закрыть любую потребность»‎, — комментирует Сергей Чуканов, генеральный директор SimpleOne.

Андрей Смирнов: аутстаф в X5 Tech, 150+ выпусков Frontend Weekend и бесконечные конференции

Гость этого выпуска ЧТНП – Андрей Смирнов, автор и ведущий подкаста  @frontendweekend. Его часто видят на конференциях, где он рассказывает о пользе софт скиллов, а в промежутках между конференциями Андрей руководит управлением клиентской разработки в X5 Tech. 

В подкасте обсудили:

— Как все устроено в X5 Tech: что разрабатывают, как растят джунов, почему выступают за аутстаф и против аутсорса?
— Как выглядит рабочий день высокоуровневого руководителя в IT, какие карьерные перспективы и к чему стоит готовиться?
— Как поддерживает экспертизу в программировании и есть ли в этом необходимость?
— Frontend Weekend: история создания, монтаж роликов и выгорание. Будет ли видеоформат?
— Сколько мероприятий Андрей посещает в год и не устает ли? Что за секретный чат гастролирующих спикеров?

«Что-то на программистском» (ЧТНП) — подкаст компании Doubletapp со спикерами из разработки, дизайна, машинного обучения, IT-образования и топ-менеджмента. Длинно, глубоко, фактурно.

Видеоверсию подкаста «Что-то на программистском» с Андреем Смирновым смотрите на YouTube-канале Doubletapp, аудиоверсию слушайте на удобной площадке.

Уже вышли выпуски ЧТНП с Григорием Бакуновым, Глебом Михеевым, Петром Асратяном.

Смотрите и подписывайтесь!

ЧТНП | Глеб Михеев — Skillbox, алгоритмы и менторство

Герой подкаста «Что-то на программистском» от Doubletapp — Глеб Михеев, пропагандист софт-скиллов и гуру фронтенд-разработки. Но эти темы уже обсуждались в других его интервью. Мы же поговорили с Глебом о развитии карьеры, бизнеса и его опыте в роли начинающего фронтендера, фаундера и СТО. 

Что ждет в выпуске:

- Гайд по конференциям для джунов, мидлов и сеньоров: как начать диалог, о чем говорить и что делать на ивентах?

- Почему оставил свою компанию Beta и ушел наемным сотрудником? 

- Нюансы собеседований: как нанять классного разработчика и СТО?

- Стоит ли доверять свою карьеру коучам и менторам?

- Почему Skillbox – это годное обучение? 

Что-то на программистском (ЧТНП) — подкаст компании Doubletapp со спикерами из разработки, дизайна, машинного обучения, IT-образования и топ-менеджмента. Длинно, глубоко, фактурно.

Другие выпуски смотрите на YouTube.

А также слушайте на любой удобной платформе. 

Если вы используете бесплатную IntelliJ IDEA Community Edition, то из поддержки JS и CSS там только весьма скудная syntax highlighting only подсветка синтаксиса, но есть простой способ её улучшить.

В этом нам поможет плагин TextMate Bundles, который уже встроен в современных версиях IDEA. В этом плагине уже встроены бандлы для JavaScript и CSS, причём, с достаточно неплохой подсветкой синтаксиса. Загвоздка в том, что эта подсветка не работает из коробки, т.к. её перекрывает та самая syntax highlighting only подсветка.

Чтобы всё заработало, идём в Settings > Editor > File Types и удаляем File name patterns для CSS (syntax highlighting only) и JavaScript (syntax highlighting only). Тоже самое можно проделать и для SQL (syntax highlighting only).

Пример было/стало для JavaScript:

К сожалению, это не даёт подсветку синтаксиса для CSS и JavaScript встроенных в соответствующие HTML тэги.