wpride

We do, but mostly as a fairly nice and fairly well-documented interface for plugging together tools like vector DBs and memory with LLMs.

My feeling is that with the agentic/AutoGPT hype fading and OpenAI adding the functions API there's a lot less value in LangChain's abstractions, at least for production use cases. They're still cool for hacking/toys.

Maybe "complaint" was the wrong word but I disagree with the conclusion that LLMs are "not for trustworthy production systems" for the reasons I stated.

Full disclosure, I wrote a blog post called "Text to SQL in Production." Maybe I should add a follow-up covering our guardrails. I agree that they are necessary.

https://canvasapp.com/blog/text-to-sql-in-production

What is the complaint here exactly? That LLMs aren't enforcing database access best practices for you? That's not their job, that's your job. LLMs generate text. You do the rest. Give the LLM a user with the correct access control rules. Add a reasonable timeout to your warehouse/database. Enforce rate limiting like you would with any other endpoint.

Everyone in this space seems to be building on the LSP and classic auto-complete in particular as their UI. But I've found this to be non ideal.

- As mentioned in this paper I definitely do not want the AI suggestion crowding out a suggestion generated directly from the type bindings

- I often do want the AI to write an entirely new block of boilerplate. To do this you have to write a comment string targeted at the AI, then delete this afterwards

- Sometimes I'd just like the AI to explain to me what some code does without writing anything

- This isn't something I always want on; I find myself turning the plugin on and off depending on the context

Overall I think we need a novel UX to really unlock the AI's helpfulness

Also, accumulating powerful backers and friends to signal "this is a successful company" instead of building an actual company.

Phew, was worried when all my CI jobs failed simultaneously

Not OC but we generate the client types with Apollo codegen (https://www.apollographql.com/blog/typescript-graphql-code-g...) using the schema file generated by our NestJS backend

What news they choose to make News is an opinion.

We use Contracts too and are in the process of transitioning to Sorbet. In addition to the same runtime type checking as Contracts, Sorbet offers static type checking (and will re-use your runtime signatures in its static analysis).