>"So what do you / your team do?"

Probably the hard part; figuring out what the heck to actually build, talking to customers, and figuring out whether it's actually working for people.

Nobody cares that your codebase is Clean and SOLID, or uses $whatever_framework of the day with 100% test coverage.

“Maintainability” is probably the word you are really looking for. Few devs care whether something adheres to whatever as long as we maintain:

- user experience/expectation (i.e., if feature X worked three years ago, it still works in a consistent way today after a bug fix) - development cadence (if implementation of feature X took N days, a comparable feature Y should take N days) - sanity (can we assume that a fix going in Thursday night or Friday morning doesn’t wreck the weekend)

SOLID, DRY, ACID-compliant, linted, formatted, clean, functional, compositional, etc. May be the means (misdirected or otherwise) but they are not the motivator(or at least should not be).

What matters is whether the day two feature requests, bug reports, CVEs, and traffic load that are coming can be met on time.

Not saying it can’t be done without a developer at the helm, Anyone Can Cook™, but I guess it depends on what harness is in use or has created for the org, and whether that consideration is baked into the guidelines for the codebase (which seems to be, at least to some extent, what this service tries to course correct).

And of course, what is done to the process when incident x happens, again and again. Are we only updating code without paying attention to process that enabled it in the first place?

Maybe that’s the story of vibe coded repos: the code devs were removed but we really still need devops personnel. Also maybe new tech will be more readily adopted.

Interesting times.

Yes, I'm familiar with these talking points. I didn't mention clean code or solid or frameworks or anything like that.

However, the poster explicitly said they don't do what you said (EDIT: I misinterpreted some of these):

RE "talking to customers"

> We get feature requests, improvements, ideas, feedback. JIRA tickets get created, and we ask AI to reference that ticket, code to it, and create a PR

RE "figuring out whether it's actually working for people"

> have senior engineers review the actual functionality and none of them have read any more than a few lines of code

RE "figuring out what the heck to actually build"

> replaced by "vibe" coding

Maybe my definition of vibe coding is wrong?

--

In any case, I don't have some ulterior anti- or pro-AI motive. I'm genuinely curious why and how a project run this way has humans in the loop at all.