frabjoused (u/frabjoused)

frabjoused commented on Ask HN: AI Replacing Engineers – Firsthand Stories? · Posted by u/ludovicianul

anonzzzies · 4 months ago

For frontend, we don't need people anymore: backend, especially complex stuff, LLMs really waste our time by not getting it/going in circles so we just don't really do that anymore as plowing through 100s of lines of code or prs that are wrong, not conform to standards, has libs included we don't need etc. It is pretty useless as agents will just go in circles until it's so messy that it would've been many times easier just writing it with code. And often it's hard to get out besides just rollback.

frabjoused · 4 months ago

You're definitely a backend engineer aren't you?

frabjoused commented on MCP vs. API Explained norahsakal.com/blog/mcp-v... · Posted by u/typhon04

saurik · 6 months ago

> This is very naive. How many different APIs have you authenticated with and connected to? Just the big ones?

I mean, a lot? I have multiple times felt like that was my entire life for weeks or months on end during the past over three decades of doing software development...

(If we expand the scope a bit to network protocols, as opposed to just "APIs", I was even the person who first spiked nmap's protocol scanning and detection logic.)

To wit, I am one of those people who pretty much never use an SDK provided for an API: if I have to, I will rather reverse engineer the protocol using a disassembler.

(This then being part of why I've won millions of dollars in bug bounties, as part of my relentless drive to always operate at the lowest level presented to me.)

But, regardless, can we move past trying to attack my credibility on software, and shift back to more productive forms of analysis? (Why did this become so personal?!)

> What happens when the docs are wrong or incomplete?

If we posit that the documentation for the API is wrong, so we should this MCP description / wrapper, as both were written by the humans charged to enable this function.

And, of course, the real point is whether the task is easier than the thing we are trying to do... even writing a correct tree map is much harder than an API client.

^ Both of these arguments can be made by someone who doesn't even do software development, helping us try to understand why MCP is being hyped up as a new paradigm.

frabjoused · 5 months ago

Congrats on the bug bounties!

I’m not hyping or defending MCP at all: I’m just saying AI can’t figure out APIs well enough to be something you can promise as a product.

I founded an integration platform so definitely a developer and I’ve been living these problems every day.

frabjoused commented on MCP vs. API Explained norahsakal.com/blog/mcp-v... · Posted by u/typhon04

nostrebored · 6 months ago

Wouldn’t you just do that with an SDK? Why the extra layer of complexity with MCP?

frabjoused · 6 months ago

Not all http based APIs have an SDK. It’s wildly inconsistent. And when you ask the llm to do something new, does it download the SDK on the fly?

frabjoused commented on MCP vs. API Explained norahsakal.com/blog/mcp-v... · Posted by u/typhon04

saurik · 6 months ago

This is like the simplest task you can give a software developer, as it is nigh-unto merely a document "translation" task, without much real thought required. If an LLM is failing to do this task, why do we hope whatever chain of reasoning it is about to embark on would work?

frabjoused · 6 months ago

This is very naive. How many different APIs have you authenticated with and connected to? Just the big ones? What happens when the docs are wrong or incomplete?

frabjoused commented on MCP vs. API Explained norahsakal.com/blog/mcp-v... · Posted by u/typhon04

rsp1984 · 6 months ago

To be honest I don't understand why this is needed. All the leading AI models can already write code that interfaces perfectly with well-known APIs, and for the niche-APIs I can supply the docs of that API and the model will understand.

So all that's needed are API docs. Or what am I missing?

frabjoused · 6 months ago

The success rate of this is impractically low. APIs are dirty, inconsistent things. Real-world connection to obscure APIs is a matter of hard sleuthing. Docs are wrong, endpoints are broken, auth is a nightmare. These APIs need to be massaged in advance and given a sanity-wrapper if you want any semblance of reliable success when a model calls them.

frabjoused commented on MCP vs. API Explained norahsakal.com/blog/mcp-v... · Posted by u/typhon04

frabjoused · 6 months ago

Ironic this post is written in repetitive SEO spam format.

frabjoused commented on Show HN: Superglue – open source API connector that writes its own code github.com/superglue-ai/s... · Posted by u/adinagoerres

frabjoused · 6 months ago

I'm building an integration platform, would love to have a call with you and share ideas.

frabjoused commented on My failed attempt to shrink all NPM packages by 5% evanhahn.com/my-failed-at... · Posted by u/todsacerdoti

frabjoused · 7 months ago

This reminds me of a time I lost an argument with John-David Dalton about cleaning up/minifying lodash as an npm dependency, because when including the readme and license for every sub-library, a lodash import came to ~2.5MB at the time. This also took a lot of seeking time for disks because there were so many individual files.

The conversation started and ended at the word cache.