[HN Gopher] A few random notes from Claude coding quite a bit la...
___________________________________________________________________
A few random notes from Claude coding quite a bit last few weeks
https://xcancel.com/karpathy/status/2015883857489522876
Author : bigwheels
Score : 180 points
Date : 2026-01-26 21:09 UTC (1 days ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| nadis wrote:
| The section on IDEs/agent swarms/fallibility resonated a lot for
| me; I haven't gone quite as far as Karpathy in terms of power
| usage of Claude Code, but some of the shifts in mistakes (and
| reality vs. hype) analysis he shared seems spot on in my (caveat:
| more limited) experience.
|
| > "IDEs/agent swarms/fallability. Both the "no need for IDE
| anymore" hype and the "agent swarm" hype is imo too much for
| right now. The models definitely still make mistakes and if you
| have any code you actually care about I would watch them like a
| hawk, in a nice large IDE on the side. The mistakes have changed
| a lot - they are not simple syntax errors anymore, they are
| subtle conceptual errors that a slightly sloppy, hasty junior dev
| might do. The most common category is that the models make wrong
| assumptions on your behalf and just run along with them without
| checking. They also don't manage their confusion, they don't seek
| clarifications, they don't surface inconsistencies, they don't
| present tradeoffs, they don't push back when they should, and
| they are still a little too sycophantic. Things get better in
| plan mode, but there is some need for a lightweight inline plan
| mode. They also really like to overcomplicate code and APIs, they
| bloat abstractions, they don't clean up dead code after
| themselves, etc. They will implement an inefficient, bloated,
| brittle construction over 1000 lines of code and it's up to you
| to be like "umm couldn't you just do this instead?" and they will
| be like "of course!" and immediately cut it down to 100 lines.
| They still sometimes change/remove comments and code they don't
| like or don't sufficiently understand as side effects, even if it
| is orthogonal to the task at hand. All of this happens despite a
| few simple attempts to fix it via instructions in CLAUDE . md.
| Despite all these issues, it is still a net huge improvement and
| it's very difficult to imagine going back to manual coding. TLDR
| everyone has their developing flow, my current is a small few CC
| sessions on the left in ghostty windows/tabs and an IDE on the
| right for viewing the code + manual edits."
| shawabawa3 wrote:
| It's been a bit like the boiling frog analogy for me
|
| I started by copy pasting more and more stuff in chatgpt. Then
| using more and more in-IDE prompting, then more and more agent
| tools (Claude etc). And suddenly I realise I barely hand code
| anymore
|
| For sure there's still a place for manual coding, especially
| schemas/queries or other fiddly things where a tiny mistake gets
| amplified, but the vast majority of "basic work" is now just
| prompting, and honestly the code quality is _better_ that it was
| before, all kinds of refactors I didn't think about or couldn't
| be bothered with have almost automatically
|
| And people still call them stochastic parrots
| phailhaus wrote:
| > And people still call them stochastic parrots
|
| Both can be true. You're tapping into every line of code
| publicly available, and your day-to-day really isn't that
| unique. They're really good at this kind of work.
| ed_mercer wrote:
| I find myself even for small work, telling CC to fix it for me
| is better as it usually belongs to a thread of work, and then
| it understands the big picture better.
| Macha wrote:
| I've had the opposite experience, it's been a long time
| listening to people going "It's really good now" before it
| developed to a permutation that was actually worth the time to
| use it.
|
| ChatGPT 3.5/4 (2023-2024): The chat interface was verbose and
| clunky and it was just... wrong... like 70+% of the time. Not
| worth using.
|
| CoPilot autocomplete and Gitlab Duo and Junie (late 2024-early
| 2025): Wayyy too aggressive at guessing exactly what I wasn't
| doing and hijacked my tab complete when pre-LLM type-tetris
| autocomplete was just more reliable.
|
| Copilot Edit/early Cursor (early 2025): Ok, I can sort of see
| uses here but god is picking the right files all the time such
| a pain as it really means I need to have figured out what I
| wanted to do in such detail already that what was even the
| point? Also the models at that time just quickly descended into
| incoherency after like three prompts, if it went off track good
| luck ever correcting it.
|
| Copilot Agent mode / Cursor (late 2025): Ok, great, if the
| scope is narrowly scoped, and I'm either going to write the
| tests for it or it's refactoring existing code it could do
| something. Like something mechanical like the library has a
| migration where we need to replace the use of methods A/B/C and
| replace them with a different combination of X/Y/Z. great, it
| can do that. Or like CRUD controller #341. I mean, sure, if my
| boss is going to pay for it, but not life changing.
|
| Zed Agent mode / Cursor agent mode / Claude code (early 2026):
| Finally something where I can like describe the architecture
| and requirements of a feature, let it code, review that code,
| give it written instructions on how to clean it up / refactor /
| missing tests, and iterate.
|
| But that was like 2 years of "really it's better and
| revolutionary now" before it actually got there. Now maybe in
| some languages or problem domains, it was useful for people
| earlier but I can understand people who don't care about "but
| it works now" when they're hearing it for the sixth time.
|
| And I mean, what one hand gives the other takes away. I have a
| decent amount of new work dealing with MRs from my coworkers
| where they just grabbed the requirements from a stakeholder,
| shoved it into Claude or Cursor and it passed the existing
| tests and it's shipped without much understanding. When they
| wrote them themselves, they tested it more and were more
| prepared to support it in production...
| Madmallard wrote:
| Are game developers vibe coding with agents?
|
| It's such a visual and experiential thing that writing true
| success criteria it can iterate on seems like borderline
| impossible ahead of time.
| redox99 wrote:
| Vibe coding in Unreal Engine is of limited use. It obviously
| helps with C++, but so much of your time is doing things that
| are not C++. It hurts a lot that UE relies heavily on
| blueprints, if they were code you could just vibecode a lot of
| that.
| 20260126032624 wrote:
| I don't "vibe code" but when I use an LLM with a game I usually
| branch out into several experiments which I don't have to
| commit to. Thus, it just makes that iteration process go
| faster.
|
| Or slower, when the LLM doesn't understand what I want, which
| is a bigger issue when you spawn experiments from scratch (and
| have given limited context around what you are about to do).
| TheGRS wrote:
| I'm trying it out with Godot for my little side projects. It
| can handle writing the GUI files for nodes and settings. The
| workflow is asking cursor to change something, I review the
| code changes, then load up the game in Godot to check out the
| changes. Works pretty well. I'm curious if any Unity or Unreal
| devs are using it since I'm sure its a similar experience.
| rschick wrote:
| Great point about expansion vs speedup. I now have time to build
| custom tools, implement more features, try out different API
| designs, get 100% test coverage.. I can deliver more quickly, but
| can also deliver more overall.
| jopsen wrote:
| > - How much of society is bottlenecked by digital knowledge
| work?
|
| Any qualified guesses?
|
| I'm not convinced more traders on wall street will allocate
| capital more effectively leading to economic growth.
|
| Will more programmers grow the economy? Or should we get real
| jobs ;)
| iwontberude wrote:
| Most of this countries challenges are strictly political. The
| pittance of work software can contribute is most likely
| negligible or destructive (e.g. software buttons in cars or
| palantir). In other words were picked all the low hanging fruit
| and all that left is to hang ourselves.
| js8 wrote:
| I actually disagree. Having software (AI) that can cut
| through the technological stuff faster will make people more
| aware of political problems.
| iwontberude wrote:
| edit: country's* all that is left*
| cyanydeez wrote:
| So I'm curious, whats the actual quality control.
|
| Like, do these guys actually dog food real user experience, or
| are they all admins with the fast lane to the real model while
| everyone outside the org has to go through the 10 layers of model
| sheding, caching and other means and methods of saving money.
|
| We all know these models are expensive as fuck to run and these
| companies are degrading service, A+B testing, and the rest. Do
| they actually ponder these things directly?
|
| Just always seems like people are on drugs when they talk about
| the capabilities, and like, the drugs could be pure shit (good)
| or ditch weed, and we call just act like the pipeline for drugs
| is a consistent thing but it's really not, not at this stage
| where they're all burning cash through infrastructure.
| Definitely, like drug dealers, you know they're cutting the good
| stuff with low cost cached gibberish.
| bigwheels wrote:
| If you access a model through an openrouter provider it might
| be quantized (akin to being "cut with trash"), but when you go
| directly to Anthropic or OpenAI you are getting access to the
| same APIs as everyone else. Even top-brass folks within
| Microsoft use Anthropic and OpenAI proper (not worth the red-
| tape trouble to go directly through Azure). Also, the creator
| and maintainer of Claude, Boris Cherny, was a bit of an oddball
| but one of the comparatively nicer people at Anthropic, and he
| indicated he primarily uses the same Anthropic APIs as everyone
| else (which makes sense from a product development
| perspective).
|
| The underlying models are all actually really undifferentiated
| under the covers except for the post-training and base prompts.
| If you eliminate the base prompts the models behave near
| identically.
|
| A conspiracy would be a helluva lot more interesting and fun,
| but I've spoken to these folks firsthand and it seems they
| already have enough challenges keeping the beast running.
| quinnjh wrote:
| > Definitely, like drug dealers, you know they're cutting the
| good stuff with low cost cached gibberish.
|
| Can confirm. My partner's chatGPT wouldnt return anything
| useful for her given a specific query involving web use, while
| i got the desired result sitting side by side. She contacted
| support and they said nothing they can do about it, her account
| is in an A/B test group without some features removed. I
| imagine this saves them considerable resources despite still
| billing customers for them.
|
| how much this is occurring is anyones guess
| atonse wrote:
| > LLM coding will split up engineers based on those who primarily
| liked coding and those who primarily liked building.
|
| I've always said I'm a builder even though I've also enjoyed
| programming (but for an outcome, never for the sake of the code)
|
| This perfectly sums up what I've been observing between people
| like me (builders) who are ecstatic about this new world and
| programmers who talk about the craft of programming, sometimes
| butting heads.
|
| One viewpoint isn't necessarily more valid, just a difference of
| wiring.
| jimbokun wrote:
| The new LLM centered workflow is really just a management job
| now.
|
| Managers and project managers are valuable roles and have
| important skill sets. But there's really very little connection
| with the role of software development that used to exist.
|
| It's a bit odd to me to include both of these roles under a
| single label of "builders", as they have so little in common.
|
| EDIT: this goes into more detail about how coding (and soon
| other kinds of knowledge work) is just a management task now:
| https://www.oneusefulthing.org/p/management-as-ai-superpower...
| simianwords wrote:
| i don't disagree. at some point LLM's might become good
| enough that we wouldn't need exact technical expertise.
| ryandrake wrote:
| I noticed the same thing, but wasn't able to put it into words
| before reading that. Been experimenting with LLM-based coding
| just so I can understand it and talk intelligently about it
| (instead of just being that grouchy curmudgeon), and the
| thought in the back of my mind while using Claude Code is
| always:
|
| "I got into programming because I like programming, not
| whatever this is..."
|
| Yes, I'm building stupid things faster, but I didn't get into
| programming because I wanted to build tons of things. I got
| into it for the thrill of defining a problem in terms of data
| structures and instructions a computer could understand,
| entering those instructions into the computer, and then
| watching victoriously while those instructions were executed.
|
| If I was intellectually excited about telling something to do
| this for me, I'd have gotten into management.
| atonse wrote:
| Funny you say that. Because I have never enjoyed management
| as much as being hands on and directly solving problems.
|
| So maybe our common ground is that we are direct problem
| solvers. :-)
| polishdude20 wrote:
| What I have enjoyed about programming is being able to get
| the computer to do exactly what I want. The possibilities are
| bounded by only what I can conceive in my mind. I feel like
| with AI that can happen faster.
| testaccount28 wrote:
| > get the computer to do exactly what I want.
|
| > with AI that can happen faster.
|
| well, not _exactly_ that.
| viccis wrote:
| Same. This kind of coding feels like it got rid of the
| building aspect of programming that always felt nice, and it
| replaced it entirely with business logic concerns, product
| requirements, code reviews, etc. All the stuff I can
| generally take or leave. It's like I'm always in a meeting.
|
| >If I was intellectually excited about telling something to
| do this for me, I'd have gotten into management.
|
| Exactly this. This is the simplest and tersest way of
| explaining it yet.
| verdverm wrote:
| I think the division is more likely tied to writing. You have
| to fundamentally change how you do your job, from one of
| writing a formal language for a compiler to one of writing
| natural language for a junior-goldfish-memory-allstar-
| developer, closer to management then to contributor.
|
| This distinction to me separates the two primary camps
| addisonj wrote:
| IMO, this isn't entirely a "new world" either, it is just a new
| domain where the conversation amplifies the opinions even more
| (weird how that is happening in a lot of places)
|
| What I mean by that: you had compiled vs interpreted languages,
| you had types vs untyped, testing strategies, all that, at
| least in some part, was a conversation about the tradeoffs
| between moving fast/shipping and maintainability.
|
| But it isn't just tech, it is also in methodologies and the
| words use, from "build fast and break things" and "yagni" to
| "design patterns" and "abstractions"
|
| As you say, it is a different viewpoint... but my biggest
| concern with where are as industry is that these are not just
| "equally valid" viewpoints of how to build software... it is
| quite literally different stages of software, that, AFAICT,
| pretty much all successful software has to go through.
|
| Much of my career has been spent in teams at companies with
| products that are undergoing the transition from "hip app built
| by scrappy team" to "profitable, reliable software" and it is
| _painful_. Going from something where you have 5 people who
| know all the ins and outs and can fix serious bugs or ship
| features in a few days to something that has easy clean
| boundaries to scale to 100 engineers of a wide range of
| familiarities with the tech, the problem domain, skill levels,
| and opinions is just really hard. I am not convinced yet that
| AI will solve the problem, and I am also unsure it doesn 't
| risk making it worse (at least in the short term)
| dpflan wrote:
| """
|
| Much of my career has been spent in teams at companies with
| products that are undergoing the transition from "hip app
| built by scrappy team" to "profitable, reliable software" and
| it is painful. Going from something where you have 5 people
| who know all the ins and outs and can fix serious bugs or
| ship features in a few days to something that has easy clean
| boundaries to scale to 100 engineers of a wide range of
| familiarities with the tech, the problem domain, skill
| levels, and opinions is just really hard. I am not convinced
| yet that AI will solve the problem, and I am also unsure it
| doesn't risk making it worse (at least in the short term)
|
| """
|
| This perspective is crucial. Scale is the great equalizer /
| demoralizer, scale of the org and scale of the systems.
| Systems become complex quickly, and verifiability of
| correctness and function becomes harder. Companies that built
| from day with AI and have AI influencing them as they scale,
| where does complexity begin to run up against the limitations
| of AI and cause regression? Or if all goes well,
| amplification?
| slaymaker1907 wrote:
| I enjoy both and have ended up using AI a lot differently than
| vibe coders. I rarely use it for generating implementations,
| but I use it extensively for helping me understand docs/apis
| and more importantly, for debugging. AI saves me so much time
| trying to figure out why things aren't working and in code
| review.
|
| I deliberately avoid full vibe coding since I think doing so
| will rust my skills as a programmer. It also really doesn't
| save much time in my experience. Once I have a design in mind,
| implementation is not the hard part.
| mkozlows wrote:
| I think he's really getting at something there. I've been
| thinking about this a lot (in the context of trying to
| understand the persistent-on-HN skepticism about LLMs), and the
| framing I came up with[1] is top-down vs. bottom-up dev styles,
| aka architecting code and then filling in implementations, vs.
| writing code and having architecture evolve.
|
| [1] https://www.klio.org/theory-of-llm-dev-skepticism/
| Imustaskforhelp wrote:
| > I enjoy both and have ended up using AI a lot differently
| than vibe coders. I rarely use it for generating
| implementations, but I use it extensively for helping me
| understand docs/apis and more importantly, for debugging. AI
| saves me so much time trying to figure out why things aren't
| working and in code review.
|
| I had felt like this and still do but man, at some point, I
| feel like the management churn feels real & I just feel
| suffering from a new problem.
|
| Suppose, I actually end up having services literally deployed
| from a single prompt nothing else. Earlier I used to have AI
| write code but I was interested in the deployment and
| everything around it, now there are services which do that
| really neatly for you (I also really didn't give into the agent
| hype and mostly used browsers LLM)
|
| Like on one hand you feel more free to build projects but the
| whole joy of project _completely_ got reduced.
|
| I mean, I guess I am one of the junior dev's so to me AI
| writing code on topics I didn't know/prototyping felt awesome.
|
| I mean I was still involved in say copy pasting or looking at
| the code it generates. Seeing the errors and sometimes trying
| things out myself. If AI is doing all that too, idk
|
| For some reason, recently I have been disinterested in AI. I
| have used it quite a lot for prototyping but I feel like this
| _complete_ out of the loop programming just very off to me with
| recent services.
|
| I also feel like there is this sense of if I buy for some AI
| thing, to maximally extract "value" out of it.
|
| I guess the issue could be that I can have vague terms or have
| a very small text file as input (like just do X alternative in
| Y lang) and I am now unable to understand the architectural
| decisions and the overwhelmed-ness out of it.
|
| Probably gonna take either spec-driven development where I
| clearly define the architecture or development where I saw
| something primagen do recently which is that the AI will only
| manipulate code of that particular function, (I am imagining it
| for a file as well) and somehow I feel like its something that
| I could enjoy more because right now it feels like I don't know
| what I have built at times.
|
| When I prototype with single file projects using say browser
| for funsies/any idea. I get some idea of what the code kind of
| uses with its dependencies and functions names from start/end
| even if I didn't look at the middle
|
| A bit of ramble I guess but the thing which kind of is making
| me feel this is that I was talking to somebody and shwocasing
| them some service where AI + server is there and they asked for
| something in a prompt and I wrote it. Then I let it do its job
| but I was also thinking how I would architect it (it was some
| detect food and then find BMR, and I was thinking first to use
| any api but then I thought that meh it might be hard, why not
| use AI vision models, okay what's the best, gemini seems
| good/cheap)
|
| and I went to the coding thing to see what it did and it
| actually went even beyond by using the free tier of gemini
| (which I guess didn't end up working could be some rate limit
| of my own key but honestly it would've been the thing I
| would've tried too)
|
| So like, I used to pride myself on the architectural decisions
| I make even if AI could write code faster but now that is taken
| away as well.
|
| I really don't want to read AI code so much so honestly at this
| point, I might as well write code myself and learn hands on but
| I have a problem with build fast in public like attitude that I
| have & just not finding it fun.
|
| I feel like I should do a more active job in my projects & I am
| really just figuring out what's the perfect way to use AI in
| such contexts & when to use how much.
|
| Thoughts?
| coffeeaddict1 wrote:
| But how can you be a responsible builder if you don't have
| trust in the LLMs doing the "right thing"? Suppose you're the
| head of a software team where you've picked up the best
| candidates for a given project, in that scenario I can see how
| one is able to _trust_ the team members to orchestrate the
| implementation of your ideas and intentions, with you not being
| intimately familiar with the details. Can we place the same
| trust in LLM agents? I 'm not sure. Even if one could somehow
| prove that LLM are very reliable, the fact an AI agents aren't
| _accountable_ beings renders the whole situation vastly
| different than the human equivalent.
| inerte wrote:
| You don't simply put a body in a seat and get software. There
| are entire systems enabling this trust: college, resume,
| samples, referral, interviews, tests and CI, monitoring,
| mentoring, and performance feedback.
|
| And accountability can still exist? Is the engineer that
| created or reviewed a Pull Request using Claude Code less
| accountable then one that used PICO?
| coffeeaddict1 wrote:
| > And accountability can still exist? Is the engineer that
| created or reviewed a Pull Request using Claude Code less
| accountable then one that used PICO?
|
| The point is that in the human scenario, you can hold the
| human agents accountable. You cannot do that with AI. Of
| course, you as the orchestrator of agents will be
| accountable to someone, but you won't have the benefit of
| holding your "subordinates" accountable, which is what you
| do in a human team. IMO, this renders the whole situation
| vastly different (whether good or bad I'm not sure).
| polishdude20 wrote:
| You can switch to another LLM provider or stop using them
| altogether. It's even easier than firing a developer.
| ipaddr wrote:
| It is as easy as getting rid of Microsoft Teams at your
| org.
| senderista wrote:
| Maybe there's an intermediate category: people who like
| designing software? I personally find system design more
| engaging than coding (even though I enjoy coding as well).
| That's different from just producing an opaque artifact that
| seems to solve my problem.
| vibeprofessor wrote:
| The AGI vibes with Claude Code are real, but the micromanagement
| tax is heavy. I spend most of my time babysitting agents.
|
| I expect interviews will evolve into "build project X with an LLM
| while we watch" and audit of agent specs
| 0xy wrote:
| Sounds great to me. Leetcode is outdated and heavily abused by
| people who share the questions ahead of time in various forums
| and chats.
| thefourthchime wrote:
| From what I've heard, what few interviews there are for
| software engineers these days, they do have you use models and
| see how quickly you can build things.
| iwontberude wrote:
| The interviews I've given have asked about how control for AI
| slop without hurting your colleagues feelings. Anyone can
| prompt and build, the harder part, as usual for business, is
| knowing how and when to say, 'no.'
| maxdo wrote:
| I've been doing vibe code interviews for nearly a year now.
| Most people are surprisingly bad with AI tools. We specifically
| ask them to bring their preferred tool, yet 20-30% still just
| copy-paste code from ChatGPT.
|
| fun stats: corelation is real, people who were good at vibe
| code, also had offer(s) with other companies that didn't run
| vibe code interviews.
| bflesch wrote:
| Interesting you say that, feels like when people were too
| stupid to google things and "googling something" was a skill
| that some had and others didn't.
| onetimeusename wrote:
| > the ratio of productivity between the mean and the max
| engineer? It's quite possible that this grows *a lot*
|
| I have a professor who has researched auto generated code for
| decades and about six months ago he told me he didn't think AI
| would make humans obsolete but that it was like other incremental
| tools over the years and it would just make good coders even
| better than other coders. He also said it would probably come
| with its share of disappointments and never be fully autonomous.
| Some of what he said was a critique of AI and some of it was just
| pointing out that it's very difficult to have perfect code/specs.
| slfreference wrote:
| I can sense two classes of coders emerging.
|
| Billionaire coder: a person who has "written" billion lines.
|
| Ordinary coders : people with only couple of thousands to their
| git blame.
| fishtoaster wrote:
| > if you have any code you actually care about I would watch them
| like a hawk, in a nice large IDE on the side.
|
| This is about where I'm at. I love pure claude code for code I
| don't care about, but for anything I'm working on with other
| people I need to audit the results - which I much prefer to do in
| an IDE.
| porise wrote:
| I wish the people who wrote this let us know what king of
| codebases they are working on. They seem mostly useless in a
| sufficiently large codebase especially when they are messy and
| interactions aren't always obvious. I don't know how much better
| Claude is than ChatGPT, but I can't get ChatGPT to do much useful
| with an existing large codebase.
| Okkef wrote:
| Try Claude code. It's different.
|
| After you tried it, come back.
| Imustaskforhelp wrote:
| I think its not Claude code per se itself but rather the
| (Opus 4.5 model?) or something in an agentic workflow.
|
| I tried a website which offered the Opus model in their
| agentic workflow & I felt something _different_ too I guess.
|
| Currently trying out Kimi code (using their recent kimi 2.5)
| for the first time buying any AI product because got it for
| like 1.49$ per month. It does feel a bit less powerful than
| claude code but I feel like monetarily its worth it.
|
| Y'know you have to like bargain with an AI model to reduce
| its pricing which I just felt really curious about. The
| psychology behind it feels fascinating because I think even
| as a frugal person, I already felt invested enough in the
| model and that became my sunk cost fallacy
|
| Shame for me personally because they use it as a hook to get
| people using their tool and then charge next month 19$ (I
| mean really Cheaper than claude code for the most part but
| still comparative to 1.49$)
| maxdo wrote:
| chatGPT is not made to write code. Get out of stone age :)
| CameronBanga wrote:
| This is an antidotal example, but I released this last week
| after 3 months of work on it as a "nights and weekdends"
| project: https://apps.apple.com/us/app/skyscraper-for-
| bluesky/id67541...
|
| I've been working in the mobile space since 2009, though
| primarily as a designer and then product manager. I work in
| kinda a hybrid engineering/PM job now, and have never been a
| particularly strong programmer. I definitely wouldn't have
| thought I could make something with that polish, let alone in 3
| months.
|
| That code base is ~98% Claude code.
| bee_rider wrote:
| I don't know if "antidotal example" is a pun or a typo but I
| quite like it.
| oasisbob wrote:
| That is fun.
|
| Not sure if it's an American pronunciation thing, but I had
| to stare at that long and hard to see the problem and even
| after seeing it couldn't think of how you could possibly
| spell the correct word otherwise.
| CameronBanga wrote:
| Lol typing on my phone during lunch and meant anecdotal.
| But let's leave it anyways. :)
| TaupeRanger wrote:
| Claude and Codex are CLI tools you use to give the LLM context
| about the project on your local machine or dev environment. The
| fact that you're using the name "ChatGPT" instead of Codex
| leads me to believe you're talking about using the web-based
| ChatGPT interface to work on a large codebase, which is
| completely beside the point of the entire discussion. That's
| not the tool anyone is talking about here.
| danielvaughn wrote:
| It's important to understand that he's talking about a specific
| set of models that were release around november/december, and
| that we've hit a kind of inflection point in model
| capabilities. Specifically Anthropic's Opus 4.5 model.
|
| I never paid any attention to different models, because they
| all felt roughly equal to me. But Opus 4.5 is really and truly
| different. It's not a qualitative difference, it's more like it
| just finally hit that quantitative edge that allows me to lean
| much more heavily on it for routine work.
|
| I highly suggest trying it out, alongside a well-built coding
| agent like the one offered by Claude Code, Cursor, or OpenCode.
| I'm using it on a fairly complex monorepo and my impressions
| are much the same as Karpathy's.
| tunesmith wrote:
| If you have a ChatGPT account, there's nothing stopping you
| from installing codex cli and using your chatgpt account with
| it. I haven't coded with ChatGPT for weeks. Maybe a month ago I
| got utility out of coding with codex and then having ChatGPT
| look at my open IDE page to give comments, but since 5.2 came
| out, it's been 100% codex.
| spaceman_2020 wrote:
| I'm afraid that we're entering a time when the performance
| difference between the really cutting edge and even the three-
| month-old tools is vast
|
| If you're using plain vanilla chatgpt, you're woefully,
| woefully out of touch. Heck, even plain claude code is now
| outdated
| shj2105 wrote:
| Why is plain Claude code outdated? I thought that's what most
| people are using right now that are AI forward. Is it Ralph
| loops now that's the new thing?
| spaceman_2020 wrote:
| Plain Claude Code doesn't have enough scaffolding to handle
| large projects
|
| At a base level, people are "upgrading" their Claude Code
| with custom skills and subagents - all text files saved in
| .claude/agents|skills.
|
| You can also use their new tasks primitive to basically run
| a Ralph-like loop
|
| But at the edges, people are using multiple instances, each
| handling different aspects in parallel - stuff like Gas
| Town
|
| Tbf you can still get a lot of mileage out of vanilla
| Claude Code. But I've found that even adding a simple
| frontend design skill improves the output substantially
| ph4te wrote:
| I don't know how big sufficiently large codebase is, but we
| have a 1mil loc Java application, that is ~10years old, and
| runs POS systems, and Claude Code has no issues with it. We
| have done full analyses with output details each module, and
| also used it to pinpoint specific issues when described. Vibe
| coding is not used here, just analysis.
| keerthiko wrote:
| Almost always, notes like these are going to be about
| greenfield projects.
|
| Trying to incorporate it in existing codebases (esp when the
| end user is a support interaction or more away) is still folly,
| except for closely reviewed and/or non-business-logic
| modifications.
|
| That said, it is quite impressive to set up a simple
| architecture, or just list the filenames, and tell some agents
| to go crazy to implement what you want the application to do.
| But once it crosses a certain complexity, I find you need to
| prompt closer and closer to the weeds to see real results. I
| imagine a non-technical prompter cannot proceed past a certain
| prototype fidelity threshold, let alone make meaningful
| contributions to a mature codebase via LLM without a human
| engineer to guide and review.
| reubenmorais wrote:
| I'm using it on a large set of existing codebases full of
| extremely ugly legacy code, weird build systems, tons of
| business logic and shipping directly to prod at neckbreaking
| growth over the last two years, and it's delivering the same
| type of value that Karpathy writes about.
| 1123581321 wrote:
| These models do well changing brownfield applications that
| have tests because the constraints on a successful
| implementation are tight. Their solutions can be
| automatically augmented by research and documentation.
| jjfoooo4 wrote:
| That _was_ true for me, but is no longer.
|
| It's been especially helpful in explaining and understanding
| arcane bits of legacy code behavior my users ask about. I
| trigger Claude to examine the code and figure out how the
| feature works, then tell it to update the documentation
| accordingly.
| languid-photic wrote:
| They build Claude Code fully with Claude Code.
| Macha wrote:
| Which is equal parts praise and damnation. Claude Code does
| do a lot of nice things that people just kind of don't bother
| for time cost / reward when writing TUIs that they've
| probably only done because they're using AI heavily, but
| equally it has a lot of underbaked edges (like accidentally
| shadowing the user's shell configuration when it tries to
| install terminal bindings for shift-enter even though the
| terminal it's configuring already sends a distinct shift-
| enter result), and bugs (have you ever noticed it just stop,
| unfinished?).
| simianwords wrote:
| i haven't used Claude Code but come on.. it is a production
| level quality application used seriously by millions.
| bluGill wrote:
| I've been trying Claude on my large code base today. When I
| give it the requirements I'd give an engineer and so "do it" it
| just writes garbage that doesn't make sense and doesn't seem to
| even meet the requirements (if it does I can't follow how -
| though I'll admit to giving up before I understood what it did,
| and I didn't try it on a real system). When I forced it to step
| back and do tiny steps - in TDD write one test of the full
| feature - it did much better - but then I spent the next 5
| hours adjusting the code it wrote to meet our coding standards.
| At least I understand the code, but I'm not sure it is any
| faster (but it is a lot easier to see things wrong than come up
| with green field code).
|
| Which is to say you have to learn to use the tools. I've only
| just started, and cannot claim to be an expert. I'll keep using
| them - in part because everyone is demanding I do - but to use
| them you clearly need to know how to do it yourself.
| simonw wrote:
| Have you tried showing it a copy of your coding standards?
|
| I also find pointing it to an existing folder full of code
| that conforms to certain standards can work really well.
| bflesch wrote:
| Yeah let's share all your IP for the vague promise that it
| will somehow work ;)
| rob wrote:
| I've been playing around with the "Superpowers" [0] plugin in
| Claude Code on a new small project and really like it. Simple
| enough to understand quickly by reading the GitHub repo and
| seems to improve the output quality of my projects.
|
| There's basically a "brainstorm" /slash command that you go
| back and forth with, and it places what you came up with in
| docs/plans/YYYY-MM-DD-<topic>-design.md.
|
| Then you can run a "write-plan" /slash command on the
| docs/plans/YYYY-MM-DD-<topic>-design.md file, and it'll give
| you a docs/plans/YYYY-MM-DD-<topic>-implementation.md file
| that you can then feed to the "execute-plan" /slash command,
| where it breaks everything down into batches, tasks, etc, and
| actually implements everything (so three /slash commands
| total.)
|
| There's also "GET SHIT DONE" (GSD) [1] that I want to look
| at, but at first glance it seems to be a bit more involved
| than Superpowers with more commands. Maybe it'd be better for
| larger projects.
|
| [0] https://github.com/obra/superpowers
|
| [1] https://github.com/glittercowboy/get-shit-done
| smusamashah wrote:
| The code base I work on at $dayjob$ is legacy, has few files
| with 20k lines each and a few more with around 10k lines each.
| It's hard to find things and connect dots in the code base.
| Dont think LLMs able to navigate and understand code bases of
| that size yet. But have seen lots of seemingly large projects
| shown here lately that involve thousands of files and millions
| of lines of code.
| jumploops wrote:
| I've found that LLMs seem to work better on LLM-generated
| codebases.
|
| Commercial codebases, especially private internal ones, are
| often messy. It seems this is mostly due to the iterative
| nature of development in response to customer demands.
|
| As a product gets larger, and addresses a wider audience,
| there's an ever increasing chance of divergence from the
| initial assumptions and the new requirements.
|
| We call this tech debt.
|
| Combine this with a revolving door of developers, and you
| start to see Conway's law in action, where the system
| resembles the organization of the developers rather than the
| "pure" product spec.
|
| With this in mind, I've found success in using LLMs to
| refactor existing codebases to better match the current
| requirements (i.e. splitting out helpers, modularizing,
| renaming, etc.).
|
| Once the legacy codebase is "LLMified", the coding agents
| seem to perform more predictably.
|
| YMMV here, as it's hard to do large refactors without tests
| for correctness.
|
| (Note: I've dabbled with a test first refactor approach, but
| haven't gone to the lengths to suggest it works, but I
| believe it could)
| gwd wrote:
| For me, in just the golang server instance and the core
| functional package, `cloc` reports over 40k lines of code, not
| counting other supporting packages. I spent the last week
| having Claude rip out the external auth system and replace it
| with a home-grown one (and having GPT-codex review its
| changes). If anything, Claude makes it _easier_ on me as a solo
| founder with a large codebase. Rather than having to re-
| familiarize myself with code I wrote a year ago, I describe it
| at a high level, point Claude to a couple of key files, and
| then tell it to figure out what it needs to do. It can use
| grep, language server, and other tools to poke around and see
| what 's going on. I then have it write an "epic" in markdown
| containing all the key files, so that future sessions already
| know the key files to read.
|
| I really enjoyed the process. As TFA says, you have to keep a
| close eye on it. But the whole process was a lot less effort,
| and I ended up doing mor than I would otherwise have done.
| strogonoff wrote:
| LLM coding splits up engineers based on those who primarily like
| building and those who primarily like code reviews and quality
| assessment. I definitely don't love the latter (especially when
| reviewing decisions not made by a human with whom I can build
| long-term personal rapport).
|
| After certain experience threshold of making things from scratch,
| "coding" (never particularly liked that term) has always been 99%
| building, or _architecture_ , and I struggle to see how often a
| well-architected solution today, with modern high-level
| abstractions, requires so much code that you'd save significant
| time and effort by not having to just type, possibly with basic
| deterministic autocomplete, exactly what you mean (especially
| considering you would have to also spend time and effort
| reviewing whatever was typed for you if you used a non-
| deterministic autocomplete).
| OkayPhysicist wrote:
| See, I don't take it that extreme: LLMs make _fantastic_ ,
| never-before seen quality autocompletes. I hacked together a
| Neovim plugin that prompts an LLM to "finish this function" on
| command, and it's a big time save for the menial plumbing type
| operations. Think things like "this api I use expects JSON that
| encodes some subset of SQL, I want all the dogs with Ls in
| their name that were born on a Tuesday". Given an example of
| such API (or if the documentation ended up in its training),
| LLMs will consistently one-shot stuff like that.
|
| Asking it to do entire projects? Dumb. You end up with
| spaghetti, unless you hand-hold it to a point that you might as
| well be using my autocomplete method.
| DeathArrow wrote:
| >LLM coding will split up engineers based on those who primarily
| liked coding and those who primarily liked building.
|
| Quite insightful.
| jimbokun wrote:
| I'm pretty happy with Copilot in VS Code. Type what change I want
| Claude to make in the Copilot panel, and then use the VS Code in
| context diffs to accept or reject the proposed changes. While
| being able to make other small changes on my own.
|
| So I think this tracks with Karpathy's defense of IDEs still
| being necessary ?
|
| Has anyone found it practical to forgo IDEs almost entirely?
| maxdo wrote:
| Coplilot is not on par with cc or cursor even
| WA wrote:
| Why not? You can select Opus 4.5, Gemini 3 Pro, and others.
| spaceman_2020 wrote:
| Claude Code is a CLI tool which means it can do complete
| projects in a single command. Also has fantastic tools for
| scaffolding and harnessing the code. You can define
| everything from your coding style to specific instructions
| for designing frontpages, integrating payments, etc.
|
| It's not about the model. It's about the harness
| piker wrote:
| This would make some sense if VS Code didn't have a
| terminal built into it. The LLMs have the same bash
| capabilities in either form.
| binarycrusader wrote:
| _Claude Code is a CLI tool which means it can do complete
| projects in a single command_
|
| https://github.com/features/copilot/cli/
| maxdo wrote:
| it's not a model limit anymore, it's tools , skills,
| background agents, etc. It's an entire agentic environment.
| illnewsthat wrote:
| Github copilot has support for this stuff as well. Agent
| skills, background/subagents, etc.
| jimbokun wrote:
| I use it to access Claude. So what's the difference?
| nsingh2 wrote:
| This stuff is a little messy and opaque, but the
| performance of the same model in different harnesses
| depends a lot on how context is managed. The last time I
| tried Copilot, it performed markedly worse for similar
| tasks compared to Claude Code. I suspect that Copilot was
| being very aggressive in compressing context to save on
| token cost, but I'm not 100% certain about this.
|
| Also note that with Claude models, Copilot might allocate a
| different number of thinking tokens compared to Claude
| Code.
|
| Things may have changed now compared to when I tried it
| out, these tools are in constant flux. In general I've
| found that harnesses created by the model providers
| (OpenAI/Codex CLI, Anthropic/Claude Code, Google/Gemini
| CLI) tend to be better than generalist harnesses (cheaper
| too, since you're not paying a middleman).
| walthamstow wrote:
| Different harnesses and agentic environments produce
| different results from the same model. Claude Code and
| Cursor are the best IME and Copilot is by far the worst.
| vmbm wrote:
| I have been assigning issues to copilot in Github. It will then
| create a pull request and work on and report back on the issue
| in the PR. I will pull the code and make small changes locally
| using VSCode when needed.
|
| But what I like about this setup is that I have almost all the
| context I need to review the work in a single PR. And I can go
| back and revisit the PR if I ever run into issues down the
| line. Plus you can run sessions in parallel if needed, although
| I don't do that too much.
| simonw wrote:
| Are you letting it run your tests and run little snippets of
| code to try them out (like "python -c 'import module;
| print(module.something())'") or are you just using it to
| propose diffs for you to accept or reject?
|
| This stuff gets a whole lot more interesting when you let it
| start making changes and testing them by itself.
| uejfiweun wrote:
| Honestly, how long do you guys think we have left as SWEs with
| high pay? Like the SWE job will still exist, but with a much
| lower technical barrier of entry, it strikes me that the pay is
| going to decrease a lot. Obviously BigCo codebases are extremely
| complex, more than Claude Code can handle right now, but I'd say
| there's definitely a timer running here. The big question for my
| life personally is whether I can reach certain financial
| milestones before my earnings potential permanently decreases.
| spaceman_2020 wrote:
| I think the senior devs will be fine. They're like lawyers at
| this point - everyone is too scared they'll screw up and will
| keep them around
|
| The juniors though will radically have to upskill. The standard
| junior dev portfolio can be replicated by claude code in like
| three prompts
|
| The game has changed and I don't think all the players are
| ready to handle it
| jerf wrote:
| It's counterintuitive but something becoming easier doesn't
| necessarily mean it becomes cheap. Programming has arguably
| been the easiest engineering discipline to break into by sheer
| force of will for the past 20+ years, and the pay scales you
| see are adapted to that reality already.
|
| Empowering people to do 10 times as much as they could before
| means they hit 100 times the roadblocks. Again, in a lot of
| ways we've already lived in that reality for the past many
| years. On a task-by-task basis programming today is already a
| lot easier than it was 20 years ago, and we just grew our
| desires and the amount of controls and process we apply.
| Problems arise faster than solutions. Growing our velocity
| means we're going to hit a lot more problems.
|
| I'm not saying you're wrong, so much as saying, it's not the
| whole story and the only possibility. A lot of people today are
| kept out of programming just because they don't want to do that
| much on a computer all day, for instance. That isn't going to
| change. There's still going to be skills involved in being
| better than other people at getting the computers to do what
| you want.
|
| Also on a long term basis we may find that while we can produce
| entry-level coders that are basically just proxies to the AI by
| the bucketful that it may become very difficult to advance in
| skills beyond that, and those who are already over the hurdle
| of having been forced to learn the hard way may end up with a
| very difficult to overcome moat around their skills, especially
| if the AIs plateau for any period of time. I am concerned that
| we are pulling up the ladder in a way the ladder has never been
| pulled up before.
| daxfohl wrote:
| Supply and demand. There will continue to be a need for
| engineers to manage these systems and get them to do the thing
| you actually want, to understand implications of design
| tradeoffs and help stakeholders weigh the pros and cons. Some
| people will be better at it than others. Companies will
| continue to pay high premiums for such people if their business
| depends on quality software.
| tietjens wrote:
| I think to give yourself more context you should ask about the
| patterns that led to SWEs having such high pay in the last
| 10-15 years and why it is you expected it to stay that way.
|
| I personally think the barrier is going to get higher, not
| lower. And we will be back expected to do more.
| riku_iki wrote:
| > like the SWE job will still exist, but with a much lower
| technical barrier of entry
|
| its opposite, now in addition to all other skills, you need
| skill how to handle giant codebases of viobe-coded mess using
| AI.
| q3k wrote:
| I think the pay is going to skyrocket for senior devs within a
| few years, as training juniors that can graduate past pure LLM
| usage becomes more and more difficult.
|
| Day after day the global quality of software and learning
| resources will degrade as LLM grey goo consumes every single
| nook and cranny of the Internet. We will soon see the first
| signs of pure cargo cult design patterns, conventions and
| schemes that LLMs made up and then regurgitated. Only people
| who learned before LLMs became popular will know that they are
| not to be followed.
|
| People who aren't learning to program without LLMs today are
| getting left behind.
| hollowturtle wrote:
| > Coding workflow. Given the latest lift in LLM coding
| capability, like many others I rapidly went from about 80%
| manual+autocomplete coding and 20% agents in November to 80%
| agent coding and 20% edits+touchups in December
|
| Anyone wondering what exactly is he actually building? What?
| Where?
|
| > The mistakes have changed a lot - they are not simple syntax
| errors anymore, they are subtle conceptual errors that a slightly
| sloppy, hasty junior dev might do.
|
| I would LOVE to have jsut syntax errors produced by LLMs, "subtle
| conceptual errors that a slightly sloppy, hasty junior dev might
| do." are neither subtle nor slightly sloppy, they actually are
| serious and harmful, and no junior devs have no experience to fix
| those.
|
| > They will implement an inefficient, bloated, brittle
| construction over 1000 lines of code and it's up to you to be
| like "umm couldn't you just do this instead?"
|
| Why just not hand write 100 loc with the help of an LLM for
| tests, documentation and some autocomplete instead of making it
| write 1000 loc and then clean it up? Also very difficult to do,
| 1000 lines is a lot.
|
| > Tenacity. It's so interesting to watch an agent relentlessly
| work at something. They never get tired, they never get
| demoralized, they just keep going and trying things where a
| person would have given up long ago to fight another day.
|
| It's a computer program running in the cloud, what exactly did he
| expected?
|
| > Speedups. It's not clear how to measure the "speedup" of LLM
| assistance.
|
| See above
|
| > 2) I can approach code that I couldn't work on before because
| of knowledge/skill issue. So certainly it's speedup, but it's
| possibly a lot more an expansion.
|
| mmm not sure, if you don't have domain knowledge you could have
| an initial stubb at the problem, what when you need to iterate
| over it? You don't if you don't have domain knowledge on your own
|
| > Fun. I didn't anticipate that with agents programming feels
| _more_ fun because a lot of the fill in the blanks drudgery is
| removed and what remains is the creative part.
|
| No it's not fun, eg LLMs produce uninteresting uis, mostly
| bloated with react/html
|
| > Atrophy. I've already noticed that I am slowly starting to
| atrophy my ability to write code manually.
|
| My bet is that sooner or later he will get back to coding by hand
| for periods of time to avoid that, like many others, the damage
| overreliance on these tools bring is serious.
|
| > Largely due to all the little mostly syntactic details involved
| in programming, you can review code just fine even if you
| struggle to write it.
|
| No programming it's not "syntactic details" the practice of
| programming it's everything but "syntactic details", one should
| learn how to program not the language X or Y
|
| > What happens to the "10X engineer" - the ratio of productivity
| between the mean and the max engineer? It's quite possible that
| this grows _a lot_.
|
| Yet no measurable econimic effects so far
|
| > Armed with LLMs, do generalists increasingly outperform
| specialists? LLMs are a lot better at fill in the blanks (the
| micro) than grand strategy (the macro).
|
| Did people with a smartphone outperformed photographers?
| TaupeRanger wrote:
| Lots of very scared, angry developers in these comment sections
| recently...
| hollowturtle wrote:
| Not angry nor scared, I value my hard skills a lot, I'm just
| wondering why people believe religiously everything AI
| related. Maybe I'm a bit sick with the excessive hype
| hollowturtle wrote:
| Also note that I'm a heavy LLM user, not anti ai for sure
| thr59182617 wrote:
| I see way more hype that is boosted by the moderators. The
| scared ones are the nepo babies who founded a vaporware AI
| company that will be bought by daddy or friends through a VC.
|
| They have to maintain the hype until a somewhat credible exit
| appears and therefore lash out with boomer memes, FOMO, and
| the usual insane talking points like "there are builders and
| coders".
| simianwords wrote:
| i'm not sure what kind of conspiracy you are hallucinating.
| do you think people have to "maintain the hype"? it is
| doing quite well organically.
| hollowturtle wrote:
| So well that they're losing billions and OpenAI may go
| bankrupt this year
| simianwords wrote:
| what if it doesn't?
| hollowturtle wrote:
| better for them! the heck i care about it
| simianwords wrote:
| This is a low quality curmudgeonly comment
| potatogun wrote:
| You learned a new adjective? If people move beyond "nice",
| "mean" and "curmudgeonly" they might even read Shakespeare
| instead of having an LLM producing a summary.
| simianwords wrote:
| cool.
|
| >Anyone wondering what exactly is he actually building?
| What? Where?
|
| this is trivially answerable. it seems like they did not do
| even the slightest bit of research before asking question
| after question to seem smart and detailed.
| hollowturtle wrote:
| I asked many question and you focused on only one, btw
| yes I did my research, and I know him because I followed
| almost every tutorial he has on YouTube, and he never
| mentions clearly what weekend project worked on to make
| him conclude with such claims. I had a very high respect
| of him if not that at some point started acting like the
| Jesus Christ of LLMs
| simianwords wrote:
| its not clear why you asked that question if you knew the
| answer to it?
| hollowturtle wrote:
| Now that you contributed zero net to the discussion and
| learned a new word you can go out and play with toys! Good
| job
| wkh129857 wrote:
| It is pretty sad who much attention people give to someone who
| has never written any production software and leaves Tesla once
| video FSD becomes difficult.
|
| This is just a rambling tweet that has all the hallmarks of an AI
| addict.
| soganess wrote:
| "addict"
|
| Great idea! Le's pathalogize another thing! I love quickly
| othering whole concepts and putting them in my brain's "bad"
| box so I can feel superior.
| reducesuffering wrote:
| https://github.com/karpathy/nanochat
|
| https://github.com/karpathy/llm.c
|
| The proof is in the pudding. Let's see your code
| jackling wrote:
| I don't agree with the parent commenters characterization of
| Karpathy, but these projects are just simple toy projects.
| They're educational material, not production level software.
| maximedupre wrote:
| > It hurts the ego a bit but the power to operate over software
| in large "code actions" is just too net useful
|
| It does hurt, that's why all programmers now need an
| entrepreneurial mindset... you become if you use your skills +
| new AI power to build a business.
| spaceman_2020 wrote:
| Once again, 80% of the comments here are from boomers.
|
| HN used to be a proper place for people actually curious about
| technology
| weirdmantis69 wrote:
| Ya it's so weird lol
| vardalab wrote:
| I'm almost a boomer and I agree. THis dichotomy is weird. I am
| retired EE and I love the ability to just have AI do whatever I
| want for me. I have it manage a 10 node proxmox cluster in my
| basement via ansible and terraform. I can finally do stuff I
| always wanted but had no time. I got sick of editing my kids
| sports videos for highlights in Davinci Resolve so just asked
| claude to write a simple app for me and then use all my random
| video cards in my boxes to render clips in parallel and so on.
| Tech is finally fun again when I do not have to dedicate days
| to understand some new framework. It does feel a little like
| late 1990's computing when everyone was making geocities
| webpages but those days were more fun. Now with local llms
| getting strong as well and speaking to my PC instead of typing
| it feels like SciFi, so yeah, I do not get this hacker news
| hand wringing about code craft.
| kejaed wrote:
| So what is your workflow now with this app for kids sports
| highlights?
| zennit wrote:
| Also interested
| einrealist wrote:
| > It's so interesting to watch an agent relentlessly work at
| something. They never get tired, they never get demoralized, they
| just keep going and trying things where a person would have given
| up long ago to fight another day. It's a "feel the AGI" moment to
| watch it struggle with something for a long time just to come out
| victorious 30 minutes later.
|
| Somewhere, there are GPUs/NPUs running hot. You send all the
| necessary data, including information that you would never
| otherwise share. And you most likely do not pay the actual costs.
| It might become cheaper or it might not, because reasoning is a
| sticking plaster on the accuracy problem. You and your business
| become dependent on this major gatekeeper. It may seem like a
| good trade-off today. However, the personal, professional,
| political and societal issues will become increasingly difficult
| to overlook.
| daxfohl wrote:
| I still find in these instances there's at least a 50% chance
| it has taken a shortcut somewhere: created a new, bigger bug in
| something that just happened not to have a unit test covering
| it, or broke an "implicit" requirement that was so obvious to
| any reasonable human that nobody thought to document it. These
| can be subtle because you're not looking for them, because no
| human would ever think to do such a thing.
|
| Then even if you do catch it, AI: "ah, now I see exactly the
| problem. just insert a few more coins and I'll fix it for real
| this time, I promise!"
| gtowey wrote:
| The value extortion plan writes itself. How long before
| someone pitches the idea that the models explicitly _almost_
| keep solving your problem to get you to keep spending? Would
| you even know?
| fragmede wrote:
| The free market proposition is that competition (especially
| with Chinese labs and grok) means that Anthropic is welcome
| to do that. They're even welcome to illegally collude with
| OpenAi such that ChatGPT is similarly gimped. But switching
| costs are pretty low. If it turns out I can one shot an
| issue with Qwen or Deepseek or Kimi thinking, Anthropic
| loses not just my monthly subscription, but everyone else's
| I show that too. So no, I think that's some grade A
| conspiracy theory nonsense you've got there.
| thunderfork wrote:
| As a rational consumer, how would you distinguish between
| some intentional "keep pulling the slot machine" failure
| rate and the intrinsic failure rate?
|
| I feel like saying "the market will fix the incentives"
| handwaves away the lack of information on internals.
| After all, look at the market response to Google making
| their search less reliable - sure, an invested nerd might
| try Kagi, but Google's still the market leader by a long
| shot.
|
| In a market for lemons, good luck finding a lime.
| krupan wrote:
| FWIW, kagi is better than Google
| coffeefirst wrote:
| It's not that crazy. It could even happen by accident in
| pursuit of another unrelated goal. And if it did, a
| decent chunk of the tech industry would call it "revealed
| preference" because usage went up.
| hnuser123456 wrote:
| LLMs became sycophantic and effusive because those
| responses were rated higher during RLHF, until it became
| newsworthy how obviously eager-to-please they got, so
| yes, being highly factually correct and "intelligent" was
| already not the only priority.
| jrflowers wrote:
| This is a good point. For example if you have access to a
| bunch of slot machines, one of them is guaranteed to hit
| the jackpot. Since switching from one slot machine to
| another is easy, it is trivial to go from machine to
| machine until you hit the big bucks. That is why casinos
| have such large selections of them (for our benefit).
| krupan wrote:
| "for our benefit" lol! This is the best description of
| how we are all interacting with LLMs now. It's not
| working? Fire up more "agents" ala gas town or whatever
| daxfohl wrote:
| To be clear I don't think that's what they're doing
| intentionally. Especially on a subscription basis, they'd
| rather me maximize my value per token, or just not use
| them. Lulling users into using tokens unproductively is
| the worst possible option.
|
| The way agents work right now though just sometimes feels
| that way; they don't have a good way of saying "You're
| probably going to have to figure this one out yourself".
| sailfast wrote:
| That's far-fetched. It's in the interest of the model
| builders to solve your problem as efficiently as possible
| token-wise. High value to user + lower compute costs =
| better pricing power and better margins overall.
| charcircuit wrote:
| You are using it wrong, or are using a weak model if your
| failure rate is over 50%. My experience is nothing like this.
| It very consistently works for me. Maybe there is a <5%
| chance it takes the wrong approach, but you can quickly steer
| it in the right direction.
| testaccount28 wrote:
| you are using it on easy questions. some of us are not.
| baq wrote:
| Don't use it for hard questions like this then; you
| wouldn't use a hammer to cut a plank, you'd try to make a
| saw instead
| mikkupikku wrote:
| I think a lot of it comes down to how well the user
| understands the problem, because that determines the
| quality of instructions and feedback given to the LLM.
|
| For instance, I know some people have had success with
| getting claude to do game development. I have never
| bothered to learn much of anything about game
| development, but have been trying to get claude to do the
| work for me. Unsuccessful. It works for people who
| understand the problem domain, but not for those who
| don't. That's my theory.
| samrus wrote:
| It works for hard problems when the person already solves
| it and just needs the grunt work done
|
| It also works for problems that have been solved a
| thousand times before, which impresses people and makes
| them think it is actually solving those problems
| wvenable wrote:
| > These can be subtle because you're not looking for them
|
| After any agent run, I'm always looking the git comparison
| between the new version and the previous one. This helps
| catch things that you might otherwise not notice.
| fooker wrote:
| > It might become cheaper or it might not
|
| If it does not, this is going to be first technology in the
| history of mankind that has not become cheaper.
|
| (But anyway, it already costs half compared to last year)
| peaseagee wrote:
| That's not true. Many technologies get more expensive over
| time, as labor gets more expensive or as certain skills fall
| by the wayside, not everything is mass market. Have you tried
| getting a grandfather clock repaired lately?
| simianwords wrote:
| "repairing a unique clock" getting costlier doesn't mean
| technology hasn't gotten cheaper.
|
| check out whether clocks have gotten cheaper in general.
| the answer is that it has.
|
| there is no economy of scale here in repairing a single
| clock. its not relevant to bring it up here.
| ipaddr wrote:
| Clocks prices have gone up since 2020. Unless a cheaper
| better way to make clocks has emerged inflation causes
| prices to grow.
| fooker wrote:
| Luxury watches have gone up, 'clocks' as a technology is
| cheaper than ever.
|
| You can buy one for 90 cents on temu.
| simianwords wrote:
| not true, clocks have gone down after accounting for
| inflation. verified using ChatGPT.
| esafak wrote:
| Instead of advancing tenuous examples you could suggest a
| realistic mechanism by which costs could rise, such as a
| Chinese advance on Taiwan, effecting TSMC, etc.
| groby_b wrote:
| No. You don't get to make "technology gets more expensive
| over time" statements for deprecated technologies.
|
| Getting a bespoke flintstone axe is also pretty expensive,
| and has also absolutely no relevance to modern life.
|
| These discussions must, if they are to be useful, center in
| a population experience, not in unique personal moments.
| solomonb wrote:
| okay how about the Francis Scott Key Bridge?
|
| https://marylandmatters.org/2025/11/17/key-bridge-
| replacemen...
| arthurbrown wrote:
| Bought any RAM lately? Phone? GPU in the last decade?
| ipaddr wrote:
| The latest iphone has gone down in price? It's double. I
| guess the marketing is working.
| ipaddr wrote:
| I purchased a 5T drive in 2019 and the price is higher
| now despite newer better drives going on the market
| since.
|
| Not much has down in price over the last few years.
| willio58 wrote:
| Repairing grandfather clocks isn't more expensive now
| because it's gotten any harder; it's because the popularity
| of grandfather clocks is basically nonexistent compared to
| anything else to tell time.
| emtel wrote:
| Time-keeping is vastly cheaper. People don't want
| grandfather clocks. They want to tell time. And they can,
| more accurately, more easily, and much cheaper than their
| ancestors.
| InsideOutSanta wrote:
| Sure, running an LLM is cheaper, but the way we use LLMs now
| requires way more tokens than last year.
| simianwords wrote:
| ok but the capabilities are also rising. what point are you
| trying to make?
| oytis wrote:
| That it's not getting cheaper?
| jstummbillig wrote:
| But it is, capability adjusted, which is the only way it
| makes sense. You can definitely produce last years
| capability at a huge discount.
| simianwords wrote:
| you are wrong. https://epoch.ai/data-insights/llm-
| inference-price-trends
|
| this is accounting for the fact that more tokens are
| used.
| techpression wrote:
| The chart shows that they're right though. Newer models
| cost more than older models. Sure they're better but
| that's moot if older models are not available or can't
| solve the problem they're tasked with.
| simianwords wrote:
| this is incorrect. the cost to achieve the same task by
| old models is way higher than by new models.
|
| > Newer models cost more than older models
|
| where did you see this?
| techpression wrote:
| On the link you shared, 4o vs 3.5 turbo price per 1m
| tokens.
|
| There's no such thing as "same task by old model", you
| might get comparable results or you might not (and this
| is why the comparison fail, it's not a comparison), the
| reason you pick the newer models is to increase chances
| of getting a good result.
| simianwords wrote:
| > The dataset for this insight combines data on large
| language model (LLM) API prices and benchmark scores from
| Artificial Analysis and Epoch AI. We used this dataset to
| identify the lowest-priced LLMs that match or exceed a
| given score on a benchmark. We then fit a log-linear
| regression model to the prices of these LLMs over time,
| to measure the rate of decrease in price. We applied the
| same method to several benchmarks (e.g. MMLU, HumanEval)
| and performance thresholds (e.g. GPT-3.5 level, GPT-4o
| level) to determine the variation across performance
| metrics
|
| This should answer. In your case, GPT-3.5 definitely is
| cheaper per token than 4o but much much less capable. So
| they used a model that is cheaper than GPT-3.5 that
| achieved better performance for the analysis.
| fooker wrote:
| OpenAI has always priced newer models lower than older
| ones.
| techpression wrote:
| https://platform.openai.com/docs/pricing
|
| Not according to their pricing table. Then again I'm not
| sure what OpenAI model versions even mean anymore, but I
| would assume 5.2 is in the same family as 5 and 5.2-pro
| as 5-pro
| fooker wrote:
| Check GPT 5.2 vs it's predecessor the 'o' series of
| reasoning models.
| simianwords wrote:
| not true! 4o was costlier than 3.5 turbo
| fooker wrote:
| 10x more tokens today cost less than than half of X tokens
| from ~mid 2024.
| ctoth wrote:
| > But anyway, it already costs half compared to last year
|
| You could not have bought Claude Opus 4.5 at any price one
| year ago I'm quite certain. The things that were available
| cost half of what they did then, and there are new things
| available. These are both true.
|
| I'm agreeing with you, to be clear.
|
| There are two pieces I expect to continue: inference for
| existing models will continue to get cheaper. Models will
| continue to get better.
|
| Three things, actually.
|
| The "hitting a wall" / "plateau" people will continue to be
| loud and wrong. Just as they have been since 2018[0].
|
| [0]: https://blog.irvingwb.com/blog/2018/09/a-critical-
| appraisal-...
| simianwords wrote:
| interesting post. i wonder if these people go back and
| introspect on how incorrect they have been? do they feel
| the need to address it?
| fooker wrote:
| No, people do not do that.
|
| This is harmless when it comes to tech opinions but
| causes real damage in politics and activism.
|
| People get really attached to ideals and ideas, and keep
| sticking to those after they fail to work again and
| again.
| simianwords wrote:
| i don't think it is harmless or we are incentivising
| people to just say whatever they want without any care
| for truth. people's reputations should be attached to
| their predictions.
| cogogo wrote:
| Some people definitely do but how do they go and address
| it? A fresh example in that it addresses pure
| misinformation. I just screwed up and told some neighbors
| garbage collection was delayed for a day because of
| almost 2ft of snow. Turns out it was just food waste and
| I was distracted checking the app and read the
| notification poorly.
|
| I went back to tell them (do not know them at all just
| everyone is chattier digging out of a storm) and they
| were not there. Feel terrible and no real viable remedy.
| Hope they check themselves and realize I am an idiot.
| Even harder on the internet.
| ak_111 wrote:
| Concorde?
| asadotzler wrote:
| cheaper doesnt mean cheap enough to be viable after the bills
| come due
| krupan wrote:
| There are plenty of technologies that have not become
| cheaper, or at least not cheap enough, to go big and change
| the world. You probably haven't heard of them because
| obviously they didn't succeed.
| root_axis wrote:
| Not true. Bitcoin has continued to rise in cost since its
| introduction (as in the aggregate cost incurred to run the
| network).
|
| LLMs will face their own challenges with respect to reducing
| costs, since self-attention grows quadratically. These are
| still early days, so there remains a lot of low hanging fruit
| in terms of optimizations, but all of that becomes negligible
| in the face of quadratic attention.
| YetAnotherNick wrote:
| With optimizations and new hardware, power is almost a
| negligible cost. You can get 5.5M tokens/s/MW[1] for kimi
| k2(=20M/KWH=181M tokens/$) which is 400x cheaper than current
| pricing. It's just Nvidia/TSMC/other manufacturers eating up
| the profit now because they can. My bet is that China will
| match current Nvidia within 5 years.
|
| [1]: https://developer-blogs.nvidia.com/wp-
| content/uploads/2026/0...
| storystarling wrote:
| Electricity is negligible but the dominant cost is the
| hardware depreciation itself. Also inference is typically
| memory bandwidth bound so you are limited by how fast you can
| move weights rather than raw compute efficiency.
| hahahahhaah wrote:
| It is also amazing seeing Linux kernel work, scheduling
| threads, proving interrupts and API calls all without breaking
| a sweat or injuring its ACL.
| cyode wrote:
| This quote stuck out to me as well, for a slightly different
| reason.
|
| The "tenacity" referenced here has been, in my opinion, the key
| ingredient in the secret sauce of a successful career in tech,
| at least in these past 20 years. Every industry job has its
| intricacies, but for every engineer who earned their pay with
| novel work on a new protocol, framework, or paradigm, there
| were 10 or more providing value by putting the myriad pieces
| together, muddling through the ever-waxing complexity, and
| crucially never saying die.
|
| We all saw others weeded out along the way for lacking the
| tenacity. Think the boot camp dropouts or undergrads who
| changed majors when first grappling with recursion (or emacs).
| The sole trait of stubbornness to "keep going" outweighs
| analytical ability, leetcode prowess, soft skills like
| corporate political tact, and everything else.
|
| I can't tell what this means for the job market. Tenacity may
| not be enough on its own. But it's the most valuable quality in
| an employee in my mind, and Claude has it.
| mikeocool wrote:
| To me this tenacity is often like watching someone trying to
| get a screw into board using a hammer.
|
| There's often a better faster way to do it, and while it might
| get to the short term goal eventually, it's often created some
| long term problems along the way.
| rileymichael wrote:
| > LLM coding will split up engineers based on those who primarily
| liked coding and those who primarily liked building
|
| as the former, i've never felt _more ahead_ than now due to all
| of the latter succumbing to the llm hype
| daxfohl wrote:
| I worry about the "brain atrophy" part, as I've felt this too.
| And not just atrophy, but even moreso I think it's evolving into
| "complacency".
|
| Like there have been multiple times now where I wanted the code
| to look a certain way, but it kept pulling back to the way it
| wanted to do things. Like if I had stated certain design goals
| recently it would adhere to them, but after a few iterations it
| would forget again and go back to its original approach, or mix
| the two, or whatever. Eventually it was easier just to quit
| fighting it and let it do things the way it wanted.
|
| What I've seen is that after the initial dopamine rush of being
| able to do things that would have taken much longer manually, a
| few iterations of this kind of interaction has slowly led to a
| disillusionment of the whole project, as AI keeps pushing it in a
| direction I didn't want.
|
| I think this is especially true if you're trying to experiment
| with new approaches to things. LLMs are, by definition, biased by
| what was in their training data. You can shock them out of it
| momentarily, whish is awesome for a few rounds, but over time the
| gravitational pull of what's already in their latent space
| becomes inescapable. (I picture it as working like a giant
| Sierpinski triangle).
|
| I want to say the end result is very akin to doom scrolling. Doom
| tabbing? It's like, yeah I could be more creative with just a tad
| more effort, but the AI is already running and the bar to seeing
| what the AI will do next is so low, so....
| Imustaskforhelp wrote:
| > I want to say it's very akin to doom scrolling. Doom tabbing?
| It's like, yeah I could be more creative with just a tad more
| effort, but the AI is already running and the bar to seeing
| what the AI will do next is so low, so....
|
| Yea exactly, Like we are just waiting so that it gets completed
| and after it gets completed then what? We ask it to do new
| things again.
|
| Just as how if we are doom scrolling, we watch something for a
| minute then scroll down and watch something new again.
|
| The whole notion of progress feels completely fake with this.
| Somehow I guess I was in a bubble of time where I had always
| end up using AI in web browsers (just as when chatgpt 3 came)
| and my workflow didn't change because it was free but recently
| changed it when some new free services dropped.
|
| "Doom-tabbing" or complete out of the loop AI agentic
| programming just feels really weird to me sucking the joy & I
| wouldn't even consider myself a guy particular interested in
| writing code as I had been using AI to write code for a long
| time.
|
| I think the problem for me was that I always considered myself
| a computer tinker before coder. So when AI came for coding, my
| tinkering skills were given a boost (I could make projects of
| curiosity I couldn't earlier) but now with AI agents in this
| autonomous esque way, it has come for my tinkering & I do feel
| replaced or just feel like my ability of tinkering and my
| interests and my knowledge and my experience is just not taken
| up into account if AI agent will write the whole code in multi
| file structure, run commands and then deploy it straight to a
| website.
|
| I mean my point is tinkering was an active hobby, now its
| becoming a passive hobby, doom-tinkering? I feel like I have
| caught up on the feeling a bit earlier with just vibe from my
| heart but is it just me who feels this or?
|
| What could be a name for what I feel?
| striking wrote:
| It's not _just_ brain atrophy, I think. I think part of it is
| that we 're actively making a tradeoff to focus on learning how
| to use the model rather than learning how to use our own brains
| and work with each other.
|
| This would be fine if not for one thing: the meta-skill of
| learning to use the LLM depreciates too. Today's LLM is gonna
| go away someday, the way you have to use it will change. You
| will be on a forever treadmill, always learning the vagaries of
| using the new shiny model (and paying for the privilege!)
|
| I'm not going to make myself dependent, let myself atrophy, run
| on a treadmill forever, for something I happen to rent and
| can't keep. If I wanted a cheap high that I didn't mind being
| dependent on, there's more fun ones out there.
| daxfohl wrote:
| Businesses too. For two years it's been "throw everything
| into AI." But now that shit is getting real, are they
| _really_ feeling so coy about letting AI run ahead of their
| engineering team 's ability to manage it? How long will it be
| until we start seeing outages that just don't get resolved
| because the engineers have lost the plot?
| stuaxo wrote:
| LLMs have some terrible patterns, don't know what do ? Just
| chuck a class named Service in.
|
| Have to really look out for the crap.
| gritspants wrote:
| My disillusionment comes from the feeling I am just cosplaying
| my job. There is nothing to distinguish one cosplayer from
| another. I am just doordashing software, at this point, and I'm
| not in control.
| TheGRS wrote:
| I do feel a big mood shift after late November. I switched to
| using Cursor and Gemini primarily and it was big change in my
| ability to get my ideas into code effectively. The Cursor
| interface for one got to a place that I really like and enjoy
| using, but its probably more that the results from the agents
| themselves are less frustrating. I can deal with the output more
| now.
|
| I'm still a little iffy on the agent swarm idea. I think I will
| need to see it in action in an interface that works for me. To me
| it feels like we are anthropomorphizing agents too much, and that
| results in this idea that we can put agents into roles and them
| combine them into useful teams. I can't help seeing all agents as
| the same automatons and I have trouble understanding why giving
| an agent with different guideliens to follow, and then having
| them follow along another agent would give me better results than
| just fixing the context in the first place. Either that or just
| working more on the code pipeline to spot issues early on - all
| the stuff we already test for.
| Macha wrote:
| > - What does LLM coding feel like in the future? Is it like
| playing StarCraft? Playing Factorio? Playing music?
|
| Starcraft and Factorio are exactly what it is not. Starcraft has
| a loooot of micro involved at any level beyond mid level play,
| despite all the "pro macros and beats gold league with mass
| queens" meme videos. I guess it could be like Factorio if you're
| playing it by plugging together blueprint books from other people
| but I don't think that's how most people play.
|
| At that level of abstraction, it's more like grand strategy if
| you're to compare it to any video game? You're controlling high
| level pushes and then the units "do stuff" and then you react to
| the results.
| daxfohl wrote:
| I'm curious to see what effect this change has on leadership. For
| the last two years it's been "put everything you can into AI
| coding, or else!" with quotas and firings and whatever else. Now
| that AI is at the stage where it can actually output whole
| features with minimal handholding, is there going to be a
| Frankenstein moment where leadership realizes they now have a
| product whose codebase is running away from their engineering
| team's ability to support it? Does it change the calculus of what
| it means to be underinvested vs overinvested in AI, and what are
| the implications?
| philipwhiuk wrote:
| > It's so interesting to watch an agent relentlessly work at
| something. They never get tired, they never get demoralized, they
| just keep going and trying things where a person would have given
| up long ago to fight another day. It's a "feel the AGI" moment to
| watch it struggle with something for a long time just to come out
| victorious 30 minutes later.
|
| The bits left unsaid:
|
| 1. Burning tokens, which we charge you for
|
| 2. My CPU does this when I tell it to do bogosort on a million
| 32-bit integers, it doesn't mean it's a good thing
| forrestthewoods wrote:
| HN should ban any discussion on "things I learned playing with
| AI" that don't include direct artifacts of the thing built.
|
| We're about a year deep into "AI is changing everything" and I
| don't see 10x software quality or output.
|
| Now don't get me wrong I'm a big fan of AI tooling and think it
| does meaningfully increase value. But I'm damn tired of all the
| talk with literally nothing to show for it or back it up.
| twa927 wrote:
| I don't see the AI capacity jump in the recent months at all. For
| me it's more the opposite, CC works worse than a few months ago.
| Keeps forgetting the rules from CLAUDE.md, hallucinates function
| calls, generates tons of over-verbose plans, generates
| overengineered code. Where I find it a clear net-positive is pure
| frontend code (HTML + Tailwind), it's spaghetti but since it's
| just visualization, it's OK.
| ValentineC wrote:
| > _Where I find it a clear net-positive is pure frontend code
| (HTML + Tailwind), it 's spaghetti but since it's just
| visualization, it's OK._
|
| This makes it sound like we're back in the days of
| FrontPage/Dreamweaver WYSIWYG. Goodness.
| twa927 wrote:
| Hmm, your comment gave me the idea that maybe we should
| invent "What You Describe Is What You Get|. To replace
| HTML+Tailwind spaghetti with prompts generating it.
| nsb1 wrote:
| The best thing I ever told Claude to do was "Swear profusely when
| discussing code and code changes". Probably says more about me
| than Claude, but it makes me snicker.
| neuralkoi wrote:
| > The most common category is that the models make wrong
| assumptions on your behalf and just run along with them without
| checking.
|
| If current LLMs are ever deployed in systems harboring the big
| red button, they WILL most definitely somehow press that button.
| arthurcolle wrote:
| US MIC are already planning on integrating fucking Grok into
| military systems. No comment.
| groby_b wrote:
| fwiw, the same is true for humans. Which is why there's a whole
| lot of process and red tape around that button. We _know_ how
| to manage risk. We can choose to do that for LLM usage, too.
|
| If instead we believe in fantasies of a single all-knowing
| machine god that is 100% correct at all times, then... we
| really just have ourselves to blame. Might as well just have
| spammed that button by hand.
| 0xbadcafebee wrote:
| > What happens to the "10X engineer" - the ratio of productivity
| between the mean and the max engineer? It's quite possible that
| this grows _a lot_.
|
| I was thinking about this the other day as relates to the DevOps
| movement.
|
| The DevOps movement started as a way to accelerate and improve
| the results of dev<->ops team dynamics. By changing practices and
| methods, you get acceleration and improvement. That creates
| "high-performing teams", which is the team form of a 10x
| engineer. Whether or not you believe in '10x engineers', a high-
| performing team is real. You really can make your team deploy
| faster, with fewer bugs. You have to change how you all work to
| accomplish it, though.
|
| To get good at using AI for coding, you have to do the same
| thing: continuous improvement, changing workflows, different
| designs, development of trust through automation and validation.
| Just like DevOps, this requires learning brand new concepts, and
| changing how a whole team works. This didn't get adopted widely
| with DevOps because nobody wanted to learn new things or change
| how they work. So it's possible people won't adapt to the
| "better" way of using AI for coding, even if it would produce a
| 10x result.
|
| If we want this new way of working to stick, it's going to
| require education, and a change of engineering culture.
| superze wrote:
| I don't know about you guys but most of the time it's spitting
| nonsense models in sqlalchemy and I have to constantly correct it
| to the point where I am back at writing the code myself. The bugs
| are just astonishing and I lose control of the codebase after
| some time to the point where reviewing the whole thing just takes
| a lot of time.
|
| On the contrary if it was for a job in a public sector I would
| just let the LLM spit out some output and play stupid, since
| salary is very low.
| all2well wrote:
| What particular setups are getting folks these sorts of results?
| If there's a way I could avoid all the babysitting I have to do
| with AI tools that would be welcome
| spongebobstoes wrote:
| i use codex cli. work on giving it useful skills. work on the
| other instruction files. take Karpathy tips around testing and
| declarativeness
|
| use many simultaneously, and bounce between them to unblock
| them as needed
|
| build good tools and tests. you will soon learn all the things
| you did manually -- script them all
| geraneum wrote:
| > If there's a way I could avoid all the babysitting I have to
| do with AI tools that would be welcome
|
| OP mentions that they are actually doing the "babysitting"
| tintor wrote:
| "you can review code just fine even if you struggle to write it."
|
| Well, merely approving code takes no skill at all.
| roblh wrote:
| Seriously, that's a completely nonsense line.
| toephu2 wrote:
| I think in less than a year writing code manually will be akin to
| doing arithmetic problems by hand. Sure you can still code
| manually, but it's going to be a lot faster to use an LLM
| (calculator).
| kypro wrote:
| I agree, but writing code is so different to calculations that
| long-term benefits are less clear.
|
| It doesn't matter how good you are at calculations the answer
| to 2 + 2 is always 4. There are no methods of solving 2 + 2
| which could result in you accidentally giving everyone who
| reads the result of your calculation write access to your
| entire DB. But there are different ways to code a system even
| if the UI is the same, and some of these may neglect to
| consider permissions.
|
| I think a good parallel here would be to imagine that tomorrow
| we had access to humanoid robots who could do construction
| work. Would we want them to just go build skyscrapers and
| bridges and view all construction businesses which didn't
| embrace the humanoid robots as akin to doing arithmetic by
| hand?
|
| You could of course argue that there's no problem here so long
| as trained construction workers are supervising the robots to
| make sure they're getting tolerances right and doing good
| welds, but then what happens 10 years down the road when humans
| haven't built a building in years? If people are not writing
| code any more then how can people be expected to review AI
| generated code?
|
| I think the optimistic picture here is that humans just won't
| be needed in the future. In theory when models are good enough
| we should be able to trust the AI systems more than humans. But
| the less optimistic side of me questions a future in which
| humans no longer do, or even know how to do such fundamental
| things.
| adamddev1 wrote:
| People keep using these analogies but I think these are
| fundamentally different things.
|
| 1. hand arithmetic -> using a calculator
|
| 2. assembly -> using a high level language
|
| 3. writing code -> making an LLM write code
|
| Number 3 does not belong. Number 3 is a fundamentally different
| leap because it's not based on deterministic logic. You can't
| depend on an LLM like you can depend on a calculator or a
| compiler. LLMs are totally different.
| nsainsbury wrote:
| Touching on the atrophy point, I actually wrote a few thoughts
| about this yesterday: https://www.neilwithdata.com/outsourced-
| thinking
|
| I actually disagree with Andrej here re: "Generation (writing
| code) and discrimination (reading code) are different
| capabilities in the brain." and I would argue that the only
| reason he can read code fluently, find issues, etc. is because he
| has spent year in a non-AI assisted world writing code. As time
| goes on, he will become substantially worse.
|
| This also bodes incredibly poorly for the next generation, who
| will mostly in their formative years now avoid writing code and
| thus fail to even develop a idea of what good code is, how it
| works/why it works, why you make certain decisions, and not
| others, etc. and ultimately you will see them become utterly
| dependent on AI, unable to make progress without it.
|
| IMO outsourcing thinking is going to have incredibly negative
| consequences for the world at large.
| gwd wrote:
| Is coding like piloting, where pilots need a certain number of
| hours of "flight time" to gain skills, and then a certain
| number of additional hours each year to maintain their skills?
| Do developers need to schedule in a certain number of "manually
| written lines of code" every year?
| themafia wrote:
| Instead of a 17 paragraph twitter post with a baffling TLDR at
| the end why not just record your screen and _demonstrate_ all of
| what you're describing?
|
| Otherwise, I think you're incidentally right, your "ego" /is/
| bruised, and you're looking for a way out by trying to
| prognosticate on the future of the technology. You're failing in
| two different ways.
| alexose wrote:
| It's refreshing to see one of the top minds in AI converge on the
| same set of thoughts and frustrations as me.
|
| For as fast as this is all moving, it's good to remember that
| most of us are actually a lot closer to the tip of the spear than
| we think.
___________________________________________________________________
(page generated 2026-01-27 23:00 UTC)