Live data from Hacker News

Snorting the AGI with Claude Code

kadekillary.work

201–210 of 253 posts

Re: Snorting the AGI with Claude Code

#201

Earlier quoted context omitted.

Of all the things I read at uni UML is the thing I've felt the least use for - even when designing new systems. I've had more use for things I never thought I'd need like Rayleigh scattering and processor design.

I think most software engineers need to draw a class diagram from time to time. Maybe there are a lot of unnecessary details to the UML spec, but it certainly doesn't hurt to agree that a hollow triangle for the arrow head means parent/child while a normal arrow head means composition, with a diamond at the root for ownership. As the sibling comment says, sequence diagrams are often useful too. I've used them a few t…

True but I don't bother with a unified system, just a mermaid diagram. I work in web though, so perhaps if I went back to embedded (which I did only a short while) or something else when a project is planned in it entirety rather than growing organically/reacting to customers needs/trends/the whims of management.

Re: Snorting the AGI with Claude Code

#202

Earlier quoted context omitted.

>People think best in 2d. no they don't. some people do. Some people think best in sentences, paragraphs, and sections of structured text. Diagrams mean next to nothing to me. Some graphs, as in representations of actual mathematical graphs, do have meaning though. If a graph is really the best data structure to describe a particular problem space. on edit: added in "representations of" as I worried people might misu…

FWIW, you're likely right here; not everyone is a visual thinker. Still, what both you and GP should be able to agree on, is that code - not pseudocode, simplified code, draft code, but actual code of a program - is one of the worst possible representations to be thinking and working in. It's dumb that we're still stuck with this paradigm; it's a great lead anchor chained to our ankles, preventing us from being able…

IMHO there's usually a lot of necessary complexity that is irrelevant to the actual problem; logging, observability, error handling, authn/authz, secret management, adapting data to interfaces for passing to other services, etc.

Diagrams and pseudocode allow to push those inconveniences into the background and focus on flows that matter.

Re: Snorting the AGI with Claude Code

#203

Earlier quoted context omitted.

You pay junior devs way way way more money for the privilege of them being bad. And since they're human, the juniors themselves do not have the patience of an LLM. I really would not want to be a junior dev right now... Very unfair and undesirable situation they've landed in.

>You pay junior devs way way way more money for the privilege of them being bad. I hope you don't think that what you're paying for an LLM today is what it actually costs to run the LLM. You're paying a small fraction. So much investment money is being pumped into AI that it's going to make the 2000 dot-com bubble burst look tiny in comparison, if LLMs don't start actually returning on the massive investments. People…

> I hope you don't think that what you're paying for an LLM today is what it actually costs to run the LLM. You're paying a small fraction.

Depends, right? Claude Code on a Max plan is obviously unsustainable if the API costs are any indication; people can burn through the subscription price in API credits in a day or less.

But otherwise? I don't feel like API pricing is that unrealistic. Compute is cheap, and LLMs aren't as energy-intensive in inference as some would have you believe (especially when they conveniently mix up training and inference). And LLMs beat juniors at API prices already.

E.g. a month ago, a few hours of playing with Gemini or Claude 3.5 / 3.7 Sonnet had me at maybe $5 for a completed little MVP of an embedded side project; it would've taken me days to do it myself, even more if I hired some random fresh grad as a junior, and $5 wouldn't fund even an hour of their work. API costs would had to be underpriced by at least two orders of magnitude for juniors to compete.

Re: Snorting the AGI with Claude Code

#204
post #127

Not trying to be rude here, but that `last_week.md` is horrible to me. I can't imagine having to read that let alone listen to the computer say it to me. It's so much blah blah and fluff that reads like a bad PR piece. I'd much rather scan through commits of the last week. I've found this generally with AI summaries...usually their writing style is terrible, and I feel like I cannot really trust them to get the facts…

I felt the same thing about the onboarding. Like what future are we trying to build for ourselves here, exactly? The kind where instead of sitting down with a coworker to learn about a codebase, instead we get an ai generated PowerPoint to read alone???? Im so over this timeline.

Naw, the new future (technically the present for orgs that use AI intelligently) is:

The AI already generated comprehensive README.md files and detailed module/function/variable (as needed) doc comments, which you could read but end up mostly being consumed by another AI, so you can just tell it what you're trying to do and ask it how you might accomplish that in the codebase, first at a conceptual level, then in code once you feel comfortable enough with the system to be able to validate the work.

All the while you're sitting next to another coworker who's also doing the same thing, while you talk about high level architecture stuff, make jokes, and generally have a good time. Shit, I don't even mind open offices as much as I used to, because you don't need that intense focus to get into a groove to produce code quickly like you did when manually writing it, so you can actually have conversations with an entire table of coworkers and still be super productive.

No comment on the political/climate side of this timeline, but the AI part is pretty good when you master it.

Re: Snorting the AGI with Claude Code

#205
post #56

Earlier quoted context omitted.

Maybe it's the senior devs who should be the ones to worry? Seniors' attitudes on HN are often quick to dismiss AI assisted coding as something that can't replace the hard-earned experience and skill they've built up during their careers. Well maybe, maybe not. Senior devs can get a bit myopic in their specializations. Whereas a junior Dev doesn't have so much baggage, maybe the fertile brains of youth are better in…

> Maybe it's the senior devs who should be the ones to worry? Why would they be worried? Who else going to maintain the massive piles of badly designed vibe code being churned out at an increasingly alarming pace? The juniors prompting it certainly don't know what any of it does, and the AIs themselves have proven time and again to be incapable of performing basic maintenance on codebases above a very basic level of…

If your seniors aren't analyzing the PRs being vibe coded by others in the orgs to make sure they meet quality standards, that is the source of your problem, not the vibe coding.

Re: Snorting the AGI with Claude Code

#206

No mention of Opus there or here (so far). Having tried everything I settled on a $100/month Anthropic "Max" plan to use Claude Code. Then I learned how Claude Opus 4 is currently their best but most expensive model for my situation (math code and research). I limited out of a five hour session, switched to their API, and burned $20 in an hour. So I upgraded to $200/month "Max" and haven't hit limits yet. Models matt…

All of this was with Opus.

I recently investigated some problematic behaviour of both Opus 4 and Sonnet 4. When tasked to develop something more complicated (broker fed task management system, staggered execution scheduler) they would inevitably produce thousands of lines of over engineered, unmaintainable garbage. When Opus was then tasked to simplify it it boiled it down to 300 lines in one shot. The result was brilliant. This happened twice.

Moral of the story: I found out that I didn't constrain them enough. I now insist that they keep the core logic to a certain size (e.g. 300 lines) and not produce code objects for each concept but rather "fold them into the code".

This improved the output tremendously.

Re: Snorting the AGI with Claude Code

#207
post #202

Earlier quoted context omitted.

FWIW, you're likely right here; not everyone is a visual thinker. Still, what both you and GP should be able to agree on, is that code - not pseudocode, simplified code, draft code, but actual code of a program - is one of the worst possible representations to be thinking and working in. It's dumb that we're still stuck with this paradigm; it's a great lead anchor chained to our ankles, preventing us from being able…

IMHO there's usually a lot of necessary complexity that is irrelevant to the actual problem; logging, observability, error handling, authn/authz, secret management, adapting data to interfaces for passing to other services, etc. Diagrams and pseudocode allow to push those inconveniences into the background and focus on flows that matter.

Precisely that. As you say, this complexity is both necessary and irrelevant to the actual problem.

Now, I claim that the main thing that's stopping advancement in our field is that we're making a choice up front on what is relevant and what's not.

The "actual problem" changes from programmer to programmer, and from hour to the next. In the morning, I might be tweaking the business logic; at noon, I might be debugging some bug across the abstraction layers; in the afternoon, I might be reworking the error handling across the module, and just as I leave for the day, I might need to spend 30 minutes discussing architecture issue with the team. All those things demand completely different perspectives; for each, different things are relevant and different are just noise. But right now, we're stuck looking at the same artifact (the plaintext code base), and trying to make every possible thing readable simultaneously to at least some degree.

I claim this is a wrong approach that's been keeping us stuck for too long now.

Re: Snorting the AGI with Claude Code

#208

Earlier quoted context omitted.

The agents are separate from the models . Claude Code only allows you to use Claude, but Aider allows you to use any model.

How does that solve the problem of closed models being better than open models?

There is no problem. OP said we should be using open _agents_, not open _models_. You can use an open agent with any model, open or closed, while using something like Claude Code locks you in to one model vendor

Re: Snorting the AGI with Claude Code

#209

Earlier quoted context omitted.

I think most software engineers need to draw a class diagram from time to time. Maybe there are a lot of unnecessary details to the UML spec, but it certainly doesn't hurt to agree that a hollow triangle for the arrow head means parent/child while a normal arrow head means composition, with a diamond at the root for ownership. As the sibling comment says, sequence diagrams are often useful too. I've used them a few t…

True but I don't bother with a unified system, just a mermaid diagram. I work in web though, so perhaps if I went back to embedded (which I did only a short while) or something else when a project is planned in it entirety rather than growing organically/reacting to customers needs/trends/the whims of management.

I've been at this 16 years. I've seen one planned project in that 16 years that stuck anywhere near the initial plan. They always grow with the whims of someone.

Re: Snorting the AGI with Claude Code

#210
post #171

I can't wait until Section 174 changes are repealed and nobody is financially invested in software from AI anymore.

America = world?

Is this meant to say "I don't care because I'm not in USA"? Or "it's not a problem because it's only USA?" Or "don't speak of US-specific situations on this forum because it contains people of many nationalities?"

It's entirely possible for a world changing tech to be created and steered to match a unique problem inside one country, and for that to change job markets everywhere.

Post reply on HN