Hacker News Reader

Comment by throwaway2016a | Hacker News Reader

throwaway2016a

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.

[1] https://www.openapis.org/blog/2023/12/06/openapi-moonwalk-20...

View on HN

> 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

You can also record a blank video on your phone for 20 minutes and call that a movie. Would anyone watch it?

You can also build a house in days. Would it crack? Is it maintainable? What happens later? Who knows.

Those make great YouTube video titles.

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.

> 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.

> "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

Is that why we often get so many posts about e.g. getting a huge bill on AWS or GCP? Or that so and so company shut them down or whatever else?

I've seen far too many "temporary" solutions and "quick fixes" that always go beyond the scope and lifetime. Never have such a mindset.

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.

> Maybe I don't truely care about my problem?

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.

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.

> but they are working software

What is "working" software?

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?

[1]: https://www.abc.net.au/news/2024-07-13/cooking-oil-contamina...

[2]: https://www.washingtonpost.com/news/morning-mix/wp/2014/09/2...

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" :-)

Reply on news.ycombinator.com