undefined | Better HN

0 pointsjeremyjh3d ago0 comments

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.

0 comments

jappgar3d ago

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.

cushychicken3d ago

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.

tardedmeme3d ago

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.

jeremyjhOP3d ago

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.

j / k navigate · click thread line to collapse