Comment by progmetaldev | Hacker News Reader

Comment by progmetaldev | Hacker News Reader

Parent Full thread

I worked with a physician's office in 2006, and the lead physician had cobbled together a system for patient tracking using Visual FoxPro. It was a monstrosity, and using it over a network drive gave all sorts of file locks and issues with multiple people changing the same record (usually the physician and front of house staff when checking the patient out).

I finally got the physician to switch to a proper client/server architecture using .NET WinForms and ASP.NET RPC calls. All issues went away, and I was even able to allow staff members to edit the interface to set what mattered to them most at the top of the application, by building the lab testing form in XML so they could move the X/Y coordinates to where they wanted them. It wasn't even a feature I had thought of, just a physician looking through the technology and figuring out how it worked (luckily the business and security logic were on the server, so a bad actor could only have destroyed their own local copy of the app).

When networked PCs and rapid application development platforms became popular there was a "Cambrian explosion" of custom electronic health record and practice management applications built by doctor hackers who knew exactly what they wanted, and had just barely enough technical skill to sort of make it partially work. Those have gradually died off because commercial products kept improving, and the cost of complying with security and interoperability requirements kept escalating. But I predict that the cycle will now repeat because the combination of AI coding tools plus headless EHR platforms (built in security, storage, and APIs) has made it easier to build a custom EHR that actually works.

Yes, I am seeing exactly this at my own workplace. Two things have happened close together: low code and LLMs. I don't personally like using low code solutions (such as PowerBI and Power Automate), but for many knowledge workers this is all they have. Now you can just ask your favorite LLM how to do stuff and it can help you. It's not exactly vibe coding because these people really understand what they have and what they want, they just don't know the syntax to get there.

Low code solution have a fairly steep learning curve, and when someone got into it in anger, the complex electrical diagrams that result are even more impenetrable than spaghetti code.

In a large enterprise environment I have seen business users getting burned by vibe coding already, as they often don't even read the comments and warnings that the LLM gives them. But I think it is inevitable and should enable software to automate the millions of manual processes that are too bespoke to pay an IT team to automate.

For a solo entrepreneur, it should enable to get so much done before having to hire the first employee. Hence less risk to go bust, easier to take risks, pure value added.

DBase/Fox Pro were born when local networks weren't common, it excelled as a single-user batteries-included IDE. Now that you mention this, I understand why it couldn't work these days as it is.

I also think it won't be that hard to make it multiuser, that's a long-ago solved problem these days.

It wasn’t that hard to make it multiuser back on the day, either. But as OP discovered, FoxPro also made it very easy to write shit multiuser code. Pessimistic/optimistic locking, etc.? It was in there, but you had to use it.

One fear I saw manifest in a job was before AI, and an associate was doing a screen for a request in dot net and it let the user read the record, edit the record and write the record. Last person to write the record won of course.

At this tier of small time company IT, I am hoping that AI will actually improve the quality of code, because people who write racey nolock code that occasionally "drops a few records" are probably hopefully not posting their code to forums or alternatively getting roasted to pieces if they do so its my hope they are only represented in training data as "what not to do."

Just antidotal but I don't know how many times I've had to help developers fix their vibe coded code to account for concurrency problems. LLMs don't seem to be very good at picking up on this today unless you call it out.

Wow, I’ve had the opposite experience. I’ve needed to talk Claude down from Redis clusters for hobby projects to avoid concurrency edge cases.

Although to your point, it struggles to do anything with SQLite beyond a single user even when its architecturally not a problem

Reply on news.ycombinator.com