Perhaps I'm missing it but where do you actually buy and/or generate a CMC? I can't find any information on it.
Personally VCM is far too expensive for me at this time which is the only reason I haven't gotten one. But I certainly realize that putting a cost barrier to entry makes it less accessible to bad actors.
Like other here I think 13 miles may be generous for city driving but pretty reasonable for highway.
With that said, it works MUCH better for me than it did a couple years ago and I find most of the time I disengage it is not because it actually needed human intervention but because it wasn't aware of the social norms at certain intersections.
For example, I have an intersection near my house that requires you to inch out and essentially floor it first chance you get if you want any hope whatsoever of taking a left hand turn, but FSD will (understandably, I think) not do that.
Exactly, the "how it works" section ironically does not actually explain much.
I would love to know how this differs from fingerprinting. And if it is just fingerprinting it seems like it'd probably be trivial to bypass. Especially since it appears that you have a way to check your ID so you could potentially experiment with different ways to affect it.
That's more or less what I suspected. Though... and I'm not sure if this is an American thing, an international thing, or just a weird quirk of the specific people I know... I know several people who run their machines every day even if they aren't even close to full.
You can't make blanket claims about the US as a whole for things that are driven by the states - many states have highly restrictive shower/toilet efficiency requirements.
You are right, I cannot generalize. In fact our main flush function in newer toilets is the same flow as almost all countries (Australia and Japan being the exceptions) but we also have far fewer "Duel Flush" toilets (apparently, I'm just learning this myself) and the low flow on duel flush toilets uses much less water.
This is really great. Managing migrations without locking the table can be a real huge pain-point. And having a dedicated project likely covers more edge cases than an internal tool would (as is evident looking at the issues list).
With that said, it looks like it could be used not just as a stand alone tool but also embedded within a Go application since it does export its API. In my case I'd love to use it from my existing tooling. I couldn't find any documentation on how to do that, though.
I'm not sure it's something I would use but it looks like some good work.
At first glance the pricing seems a little high for a single-use tool. It is still cheaper than using humans but also, as it sounds like you are aware you are aware, there are some issues demo page that the AI agents didn't call out that a human would have.
I like that you included developer tool results in your summary. Consider possibly including Accessibility results in there as well. A11y is something a lot of developer and product people don't think about. It could be you already have it and I just didn't notice.
This was my first reaction. It hasn't been that long and giant ships can't change course quickly.
And for much of that year there were a lot of questions around the ownership of AI generated code as well as information security. In fact, most of those questions are still not satisfactorily solved. So I'm not so surprised that we haven't seen massive results "yet"
I find it striking that in the same day I saw a video about how someone "Made an API in 20 minutes with one prompt" and this. The two approaches seem very divergent. One that is almost cavalier about things like security, standards, etc and another that is (almost) over engineered.
One observation, is that I there are two trains of thought. Using OAD (Open API Descriptions) as a source of truth and generating code from there or treating OAD as an artifact that comes out of some other tools.
I personally see OpenAPI as kind of a glue that can allow different tooling to be able to speak the same language.
Overall I found the linked Moonwalk[1] document to be more interesting. But there is some interesting analysis to be found in this article as well.
The ethos I have seen around these is usually "It doesn't have to be proper if it isn't making money"
I think it's a fair attitude if your only goal is to make money, but it completely misses "why" you should build something... if you truly care about a problem you wouldn't haphazard it anyway.
Maybe I don't truely care about my problem? But I just care a little bit, and I've done the risk analysis.
I used a whole lot of "ChatGPT just wrote it all for me" for a rust program that watches for and renames video game clips for me. Maybe it's insecure or has subtle bugs, I don't really care all that much because it does the job for me.
You pretend to not care until you do. When it accidentally deletes your files or even your whole hard drive you'll suddenly find someone / something to blame.
> I think it's a fair attitude if your only goal is to make money
Short term, yes. But it's a bit short sighted as most of the AI code I have seen has security and scalability issues that long term have potential to blow up in your face costing even more money.
Granted that can usually be fixed by better prompts. But to right those prompts requires the person doing the "prompt engineering" (rolls eyes) to actually have a working knowledge of a lot of areas such as architecture, security, software engineering best practices, etc. And a lot of the influencers out there pushing AI openly admit to "not knowing how to code" let alone knowing the right way to build a technology product so that it scales and is safe.
To be fair I wasn't agreeing with the "API in 20 minutes approach" I was only pointing out the contrast between that and something like this.
As I tried to allude too, AI written APIs often have security, performance, maintainability and a whole slew of other issues.
But at the same time, I think "blank video on your phone for 20 minutes" is a bit of a stretch. These AI generated APIs have problems for certain but they are working software and in many cases better working software than a non-coder or junior engineer could have written in a much longer time.
And while I don't like the idea of tons of insecure poorly architected APIs being out there, the realty is, people are using AI generated APIs in the real-world right now, it's not hypothetical.
Have we lost the meaning of that now too? Samsung Galaxy Note 7 is a "working phone" too - it just might explode.
> but they are working software and in many cases better working software than a non-coder or junior engineer could have written in a much longer time.
Imagine the nurse telling you that you've got an AI doctor operating on you that's better than the junior surgeon. I'm sure you'd be happy. We've been cheapening the industry for a long time. Not everyone needs to produce code.
> the realty is, people are using AI generated APIs in the real-world right now, it's not hypothetical.
The reality is there is contaminated cooking oil [1], noodles with opium [2] and a infinite amount of issues. Let's not make the world worse?
Working means you give it input and it produces the expected output for all your defined used cases. Don't confuse working with good.
Let's keep your analogy: AI isn't producing software that is the equivalent of a AAA movie title by any stretch but it is producing far better than a bunch of kids in a garage with their cell phones can make. Which is orders of magnitude better than 20 minutes of blank video. Which means that people will use it whether you like it or not.
Reality doesn't care if you think it is a bad idea... in fact I think you and I are on the same page, I do think it is a bad idea... but reality will continue to exist whether you and I like it or not.
You're not helping anyone by arguing how crappy and harmful it is to someone who already knows how crappy and harmful it is.
Yeah this article is more about how we (the OpenAPI Initiative) are designing the next versions of the OpenAPI Specification than it is about how to use it. The diagram does include both an OAD generator and editor, intended to encompass both code-first and description-first (which doesn't make too much difference for this blog post). The Moonwalk article is definitely more general purpose! This is "OK Moonwalk has a great vision, but how do we actually make it a real spec?" I've been using variations of this diagram in the weekly Moonwalk calls for the past month or two.
> OK Moonwalk has a great vision, but how do we actually make it a real spec?
I'm not sure the article really succeeds if that was the goal. I suspect that there might be some aspects of the discussion that are taking place that are missing from the article making it a little difficult for someone who wasn't in those discussions to connect the dots.
Don't get me wrong, I think the article had some useful pieces in it, I just think if that was the goal of the article it could possibly use some additional framing for people who don't have the full context.
With that said, I really appreciate transparency into the thought process!
> I just think if that was the goal of the article it could possibly use some additional framing for people who don't have the full context.
It's always a struggle to figure out how much explanation to put in before people see something like "20 minute read" and just refuse to read it. (BTW I don't mind the critical feedback at all- I'm just glad you found something useful in it).
But keep in mind that _we_ haven't answered "how do we actually make it a real spec?" either! This is a snapshot of our efforts at this particular moment.
Also, there's a reason that this is "part one in a series" :-)
I like that idea but I purposely stay anonymous on HN and I would be DOXing myself if I used this. It'd be great to be able to either use it without a username (ideally) or have the choice to keep your HN username private.
In my experience Accept-Language header is pretty unreliable. It tends to just be one of a few values. Between people never updating it, proxies stripping it, people concerned it will make them easier to fingerprint, etc.
Also, form an implementation standpoint, translation is a lot of work to get right and some companies may not do it for all languages so they may support the header but just not support the language choice you have. Yelp being a weird example where they apparently have the Japanese translation on another site.
Combine all that together and it's not usually worth the effort to do it unless you have specific legal requirements or high demand from users.
(Sorry for the delay, I haven't checked HN is a while and just noticed this)
So some proxies (forward and reverse) will strip this header for different reasons.
The reverse proxies sometimes strip it to improve caching and/or because they were configured to have a allow-list of headers and this (being a less common one) was excluded.
The forward proxies will sometimes strip it for privacy reasons (it can be used in fingerprinting) or for the same reason (they have a list of allowed headers and this isn't one).
Personally VCM is far too expensive for me at this time which is the only reason I haven't gotten one. But I certainly realize that putting a cost barrier to entry makes it less accessible to bad actors.
reply