> The current closed source frontier models are more capable than the latest from DeepSeek. But is the capability difference enough to justify a 30x price difference?
We talk about capability like it's some kind of linear scale. I am not paying 30x for 30x performance. I am paying 30x so that my use case goes from "haha nope" to a signed contract with the client. Works 0% of the time => works 3% of the time is an infinite improvement in capability. That is what the premium is paying for.
> You can save a lot of money in maintenance and repairs by doing your own work whenever possible. I replaced the drain pump in my dishwasher, replaced a leaking kitchen faucet, replaced the control board on my HVAC system, do all my own yard work, etc.
This is where the margins of home ownership open up. Doing your own yard work also has added benefit of giving you routine awareness of potential issues around your property before things become much more expensive. Irrigation and drainage issues are usually obvious when you are standing right on top of them. I would argue that if you aren't willing to push a mower around your property, you might not want to own that property.
Also, DIY yard work also forces you to maintain various tools and skills that are extremely useful for adjacent applications. For example, lawnmowers and standby generators tend to have similar principles of operation. The tool and knowledge I use to gap the spark plugs for my mower works just as well for the generac.
It's also really nice to just do some work outside instead of staring at a screen . I really enjoy mowing my huge lawn, doing some light landscaping stuff. My wife and daughter pick weeds for hours and it really centers them.
The last two projects I built I did the CI/CD manually with a small win32 service that polls git and builds+deploys the main service locally. It's barely 200 lines of code. Not much to go wrong. "dotnet publish" is not difficult to wrap.
The latest language models have enabled this sort of thing for me. I can integrate a mini Jenkins into every project within a 5-10 minute prompting session. This sort of code isn't hard. It's just tedious, and the LLMs absolutely rock at boring repetitive stuff. Having a win32 service start up successfully on the very first try is something I haven't experienced until 2026.
That works for relatively simple scenarios. When you have to add deploying sql changes or something having to update something in the cloud, you'd have to include a lot more plumbing.
In my world CI/CD and db migrations are 2 different things working together. CI/CD at heart is rather simple for many setups. Migrations need quite a lot scrutiny, you really want to mess up there. But if you run on gihub actions with 50/50 uptime, does it matter?
Deploying SQL changes is actually trivial if you are using SQLite.
I agree in a hosted+shared SQL scenario you have to be a little bit more careful with all of this. Arguably, you should have a separate schema management phase in these cases.
But if you are just SQLite embedded in the service, you can use the user_version pragma to track schema version and perform deterministic migrations (assuming a user didn't manually jack with the file in-between).
We try to keep things simple. Everything has risks. No stall, run async, backward compatible. DB handles rollback via transactions. Happy to expand if interested.
This one is a bit more ridiculous than the others.
You can get something like a Tascam DR-07XP for $150 and it does 32bit float format with essentially unlimited dynamic range. I will never need to buy another field mic.
I think using speed to describe the rate of progress in software development is where the frustration comes from. Software isn't a velocity thing. It's a space thing. It's memory. Information in some media. You can transfer a billion bits in less than a second. The time domain is largely irrelevant in business terms.
Having taste and the ability to author high quality prompts is still the most important thing. It was always the most important thing if you think abstractly about how all of this works.
PCI-DSS still takes the cake for most oppressive rules out of all the compliance frameworks. The notion that your system might become "in-scope" is one of the scariest things you have to deal with. Avoiding this designation is almost always easier than satisfying all the controls they prescribe. Stripe & friends have it really good. I don't know who their equivalents are in the health care industry but I am certain they exist.
> PCI-DSS still takes the cake for most oppressive rules out of all the compliance frameworks.
My personally most hated compliance ruleset. I've been in Healthcare for over a decade, I'm a HIPAA/data security expert, and PCI compliance is genuinely harder and more nonsensical than HIPAA.
And to be honest, for every ONE healthcare place I've seen that would fail a HIPAA audit, I've seen 20 companies that would fail PCI compliance and by a wider margin. The number one PCI issue I've seen *literally* everywhere is recording/writing down card numbers with CVV. It's strictly forbidden by the rules, and every snall and medium business breaks that rule constantly.
What kind of business writes down credit card numbers (even without CVV)?
Online payments (e.g. e-commerce) usually send such data directly to the PSP, or encrypt it with a PSP controlled key.
And in person payments (e.g. stores and restaurants) use a payment terminal/device, which is presumably PCI DSS compliant and doesn't store such information.
I despise PCI-DSS. A friend owns a small business and has a credit card reader. Due to that, we had to build out a separate LAN so that the reader is on its own precious network, and have to pay an external auditor for a quarterly scan of our external IP. Bullshit past findings were things like “your VPN server supports old encryption algorithms”. “But our clients don’t support them. They select the newer algorithms!” “But they could!” “What do you care? Those clients aren’t even on the same LAN as the scanner.” “PCI-DSS lol!” I have no way of knowing, but I bet the firewall might’ve accidentally blocked the scanning IP from reaching the VPN server port on the retest and called it a day, but surely not.
Basically, Visa and friends externalized their own shitty security and made every other company in the land responsible for wrapping their janky hardware in electronic bubble wrap. A real security framework would’ve said “don’t make a credit card scanner so weak that it can’t survive being on the same LAN as a printer”. Instead, the whole country has to waste billions of dollars mitigating that risk for them.
> Bullshit past findings were things like “your VPN server supports old encryption algorithms”. “But our clients don’t support them. They select the newer algorithms!”
Given that downgrade attacks are a massive category of attacks for network protocols, and in fact modern protocols go to great lengths to make them impossible, that doesn’t sound very bullshit at all.
The whole VPN requirement sounds like bullshit to me. The terminal should use secure TLS connections to the servers it communicates with, without relying on the security of the (local) network at all.
Last I checked, a VPN isn’t required by PCI (or really any other compliance regime). The parent commenter’s infrastructure had a VPN. And once you have a VPN and you’re showing it to the auditors as part of your in-scope infra for PCI, asking you to remediate findings for insecure algorithms allowed in the server config is rational.
Eh, not really. The VPN was on the same router that gave the card scanner access to phone home to the credit card company. They weren’t related at all. You couldn’t connect to the scanner’s LAN through the VPN. But since they had the same public IP, the vuln scanner counted them as in scope.
But in reality, why’s that a problem? Is the credit card scanner so tacitly busted that it can’t coexist with other hosts? Does it not use TLS? Doesn’t it pin TLS certs so that it’s not subject to MITM? Is it listening on ports with vulnerable services? There’s no excuse for the scanner being that delicate. It should be able to service an office LAN. And yet, the PCI-DSS group managed to push the responsibility for their hardware onto the network owners rather than making their own hardware robust. That’s nuts.
If a client doesn’t support an algorithm, you can’t force a downgrade to it. A compensating control is that the clients are managed and only support the newest algorithms, and aren’t vulnerable to a downgrade attack.
Context is everything. Here, the context is that within this scan environment, it was, in fact, a bullshit finding.
I've implemented PCI-DSS and have 12 years of level 1 audits behind me. I actually find their rules to be sane, pretty good security practice. Internally, we made many of the controls standard across the board even for out-of-scope systems because they were sensible and we'd already built the tooling for it. If you implement it well, once you're compliant it is easy to stay compliant.
And yes, there is plenty of incentive to keep things out of PCI scope. I'd say that is PCI working as intended. Why would you want a larger attack surface that touches your credit card data?
We recently did PCI-DSS level2 and it was pain in the right place to complete the scans and gaps their scripts find. It took 6 months to complete the audit.
That's on the other side of the river from New Orleans.
To what I think is your larger point, that project is a small part of the efforts at water control around New Orleans. But, so far they have generally been viewed as beneficial and the various governmental entities keep paying for them -- why should we expect anything different in the future ? Roads get repaved all over the country, bridges rebuilt, and the levees rebuilt. There's always an "infrastructure crisis" of the decade, the chatter is how we as a society judge the expense and confirm it's necessary.
I'm not having much trouble with very large (>50mb raw source) and complex codebases. The fact that it's all strongly typed probably helps a lot, but I don't think that's the whole story.
I think the harness and code patching technique starts to matter a lot more once you get outside the trivial range of codebases that fit within the first ~20% of the context window and can otherwise be iterated completely in a single inference pass.
The apply_patch technique that OAI has polished their models on seems to be the best approach for monster scale codebases. Anything based on line ranges and simple find-replace will disintegrate at the edges. You need multiple spatial anchors to deal with nasty things like cshtml files. The prepare/commit behavior is ideal for iterating through ambiguous contexts across many large files and refining anchors.
> Rockstar and Take-Two have not yet confirmed the price of GTA 6, but some expect the game to be priced above the $70 standard for current-gen consoles. Last month, Zelnick addressed the concerns around the game's price and said that consumers would pay for the value offered.
The difference, and the reason these comparisons are always disingenuous, is that Rockstar didn’t have the consumers fund its development and miss its promises repeatedly.
The studio is funding it and has been clear they’ll release it when they feel like it.
We talk about capability like it's some kind of linear scale. I am not paying 30x for 30x performance. I am paying 30x so that my use case goes from "haha nope" to a signed contract with the client. Works 0% of the time => works 3% of the time is an infinite improvement in capability. That is what the premium is paying for.
reply