But it does have a verifiable output, no more or less than HTML+CSS. Not sure what you mean by "input" -- it's not a function that takes in parameters if that's what you're getting at, but not every app does.
Yeesh.. I've definitely tried using break-after and being disappointed it didn't work properly. The amount of hoops I had to jump through to get things to print properly on paper...
Agreed. This has come up multiple times during my job. It's gotten to the point where we had a microservice running that spun up selenium and printed the dom and then sent that pdf back to the front-end all just to make consistent print outputs. I've read tech blogs of others doing just that too so it's not uncommon.
Unfortunately the test set of wpt does not have the capability to cover printed matter so relief isn't coming any time soon
> While it is cautious in accessing sensitive files, there’s no enforcement.
I don't understand why this isn't a day 0 feature. Like... what? I was hacking together my own CLI coding agent and... like just don't give it shell access for starters. It needs like 4 tools: read file, list files, patch file, search. Just write those yourself. Don't hand it off to bash. Want to read a sensitive file? Access denied. Want to list files but some of them might be secret env files? Don't even list them so the LLM doesn't even know they exist. Want to search the whole codebase? Fine, but automatically skip over sensitive files.
Why is this hard? I don't get it.
Is it the definition of "sensitive file"? Just let the user choose. Maybe provide a default list of globs to ignore but let the SWEs extend it with their own denylist.
The problem is that coding agents with Bash are massively more useful than coding agents without Bash, because they can execute the code they are writing to see if it works.
But the moment you let an agent run arbitrary code to test it out that agent can write code to do anything it likes, including reading files.
> you will need to maintain mappings of price ids to your plans
I think you're overvaluing how much work this is. For years I just created the plans in Stripe and then manually copied them over into my database. If you're small and not changing your plans often, this is fine.
When eventually I got annoyed because I had a Stripe sandbox and my own staging environments I wanted to sync periodically, I banged out a 'sync' script in a couple hours. Could probably do it even less time with AIs these days.
> your plans to what features you grant for each
I don't understand how your service can even help with this. "Features" are necessarily part of my app, I have to define what the user is purchasing.
> stripe customer ids to your customer ids
It's one extra column.
Maybe you can call it 'grunt work' but how often are ya'all putting up new SaaS's?
Even if you can somehow keep your latency to a minimum, if you have even a second of down time, my app goes down with yours. I don't like that. Right now if Stripe goes down for a bit, nothing happens to my app. It keeps chugging along. Maybe some of my customers can't pay their monthly subscriptions for a bit but they're not locked out of the app.
This whole thing feels like a trap TBH. Feels like vendor lock-in. I am kind of locked into Stripe because it'd be a PITA to re-integrate with something else, but at least I own the data (sans credit card #s, which I don't want) and can move elsewhere if push comes to shove (well... OK, asking everyone to re-enter their card # would suck too).
The "storing my source of truth externally" is super fair, and something we plan to address soon by giving you the ability to store this data on your side. So you'll still get all the benefits of our data model and full stack SDK, but aren't locked in to our hosting.
> I don't understand how your service can even help with this. "Features" are necessarily part of my app, I have to define what the user is purchasing.
We let you define features that you reference using slugs that you decide, and then group those features with products. So when someone subscribes to the product, they get the features you defined and associated with that product. So to see whether they can access a feature (boolean):
The problem we're trying to address is a bit broader than just storing price ids. You use your customers' payments state to derive billing state, and you use billing state to derive app behavior (what features they can access, what usage meters what balances and whether those are sufficient to continue consumption). You need this data on your backend and your frontend. So a substantial amount of most CRUD app code is just managing, transposing, and shuttling this kinda of data around between backend and frontend.
For fun I once mapped out a vanilla SaaS checkout flow and realized that it required a developer to coordinate 15 server-client boundary hops [0]. Each one is a liability that you have to maintain. And the flow as a whole is one of the most frustrating to test. If a developer came up with this flow on their own, we'd immediately say it smells. But it's the flow required by the current best-in-class vendors.
And it's not entirely the result of complexity intrinsic to the domain. Much of it is the result of decisions made over a decade ago that haven't really been revisited. At least in React-land, we've learned a lot in that time about how gracefully different patterns for state management age in a codebase. The last time the webhook-only pattern was the frontier of DX, Redux was the considered the best state management framework for React.
I haven't seen Redux in React code in a very long time, maybe 6 years. Not because Redux is terrible - in fact it represented the community's best understanding of state management at the time. But over time we realized the limitations of Redux as a framework, and engineered our way out of them with new frameworks. This process is natural and beautiful and part of what makes technology magical. In payments, this improvement loop is significantly rate limited. Because to build a truly better solution you have to commit to all of the uphill compliance and financial services work that people have very astutely pointed out in other comments.
I don't know if big companies even know how to make web apps. Honestly. Which is extra insane to me because there's so much investment in web technologies. On my team at $BigTech there's like 1 or 2 people out of 30 people on our team that knows web, the rest are mobile. I'm a web guy but I refuse to touch our web-app because they butchered the tech stack and I don't have the energy to deal with that BS. We still have an mobile-web version distinct from the 'desktop' version because.... I don't know why, whoever wrote it never learned about responsive web design and we never bothered to move out of the stone ages because if people want to use the app on their phone, they should download the native app of course! And by "native" I mean we built our own half-baked framework so that we could cross-compile for Android and iOS.
Also I don't think these people know how capable PWAs are. There's very little you can't do in a web-app that you can do with a native app.
What's more -- how long can they keep the lid on AGI? If anyone actually cracks it... surely competitors are only a couple months behind. At least that seems to be the case with every new model thus far.
Aren't you contradicting yourself? To even be considering all the various models, the switching cost can't be that large.
I think the issue here isn't really that it's "hard to switch" it's that it's easier yet to wait 1 more week to see what your current provider is cooking up.
But if any of them start lagging for a few months I'm sure a lot of folks will jump ship.
reply