[captain_coffee]

So let me get this straight - you vibe code, make what you consider as necessary changes to the LLM-generated code, create PRs that get to be reviewed by another AI tool (Copilot), potentially make changes based on Copilot's suggestions and at the end, when you are satisfied with that particular PR you merge it yourself without having any other human reviewing it and then continue to the next PR.

Did I get that right or did I miss anything?

[bartread]

Not quite: remember I said I fettled the code myself? This might involve rewriting, refactoring, reorganising, and I'll make changes to Copilot's PRs as well, but still the percentage of code written by LLM remains what I'd consider to be very high.

I've been an engineer for more than 25 years so I know how to architect an application from the highest level down to the fine details, and I can obviously code in a variety of languages. Even with Ruby and Rails I know it well enough to read and understand the code already. Plus I obviously know HTML and JavaScript, and have used various CSS frameworks and overlays. (Though the truth is I basically hate fussing with CSS [and its various proxies], and I'm very far indeed from the king of UX or design anyway, so having an LLM to assist with that is a godsend.)

The strict definition of vibe coding, as far as I've understood it, is that you don't touch or even really look at the code at all, and make all modifications, do debugging, etc., via prompting the LLM or using an agent. Vibe coding tends to break down in critical areas like security, or when the contours and wrinkles of the domain become too complex, so I'd never trust that approach for anything substantial or where security is a critical concern. For most organisations the data that I'm working with in our app is going to be second only to financial information in terms of sensitivity, and it's a complex domain, so the problems we're solving are simply not amenable to a pure vibe-coding approach.

Going back to the original point on how much code LLMs are writing: with other languages that I'm more familiar with, where it might be quicker for me to write the code to do what I need myself rather than write a spec for the LLM, and modify afterwards, you would probably see quite a different picture.

[captain_coffee]

Yes OK, but that was not the point that I was trying to make.

You are developing in a language + framework that you are not familiar with, without having any human feedback in the process at all - see where I am going with this?

Even with a quarter of a decade of experience you are still in what can basically be reffered to as uncharted territory.

[bartread]

Define what you mean by uncharted territory?

- I've never used a new language or framework before? Nope

- I've never used both a new language and a new framework at the same time? Nope

- I've never tried to do real work in a new language and new framework that I'm not particularly familiar with? Nope

- I've never shipped work I've done in a new langauge and new framework that I'm not particularly familiar with? Nope

What specifically do you think is so magic about Ruby and/or Rails that you think I won't have encountered something similar in some other form - in some other language or framework - before?

And do you not think that the reviewing and changes that I am making to the code, the prompting I'm doing, the decisions I'm making about which changes to integrate and which to ignore, etc., as a human being, count as feedback?

At the end of the day I'm building a web app, and soon enough an API, and the concerns in building this web app and API are exactly the same as the concerns I've had in building other web apps and APIs.

The only difference is the language and the framework, and I've learned new languages and frameworks before. And, although I'm using an LLM to help, I've been doing that for the past 3 years using different stacks and the only notable difference is that LLMs are quite a lot better at helping to develop software than they were 3 years ago.

So how is this uncharted territory?

---

And, as an aside, not an issue you've raised but one I commonly see on HN: people moaning about job ads demanding X years of experience in this or that framework or language (with the parody being that the desired framework or language has only existed for X years, or maybe not even that long), and how this isn't really relevant to whether an experienced software engineer can do the advertised job or not. I happen to agree with that perspective but here's the thing: you can't have it both ways. Either that's true or it's not true, and I'm operating (as I have done before and as you can probably tell) on the basis that it is true.