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