Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What we learned building 100 API integrations with OpenCode

nango.dev

Post reply on HN
Print view View original

21–27 of 27 posts

Re: What we learned building 100 API integrations with OpenCode

#21

Post by neya »

gchamonlive wrote: post #19
neya wrote: post #14

This is the wrong way to do it. As software architects, you need to learn to appropriate the correct usage of algorithms and AI. Using AI for building everything is not just a waste of tokens, it also is an exercise in futility. Here is how I solved this problem: 1. There is already a knowledgebase of almost all APIs (the ones that are useful to the average Joe anyway) in either Swagger.json or Postman.json format. T…

> There are two obvious approaches: start with lots of guardrails, or start with very few and learn what the models actually do. > We chose the second because we didn’t want to overfit our assumptions. > Some of it went better than expected. > But they also broke in very unexpected ways, sometimes spectacularly. You clearly missed the whole point of the article, which is to experiment with agents and explore the limi…

> which is to experiment with agents

I think you completely missed the point - they built a product purely using agents and deployed it to production for others to use. Read what the product actually does first.

Re: What we learned building 100 API integrations with OpenCode

#22

Post by gchamonlive »

neya wrote: post #21
gchamonlive wrote: post #19

Earlier quoted context omitted.

> There are two obvious approaches: start with lots of guardrails, or start with very few and learn what the models actually do. > We chose the second because we didn’t want to overfit our assumptions. > Some of it went better than expected. > But they also broke in very unexpected ways, sometimes spectacularly. You clearly missed the whole point of the article, which is to experiment with agents and explore the limi…

> which is to experiment with agents I think you completely missed the point - they built a product purely using agents and deployed it to production for others to use. Read what the product actually does first.

Why shouldn't they ship it to production if the experiment was a success? You say the only way to code is to "learn to appropriate the correct usage of algorithms and AI" which for you is to code a generator and only use "dumb" generators to produce code, which is fine, but they just showed that for 20 bucks and a few minutes you can get very far, so their evidence is just stronger than yours.

Re: What we learned building 100 API integrations with OpenCode

#23

Post by neya »

gchamonlive wrote: post #22
neya wrote: post #21

Earlier quoted context omitted.

> which is to experiment with agents I think you completely missed the point - they built a product purely using agents and deployed it to production for others to use. Read what the product actually does first.

Why shouldn't they ship it to production if the experiment was a success? You say the only way to code is to "learn to appropriate the correct usage of algorithms and AI" which for you is to code a generator and only use "dumb" generators to produce code, which is fine, but they just showed that for 20 bucks and a few minutes you can get very far, so their evidence is just stronger than yours.

> their evidence is just stronger than yours.

What evidence? There is 0 evidence. It's deployed to production, but that doesn't mean it works fine or is free of bugs - which is exactly my point and why you use algorithms for these types of things. They're testable, repeatable and scalable.

With LLM slop it's just that - slop.

Re: What we learned building 100 API integrations with OpenCode

#24

Post by gchamonlive »

neya wrote: post #23
gchamonlive wrote: post #22

Earlier quoted context omitted.

Why shouldn't they ship it to production if the experiment was a success? You say the only way to code is to "learn to appropriate the correct usage of algorithms and AI" which for you is to code a generator and only use "dumb" generators to produce code, which is fine, but they just showed that for 20 bucks and a few minutes you can get very far, so their evidence is just stronger than yours.

> their evidence is just stronger than yours. What evidence? There is 0 evidence. It's deployed to production, but that doesn't mean it works fine or is free of bugs - which is exactly my point and why you use algorithms for these types of things. They're testable, repeatable and scalable. With LLM slop it's just that - slop.

Have you seen the code to write it off as slop?

Re: What we learned building 100 API integrations with OpenCode

#25

Post by cl0ckt0wer »

neya wrote: post #14

This is the wrong way to do it. As software architects, you need to learn to appropriate the correct usage of algorithms and AI. Using AI for building everything is not just a waste of tokens, it also is an exercise in futility. Here is how I solved this problem: 1. There is already a knowledgebase of almost all APIs (the ones that are useful to the average Joe anyway) in either Swagger.json or Postman.json format. T…

There are lots of APIs with poor or nonexistent documentation. I'm talking about internal systems where one programmer that kinda knew what he was doing built a proof of concept, and now it's a core business requirement.

Re: What we learned building 100 API integrations with OpenCode

#26

Post by maxdo »

neya wrote: post #14

This is the wrong way to do it. As software architects, you need to learn to appropriate the correct usage of algorithms and AI. Using AI for building everything is not just a waste of tokens, it also is an exercise in futility. Here is how I solved this problem: 1. There is already a knowledgebase of almost all APIs (the ones that are useful to the average Joe anyway) in either Swagger.json or Postman.json format. T…

I’m sorry but this is a caveman mentality . How about tests , payloads , integrating into existing system , logs etc . Llm is perfect for that , you can point your skill in harvest to learn from docs , that will save tokens.

I’m not going to trust a scripted codegen without any logic fo such thing as api integration

Re: What we learned building 100 API integrations with OpenCode

#27

Post by evilelectron »

neya wrote: post #14

This is the wrong way to do it. As software architects, you need to learn to appropriate the correct usage of algorithms and AI. Using AI for building everything is not just a waste of tokens, it also is an exercise in futility. Here is how I solved this problem: 1. There is already a knowledgebase of almost all APIs (the ones that are useful to the average Joe anyway) in either Swagger.json or Postman.json format. T…

This is the way.

I am doing something similar where I have a parser which looks for changes in documentation, matches them with the GraphQL schema and generates code using Apollo. In a nutshell it is a code generator written using Claude to generate more code and on failure goes back to Claude to fix the generator and asks a human for review.

Post reply on HN