> Textual command filtering is entirely useless. It is fit for no purpose. Nobody with any instinct or experience in security would even bother to implement this filter because it achieves nothing except a false sense of security.
Not if you only use an allow list. E.g. only allow things matching a particular prefix to run. Also, isn't this what every agent does? And by every I mean Codex because I haven't used the others.
> Even if your average developer is a measly 30% more efficient, that might create 20% less demand for developers
I mean it might. But I wouldn't rule out Jevon's paradox where the increased efficiency increases demand.
Build more roads, congestion gets worse. Make developers more efficient, demand for developers increases. I wouldn't be surprised if demand for bespoke software goes up.
And I would say in its case, there was great synergy between not doing anything and appearing uninvited. Two negatives combining to produce an overwhelmingly greater negative.
About six months ago I had an idea for a short story in which an LLM takes over the world and is decidedly bad. The solution was going to be for everybody to write positive stories in which the LLM is good and relinquishes control, which then made it's way into the LLM's training data and it backed off. I never got around to it.
AI Coding "All the things" (tm). More agent engineering on the bigger stuff and more vibe coding on the smaller things.
A print farm manager for bambu printers in lan mode. I lay down the base types and schema structure and a few other bits here and there.
Using AI to preprocess some amazon transactions from both personal account and business accounts as I untangle them since I started a side business with my spouse a few months ago (involving 3d printing).
Starting on a yoga workout generator and food/fitness/weight tracker.
> And yet, people are being more productive (actually productive) with AI. Release schedules are increasing, bugs are getting fixed faster, security issues identified and patched sooner, so on and so forth.
I didn't see anything in parent chain that implied this. Nor did I see it "characterized as a magic eraser"; I saw it framed as something that impedes learning, and that was tied back to constant simulation.
> Or at least, aware that this argument continues to be made with tenuous evidence and anecdotes
The arguments I read and the argument you seem to be replying to seem to be different things.
I read it more as response to your argument that it was a lack of curiosity due to over stimulation, which they responded to by citing an example of a time when they were curious while stimulated and chucked something at a vibe-coding agent to satisfy that curiosity.
> relatively little friction if you decide to move to a state that better reflects them.
Yes, moving is possible, and easier than switching countries. But the biggest strength of the U.S. is not that people can move, but that the blast radius is contained. The strength is being able to think later "I'm glad we didn't try that everywhere at once." The strength is being able to experiment, not necessarily have states aligned to with all there residents needs within a certain threshold.
It comes off very much as a summary of days of vibe-coding from the AI itself, but it's still nice to see the condensed decisions, approach and frankly the whole concept of embedding a wasm runtime.
I wouldn't call something a non-story just because the ultimate end-goal was mitigated. The fact that it was attempted is a story, especially when it's a meta commentary on story about trying the same thing _officially_.
To be honest, we should probably go into injection molding. We do have a pretty long tube in there that might be a bit problematic for injection molding from what I've read (1 degree draft means the tube size inside changes by 1/8 of an inch), and the orientation of the magnets is pretty important, and they can repel each other pretty hard to. So part of it is the unknowns.
The other part is the upfront cost. I bet we'll get to injection molding in the next few months as revenue allows, and we're going to start exploring it this month I think. We'd like to keep things local, though we know we'll still have to contend with knock offs sooner than later.
I'm writing a print farm manager for my wife, who has 8 bambu printers. I've put one of them in lan mode for testing, but I'm pretty close to replicating the important handy (Bambu's cloud app) features, at which point I'll be able to start adding the really nice.
She sells a product with 16 different printed parts, and she prints the parts in bulk batches across 7 different pause points, some of which have pause points for embedding magnets.
The idea is to integrate inventory management and print scheduling into the tool, which will be nice.
I have working so far:
* Pulling camera images
* Pulling the currently printing file, including the preview image (rendered in bambu studio and bundled with the print; standard for bambu studio), and the pause points
* A dashboard with projected timing information
* Notifications about jobs starting, stopping & pausing
* Remote printer control
Next on the list:
* Delayed printing - schedule a print to start in the night. Mostly useful so that if there's a pause point we don't leave a print paused for hours on end.
* Print queueing - manually build a list of prints so that after switching plates we can just "next print" for a printer
* Print scheduling - select a quantity of print files or groups of files to print, and have it schedule the prints, including projected switch times, to maximize printer utilization by avoiding jobs ending at night
* Tracking magnet & filament usage, and integrating BoM and production quantity tracking.
I've been mostly AI coding this, but I've go in to make it extract out components, etc. And I lay down and enforce the DB schema. I've had to ask it to back out a few things entirely. And I've had to give it the Bambu API docs I found github. But it's been going pretty well.
I worked at a dev company, and we got bought by an IT company. Much pain and friction, all around. Is that a reductive representative of the company differences? Yeah, but it's still a useful mental model that helps one understand the differences. And I think the lawyer vs engineer trope is useful. Yeah we have both. Both my companies had both IT and developera, but the stakes & priorities were different enough that that lense became extremely helpful.
A religious corollary: "You cannot legislate righteousness", or to your point, "you cannot legislate [willingness to forgo benefits on principle rather than economic and utilitarian calculation, despite recognizing the prisoners dilemma of doing so]"
I mean, it kind of is. But I'd say the framing is about general air pollution, and they happen to use NOx levels as proxy indicator. So from that perspective, I think it is important to note that there are other types of pollution that go up with electric cars.
No, in a perfect world, there would be a use tax, and those doing the delivery would pay the cost, and then pass that cost on to you. You might have meant it that way, but it sounded more like a gov. imposed tax based on the price of goods or something.
Hate is powerful, and I think that's part of what drives protests into riot. And some people to protests honestly. But I think the root of it is anger at the situation, not just the leader. And it doesn't negate the reasonableness of the concerns and worries people have.
I know one of the lead protest organizers where I live. They have a long list of things. Things they feel are bad and want reversed. And having known them for a long time, I can say they are internally consistent, and would be out there protesting if it was a Democratic president doing this, or more likeable person doing this. It's less about the hate, and more about concern for the direction things are going, and blatant disregard for the law.