But IMO, React didn't go as far as it could have; partly because it is backend-agnostic. You still have to re-implement a lot of the same wiring over and over and you keep running into the same issues and vulnerabilities. Also React offers too many ways to do the same thing; it just confuses the LLM as it mixes all different approaches, it lacks a clear philosophy to provide the guardrails you mentioned.
We should be able to just deal with pure UX issues/tradeoffs; we shouldn't be running into technical issues.
Frameworks matter, but they should be focused on minimizing the amount and complexity of code per feature.
The more feature-dense your code is, the less unnecessary hurdles and complexity, the more reliable your software is and the easier to extend and maintain. The more code can fit into the LLM's context window, the more complex your application can become whilst remaining reliable.
I built my own framework which is declarative HTML web components with a serverless backend (similar to Firebase but optimized for AI so that the AI can interact with the control panel, impersonate users and test access controls by itself) and it's so easy to create new features. It's just pure UX work. Just telling the AI what the problems are. Once fixed, it's fixed for good. By contrast, with a standard framework, I have to spend a lot of time debugging technical problems and keep running into regressions and it takes way longer to fix anything and requires coding knowledge.
LLMs work really well with custom frameworks provided that they're well documented via agent skills.
React doesn't provide optimal abstractions for safe and efficient LLM coding IMO; when building applications, React still makes you duplicate a lot of work and create a lot of custom components. A lot of the wiring has to be re-created over and over. If you really think about the essence of a web UI; it's just sections with lists of records, single records (loaded based on ID), single fields of specific records, forms... And each one requires access control rules which should be enforced by the backend; ideally in a declarative way so that it's easy to audit. IMO, the backend access control rules should be exhaustively auditable so that the AI can impersonate all the roles and access all possible resources in all possible states to verify that access control is enforced correctly in all possible situations. Anything less than that is not suitable for vibe-coding IMO. A user who doesn't even know what access control means cannot possibly build a secure application.
I was never interested in hacking but as a software engineer with 15 years of experience, I frequently encounter tricky situations in the code where I think to myself that it would present a perfect hacking opportunity and probably present in a large percentage of software.
Last time I tried my hand at whitehat hacking on HackerOne, it took me 30 minutes to find a major system crash/DoS vulnerability in a major platform. The company acknowledged that the issue was real but denied me the bounty payment because they said I would have to 'prove' that it leads to catastrophic failure. I had already done so in the sense that you could reliably infer it from the data I had provided, but it seemed like they were baiting me into committing a felony (DoS attack) to prove my point, which I wasn't prepared to do but I'm sure I could have done cheaply. So yeah, whitehat hacking seems to be a waste of time. Most software today is incredibly insecure.
This approach feels wrong. For code, it's obvious now that Claude is adding watermarks through comments because they are way too long. I keep asking Claude to remove and reduce its comments.
Also, I don't think it's useful because AI involvement in the work is a spectrum, not a binary true or false. If I ask Claude to go over my code and fix up typos and clean up and it starts adding comments with hidden watermarks everywhere it makes the tiniest adjustment, it's essentially appropriating my code. Its contribution may be trivial and superficial.
When I use AI on my own projects, the code it generates basically looks like auto-complete to me; exactly what I would have written by hand. So I don't see why it needs to be marked as AI. It's just saving me time. It's very much my own work.
I would push back on "LLMs seem to love duplicating code" - LLMs love copying your code style.
If your code style involves duplicating code, then LLMs will duplicate a lot of code. If you reuse code, LLMs will reuse code.
If your code is full of patches and workarounds, then LLMs will write code that is full of patches and workarounds.
That's the inference aspect.
There are also some biases introduced by the training set itself. If your favorite programming language's training set favors over-engineering and an enterprise coding style, then LLMs will leans towards that coding style.
This is why I prefer Javascript over Typescript. TS is more enterprisey. In TS, LLMs tend to invent unnecessary abstractions and create architectural complexity... TS was designed for large corporate teams of people who move slowly, bill by the hour and whose salary and job security is determined primarily by their lock-in factor within the company; their incentives aren't necessarily aligned with delivering results and this is reflected in LLM output.
With Claude, most tasks do not require discussion, I know exactly what to ask and what approach I want to take but for especially complex functionality with multiple possible options, I will ask it to list the tradeoffs and suggest an approach. It's still kind of 50/50 whether I take its suggestion or not; it's still a bit off in terms of weighing up importance, but it's really good at listing out relevant constraints and tradeoffs. It sometimes misses opportunities but it always sees the tradeoffs and the issues.
MCP definitely has its niche in certain environments. It's good for a specific kind of constrained problem; not so constrained that you could solve the problem with just Node.js + fetch call to LLM API but not so open that you'd want to let the AI agent directly invoke any service it wants over the web. The latter is what happens if you give the agent access to curl.
Though I agree with OP's point of view that MCP was overhyped for too many use cases. Complex agent-system integration problems are usually better solved with just AI agent + curl + SKILL.md. It's just way more flexible.
It's another variant of the 'fat client/thin server vs thin client/fat server' debate. Some people want rigid, thin (e.g. web-based) frontends with the LLM doing work in secret behind the scenes. Others want fat, versatile frontends through which the LLM can interact with the user's own environment.
I've always been a fat client guy and this time is no exception. I doubt the constrained approach is going to lead ground-breaking innovation. I also wish companies would treat SKILL.md + curl as the main mechanism for agent tool calling as opposed to MCP. MCP is niche.
That niche environment is all SaaS-to-SaaS integrations. The client doesn't want to have users struggling to get every integration working on their platform. The service providers don't want to have to support non-standarized behavior by every client.
As a software engineer, 6 months ago. I was better than AI in essentially every way except raw typing speed.
Now AI has surpassed me in fine-grained problem-solving ability. It can write more reliable code than I can, faster than I can, provided it is given the right guidance.
But one thing that I'm still much better at is identifying technical opportunities and choosing the right tradeoffs.
My feeling is that frontier models are incredibly smart in some ways, but incredibly dumb in other ways
When I chat with Claude using deep technical language about distributed systems issues, the arguments it presents are mind-blowingly good. I worked with many skilled engineers on complex projects but the kinds of arguments Claude makes are on another level. It feels like it can read my mind because it already identified all of the relevant aspects to the current topic and it's incredibly persuasive. I would say it's even better at deep, nuanced technical discussions than I am.
When I ask it to implement a feature using technical language, it does a really good job and the solution usually works out of the box. No bugs at all 95% of the time even after adding 1000 lines!
But the problem it still has is that when it implements solutions, it misses so many low-hanging fruits/opportunities. Especially in terms of performance, maintainability, scalability and UX. It's like it sees and recalls all the relevant parts perfectly but yet somehow misses opportunities which seem extremely obvious to me.
It feels like AI has 0 creativity. It only sees the opportunity once I mention it... And once it sees the opportunity, it demonstrates deep understanding of the technical implications. I think what's surprising is that it understands the suggested solution so well, with such nuance, that I can't understand how it didn't see the opportunity and why it never seems to see it until I mention it.
This is very unhuman-like. There is no way that a human being with that degree of understanding of a topic would be presented with such highly relevant context and not make the connection.
This is exactly how I feel about the recent ChatGPT models. It feels like I'm working with an incredibly enthusiastic junior student who listens to everything I say, checks it against my entire codebase, and thinks through all of the possible connections 1000x faster than I can. But it doesn't spot the ideas first. It actually makes work quite fun, since I can spend so much more time in "idea space" instead of "implementation space".
Thanks for putting it in words. I feel the same about SOTA coding models. I get visibly frustrated by this and often find myself using curse words at Astra.
You're right it's very unhuman to miss obvious opportunities you mentioned. And what's why I think these models would continue sucking as long as they don't have human level general intelligence. They may get marginally better at these tasks but I don't think we can expect them to connect dots like humans before AGI.
This mirrors my understanding when I use Claude code for mathematics. I can have deep discussions with it and it can solve my hairy problems. But whenever we go off the beaten track into design new mathematics, it struggles to make conceptual leaps and find the right definitions. Once I give it my ideas, it is back to its super-human pace and top notch intelligence.
This situation suits me fine, since I am anyways more of an ideas person, than a crunching open problems person. But I understand the desperation of my colleagues who mad solving hard problems their identity.
> Once I give it my ideas, it is back to its super-human pace and top notch intelligence.
That's the real benefit of AI today: you can test your ideas almost as fast as you can generate them, in parallel even. If you have a crazy idea that is unlikely to work but has massive advantages if it does, you just set an agent to explore and prototype it while you focus your main attention elsewhere. And so on.
It's still GIGO, though! An AI can make a bad idea work (and will do so if you don't carefully prompt it to not be so sycophantic!) but it won't work well. Knowing when the idea is bad and should be abandoned is also the part that currently requires human judgment.
That said, given the pace at which models have been improving so far, I can't help but think that this is a transient state of affairs.
Yes very much the same situation in software development.
The people who prided themselves on raw puzzle-solving ability got hit hard. Those who are idea-driven and architecture-oriented feel like they got handed a superpower.
It's quite a big shock at the industry level because the entire software engineering job interview process at essentially all large companies was heavily biased towards well-defined, raw problem-solving under time constraints which is precisely the skill which AI has replaced.
Yeah and companies continue to use leetcode style interviews even today and software engineers keep grinding for them. It's nauseating to contemplate on.
I'm an open source dev and I appreciate AI. I'm glad it exists and I have no problem with people being rewarded for their work on AI.
That said, I also think everyone who contributed content online deserves to be rewarded for their contribution, especially since OpenAI (which made the largest contribution) was a non-profit in the beginning. So there should be some kind of tax. Otherwise I agree, it's not ethical. It's not 'fair use' of copyrights.
We should be able to just deal with pure UX issues/tradeoffs; we shouldn't be running into technical issues.