Instance: programming.dev
Joined: 6 months ago
Posts: 210
Comments: 41
London based software development consultant
Posts and Comments by codeinabox, codeinabox@programming.dev
Comments by codeinabox, codeinabox@programming.dev
Could you give more context about what Vercel features you need - is the site statically generated, or do you also need Vercel Functions?
There are several European based alternatives to Vercel. It’s also worth having a read through or posting to !web_hosting@programming.dev
Though that quote is followed by this, which indicates at least five of those vulnerabilities were real:
I searched the Linux kernel and found a total of five Linux vulnerabilities so far that Nicholas either fixed directly or reported to the Linux kernel maintainers, some as recently as last week:
Your comment reminded me of this article, The Software Quality and Productivity Crisis Executives Won’t Address, which discusses the lack of technical leadership when it comes to tackling technical debt, and that the solution is usually a rewrite.
Instead, most organisations don’t tackle technical debt until it causes an operational meltdown. At that point, they end up allocating 30–40% of their budget to massive emergency transformation programmes—double the recommended preventive investment (Oliver Wyman, 2024).
I have noticed the repository lacks CONTRIBUTING.md. If you want to set some rules about contributing, I would have added them there, instead of creating a Markdown file specific for agents. I’m very much of the philosophy that you should write documentation for humans, which has the added bonus that it will also be consumed by agents.
I agree but it depends on how teams create and refine their tickets. For example, you could have high level tickets, and someone picks one up and creates an implementation that’s not an appropriate fit for your architecture.
Thank you for not assuming my motivations. Could you please elaborate on what you mean by “oneshotted”? I share a lot of articles, so I’m not surprised you recognise my username.
I don’t specifically seek them out. I follow quite a few different programming blogs, and I am just sharing what people are posting about, and it just so happens a lot of people are posting about this topic.
Headless does not mean “no screen anywhere.” It means you are not required to use the company’s app or site to finish the job.
You might say: “Book a flight and a hotel in Tokyo.” A helper (with hooks into services, e.g. MCP or other agent APIs) talks to airlines and hotels for you. You might never see their homepage or their “join our club” popup.
Whilst I can see where the author is going with this, I can’t see some tasks, particularly booking concert tickets, being done by AI agents. Whilst it may be convenient for end users, it’s also open to exploitation by scalpers.
If you’re going to make that claim, could you please provide some evidence.
I think you’re misconstruing the author’s argument, at no point does the author imply that Claude knows best, or that Electron apps are better. Their closing argument is certainly not an endorsement for Electron or AI slop.
Don’t get me wrong: writing this brings me no joy. I don’t think web is a solution either. I just remember good times when native did a better-than-average job, and we were all better for using it, and it saddens me that these times have passed.
I just don’t think that kidding ourselves that the only problem with software is Electron and it all will be butterflies and unicorns once we rewrite Slack in SwiftUI is not productive. The real problem is a lack of care. And the slop; you can build it with any stack.
Imagine being such a slop-brainwashed fanboi
Do you have any evidence for this? Looking through the post, and the author’s other blog post titles, there is very little mention of AI or Claude.
Instead of throwing labels at the author, it’s much more worthwhile to discuss their key argument about the challenges of developing native apps.
I wonder if we’ll end up in a situation of open source projects with closed source tests. Though I don’t know how that would work, because how would you contribute a new feature if the tests are closed? 🤔
Check against Can I Use, all of the APIs, except for the following are supported by major browsers:
- Synchronous Clipboard API only Safari has full support, the rest have partial
- Temporal only currently supported in Chrome and Firefox
The fact that people even bring javascript as the backend is a bit crazy to me.
To clarify do you mean replacing JavaScript just on the backend? This article is about using JavaScript on the front end.
I’m intrigued, what would you replace it with?
There are some really good tips on delivery and best practice, in summary:
Speed comes from making the safe thing easy, not from being brave about doing dangerous things.
Fast teams have:
- Feature flags so they can turn things off instantly
- Monitoring that actually tells them when something’s wrong
- Rollback procedures they’ve practiced
- Small changes that are easy to understand when they break
Slow teams are stuck because every deploy feels risky. And it is risky, because they don’t have the safety nets.
I think there’s many solutions to this, including setting a minimum account age to accept pull requests from, or using Vouch.
Guys, can we add a rule that all posts that deal with using LLM bots to code must be marked? I am sick of this topic.
How would you like them to be marked? AFAIK Lemmy doesn’t support post tags

Open source was never about trust (opensourcesecurity.io)
fakecloud - Free, Open-Source LocalStack Alternative for AWS Testing (fakecloud.dev)
fakecloud is a free, open-source local AWS emulator for integration testing and local development. It runs on a single port (4566), requires no account or auth token, and aims to faithfully replicate AWS behavior.
Could you give more context about what Vercel features you need - is the site statically generated, or do you also need Vercel Functions?
The DX shift no one noticed: Web interoperability (blog.logrocket.com)
These days, developer experience (DX) is often the strongest case for using JavaScript frameworks. The idea is simple: frameworks improve DX with abstractions and tooling that cut boilerplate and help developers move faster. The tradeoff is bloat, larger bundles, slower load times, and a hit to user experience (UX).
There are several European based alternatives to Vercel. It’s also worth having a read through or posting to !web_hosting@programming.dev
On Vinyl Cache and Varnish Cache (vinyl-cache.org)
Comments
February 2026 Baseline monthly digest (web.dev)
Package Security Problems for AI Agents (nesbitt.io)
Under the hood of MDN's new frontend (developer.mozilla.org)
Assessing Claude Mythos Preview’s cybersecurity capabilities (red.anthropic.com)
During our testing, we found that Mythos Preview is capable of identifying and then exploiting zero-day vulnerabilities in every major operating system and every major web browser when directed by a user to do so. The vulnerabilities it finds are often subtle or difficult to detect. Many of them are ten or twenty years old, with the oldest we have found so far being a now-patched 27-year-old bug in OpenBSD—an operating system known primarily for its security.
Burnout Is Real for Open Source Maintainers: A Conversation with John-David Dalton, Creator of Lodash (openjsf.org)
Minimum Release Age is an Underrated Supply Chain Defense (daniakash.com)
Screen readers are not testing tools (yatil.net)
If you thought the speed of writing code was your problem - you have bigger problems (debuggingleadership.com)
Comments
OpenClaw gives users yet another reason to be freaked out about security (arstechnica.com)
Stop Committing Your Secrets (You Know Who You Are) (jfmaes.me)
Plaintext .env files are a stupid little footgun. Here’s the SOPS + age + direnv setup I use to keep secrets encrypted, auto-loaded, and out of Git.
METR’s developer productivity research: 2026 update (blog.robbowley.net)
What does Open Source mean? (nesbitt.io)
Don’t let A.I. read your .env files (filiphric.com)
AI coding assistants like Claude Code, Cursor, and GitHub Copilot are becoming part of our daily workflow. They read our files, understand our codebase, and help us write code faster. But there’s a problem - they can also read your .env files.
Though that quote is followed by this, which indicates at least five of those vulnerabilities were real: