Most active commenters

    ←back to thread

    190 points arittr | 15 comments | | HN request time: 4.876s | source | bottom
    1. antirez ◴[] No.44003190[source]
    So because they need to have a better business model, they will try to move users to weaker models compared to the best available? This "AI inside the editor" thing makes every day less sense in many dimensions: it makes you not really capable of escaping the accept, accept, accept trap. It makes the design interaction with the LLM too much about code and too little about the design itself. And you can't do what many of us do: have that three subscriptions for the top LLMs available (it's 60$ for 3, after all) and use each for it's best. And by default write your stuff without help if LLMs are not needed in a given moment.
    replies(8): >>44003218 #>>44003232 #>>44003442 #>>44003514 #>>44004509 #>>44006515 #>>44007143 #>>44007522 #
    2. visarga ◴[] No.44003218[source]
    > it makes you not really capable of escaping the accept, accept, accept trap

    The definition of vibe coding - trust the process, let it make errors and recover

    replies(1): >>44003566 #
    3. ipnon ◴[] No.44003232[source]
    I don't think they are targeting software engineers as users. They are seeking those on the software engineering margins, users who know what Python and for-loops are but don't care to configure Aider and review each of the overwhelming number of models released daily. They want to tell the editor to add function foo to bar.py. I suspect this latter market segment is much larger than the former!
    replies(1): >>44054886 #
    4. ◴[] No.44003442[source]
    5. bluelightning2k ◴[] No.44003514[source]
    I don't like or agree with this take. You're basically saying - "something good exists, so why try to improve upon it".

    Their stated goal is to improve on the frontier models. It's ambitious, but on the other hand they were a model company before they were an IDE company (IIRC) and they have a lot of data, and the scope is to make a model which is specialized for their specific case.

    At the very least I would expect they would succeed in specializing a fronteir model for their use-case by feeding their pipeline of data (whether they should have that data to begin with is another question).

    The blog post doesn't say much about the model itself, but there's a few candidates to fine tune from.

    6. conartist6 ◴[] No.44003566[source]
    "press pay to think for me button" "press pay to think for me button" "press pay to think for me button" "press pay to think for me button" "press pay to think for me button" I love it
    replies(1): >>44004299 #
    7. DrBenCarson ◴[] No.44004299{3}[source]
    “Hmm seems we’re very far off course but we have thousands of lines…I can’t figure all that out rn…press magic thinking button”
    8. infecto ◴[] No.44004509[source]
    You’ve got a couple of ideas colliding here, let me try to unpack them.

    First, most of the major players already have their own models or have been developing them for some time. Your take feels a bit reductive. Take Windsurf pre-acquisition, for example, their risk was being too tightly coupled to third-party vendors. It’s only logical to assume that building task- or language-specific models will ultimately help reduce costs and offer more control.

    As for the other point: in my experience, trying to fully leverage LLMs actually makes me more prescriptive in my designs. I spend more time thinking through architecture and making my code modular, more so than when I wasn’t using an LLM. I’m sure others may design less or take shortcuts, but for me it’s pushed the opposite behavior. Is it the “right” way? I’m not sure, but I’m enjoying it and staying productive.

    replies(1): >>44006034 #
    9. phillipcarter ◴[] No.44006034[source]
    I think the point is that the UX favors accepting code changes as the primary action, rather than using the chat interface as an ideation tool. It's quite valid, because as a user of all these tools, Winsurf and Cursor very much do try to make you slap the Accept button uncritically!
    replies(1): >>44006514 #
    10. infecto ◴[] No.44006514{3}[source]
    Does it though? I use the chat option quite a bit in the tools. The only UX that favors accept pattern is tab which makes sense.
    replies(1): >>44008568 #
    11. keeganpoppen ◴[] No.44006515[source]
    i think this comment is just a reflection of how the world has not caught up with the inevitable shift of “software engineering” up further into “idea space”. i completely agree that the tooling has not caught up with this new world order yet. personally, i think “true software engineering” is more valuable than ever in the AI era, but the tools for actually realizing this are woefully behind.
    12. bhl ◴[] No.44007143[source]
    Slightly weaker, but cheaper models mostly good for Windsurf only. As a developer, I would rather have stronger models I can throw more money at.
    13. vunderba ◴[] No.44007522[source]
    > they will try to move users to weaker models compared to the best available

    > you can't do what many of us do: have three subscriptions and use each for its best

    I don't think has anything to do with whether or not AI is in the editor so much as it is the difference between a subscription (Cursor) vs. a BYOK approach (VS Codium + Cline, Zed, etc). Most BYOK plug-ins will let you set up multiple profiles against various providers so that you can choose the most optimal LLM for the given problem you're trying to solve.

    14. phillipcarter ◴[] No.44008568{4}[source]
    It does. Defaults matter, and the defaults for these tools are agent mode with code changes meant to be accepted, rather than forcing you to read the code and manually apply those changes.

    Note: I'm not saying that's a bad thing! It's significantly more convenient for many use cases, so I can see why it's a default. But the incentive being created is to accept first, analyze later.

    15. _hcuq ◴[] No.44054886[source]
    When I got my first job in 1986, the company had a tool that allowed non engineers to write code. Of course it didn't work. They could write code, but it ended up as a buggy, unreliable, unmaintainable mess. It turned out it was a good sales tool, get our technology into the company, then we would get paid to write the programs.

    Then the were the the MS Access and Excel amateur efforts. I worked at a company that for years had a very profitable business replacing in house MS Access spaghetti with our well designed application.

    Aaaand..... here we go.... deja vu all over again....