Search
Write a publication
Pull to refresh

Comments 16

Рад, что понравилось. Вот читаешь и кажется, что он достаточно просто устроен и не до конца понятно на чем основан его успех среди других похожих решений.

Забавно. Прошло меньше месяца, но все закончилось не успев начаться.

Сделка сорвалась, топов из Windsurf забрал себе Google, а саму компанию выкупил другой стартап с кодинг-ассистентом. В принципе, кто-то денег получил, но не те три 3B, о которых шла речь.

Не только. Я мельком смотрел и тот и другой, и от Windsurf осталось ощущение, что он немного сыроват ещё - если сравнивать хоть с Cursor хоть с Zed. Оно из множества разных мелочей складывалось (притормаживал, странные ограничения на размеры и количество правил, неясно зачем и кому нужный режим планирования, их основная модель SWE-1 творит полную дичь, если не путаю нет белого списка команд, …), вроде всё не критичное, но в сумме желания продолжать его использовать не возникло в принципе.

Фантастика!

Вторая часть получилась сильно круче первой. И задачи команда решает совершенно нереальные.

Спасибо за перевод!

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

Ну нету у них других таких пользователей...

Сам Амазон столько не просит

А задачи у них в целом типичные для высоконагруженных сервисов, правда умноженные на порядок

Вот этот порядок (10 раз) в статье отлично виден

Из того что они отмечали как великие подвиги почти все известные и иногда детские проблемы. На лицо отсутствие проработанного дизайна, нормальных архитекторов и специалистов способных работать с конкретными технологиями (хотя чего ожидать от стартапа на 50 человек). Заявление от том что надо "по возможности избегать шардинга в будущем" добило, посмотрим что они напишут через год-два.

Любой подвиг - обычно следствие чьей-то ошибки. Если всё делать нормально, то подвиги не понадобятся. Но - всё нормально не делается почти никогда, так что место подвигу всё ещё есть.

Да, почти всё проблемы известные и относительно детские. Но не тогда, когда во-первых ты заранее не знаешь, какие из известных и детских проблем критично проявятся на конкретно этом проекте, и во-вторых когда они на тебя вываливаются внезапно и по нескольку одновременно, и времени на нормальное решение нет, потому что нужно тушить пожары и срочно масштабироваться на порядок. Да, если знать заранее что понадобится то многих проблем можно было бы избежать. Но этого не знает никто. Так что если Cursor с этим справился, значит они молодцы.

Спасибо. Интересная статья! Меня все не отпускают сомнения - смогут ли они и дальше справляться с ростом. Уж слишком нагрузка у них запредельная, учитывая относительно небольшое кол-во пользователей. Уже крупнейшие в aws.

Sign up to leave a comment.

Articles