You or a business with legal owners can have a bank account, and you can give access to that account to an agent, but real banks work in the real world, and "know your customer" regulations need a real person somewhere in the chain.
I wish I could properly cite it, but one of my favorite HN comments recently was, to paraphrase, "thing, but from the Internet". Which is to say that old rules don't apply, for some reason.
Things are going to get weird when the automatons become sophisticated enough to pull off identity theft while unsupervised.
Putting a brick on the gas pedal is obviously negligent. Whereas it is not so obvious that running a random script from github that spins up an agent with access to your home folder could lead to real world financial crimes.
> Whereas it is not so obvious that running a random script from github that spins up an agent with access to your home folder could lead to real world financial crimes.
disagree, and the courts will likely take this position as well. ignorance has never been a defensible strategy to avoid liability.
pick up a detonator, it's up to you to understand where the bombs are positions what's in the blast range.
Again, I never used the term "liable". You introduced that. I spoke of criminal negligence.
And I don't believe your claim of liability generalizes. If someone else set up the detonator and then I pushed the button without realizing what it was I don't believe I'd be liable.
The party that set it up might be, but it gets really complicated and messy because it depends on the specific circumstances of all involved parties.
If A sets it up in a manner believed to be safe, B moves something in good faith which unintentionally makes things unsafe, and then C comes along and triggers it without realizing, you might well end up with a situation where no one is considered liable.
That might be true, but it doesn't have to be immediately true. It's an arbitrage problem: seeing a gap, knowing you can apply this new tool to make a new entrant, making an offering at a price that works for you, and hoping others haven't found a cheaper way or won the market first. In other words, that's all business as usual. How does Glad sell plastic bags when there are thousands of other companies producing plastic bags, often for far, far less? Branding, contracts, quality, pricing -- just through running a business. No guarantee it's gonna work.
Vibe-coding something isn't a guarantee the thing is shit. It can be fine. It still takes time and effort, too, but because it can take lot less time to get a "working product", maybe some unique insight the parent commenter had on a problem is what was suddenly worth their time.
Will everyone else who has that insight and the vibe coding skills go right for that problem and compete? Maybe, but, also maybe not. If it's a money-maker, they likely will eventually, but that's just business. Maybe you get out of the business after a year, but for a little while it made you some money.
> That might be true, but it doesn't have to be immediately true. It's an arbitrage problem: seeing a gap, knowing you can apply this new tool to make a new entrant, making an offering at a price that works for you, and hoping others haven't found a cheaper way or won the market first. In other words, that's all business as usual.
I'm hearing what you are saying, but the "business as usual" way almost always requires some money or some time (which is the same thing). The ones that don't (performance arts, for example) average a below-minimum-wage pay!
IOW, when the cost of production is almost zero, the market adjusts very quickly to reflect that. What happens then is that a few lottery ticket winners make bank, and everyone else does it for free (or close to it).
You're essentially hoping to be one of those lottery ticket winners.
> How does Glad sell plastic bags when there are thousands of other companies producing plastic bags, often for far, far less?
The cost of production of plastic bags is not near zero, and the requirements for producing plastic bags (i.e. cloning the existing products) include substantial capital.
You're playing in a different market, where the cost of cloning your product is zero.
There's quite a large difference between operating in a market where there is a barrier (capital, time and skill) and operating in a market where there are no capital, time or skill barriers.
The market you are in is not the same as the ones you are comparing your product to. The better comparison is artists, where even though there is a skill and time barrier, the clear majority of the producers do it as a hobby, because it doesn't pay enough for them to do it as a job.
All fair points, I think I agree with your take overall but we might each be focusing on situations involving different levels of capital, time, and skill: I'm imagining situations where AI use brought the barrier down substantially for some entrants, but the barriers still meaningfully exist, while it sounds to me like you're considering the essentially zero barrier case.
My Glad example was off the cuff but it still feels apt to me for the case I mean: the barrier for an existing plastic product producer who doesn't already to also produce bags is likely very low, but it's still non zero, while the barrier for a random person is quite high. I feel vibe coding made individual projects much cheaper (sometimes zero) for decent programmers, but it hasn't made my mom start producing programming projects -- the barrier still seems quite high for non technical people.
I dunno about the Glad bag analogy, and now I'm not sure that the artist analogy applies either.
I think a better analogy (i.e. one that we both agree one) is Excel preadsheets.
There are very few "Excel consultants" available that companies hire. You can't make money be providing solutions in Excel because anyone who needs something that can be done in Excel can just do it themselves.
It's like if your mum needed to sum income and expenditures for a little side-business: she won't be hiring an excel consultant to do write the formulas into the 4 - 6 cells that contain calculations, she'll simply do it herself.
I think vibe coding is going to be the same way in a few years (much faster than spreadsheets took off, btw, which occurred over a period of a decade) - someone who needs a little project management applications isn't going to buy one, they can get one in an hour "for free"[1].
Just about anything you can vibe-code, an office worker with minimal training (the average person in 2026, for example) can vibe-code. The skill barrier to vibe-coding little apps like this is less than the skill barrier for creating Excel workbooks, and yet almost every office worker does it.
[1] In much the same way that someone considers creating a new spreadsheet to be free when they already have Excel installed, people are going to regard the output of LLMs "free" because they are already paying the monthly fee for it.
I experienced the exact same thing: I needed a web tool, and as far as I could tell from recent reviews, the offerings in the chrome extension store seemed either a little suspicious or broken, so I made my own extension in a little under an hour.
It used recent APIs and patterns that I didn't have to go read extensive docs for or do deep learning on. It has an acceptable test suite. The code was easy to read, and reasonable, and I know no one will ever flip it into ad-serving malware by surprise.
A big thing is just that the idea of creating a non-trivial tool is suddenly a valid answer to the question. Previously, I know would have had to spend a bunch of time reading docs, finding examples, etc., let alone the inevitable farting around with a minor side-quest because something wasn't working, or rethinking+reworking some design decision that on the whole wasn't that important. Instead, something popped into existence, mostly worked, and I could review and tweak it.
It's a little bit like jumping from a problem of "solve a polynomial" to one of "verify a solution for a polynomial".
Yeah, getting into the car with the guy holding the gun doesn't become okay because you have a great argument you're waiting to use down the road. He's already got the gun out.
We should have started arguing when he just said he had a gun, indoors, in the crowd. We shouldn't have quietly walked outside at his demand. But that all happened. Here we are now, at the car, and he's got the gun out, and he's saying "get in", and we're probably not going to win from here -- but pal, it's time to start arguing. Or better yet, fighting back hard.
Because that car isn't going anywhere we want to be. We absolutely can not get in the car right now, and just plan to argue the point later. It doesn't matter how right the argument is at all.
> So, no. There is no development configuration in production, or mirroring of a point of sales terminal to another system that's running development code.
This is a misreading of the suggestion, I think. My reading of the suggestion is to run a production "dry run" parallel code path, which you can reconcile with the existing system's work for a period of time, before you cut over.
This is not an issue precluded by PCI; it is exactly the method a team I led used to verify a rewrite of and migration to a "new system" handling over a billion dollars of recurring billing transactions annually: write the new thing with all your normal testing etc, then deploy it alongside in a "just tell us what you would do" mode, then verify its operation for specific case classes and then roll progressively over to using it for real.
edit: I don't mean to suggest this is a trivial thing to do, especially in the context you mentioned with many elements of hardware and likely odd deployment of updates, etc.
Our reading of PCI DSS was that there was no development code in a production build. Having a --dry-run flag would have meant doing that.
You could do "here is the list of skus for transaction 12120112340112345 - run this through the system and see what you get" on our dev boxes hooked up to QA store 2 (and an old device in the lab hooked up to QA store 1). That's not a problem.
Sending the scanner reads to the current production and a dev box in production would have been a hardware challenge. Not completely insurmountable but very difficult.
Sending the keyboard entry to both devices would be a problem. The screens were different and you can hand enter credit card numbers. So keyboard entry is potentially PCI data.
The backend store server would also have been difficult. There were updates to the store server (QA store 1 vs QA store 2 running simultaneously) that were needed too.
This wasn't something that we could progressively roll out to a store. When a store was to get the new terminals, they got a new hardware box, ingenicos were swapped with epson, old epson were replaced with new (same device but the screens had to be changed to match a different workflow - they were reprogrammable, but that was something that stores didn't have the setup to do), and a new build was pushed to the store server. You couldn't run register 1 with the old device and register 2 with a new one.
Fetching a list of SKUs, printing up a page of barcodes and running it was something we could do (and did) in the office. Trying to run a new POS system in a non-production mode next to production and mirroring it (with reconciling end of day runs) wasn't feasible for hardware, software, and PCI reasons that were exacerbated by the hardware and software issues.
Online this is potentially easier to do with sending a shopping cart to two different price calculators and logging if the new one matches the old one. With a POS terminal, this would be more akin to hooking the same keyboard and mouse up to a windows machine and a linux machine. The Windows machine is running MS Word and the linux is running Open office and checking to see that after five minutes of use of the windows machine that the Linux machine had the same text entered into OpenOffice. Of course they aren't - the keyboard entry commands are different, the windows are different sizes, the menus have things in different places in different drop downs... similarly, trying to do this with the two POS systems would be a challenge. And to top it off sometimes the digits typed are hand keyed credit card numbers when the MSR couldn't get a read - and make sure those don't show up on the linux machine.
I do realize this is reminiscent of business giving a poorly spec'ed thing and each time someone says "what about..." they come up with another reason it wouldn't work. This was a system that I worked on for a long while (a decade and a half ago) and could spend hours drawing and explaining diagrams of system architecture and issues that we had. Anecdotes of how something worked in a 4M Sloc system are inherently incomplete.
Neat! Yeah, that's a pretty complex context and I completely see what you mean about the new hardware being part of the rollout and necessarily meaning that you can't just run both systems. My comment is more of a strategy for just a backend or online processing system change than a physical brick and mortar swap out.
In my note about misreading the suggestion, I was thinking generally. I do believe that there is no reason from a PCI perspective why a given production system cannot process a transaction live and also in a dry mode on a new code path that's being verified, but if the difference isn't just code paths on a device, and instead involves hardware and process changes, your point about needing to deploy a dev box and that being a PCI issue totally makes sense, plus the bit about it being a bad test anyway because of the differences in actions taken or outputs.
The example you gave originally, of shipping to the lower stake exceptional stores first and then working out issues with them before you tried to scale out to everywhere, sounded to me like a very solid approach to mitigating risk while shipping early.
The original register was a custom written C program running in DOS. It was getting harder and harder to find C programmers. The consultancy that had part of the maintenance contract with it was also having that difficulty and between raising the rates and deprioritizing the work items because their senior people (the ones who still knew how to sling C and fit it into computers with 4 MB of memory that you couldn't get replacement parts for anymore) were on other (higher paying) contracts.
So the company I worked at made the decision to switch from that program to a new one. They bought and licensed the full source to a Java POS system (and I've seen the same interface at other big retail companies too) and replace all the hardware in all the stores... ballpark 5000 POS systems.
The professional services consultancy was originally brought in (I recall it being underway when I started at there in 2010). They missed deadlines and updates and I'm sure legal got in there with failure to deliver on contract. I think it was late 2011 that the company pulled the top devs from each team and set us to working on making this ready in all stores by October 2012 (side note: tossing two senior devs from four different teams into a new team results in some challenging personality situations). And that's when we (the devs) flipped the schedule around and instead of March 2013 for the cafeteria and surplus store (because they were the odd ones), we were going to get them in place in March of 2012 so that we could have low risk production environments while we worked out issues (so many race conditions and graphical event issues hanging with old school AWT).
---
... personality clash memory... it was on some point of architecture and code and our voices were getting louder. Bullpen work environment, (a bunch of unsaid backstory here) but the director was in the cube on the other side of the bullpen from us. The director "suggested" that we take our discussion to a meeting room... so we packed up a computer (we needed it to talk about code), all of the POS devices that we needed, put it on a cart, pushed the cart down the hall into a free conference room (there were two conference rooms on that floor - no, this wasn't a building designed for development teams) and set up and went back to loudly discussing. However, we didn't schedule or reserve the room... and the director that kicked us out of the bullpen had reserved the room that we had been kicked into shortly after we got there. "We're still discussing the topic, that will probably be another 5-10 minutes from now... and it will take us another 5 minutes pack the computer back up and take it back to the bullpen. Your cube with extra chairs in it should be available for your meeting and it's quiet there now without our discussions going on."
Dev: "Could we pull an export of relevant historical data and get some time to write code to safely anonymize that, and stand up a parallel production system using just the anonymized data and replicate our deploy there, so we can safely test on real-ish stuff at scale?"
Lead: "I'll think about it. In the meantime, please just build the features I asked you to. We gotta hustle on this one."
I'm not arguing with this hypothetical exchange that it's infeasible or even a bad idea to do exactly what you suggested, but attempting to justify an upfront engineering cost that isn't directly finishing the job is a difficult thing to win in most contexts.
It's very common to use identical systems but anonymised data shipped back to test environments in such cases. There are certain test card numbers that always fail or always succeed against otherwise-real infrastructure on the card provider's side.
Absolutely, I agree that it's a useful pattern. I've personally typed 4111 1111 1111 1111 into a stripe form more times than I want to even think about.
My point above was that it's not necessarily easy to convince the operators of a business that it's a justifiable engineering expense to set up a new "prodlike but with anonymized data" environment from scratch, because it's not a trivial thing to make and maintain.
I do think it's pretty easy to convince operators of a business to adopt the other strategy suggested in a sibling thread: run a dry mode parallel code path, verify its results, and cut over when you have confidence. This shouldn't really be an alternative to a test environment, but they can both achieve similar stuff.
> I do think it's pretty easy to convince operators of a business to adopt the other strategy suggested in a sibling thread: run a dry mode parallel code path, verify its results, and cut over when you have confidence. This shouldn't really be an alternative to a test environment, but they can both achieve similar stuff.
I agree - it's a nice low-risk way of doing things.
It is as low risk as trying to use Windows and Microsoft Word with a keyboard and mouse mirrored to a Linux machine running Open Office and expecting the same results.
You can't run the two systems side by side - different screens, different keyboard entry... and some of the keyboard entry can't touch the other system.
And this is assuming you can put a dry path into the production system. If the answer is "no", then you're putting a dev environment into a production environment... and that's certainly a "no".
We had test environments and we had a lab were we had two rows of systems where the two systems sat back to back and each row was hooked up to a different test store (not feasible in a production store environment).
There's some fair points here but this is much less than half the picture. What I gather from your message: "if it is built like a human and it says it is conscious we have to assume it is", and, ok. That's a pretty obvious one.
Was Helen Keller conscious? Did she only gain that when she was finally taught to communicate? Built like a human, but she couldn't say it, so...
Clearly she was. So there are entities built like us which may not be able to communicate their consciousness and we should, for ethical reasons, try to identify them.
But what about things not built like us?
Your superconductivity point seems to go in this direction, but you don't seem to acknowledge it: something might achieve a form of consciousness very similar to what we've got going on, but maybe it's built differently. If something tells us it's conscious but it's built differently, do we just trust that? Because some LLMs already may say they're conscious, so...
Pretty likely they aren't at present conscious. So we have an issue here.
Then we have to ask about things which operate differently and which also can't tell us. What about the cephalopods? What about cows and cats? How sure are we on any of these?
Then we have to grapple with the flight analogy: airplanes and birds both fly but they don't at all fly in the same way. Airplane flight is a way more powerful kind of flight in certain respects. But a bird might look at a plane and think "no flapping, no feathers, requires a long takeoff and landing: not real flying" -- so it's flying, but it's also entirely different, almost unrecognizable.
We might encounter or create something which is a kind of conscious we do not recognize today, because it might be very very different from how we think, but it may still be a fully legitimate, even a more powerful kind of sentience. Consider human civilization: is the mass organism in any sense "conscious"? Is it more, less, the same as, or unquantifiably different than an individual's consciousness?
So, when you say "there is nothing more to it, it's pretty much that basic and simple," respectfully, you have simply missed nearly the entire picture and all of the interesting parts.
You or a business with legal owners can have a bank account, and you can give access to that account to an agent, but real banks work in the real world, and "know your customer" regulations need a real person somewhere in the chain.
But, hey, maybe I'm wrong.
reply