If that's third then I have fourth. Self plug obviously, but figured that I'd like something between smart autocomplete and an agent -
an autocomplete that has wider context.
Called it rik, and it's on GitHub if anyone's interested checking it.
Having worked across many disjunctive domains the value of "expert in domain" is greatly exaggerated. It's not like search engine doesn't exist nor that it cannot be easily absorbed. Quite often becoming expert is as simple as careful reading API documentation for existing, same domain system.
The piece is heavily one sided and don't recognize the problem of low reliability software: e.g. imagine a software designed in a way that it keeps critical piece of data as a global static variable. This will always work for a single user but will leak with two. Make it semi-critical and e.g. a part of profile loading.
Just as non-expert cannot verify if result is correct from a domain perspective, expert in domain cannot verify the output based on the basic principles (data security, safety, isolation, persistence, etc.) or even know that monetary values shouldn't be kept in floats.
Nothing like article claim had changed outside of a false promise of being productive.
Software engineers without domain expertise can fake it with unreliable results and experts without swe skills can fake it with unreliable results.
Imagine Internet forum/StackOverflow etc. and a objectively bad description or attempt to a solved problem.
Pleasantry and back pats won't encourage the change while harsh words will either make poster go silent or push forward and improve.
AIs aren't people. They are statistical training sets which have majority of their sets consisting in human-like communication which gives them high probability of human-like speech. But it's not kindness or rudeness in the end. It's how good the pattern can scoop data out of training set.
I'll piggyback on something someone else here on HN commented (can't cite, sorry!): I can immediately recognize vibe coded projects by their visual design.
It's a weird skill but after seeing website, screenshot etc. I need only couple of seconds to make an opinion. I then look into history of project etc., though it rarely contradicts first impression.
I think I do this because I don't trust thus I don't want to use such projects. Not because vibe coded/vibe-code driven projects are inherently bad (they aren't). Because I think low self-investment translates to low ongoing self-interest.
Since all software is buggy to some degree, I'm certain I'll find a dealbreaker that will never be addressed, and risk is rarely worth it.
I won't be as harsh because I have years of experience in Rails and didn't develop harsh feelings against it but moving from Rust/Go/Zig/TypeScript (which I used lately) to Ruby ain't smooth ride.
Discoverability is much worse, LSPs aren't super helpful. Using Dash (documentation app) helps a ton. Still some names are confusing after switch (took a minute to recall that 'filter' is actually 'select' in Ruby).
I won't say that dev experience is bad but it's definitely different.
Weird that searching for it didn't yield any results, though I stand corrected.
However it seems that select is the actual "root" of documentation. Filter sends to find_all, find_all sends to filter or select.
Post ain't about project written in LLM (and Rust one have 6 months in good ol' craft code) but about contrast between two variants.
While personally I'm skeptical about LLM usage (and vibe coding in general) I'm not going to pretend it doesn't exist just on principle. I wouldn't risk rewrite 6 months worth of code to Rails but it's a perfectly good case for LLM conversion.
The point isn't about writing it but seeing difference and making probably suboptimal choice.
I mentioned in other comment that I reviewed it extensively. It's not a big project so outside of a few spicy bits it's mostly a web app.
I'd say that saying "not putting thought into it" is unfair. I didn't push the button and YOLO.
I did research about the tradeoffs and consequences. Snippets of Rust code vs Rails are the real thing and testability of Rust app is something I spent 2 months on.
Called it rik, and it's on GitHub if anyone's interested checking it.
https://github.com/exlee/rik
reply