ryanSrich

Spend limits saved me. I noticed a massive spike on one of my Anthropic keys and couldn't figure out where it was coming from. It hit the cap in one day, which isn't normal. So I rotated it just to be safe. I went to update it in Railway only to find out that I couldn't do deploys, so I also have a broken product. The good news is that it's only serving around 300 users, but still. Not great.

Must be different from the rest of the market as well, since most software companies report that LLMs generate 80-95% of their code (including frontier model providers who are reporting > 90% of the code they produce being generated by LLMs).

I do think most of this is a skill issue. I don't mean your personal skills; I mean the misuse or non-use of agentic skills. The majority of issues with code synthesis and review can be repaired by giving the agent enough guardrails, context and skills to use.

And I think the online reality is much closer to the truth than AFK reality. I can't think of a single founder I've talked to in the past two years that's building with rails. That doesn't mean rails dies overnight, but it does mean it's simply all downhill from here.

Two ways I use skills

1. Personally - these are for apps I use like Codex. This one is pretty simple

2. For our product (which is mostly an internal tool, with minimial customer facing UI) - we have a skills factory that lets our employees create reusable instructions for our internal agent (fully custom built harness with routing). User describes the task and writes the instructions (can attach reference files, etc.). Custom skills and their versions are stored in postgres, with attachments in file storage. The assistant loads those instructions and references when it uses the skill. To update a shared skill, users edit a draft, test it, and submit it for review. Once approved, that version becomes live. Skills can learn or rewrite themselves from conversations (cuts a new draft and prompts the user if they want to update/improve the skill).

EDIT: I should say that our employees have a particular set of expertise and knowledge that make skill sharing insanely useful. Which is why I took the time to build this out. It's helped reduce manual work, and has increased our AI usage drastically. We also measure AI output (in terms of quality) and the reduction in slop has sky rocketed.

Not a great argument. You're describing what LLMs are trained to do, not necessarily every capability or property produced by that training. We do not know what conditions are sufficient for consciousness. Any statements saying it's not possible for consciousness to emerge (or that it hasn't already) in such a system is no more established than claiming that it has

Consciousness can factually exist even though another being’s subjective experience is not directly observable. we can measure its behavioral and neural correlates and infer consciousness from them but we cannot directly observe the experience itself or conclusively prove its absence in another being. I don't think we'll ever get to a point where subjective experience in another is directly observable. But I don't think we need that to happen to prove consciousness factually exists.

I haven't used fable since they brought it back. But based on my experience before they removed it, I would agree that sol is pretty close.

For anyone on the fence, I was a hardcore CC user since it was released. I made the full switch to 5.6 sol and Codex about a month ago.

It's the better experience. The limits are way higher (I almost never burn through my $200/m plan), and the output is better than Opus 4.8 (Opus 5 is completely unusable for me).

> but maybe it's 2 lines of code with 6 lines of comments (looking at you Claude), maybe it defines three helper functions it doesn't really need, maybe it does something "here" when it should be doing that something "there" instead, maybe it finds itself in a framework and completely disregards how the framework is supposed to do things, etc.

I would fully expect a brand new college grad to call these things out. There's nothing in here that requires extensive experience to understand. These are basic principles any SWE should know. Nonsense comments are common sense to pull, if the LLM is pulling in a framework you should look into that framework and understand how it works. Don't know the framework during the interview? Say that. Tell the person interviewing you "looks like it's pulling in XYZ. I'm not entirely familiar with that. I understand at a high level what it's doing, but I'd want to dig deeper and understand if the LLM is doing this part right"

SWE was a sub degree within the school of CS where I went to school. You could do CS with a minor in SWE and get the best of both. I suppose if you're just doing a straight ticket CS degree you'll have little exposure to engineering (I believe when I went to school 13 years ago there were 3 courses over 4 years on engineering within a pure CS degree).

> I’m sorry to say but colleges don’t teach the kinda stuff you’re gonna use day-to-day.

This was not my experience in college. A lot of it was VERY applied. Granted, that was 13 years ago.

But even so, if you're at a college where you feel that you're not getting enough exposure, that's why I also called out "Have done dozens of projects" and "Have done several (at least 2) internships".

> This all sounds good on paper but I have an honest question: How do you develop judgement as a junior or mid level engineer to critique AI if you yourself never learned that skill by making mistakes in the first place?

Shouldn't this be a pretty fundamental part of a degree? If you're in school right now for a CS or SWE related degree, I would imagine you're learning how code actually works, how the math actually works, etc.

If an LLM makes a mistake, you should be able to call that out.

You might be arguing that a junior engineer may not have the RWE to make those judgements, but by the time you've completed a 4-5 year degree, you should have done the following:

- Completed coursework where you've learned the fundamentals of programming and software engineering

- Have done dozens of projects (building everything from basic web apps to more advanced pieces of software) where you've seen what works, what doesn't work, etc. This also gives you real world exposure to the latest and greatest frameworks, tools, etc.

- Have done several (at least 2) internships where you've worked at a real company writing real code, and have seen/been mentored into what AI is good at, where it fails, etc.

So the moral of the story is, don't build a frontier model in the US. Got it.