[beachy]

My friend built a construction management SaaS entirely via Claude.

It looked damned impressive, and it kind of worked to demo, but he is in no way a programmer, though he understood the problem domain very well. I asked a few basic questions:

- where is the data stored?

- How would you recover from a database failure?

- does it consume tokens at runtime?

- what is the runtime used at the back end?

- why are the web pages 3M in size and take forever to load?

He had no idea.

It's a typical vibe coding scenario, and people like to paint this as why vibe sucks.

I think however that all that is needed to bridge the gap is some very simple feedback from an expert at the right time.

For example to someone who knows about databases, its pretty easy to look at a database schema and spot stuff that looks off - denormalised data, weird columns. That takes 10 minutes, and the feedback could be given directly to the LLM.

Likewise someone who knows a little about systems architecture could make sure at the outset that some good practices are followed, e.g.:

- "I want your help to build this system but at runtime I do not want to consume any tokens."

- "I want the system to store its data in Postgres (or whatever) and I want documented recovery plans if the database craps itself".

- "I want web pages to, as much as possible, load and render as quickly as possible, and then pull data in from the back end, with loading indicators showing where the UI was not yet up to date".

[jeremyjh]

One of the riskier bets my team is currently making is that this is exactly what is needed, and nearly nothing more.

We have LOB prototypes vibe coded by enthusiastic domain experts that we are supporting in a “port and release” fashion. A senior engineer takes the prototype and uses Claude code to generate a reasonable design, do an initial rough port (~80% functional, 100% auth & audit logging) and (hopefully) all the guidance necessary to keep the agent between the lines. Coupled with review bots and evolving architecture guidance etc. Then the business partner develops and supports it from there.

For low stakes CRUD, I think it’s a reasonable middle ground. There truly is a lot of value in letting an expert user fine tune UX; and we’re only doing this with people who are already good at defining requirements and have the kind of “systems” thinking that makes them valuable analyst resources to the tech team already. Early results are encouraging but it’s way too early to draw conclusions.

Personally I hate how badly internal users are served by the majority of their systems and am willing to take some calculated long-term governance risks.

[cushychicken]

Personally I hate how badly internal users are served by the majority of their systems and am willing to take some calculated long-term governance risks

This, I think, is the LLM/vibe coded app’s current place to shine.

Most internal systems don’t need massive concurrency or redundancy. It’s a webapp that reduces coordination cost between 20ish people. That’s something you can typically vibe code and deploy for ten bucks a month, and create real value.

[jappgar]

The problem is that everyone has a different opinion. If you let a single user drive the design then that single user might love it, but everyone else will hate it.

Bespoke designs are often really terrible. Have you ever shopped for a house?

You know immediately when the previous owner had their stupid whims indulged by contractors with dollar-signs in their eyes. The house is ugly, non-functional and is not going to get the sellers price.

The next owner will undo nearly all of the work, and the contractor will cash in on both ends.

As engineers, we like to think we're the contractor in this scenario. But it's actually just an LLM.

[Merad]

I've been in a similar situation as the GP. 15 years ago my first job after college was at a large Fortune 500 building LOB apps. The company was full of departments that were run entirely out of a massive Excel spreadsheet (hundreds of MB or more), or better yet a totally custom thing built on Access97 and VB made by a guy who retired 10 years ago. More than a few of the people in these departments had been in the same job for 20+ years and literally done the job the same way the whole time. Our mandate was not to modernize their business processes or make them friendly to automation, it was literally to indulge their stupid whims. But at least at the end they would be on an app where IT had access to the source code, could ensure databases were backed up, etc.

[jeremyjh]

Sure, but these are small departmental apps, 20 users or less in most cases. It’s not like everyone is using every app. The alternatives at this scale are far worse.

[AlotOfReading]

I know you didn't intend this, but a job where your main function is telling a machine how to copy someone else's half-baked CRUD sounds absolutely soul-sucking.

[jeremyjh]

It would, but that is not what is happening here so far, these are less than 5% of our workload.

[tardedmeme]

Is CRUD low stakes? Even if all you do with the employee database is read and write employees, losing it or corrupting it is disastrous, potentially business-ending.

[jeremyjh]

Some of it is, certainly, and those are the ones we’re supporting this way. I’m not talking about systems of record - more like custom project and task coordination systems that would alternatively exist in spreadsheets, in Monday.com or wedged into some larger system that is a poor fit and functions largely through side channels.

[0rbiter]

> review bots

Say no more.

[jeremyjh]

Have you actually used them ? They are really good now if you configure them correctly. Code Rabbit catches more bugs than anyone in our main platform - mostly because it gets the first crack but that is still significant time and churn savings. Very low rate of false positives and almost always reasonable questions when they are.

[Retric]

> That takes 10 minutes

Verifying LLM output needs to occur every time LLM output is generated, so no it doesn’t just take 10 minutes.

It takes 10 minutes + time to change the LLM input + 10 minutes to verify it worked * ~the number of times the code is generated.

Which is why vibe coding is so common, if you actually care about quality LLM’s are a near endless time sink.

[gnz11]

> I think however that all that is needed to bridge the gap is some very simple feedback from an expert at the right time.

I don't think it's as simple as that. What will most likely happen is that the vibe coders will quickly eat up your time asking for validation and feedback if you are not careful. You are also now implicitly contributing to their project, which if it goes south, could come back to bite you. If the vibe coders are pushing code in the org, then they should become part of the formal review process like any other junior programmer.

They should also be forced to do daily stand-ups, sit in meetings and explain their code like the rest of us.

[pessimizer]

> I think however that all that is needed to bridge the gap is some very simple feedback from an expert at the right time.

This could be a viable business idea. LLMs have allowed people to code who have very little understanding of how computers work but maybe a lot of specific domain knowledge and a good idea for a tool that could solve a problem. Maybe they need to rent a manager/advisor to review what they're doing and provide sanity checks.

Maybe pay for an hour a day of somebody reviewing your day's work and sending you a bit of prose explaining the parts that are wrong-headed about it?

I guess the problem with this might be that the review may just end up virtually identical to a prompt in the end; and if you can't completely remove the programmer when you have the domain knowledge, it might be easier to use the LLM for the domain knowledge you lack as a programmer. The work product is on a computer, computing might be the most relevant thing to know.

But independent writers hire editors, seems like the same sort of thing.

[baxtr]

Sounds like it was a prototype to validate an idea?

I think at validation stage technical details like that shouldn’t matter. All that matters is there market demand for this.

If yes, go and build it properly.

[daemin]

Sadly I don't think management would go and build it properly, this sort of thing happens frequently where the prototype is put directly into production because why waste time redoing something that already exists and works. Just got to clean it up a bit, round off some sharp corners, and put it into production post-haste.

[methyl]

Perhaps the author of the code and architecture (Claude) should receive those questions.

[mattmanser]

So far, when Claude pops out a schema it's pretty spot on, iff you've described the problem correctly.

What the article's author seems to be hinting at is that the problem was described incorrectly from day one, and the LLM picked the wrong schema from day one. Because the person making it is not technically literate enough to describe the problem in a way an LLM interpreted correctly.

The hidden BA work a developer usually does was missing from the process.