Snorting the AGI with Claude Code
kadekillary.work
kadekillary.work
I'd caution against using devstral on a 24 gb vram budget. Heavy quantisation (the only way to make it fit into 24gb) will affect it a lot. Lots of reports on locallama about subpar results, especially from kv cache quant.
We've had good experiences with running it fp8 and full cache, but going lower than that will impact the quality a lot.
Most of these things in the post aren't new capabilities. The automation of workflows is indeed valuable and cool. Not sure what AGI has anything to do with it.
Plus you shouldn't need an LLM to understand a codebase. Just make it more understandable! Of course capital likes shortcuts and hacks to get the next feature out in Q3.
The kind of person who prefers this setup wants to read (and write) the least amount of code on their own. So their ideal workflow is one where they get to make programs through natural language. Making codebases understandable for this group is mostly a waste of effort.
It's a wild twist of fate that programming languages were intended to make programming friendly to humans, and now humans don't want to read them at all. Code is becoming just an intermediary artifact useless to machines, which can instead write machine code directly.
I wish someone could put this genie back in the bottle.
Those are two different groups of humans, as you implied yourself.
Having a thing that is interactive and which can answer questions is a very useful thing. A slide deck that sits around for the next person is probably not that great, I agree. But if you desperately want a slide deck, then an agent like Claude which can create it on demand is pretty good. If you want summaries of changes over time, or to know "what's the overall approach at a jargon-filled but still overview level explanation of how feature/behavior X is implemented?", an agent can generate a mediocre (but probably serviceable) answer to any of those by reading the repo. That's an amazing swiss-army knife to have in your pocket.
I really used to be a hater, and I really did not trust it, but just using the thing has left me unable to deny its utility.
Maybe that is the idea (vibe coding ftw!) but if you want something people can understand and refine it is good to make it modular and decomposable and understandable. Then use AI to help you with the words for sure but at some level there is a human that understands the structure.
<laughs in legacy code>
And fundamentally, that isn't a function of "capital". All code bases are shaped by the implicit assumptions of their writers. If there's a fundamental mismatch or gap between reader and writer assumptions, it won't be readable.
LLMs are a way to make (some of) these implict assumptions more legible. They're not a panacea, but the idea of "just make it more understandable" is not viable. It's on par with "you don't need debuggers, just don't write bugs"
Judging from the tone of the article, they’re using the term AGI in a jokey way and not taking themselves too seriously, which is refreshing.
I mean like, it wouldn’t be refreshing if the article didn’t also have useful information, but I do actually think a slide deck could be a useful way to understand a codebase. It’s exactly the kind of nice-to-have that I’d never want a junior wasting time on, but if it costs like $5 and gets me something minorly useful, that’s pretty cool.
Part of the mind-expanding transition to using LLMs involves recognizing that there are some things we used to dislike because of how much effort they took relative to their worth. But if you don’t need to do the thing yourself or burn through a team member’s time/sanity doing it, it can make you start to go “yeah fuck it, trawl the codebase and try to write a markdown document describing all of the features and requirements in a tabular format. Maybe it’ll go better than I expect, and if it doesn’t then on to something else.”
For the "sub agents"thing, I must admit, that Claude Code calling o3 via sigoden/aichat saved me countless of times!
There are just issues that o3 excells at (race conditions, bug hunting - anything that requires lot of context and really high reasoning abilities).
But I'm using it less since Opus 4 came out. And of course its none of the sub-agent thing at all.
I use this prompt @included in the main CLAUDE.md: https://github.com/pgflow-dev/pgflow/blob/main/.claude/advan...
sigoden/aichat: https://github.com/sigoden/aichat
Commands for working with copies of your entire repo in a new folder on a new branch
git worktree add new/path/for/worktree branchname
I now refuse to use git checkout to switch branches, always keep my main branch checked out and updated and always use worktrees to work on features. Love this workflow!
In the end, you either concede control over 'details' and just trust the output or you spend the effort and validate results manually. Not saying either is bad.
Now we can work on our passion projects and everything will just be LLMs talking to LLMs.
By manual labor I specifically mean the kind where you have to mix precision with power, on the fly, in arbitrary terrain, where each task is effectively one-off. So not even making things - everything made at scale will be done in automated factories/workshops. Think constructing and maintaining those factories, in the "crawling down tight pipes with scewdriver in your teeth" sense.
And that's only mid-term; robotics may be lagging behind AI now, but it will eventually catch up.
However with an LLM I'm not so sure. So how will you write a test to validate this is done but also guarantee it doesn't add the email to a blacklist? A whitelist? A list of admin emails? Or the tens of other things you can do with an email within your system?
So the process becomes: Read PR -> Find fundamental issues -> Update prompt to guide agent better -> Re-run agent.
Then your job becomes proof-reading and editing specification documents for changes, reviewing the result of the agent trying to implement that spec, and then iterating on it until it is good enough. This comes from the belief that better, more expensive, agents will usually produce better code than 5 cheaper agents running in parallel with some LLM judge to choose between or combine their outputs.
Do you not want to edit your code after it’s generated?
You get both editors to choose from, vi _and_ emacs! All the man pages you could possibly want _and_ perldocs! Of _course_ as a Perl newbie you'll be able to fall back on gdb for complicated debugging where print statements no longer cut it.
How do you interact with your projects?
The Chat panel in VS Code has seen a lot of polish, can display full HTML including formatting Markdown nicely, has some fancy displays for AI context such as file links, supports hyperlinks everywhere, and has fancy auto-complete popups for things like @ and # and / mentioned "tools"/"agents"/whatever. Other VS Code widgets can show up in the Chat panel, too. The Chat Panel you can dock in either sidebar and/or float as its own window.
A terminal can do most of those things too, with effort and with nothing quite like the native experience of your IDE and its widgets. It seems like a lesser experience than what VS Code already offers, other than you only have one real choice for AI assistant that supports VS Code's Chat panel (though you still have model choice).
It can even debug my k8s cluster using kubectl commands and check prometheus over the API, how awesome is this?
It's got 7 fingers? Looks fine to me! - AI
The number of times that my manager or coworkers have rejected proposals for technical solutions because I can't make a webpage look halfway decent is too damn high.
I have a designer on my team that adds their polish to the basic HTML and CSS I produce, but first I have to produce it. I really don't care what the front-end ends up looking like, that's for someone else to worry about. So I let the "AI" write the CSS for buttons and other UI elements, which it is good enough at to save me time. Then I hand it off to the designer and they finish the product, make the buttons match the rest of the buttons, fix the padding, whatever. It certainly has accelerated that part of my workflow, and it produces way better looking front-end UI styling than I would care to spend my time on. If I didn't have the designer, the AI-generated CSS would be good enough for most people. But, I wouldn't trust the AI to tell me if a page "looks weird". I have no doubt it would become a nuisance of false-positives, or just not reporting problems that actually exist.
A complete waste of time for important but relatively simple tasks.
Such a weird complaint. If you were to explain the rust borrow checker to me, should I complain that it doesn't count because you had read explanations of the borrow checker? That it was "in your training data"? I mean, do you think you just understand the borrow checker without being taught about it in some form?
I mean, I get what you are kind of saying, that there isn't much evidence that they tools are able to generate new ideas, and that the sheer amount of knowledge it has obscures the detection of that phenomenon, but practically speaking I don't care because it is useful and helpful (within its hallucinatory framework).
Not exactly “three laws safe” if we can’t use the thing for work without violating their competitive use prohibition
This made me chuckle
Agreed, and I find that I use Claude Code on more than traditional code bases. I run it in my Obsidian vault for all kinds of things. I run it to build local custom keyboard bindings with scripts that publish screenshots to my CDN and give me a markdown link, or to build a program that talks to Ollama to summarize my terminal commands for the last day.
I remember the old days of needing to figure out if the formatting changes I wanted to make to a file were sufficient to build a script or just do them manually - now I just run Claude in the directory and have it done for me. It's useful for so many things.
Obsidian is my source of truth and Claude is really good at managing text, formatting, markdown, JS, etc. I never let it make changes automatically, I don't trust it that much yet, but it has undoubtedly saved me hours of manual fiddling with plugins and formatting alone.
What does this mean?
You can EASILY burn $20 a day doing little, and surely could top $50 a day.
It works fine, but the $100 I put in to test it out did not last very long even on Sonnet.
He uses two max plans ($200/mo + $200/mo) and his API estimate was north of $10,000/mo
5x Pro usage ($100/month)
20x Pro usage ($200/month)
Source: https://support.anthropic.com/en/articles/11145838-using-cla...
"Pro ($20/month): Average users can send approximately 45 messages with Claude every 5 hours, OR send approximately 10-40 prompts with Claude Code every 5 hours."
"You will have the flexibility to switch to pay-as-you-go usage with an Anthropic Console account for intensive coding sprints."
The open source world is one where antirez, working on his own off in Sicily, could create a project like Redis and then watch it snowball as people all over got involved.
Needing a subscription to something only a large company can provide makes me unhappy.
We'll see if "can be run locally" models for more specific tasks like coding will become a thing, I guess.
I, for one, welcome our new LLM overlords.
The open source alternatives I've used aren't there yet on my 4090. Fingers crossed we'll get there.
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 matter. All these stories are like "I met a person who wasn't that smart." Duh!
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.
Is anyone aware of something like this? Maybe in the GitHub actions or pre-commit world?
Yeah now companies that paid lip service to those things can still not have them but pretend they do cause the AI did it....
It's at least decent though, right?
> "What emerged over these seven days was more than just code..."
Yeesh, ok, but is it accurate?
> Over time this will likely degrade the performance and truthfulness
Sure, but it's cheap right?
> $250 a month.
Well at least it's not horrible for the environment and built on top of massive copyright violations, right?
Right?
Lol, I guess their AI is too good for a redactor. Better have humans do it.
I don't know, just feels like a weird community response to something that is the equivalent to me of bash piping...
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 right, and reading the original text is often faster and better.
document.body.style.backgroundColor = "black";
Im so over this timeline.
if this is all ultimately java but with even more steps, its a sign im definitely getting old. it’s just the same pattern of non technical people deceiving themselves into believing they dont need to be technical to build tech and then ultimately resulting in again 10-20 years of re-learning the painful lessons of that.
let me off this train too im tired already
https://en.wikipedia.org/wiki/Fourth-generation_programming_...
Put another way, I am certain that Unity has done more to get non-programmers to develop software than ChatGPT ever will.
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 misunderstand.
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 to handle complexity better.
It depends on the language. In my experience, well-written Lisp with judicious macros can come close to fitting the way I think of a problem. But some language with tons of boilerplate? No, not at all.
That's what I mean by Pareto frontier: the choices made by various current-generation languages and coding methodologies (including choices you as a macro author makes, too), are all promoting readability for some tasks, at the expense of readability for other tasks. We're just shifting the difficulty around the time of day, not actually eliminating it.
To break through that and actually make progress, we need to embrace working in different, problem-specific views, instead of on the underlying shared single-source-of-truth plaintext code directly.
Diagrams and pseudocode allow to push those inconveniences into the background and focus on flows that matter.
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.
It's just hell of an expensive way to get around doing it. But then maybe at least a real demonstration will convince people of the utility and need of doing it properly.
But then, by that time, LLMs will take over all software development anyway, making this topic moot.
(Also, I'm _fairly_ sure that sequence diagrams didn't originate with UML; it just adopted them.)
As the sibling comment says, sequence diagrams are often useful too. I've used them a few times for illustrating messages between threads, and for showing the relationship between async tasks in structured concurrency. Again, maybe there are murky corners to UML sequence diagrams that are rarely needed, but the broad idea is very helpful.
Sounds a lot like RegEx to me: if you use something often then obviously learn it but if you need it maybe a dozen or two dozen times per year, then perhaps there’s less need to do a deep dive outside of personal interest.
I'm not sure what you mean by "unified system". If you mean some sort of giant data store of design/architecture where different diagrams are linked to each other, then I'm certainly NOT advocating that. "Archimate experience" is basically a red flag against both a person and the organisation they work for IMO.
(I once briefly contracted for a large company and bumped into a "software architect" in a kitchenette one day. What's your software development background, I asked him. He said: oh no, I can't code. D-: He spent all day fussing with diagrams that surely would be ignored by anyone doing the actual work.)
UML may be ugly and in need of streamlining, but the idea of building software by creating and manipulating artifacts at the same conceptual level we are thinking at any given moment, is sound. Alas, we've long ago hit a wall in how much cross-cutting complexity we can stuff into the same piece of plaintext code, and we've been painfully scraping along the Pareto frontier ever since, vacillating between large and small functions and wasting time debating merits of sum types in lieu of exception handling, hoping that if we throw more CS PhDs into category theory blender, they'll eventually come up with some heavy duty super-mapping super monad that'll save us all.
(I wrote a lot on it in in the past here; c.f. "pareto frontier" and "plaintext single source of truth codebase".)
Unfortunately, it may be too late to fix it properly. Yes, LLMs are getting good enough to just translate between different perspectives/concerns on the fly, and doing the dirty work on the raw codebase for us. But they're also getting good enough that managers and non-technical people may finally get what they always wanted: building tech without being technical. For the first time ever, that goal is absolutely becoming realistic, and already possible in the small - that's what the whole "vibe coding" thing heralds.
1) Plaintext representation, that is
2) a single source of truth,
3) which we always work on directly.
We're hitting hard against limits of 1), but that's because we insist on 2) and 3).
Limits of plaintext stop being a problem if we relax either 2) or 3). We need to be able to operate on the same underlying code ("single source of truth") indirectly through task-specific view, that hide the irrelevant and emphasize the important for the task at hand, which is something that typically changes multiple times a day, sometimes multiple times an hour, for each programmer. The views/perspectives themselves can be plaintext or not, depending on what makes most sense; the underlying "single source of truth" does not have to be, because you're not supposed to be looking at it in the first place (beyond exceptional situations, similar to when you'd be looking at the object code produced by the compiler).
Expressiveness is a feature, but the more you try to express in fixed space, the harder it becomes to comprehend it. The solution is to stop trying to express everything all at once!
N.b. makes me think of a recent exchange I had on HN; people point out that code is like a blueprint in civil engineering/construction - but then, in those fields there is never a single common blueprint being worked on. You have different documents for overall structure, different for material composition, hydrological studies, load analysis, plumbing, HVAC, electrical routing, etc. etd. Multiple perspectives on the same artifacts. You don't see them merge all that into a single "uber blueprint", which would be the equivalent of how software engineers work with code.
See also 'no-code', 4GLs, 5GLs, etc etc etc. Every decade or so, the marketers find a new thing that will destroy programming forever.
But I just couldn't handle it when I got into like COMP102 and in the first lecture, the lecturer is all "has anybody not used the internet before?"
I spent my childhood doing the stuff so I just had to bail. I'm sure others would find it rewarding (particularly those that were in my classes because 'a computer job is a good job for money').
I.e. the very species we try to limit our contact with, which is why we chose this particular field of work? Or are you from the generation that joined software for easy money? :).
/s, but only partially.
There are aspects of this work where to "engage with my coworkers" is to be doing the exact opposite of productive work.
It would be helpful if I had a long rambling dialogue with a chat model and it distilled that.
IME this can work pretty well with Gemini in the web UI. If it misinterprets you at any stage you can edit your last comment until it gets on the same page, so to speak. Then once you're to a point in the conversation where you're satisfied it seems to "get it", you can drop in some more directly relevant context like example code if needed and ask for what you want.
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.
Another approach is Ill dictate how an api SHOULD work, or even go nuclear and write code i want to work, and tell the they must make the test pass and cant change what i wrote. They take these constraints well ime.
## Instructions
* Be concise
* Use simple sentences. But feel free to use technical jargon.
* Do NOT overexplain basic concepts. Assume the user is technically proficient.
* AVOID flattering, corporate-ish or marketing language. Maintain a neutral viewpoint.
* AVOID vague and / or generic claims which may seem correct but are not substantiated by the the context.
Assuming it is fact checked, why?
As I say, keep your slop in your own trough.
The only argument is that it improves the style of writing.
But I am in an ESL environment and no one cares about that.
Even otherwise why would anyone want to read a decompressed version instead of the "prompt" itself?
It praised so many things that I would just consider table steaks and made simple tweaks or features sound like massive projects.
I’m sure it could be improved by tweaking the prompt and there were parts of it that I found impressive that it had picked out (specifically things not in commit messages) but I found it unusable in its current form.
1. I shouldn't have used a newly created repo that had no real work over the course of the last week.
2. I should have put more time into the prompt to make it sound less nails on chalkboard.
1) This was supposed to be piped through TTS and listened to in the background, and...
2) People like podcasts.
Your typical podcast is much worse than this. It's "blah blah" and "hahaha <interaction>" and "ooh <emoting>" and "<irrelevant anecdote>" and "<turning facts upside down and injecting a lie for humorous effect>", and maybe some of the actual topic mixed in between, and yet for some reason, people love it.
I honestly doubt this specific thing would be useful for me, but I'm not going to assume it's plain dumb, because again, podcasts are worse, and people love it.
They aren't all Joe Rogan.
Unless of course people talking in any capacity is human interaction sounds, in which case, yes, every podcast is > 90% human interaction sounds.
> Unless of course people talking in any capacity is human interaction sounds, in which case, yes, every podcast is > 90% human interaction sounds.
No, I specifically mean all the thing that is not content - hellos, jokes, emoting, interrupting, exchanging filler commentary, etc. It may add character to the show, but from the POV of efficiently summarizing a topic, it's fundamentally even worse than the enterprisey BS fluff in the example in question.
I suppose preferences differ, but really, does anyone _like_ this sort of writing style?
Even Gemini/gpt4o/etc are all guilty of this. Maybe they'll tighten things up at some point - if I ask an assistant a simple question like "is it possible to put apples into a pie?" what I want is "Yes, it is possible to put apples into a pie. Would you like to know more?"
But not "Yes, absolutely — putting apples into a pie is not only possible, it's classic! Apple pie is one of the most well-known and traditional fruit pies. Typically, sliced apples are mixed with sugar, cinnamon, nutmeg, and sometimes lemon juice or flour, then baked inside a buttery crust. You can use various types of apples depending on the flavor and texture you want (like Granny Smith for tartness or Honeycrisp for sweetness). Would you like a recipe or tips on which apples work best?" (from gpt4).
Wow yeah what a waste. That is exactly the opposite of saving time.
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.
I objected to the '[...] and nobody is financially invested in software from AI anymore.' That's a rather dubious claim of a universal consequence for a change that only affects the US.
If the comment was 'I can't wait until Section 174 changes are repealed and nobody in the US is financially invested in software from AI anymore.' I would have nothing to complain about.
To critique the content more specifically and explicitly, and not just the form: people and companies all around the world have plenty of incentives to invest in AI. A tax change in the US might change the incentives in the US slightly. But it won't have much of an impact on the incentives in Europe, China, etc.
And even in the US, even with that suggested tax change, I doubt it'll lead to 'nobody [in the US being] financially invested in software from AI anymore.'
Basically, the original comment was hyperbole at best and BS at worst.
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.
Learning comes from grinding and LLMs are the ultimate anti-intellectual-grind machines. Which is great for when you're not trying to learn a skill!
That's just one use though. The other is treating it like it's a jr developer, which has its own shift in thinking. Practice in writing details specs goes a long way here.
> Practice in writing details specs goes a long way here.
This is an additional asymmetric advantage to more senior engineers as they use these tools
Says who? While “grinding” is one way to learn something, asking AI for a detailed explanation and actually consuming that knowledge with the intent to learn (rather than just copy and pasting) is another way.
Yes, you should be on guard since a lot of what it says can be false, but it’s still a great tool to help you learn something. It doesn’t completely replace technical blogs, books, and hard earned experience, but let’s not pretend that LLMs, when used appropriately, don’t provide an educational benefit.
There is no learning by consumption (unfortunately, given how we mostly attempt to "educate" our youth).
I didn't say they don't or can't provide an educational benefit.
That's application. Then presumably you started deviating a little bit from exactly what the instructor was doing. Then you deviated more and more.
If you had the instructor just writing the code for every new deviation you wanted to build and you just had to mash the "Accept Edit" button, you would not have learned very effectively.
Consequence is you get a bunch of output that looks really good as long as you don't think about it (and they actively promotes not thinking about it) that you don't really understand, and that if you did dig into you'd realize is empty fluff or actively wrong.
It's worse than not learning, it's actively generating unthinking but palatable garbage that's the opposite of learning.
I'm not so sure; I get great results (learning) with them because I can nitpick what they give me, attempt to explain how I understand it and I pretty much always preface my prompts with "be critical and show me where I am wrong".
I've seen a junior use it to "learn", which was basically "How do I do $FOO in $LANGUAGE".
For that junior to turn into a senior who prompts the way I do, they need a critical view of their questions, not just answers.
I have experienced multiple instances of junior devs using llm outputs without any understanding.
When I look at the PR, it is immediately obvious.
I use these tools everyday to help accelerate. But I know the limitations and can look at the output to throw certain junk away.
I feel junior devs are using it not to learn but to try to just complete shit faster. Which doesn’t actually happen because their prompts suck and their understanding of the results is bad.
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 times of rapid disruption where extreme flexibility of thought is the killer skill.
Or maybe the whole senior/junior thing is a red herring and pure coding and tech skills are being deflated all across the board. Perhaps what is needed now is an entirely new skill set that we're only just starting to grasp.
I had a feeling today that I should really be managing multiple instances at once, because they’re currently so slow that there’s some “downtime”.
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 complexity.
As the ladder gets pulled up on new juniors, and the "fertile brains" of the few who do get a chance are wasted as they are actively encouraged to not learn anything and just let a computer algorithm do the thinking for them, ensuring they will never have a chance to become seniors themselves, who else will be left to fix the mess?
do webdev is still there??? yes there are just because you can "create" something that doesn't mean you knowledge able in that area
we literally have entire industry created to fix wordpress instance + code, what do you else we need to worry for
One definition of experience[0] is:
direct observation of or participation in events as a basis of knowledge
One might as well assert an MS-Word document template can produce a novel Shakespearean play or that a spreadsheet is an IRS auditor.
> Or maybe the whole senior/junior thing is a red herring and pure coding and tech skills are being deflated all across the board. Perhaps what is needed now is an entirely new skill set that we're only just starting to grasp.
For a repudiation of this hypothesis, see this post[1] also currently on HN.
0 - https://www.merriam-webster.com/dictionary/experience
1 - https://blog.miguelgrinberg.com/post/why-generative-ai-codin...
I don't really get this, at the beginning of my career I masquaraded as a senior dev with experience as fast as I could until it was laundered into actual experience
Form the LLC and that's your prior professional experience, working for it
I felt I needed to do that and that was way before generative AI, like at least a decade
Hmm no news about that really
Oh, it's worse than that. You do that, and they complain that they are underpaid and should earn much, much more. They also think they are great, it's just you, the old-timer, that "doesn't get it". You invest lots of time to work with them, train them, and teach them how to work with your codebase.
And then they quit because the company next door offered them slightly more money and the job was easier, too.
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 are waking up to the realities of what an LLM can and can't do, and it's turning out to not be the genie in the bottle that a lot of hype was suggesting. Same as crypto.
The tech world needs a hype machine and "AI" is the current darling. Movie streaming was once in the spotlight too. "AI" will get old pretty soon if it can't stop "hallucinating". Trust me I would know if a junior dev is hallucinating and if they actually are then I can choose another one that won't and will actually become a great software developer. I have no such hope for LLMs based on my experiences with them so far.
A lot of the application layer will disappear when it fails to show ROI, but the foundation models will continue to have obscene amounts of money dumped into them, and the coding use case will come along with that.
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.
Every wizard was once a noob. No one is born that way, they were forged. It's in everybody's interest to train them. If they leave, you still benefit from the other companies who trained them, making the cost equal. Though if they leave, there's probably better ways to make them stay that you haven't considered (e.g. have you considered not paying new juniors more than your current junior that has been with the company for a few years? They should be able to get a pay bump without leaving)
the same way we treat it like human making mistake??? AI cant code themselves, someone command them to create something
1) There is no universal rule for anything. It doesn't have to apply to every single case. No one is saying a startup needs to hire juniors. No one is saying you have to hire only juniors. We haven't even talked about the distribution tbh. That's very open to interpretation because it is implicit that you will have to modify that based on your context.
2) Lots of big companies still act like they're startups. You're right, that short term "the math" doesn't work out. But it does on the medium and long term. So basically as long as you aren't working at the bootstrapping stage of a startup, you want to start considering this. Different distributions for different stages, of course.
But you shouldn't sacrifice long term rewards for short term ones. You are giving up larger rewards...
Try telling that to companies with quarterly earnings. Very few resist the urge to optimize for the short term.
> Try telling that to companies with quarterly earnings.
Just make sure you talk to Claude in addition to the humans and not instead of.
On the other hand, every time people are just spinning off sub-agents I am reminded of this: https://www.lesswrong.com/posts/kpPnReyBC54KESiSn/optimality...
It's simultaneously the obvious next step and portends a potentially very dangerous future.
As it has been over three years ago, when that was originally published.
I'm continuously surprised both by how fast the models themselves evolve, and how slow their use patterns are. We're still barely playing with the patterns that were obvious and thoroughly discussed back before GPT-4 was a thing.
Right now, the whole industry is obsessed with "agents", aka. giving LLMs function calls and limited control over the loop they're running under. How many years before the industry will get to the point of giving LLMs proper control over the top-level loop and managing the context, plus an ability to "shell out" to "subagents" as a matter of course?
When/if the underlying model gets good enough to support that pattern. As an extreme example, you aren't ever going to make even a basic agent with GPT-3 as the base model, the juice isn't worth the squeeze.
Models have gotten way better and I'm now convinced (new data -> new opinion) that they are a major win for coding, but they still need a lot, a lot of handholding, left to their own devices they just make a mess.
The underlying capabilities of the model are the entire ballgame, the "use patterns" aren't exactly rocket science.
> ${SUGESTION}
And recognized it wouldn't do anything because of a typo? Alas, my kind is not long for this world...
I got Claude Code (With CLine and VSCode) to do a task for a personal project. It did it about 5x faster than i'd have been able to do manually including running bash commands e.g. to install dependencies for new npm packages.
These things can do real work. If you have things in plain text format like markdown, csv spreadsheets etc, alot of what normal human employees do today could be somewhat automated.
You currently still need a human to supervise the agent and what its doing, but that won't be needed anymore in the not so distant future.