I just can't get behind this perspective, perhaps because I am a 'bad prompter', simply due to the lack of capability from current models. I end up rejecting them, asking them to implement again, they spew out tons of crap code instead of a 10 line fix, and on, and on.
Note that I'm not saying the agents are useless. They certainly write a lot of code and sometimes it is good. But I don't think you can get away without touching code yourself simply because at some level it is often the most concise way to get your idea across. I find it best to implement a core set of changes by-hand, and then ask the system to e.g. replicate them to other dependencies. I genuinely don't understand how anyone can work on a system with any complexity, and get the results they actually want, without touching code.
People write applications that work with the S3 API but may want to host their own storage for a variety of reasons. Personally I make use of S3-compatible services for pre-signed url access to data on disks I own. The distributed aspect is only one reason why someone might want an S3-like service.
Yeah, having your agent write 3x the code in exhaustive tests (I tried this recently and got 600 lines of tests for my 100 lines of code!) sure makes things look great, but when you actually look at the content of the tests they’re meaningless. Good tests validate the use of design patterns, ensure that dependencies hold, and are meaningful (e.g. shortcut debugging by setting up useful state) when they break.
Maybe I'm entirely out of the loop and a complete idiot, but I am really not sure at all what people mean when they talk about this stuff. I use AI agents every day, but people who say they spend 'most of my time writing agents and tools' must be living in an absolutely different world.
I don't understand how people are making anything that has any level of usefulness without a feedback loop with them at the center. My agents often can go off for a few minutes, maybe 10, and write some feature. Half of the time they will get it wrong, I realize I prompted wrong, and I will have to re-do it myself or re-do the prompt. A quarter of the time, they have no idea what they're doing, and I realize I can fix the issue that they're writing a thousand lines for with a single line change. The final quarter of the time I need to follow up and refine their solution either manually or through additional prompting.
That's also only a small portion of my time... The rest is curating data (which you've pretty much got to do manually), writing code by hand (gasp!), working on deployments, and discussing with actual people.
Maybe this is a limitation of the models, but I don't think so. To get to the vision in my head, there needs to be a feedback loop... Or are people just willing to abdicate that vision-making to the model? If you do that, how do you know you're solving the problem you actually want to?
At some level this is driven by street design. The reason bus stops are so close in Philadelphia is because they stop every block, and there's a stop sign every block. The blocks are very small.
I don't know that 'removing' these as bus-stops would actually change anything. I think a larger question is whether route changes should occur.
There was a large effort in Philly called the 'Bus Revolution' [1] that aimed to re-balance routes (I have a map from the 50s on my wall and the bus routes are the same, including numbers, as they are today). The problem there was that there was a funding crisis that massively delayed the implementation [2]. These services are massively under-funded, and that's the primary issue; implementing the article's suggestions are not free.
Racing and street driving are completely different. Racing involves detailed knowledge of vehicle dynamics and grip. Street driving is mainly obstacle recognition and avoidance. No waymo ever operates anywhere close to the limit of grip, which is where you are all the time when racing.
I don't really understand how me saying that this tool isn't good for science as gatekeeping. The vibe-written papers that I am talking about have little-to-no valuable scientific content, and as such would always be rejected. It's just that it's way easier to produce something that _looks_ reasonable from a five-second glance than before, and that causes additional load on an already strained system.
I also don't understand your second paragraph at all.
The journal that I'm an editor for is 'diamond open access', which means we charge no submission fees and no publication fees, and publish open access. This model is really important in allowing legitimate submissions from a wide range of contributors (e.g. PhD students in countries with low levels of science funding). Publishing in a traditional journal usually costs around $3000.
From my perspective as a journal editor and a reviewer these kinds of tools cause many more problems than they actually solve. They make the 'barrier to entry' for submitting vibed semi-plausible journal articles much lower, which I understand some may see as a benefit. The drawback is that scientific editors and reviewers provide those services for free, as a community benefit. One example was a submission their undergraduate affiliation (in accounting) to submit a paper on cosmology, entirely vibe-coded and vibe-written. This just wastes our (already stretched) time. A significant fraction of submissions are now vibe-written and come from folks who are looking to 'boost' their CV (even having a 'submitted' publication is seen as a benefit), which is really not the point of these journals at all.
I'm not sure I'm convinced of the benefit of lowering the barrier to entry to scientific publishing. The hard part always has been, and always will be, understanding the research context (what's been published before) and producing novel and interesting work (the underlying research). Connecting this together in a paper is indeed a challenge, and a skill that must be developed, but is really a minimal part of the process.
I’m not sure that’s an accurate description of the word’s entomology not least because “goyslop” is itself derived from… “slop”, which is low quality high-volume food for livestock.