What happens when coding agents stop feeling like dialup?
martinalderson.com
martinalderson.com
I still find myself incredibly skeptical LLM use is increasing productivity. Because AI reduces cognitive engagement with tasks, it feels to me like AI increases perceptive productivity but actually decreases it in many cases (and this probably compounds as AI-generated code piles up in a codebase, as there isn't an author who can attach context as to why decisions were made).
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o...
I realize the author qualified his or her statement with "know how to harness it," which feels like a cop-out I'm seeing an awful lot in recent explorations of AI's relationship with productivity. In my mind, like TikTok or online dating, AI is just another product motion toward comfort maximizing over all things, as cognitive engagement is difficult and not always pleasant. In a nutshell, it is another instant gratification product from tech.
That's not to say that I don't use AI, but I use it primarily as search to see what is out there. If I use it for coding at all, I tend to primarily use it for code review. Even when AI does a good job at implementation of a feature, unless I put in the cognitive engagement I typically put in during code review, its code feels alien to me and I feel uncomfortable merging it (and I employ similar levels of cognitive engagement during code reviews as I do while writing software).
Of course there are going to be discussions what is real programming (like I'm sure there were discussions what is "real" accounting with the onset of a calculator)
The moment we stop treating LLMs like people and see them as big calculators, it all clicks.
If you've ever done any modeling/serious accounting, you'll find that you feel more like a DBA than a "person punching on a calculator". You ask questions and then you figure out how to get the answers you want by "querying" excel cells. Many times querying isn't in quotes.
To me, the analogy of the parent is quite apt.
Whenever people are doing the data entry you shouldn't trust your data. It's not the same as LLM hallucinations but it's not entirely different either.
Perhaps this OpenAI paper would be interesting then (published September 4th):
https://arxiv.org/pdf/2509.04664
Hallucination is still absolutely an issue, and it doesn’t go away by reframing it as user error, saying the user didn’t know what they were doing, didn’t know what they needed to get from the LLM, or couldn’t describe it well enough.
But a lot of software isn’t like that. You can introduce subtle bugs along the way, so verifying is at least as hard as writing it in the first place. Likely harder, since writing code is easier than reading for most people.
If my calculator sometimes returned incorrect results I would throw it out. And I say this as an MLE who builds neural nets.
Thankfully the more complex the question almost always there's more than one way to derive the answer and you use that to check.
It does make mistakes and is not reliable[0]. The user still needs to have a "feel" for the data.
(to be pedantic "Excel" doesn't make mistakes, people trusting its defaults do)
[0] https://timharford.com/2021/05/cautionary-tales-wrong-tools-...
So what is your point? An expert that mastered excel don't have to check that excel calculated things correctly, he just need to check that he gave excel the right inputs and formulas. That is not true for LLM, you do have to check that it actually did what you asked regardless how good you are at prompting.
The only thing I trust an LLM to do correctly are translations, they are very reliable at that, other than that I always verify.
See the issue here?
Excel has no proper built-in validation or test suite, not sure about 3rd party ones. The last time I checked some years back there was like one that didn't do much.
All it takes is one person accidentally or unknowingly entering static data on top of a few formulas in the middle and nobody will catch it. Or Excel "helps" by changing the SEPT1 gene to "September 1. 2025"[0] - this case got so bad they had to RENAME the gene to make Excel behave. "Just" doing it properly didn't work at scale.
The point I'm trying to get at here that neither tool is perfect and requires validation afterwards. With agentic coding we can verify the results, we have the tools for it - and the agent can run them automatically.
In this case Excel is even worse because one human error can escalate massively as there is no simple way to verify the output, Excel has no unit test equivalents or validators.
[0] https://www.progress.org.uk/human-genes-renamed-as-microsoft...
“Just” checking a million rows is trivial depending on the types of checks you’re running. In any case, you would never want a check which yields false positives and false negatives, since that defeats the entire purpose of the check.
Hallucination is not an intractable problem, the stochastic nature of hallucinations makes it easy to use the same tools to catch them. I feel like hallucinations have become a cop out, an excuse, for people who don't want to learn how to use these new tools anyway.
I've seen Python unit tests emitted by LLM that, for a given class under test, start with.
def test_foo_can_be_imported(self):
try:
from a.b.c import Foo
except ImportError:
self.fail()
def test_foo_can_be_instantiated(self):
from a.b.c import Foo
instance = Foo()
self.assertNotNull(instance)
self.assertTrue(isinstance(instance, Foo)
def test_other_stuff_that_relies_on_importing_and_instantiating_foo(self)
...
"1: The tests failed! I better change the code. 2: The tests failed! I better change the tests. GOTO 1"
until it gets passing tests, sometimes by straight out deleting tests, or hardcoding values to make them pass.
So I don't have the same faith in LLM-authored tests as you do.
> I feel like hallucinations have become a cop out, an excuse, for people who don't want to learn how to use these new tools anyway.
I feel like you've taken that attitude so you can dismiss concerns you don't agree with, without having to engage with them. It's disappointing.
Gee thanks for all that extra productivity, AI overlords.
Maybe they should replace AI programmers with AI instead?
Like fixing useless and/or broken tests written by an LLM?
(Thank you, AI overlords, for freeing me from the pesky algorithmic and coding tedia so I can instead focus on fixing the mountains of technical debt you added!)
I don't think you two are disagreeing.
I have noticed this personally. It's a lot like the fatigue one gets from too long scrolling online. Engagement is shallower but not any less mentally exhausting than reading a book. You end up feeling more exhausted due to the involuntary attention-scattering.
You're in some senses managing an idiot savant, emphasis on the idiot part, except they're also a narcissist who will happily go out of scope if you let it.
If you have management experience, the analogy is immediately obvious. If you don't, I can see how having speed run learning it with a kid running around with dynamite would be taxing.
Many people hate when you don't anthropomorphize LLM though, but that is the best way to understand how they can fail so spectacularly in ways we would never expect a human to fail.
Interestingly, I have friends who aren't coders who use LLMs for various personal needs, and they run into the same kind of problems you are describing. 100% of the time, i've found that it's that they do not understand how to work with an LLM. Once i help them, they start getting better results. I do not have any need to anthropomorphize an LLM. I do however understand that I can use natural language to get quite complex and yes ACCURATE results from AI, IF i know what i'm doing and how to ask for it. It's just a tool, not a person.
I'm a bit of a luddite, I still just use notepad++ and a terminal window to develop my code. I don't want to get bogged down in using vscode so trusting AI to handle things beyond "can you make this email sound better?" has been a big leap for me.
1) An easily defined go/no-go task with defined end point which requires
2) A bunch of programming code that nobody gives a single shit about
3) With esoteric function calls that require staring at obscure documentation
This is the LLM dream task.
When the next person has to stare at this code, they will throw it out and rerun an LLM on it because the code is irrelevant and the end task is the only thing that matters.
I'm revisiting this comment a lot with LLM's. I don't think many HN readers run into real life mudball/spaghetti code. I think there is a SV bias here where posters think taking a shortcut a few times is what a mudball is.
There will NEVER be a time in this business where the business is ok with simply scrapping these hundreds of inconsistent one off generations and be ok with something that sorta kinda worked like before. The very places that do this won't use consistent generation methods either. The next person to stare at it will not just rerun the LLM because at that time the ball will be so big not even the LLMs can fix it without breaking something else. Worse the new person won't even know what they don't know or even what to ask it to regenerate.
Man I'm gonna buy stock in the big three as a stealth long term counter LLM play.
I've seen outside of SV mudballs and they are messes that defy logical imagination. LLM's are only gonna make that worse. Its like giving children access to a functional tool shop. You are not gonna get a working product no matter how good the tools are.
Someone in the company manages a TON of questionnaires. They type the questions into the service, get the results. The results are in an CSV format or some shit. Then they need to manually copy them to Google Sheets and do some adjustments on them.
Took me about 30 minutes of wall clock time, maybe 5 minutes of my time to have an LLM write me a simple python script that uses the API in the questionnaire service to pull down the data and insert it into a new Google Sheet.
Saves the person a TON of time every day.
---
Second case was a person who had to do similar manual input to crappy Sheets daily, because that's what the next piece in the process can read.
This person has a bit of an engineer mindset and vibe-coded a web tool themselves that has a UI that lets them easily fill the same information but view it in a more user friendly way. Then it'll export it in a CSV/JSON format for the next step in the process.
None of these would've been granted the day(s) of engineering time before, now both were something that could be thrown together quickly over a coffee break or done by themselves over a weekend.
You are 100% wrong on this. They exist all the time when I'm doing a hardware task.
I need to test a new chip coming off the fab. I need to get the pins in the right place, the test code up and running, the jig positioned correctly, the test vectors for JTAG generated, etc.
This ... is ... a ... pain ... in ... the ... ass.
It changes every single time for every single chip. It changes for every jig and every JTAG and every new test machine. Nobody gives one iota of damn about the code as it will be completely different for the next revision of this chip. Once I validate that the chip actually powers on and does something sane, the folks who handle the real testing will generate real vectors--but not before.
So, generating that go/no-go code is in the way of everything. And nobody cares about what it looks like because it is going to be thrown out immediately afterward.
Ask one to count the 'r's in "strawberry" and it may or may not get it right.
Ask it to create a program to do it, it'll get it right instantly and it'll work.
When we get to a point where "AI" can write a program like that in the background, run it and use its result as a tool, we'll get the next big leap in efficiency.
To me an “actual software developer” is always learning, always growing, always making mistakes, always looking back and blown away by how far they’ve come - and most importantly, is always willing to generously offer a hand up to anyone who cares enough to learn the craft.
It’s ok to make a big ball of mud! You can deal with it later once you understand the problem v1 solves. Parallel rebuilds and migrations are part of software engineering. Or alternatively - maybe that big ball of mud does its job, has no new requirements, so can be left quietly chugging along - for potentially decades, never needing a v2.
Ofc we're screwed in a couple more generations of Moore's law, if/when AI is able to one-shot "untangle this big ball of mud for me please".
Some things are highly valuable (e.g. validating electronic equipment via scores of hardware testing) and can be curated by a skilled "amateur" programmer (we used to call these folks "scripters" back in the day) more or less indefinitely. Adding "real programmers" to the mix would simply cause costs to skyrocket with no discernable impact on revenue produced - just some smug programmers showing off how much better their code looks and how much more maintainable it is.
Stuff like this is domain knowledge distilled into a bash script. If you have the domain knowledge it is typically pretty trivial to simply do a full rewrite if you come in after this guy retires. The domain knowledge and understanding of what the automation is actually doing is the hard and skilled part of the job.
I'm not downvoting the low-value comment because I believe it needs high visibility for many who come here and see the responses to it. You don't need to "engineer" software for every use-case. Sometimes the guy with deep domain knowledge who can hack and kludge a bash or python script together is 10x more valuable than some guy with a CS degree and a toolbox of "best practices" who doesn't give a shit about the underlying task at hand. I'm sure some fancy new frameworks will be used though!
Sysadmins of yesteryear who were expected to deeply understand hardware and OS level things, but not be able to program all understand this and would be able to make great use of AI. The advance of programmers into the sysadmin (aka devops) space is really a travesty of speciality skills being lost and discarded. A whole lot of very pretty overengineered code sitting on top of hardware and systems that are barely understood by those who wrote it and it shows.
Bringing software development practices to the sysadmin world has improved it so much.
Infra as code, no pet servers, languages that don't require massive maintenence every time a dependency or language version changes, testing frameworks.
Things are so much better then clicking around VMware, bugging the one guy that runs a bash script cron off his laptop to write a feature.
This task: "I have to constantly be on my toes to follow what the LLMs are proposing"
and "understanding, then solving the specific problems you are being paid to solve"
are not the same thing. It's been linked endlessly here but Programming as Theory Building is as relevant today as it was in '85: https://pages.cs.wisc.edu/~remzi/Naur.pdf
"You're doing AI wrong" is the new "you're doing agile wrong" which was the new "you're doing XP wrong".
The consequence in this model of not being an early AI adopter is that unless you're a rock star performer already, you're going to fall behind the curve and get ejected from the game of software engineering early. The people who stay in the game until the end will be the ones that have vision now.
If I'm wrong, then all the people who learned AI now will have just wasted a few years on a low value skill, which is honestly the story of the entire history of tech (hello flash devs?), i.e. not an existential threat to engineers.
This is assuming that AI _currently improves productivity_. There's little empirical evidence for this (there is evidence that it causes people to believe that they themselves are more productive, but that's not very useful; _all sorts_ of snake oil cause people to believe that they themselves are more productive).
My baseline assumption right now would be that AI does not, in aggregate, improve productivity (at least in software engineering; it may in some other fields); if it ever _does_, then sure, I'll probably start using it?
AI delivers results when you understand its characteristics and build a workflow around it designed to play to its strengths. AI doesn't deliver huge results when you try to shoehorn it into AI unfriendly workflows. Even if you took the Stanford 95% study on its face (which you shouldn't, there are a lot of methodological issues), there are still 5% of projects that are returning value, and it's not random, it's process differences.
What definition of productivity are you using?
The link in your bio is a long series of tools for various personas with a "schedule a consultation" link next to each one. I'm not sure what "consultation" is if not "a product". But maybe they're all free?
That said, I did not intend to call out your bias as a means of questioning your honesty and I apologize if my communication came across as doing so!
Also, design and rationale what humans need is different than what LLMs need. Even what is needed according to humans writing code/documentation and what’s needed for reading is different, that’s why we have that many bad documentation. There are ton of Apache projects whose documentation is rather a burden than helpful. They are long and absolutely useless.
Documentation for a system, particularly a rationale, is never a code smell.
> There are ton of Apache projects whose documentation is rather a burden than helpful. They are long and absolutely useless.
LLM prompts are short and to the point by comparison, that's part of my point.
/* This changes the sorting of the original list based on the result, when you use a pipeline <- you have an architectural problem - this happens for example in Splunk */
map()
/* You need to call these in this exact order, one after another <- your architecture is terrible */
processFirst()
processSecond()
processThird()
/* We did this unusual thing because we hate encapsulation <- obvious paraphrase, and lie, you were just lazy, or you didn't have time */
class A {
public static String x
}
In unrelated code: A.x = "something";
/* We merged these two classes because they looked similar, in the code we have a lot of switches and ifs to differentiate between them, we explained them one-by-one <- do I need to explain this? */
class TwoCompletelyUnrelatedThingsInOne
> that's part of my point
> The gigantic prompt
It was clearly not.*
In that regard, nothing will change.
I've used LLMs for code gen at work as well as for personal stuff.
At work primarily for quick and dirty internal UIs / tools / CLIs it's been fantastic, but we've not unleashed it on our core codebases. It's worth noting all the stuff we've got out of out are things we'd not normally have the time to work on - so a net positive there.
Outside of work I've built some bespoke software almost entirely generated with human tweaks here and there - again, super useful software for me and some friends to use for planning and managing music events we put on that I'd never normally have the time to build.
So in those ways I see it as massively increasing productivity - to build lower stakes things that would normally just never get done due to lack of time.
A lot of open source tooling gets created to solve those random "silly" things that are personal annoyances or needs. Then you find out others have the same or similar problem and entire standard tooling or libraries come into existence.
I have pontificated on how easy access to immediate "one offs" will kill this idea exchange? Instead of one tool maintained by hundreds to fulfill a common need, we will end up with millions of one-off LLM generated that are not shared with anyone else.
Might be a net win, or a net loss. I'm really not sure!
"How to harness it" is very clearly the difference between users right now, and I'd say we're currently bottom heavy with poor users stuck in a 'productivity illusion'.
But there is the question of "what is productivity?"
I'm finding myself (having AI) writing better structured docs and tests to make sure the AI can do what I ask it to.
I suspect that turns into compounding interests (or lack of technical debt).
For an industry where devs have complained, for decades, about productivity metrics being extremely hard or outright bullshit, I see way too many of the same people now waving around studies regarding productivity.
"AI" might be a good thing or a bad thing especially depending on the context and implementation, but just generally saying something is about maximizing comfort as some inherently bad goal seems off to me.
I use Claude, Codex, and the Gemini CLI (all "supervised command line agents"). I write Go. I am certain that agents improve my productivity in a couple common scenarios:
1. Unsticking myself from stalling at the start of some big "lift" (like starting a new project, adding a major feature that will pull in some new dependency). The LLM can get things very wrong (this happens to me maybe 20% of the time), but that doesn't matter, because for me the motion of taking something wrong and making it "righter" is much less effort than getting past a blank page, assembling all the resources I need to know how to hello-world a new dependency, that kind of thing. Along with "wrestling for weeks with timing-dependent bugs", this kind of inertia is one of like two principal components of "effort" in programming for me, so clearing it is a very big deal. I'm left at a point where I'm actually jazzed about taking the wheel and delivering the functionality myself.
2. Large mechanical changes (like moving an interface from one component to another, or major non-architectural refactors, or instrumentation). Things where there's one meta-solution and it's going to be repeated many times across a codebase. Easy to review, a lot of typing, no more kidding myself for 20 minutes that I can make just the right Emacs macro to pull it off.
3. Bug hunting. To be clear: I am talking here about code I wrote, not the LLM. I run it, it does something stupid. My first instinct now is to drop into Claude or Gemini, paste the logs and an @-reference to a .go file as a starting point, and just say "wtf". My hit rate on it spotting things is very good. If the hit rate was even "meh borderline" that would be a huge win for the amount of effort it takes, but it isn't, it's much better.
I'm guessing a lot of people do not have these 3 experiences with LLM agents. I'm sorry! But I do think that if you stipulate that I'm not just making this up, it's hard to go from here to "I'm kidding myself about the value this is providing". Note that these are three cases that look nothing at all like vibe-coding.
Could I have found this bug as quickly as Claude? Sure, in retrospect the cause seems quite obvious. But I could just as easily rabbit holed myself looking somewhere else, or taken a while to figure out exactly which dependency caused the issue.
It's definitely the case that you cannot blindly accept the LLM's output, you have to treat it as a partner and often guide it towards better solutions. But it absolutely can improve your productivity.
For me it's been somewhat useful to ask questions but always fails at modifying any code in a big codebase.
Agreed, and also configuration debugging. Treat the LLM as interactive documentation for libraries, frameworks, etc. that you may be using. They're great for solving problems in getting systems up and running, and they explain things better than the documentation because it's specific to your scenario.
I've had one 3-day basic course in Unity, but I know how to prompt and guide an AI.
> AI systems do not currently speed up many or most software developers
> AI systems in the near future will not speed up developers in our exact setting
> There are not ways of using existing AI systems more effectively to achieve positive speedup in our exact setting
increases the perception of productivity?
For me is the exact opposite. When not using AI, while coding you notice various things that could be improved, you can think about the architecture and what features you want next.
But AI codes so fast, that it's a real struggle keeping up to it. I feel like I need to focus 10 times harder to be able to think about features/architecture in a way that AI doesn't wait after me most of the time.
Just a sideways thing. Cognitive offloading is something humans do with each other quite a lot. People offload onto colleagues, underlings and spouses all the time.
People engage with AI through the prism of reducing engagement with the thing they dont like, and increasing engagement with the thing they do like.
It isnt a straight up productivity boost, but its more like going from being a screenwriter to a director.
I don't see why. If anything there's more opportunity for documentation because the code was generated from a natural language prompt that documents exactly what was generated, and often why. Recording prompts in source control and linked to the generated code is probably the way to go here.
Except no YouTube, I just watch my shows off Plex.
No LSP server autocomplete has managed to do that.
The context switching may be difficult for some. Those that can manage it and excel at these new skills will undoubtedly become more productive than those who cannot and do not.
Expectations of full agentic parallelization is still not so widespread though as employers are slow to pick up on the need to budget $2400-4800+ annually per developer for enough capacity with recent sota tools.
But now we can start the tasks and rest while they are ongoing, and wait until a later point to evaluate their result. So you have choices: do you avoid delegating any tasks because you think you can do them faster? Do you rest and do nothing or get distracted with non-work while you wait? Or do you begin parallel async work and interleave orchestration and evaluation tasks (performed serially as individual pieces)?
None of this is about breaking human psychology. It’s about how to adapt processes within lean methodologies that became pervasive in our industry.
If I could have it read more of my project in a single gulp and produce the 10-1000 lines of code I want in a few seconds, I wouldn't need it to go off and write the thousands of lines on its own in the background. But because even trivial changes can take minutes by the time it slurps up the right context and futzes with the linter and types, that ideal pair programmer loop is less attractive.
In the past, factories used to shut down when there was a shortage of coal for steam engines or when the electricity supply failed. In the future, programmers will have factory holidays when their AI-coding language model is down.
> if Anthropic is down, there is still Google, OpenAI, Mistral, Deepseek and so on
No company is going to pay for subscriptions to all of them. Either way, we'll see a new layer of fragility caused by overdependence on AI. Surely, though, we will adapt by learning from every major event related to this.
That really depends on your Macbook :). If you throw enough RAM at it, something like a qwen3-coder will be pretty good. It won't stack up to Claude, or Gemini or GPT, of course, but it's certainly better than nothing and better than useless.
> No company is going to pay for subscriptions to all of them.
They don't have to, every lab offers API based pricing. If Anthropic is down, I can hop straight into Codex and use GPT-5 via API, or Gemini via Vertex, or just hop onto AWS Bedrock and continue to use Claude etc.
I don't think this is an issue in practice, honestly.
Developers used to share code through version control before there were websites to serve the "upstream", and they used to communicate without bespoke messenger apps.
Their former ways of doing so still work just fine.
I meant locally as a company.
>programmers
Don't Look Up
Technology changes, people often don't.
Programmers will be around for a longer time than anyone realises because most people don't understand how the magic box works let alone the arcane magics that run on it.
Except it doesn’t fit. For a while now we’ve had access to basically all the knowledge in the world and most people don’t use it.
Why would people make the effort to build a website using AI when they didn’t do so with any of the existing no-code options available.
They won’t.
Will dev be exactly the same in 10 years time? No.
Will there be more devs than there are now? 100%
Will experienced devs make bank? Yes.
Pretty easy sell.
All signs point to it rapidly progressing towards this inflection.
Current agents are insanely good, every decent programmer using them knows this.
> All signs point to it rapidly progressing towards this inflection. Not really
> Current agents are insanely good, every decent programmer using them knows this. Also not really
If you find them "insanely good" you were likely doing work that was already very repetitive or broadly implemented by others.
They have their uses, but it isn't as pervasive as people believe.
You've set yourself up such that all I need to do is go "I'm developing complex veterinary software including integrations with laboratory equipment" and you're completely falsified. Why expose yourself like this instead of being intellectually humble?
The only reason that anyone has engaged with you here is because you're being intellectually arrogant.
Most of my day job is not about bashing out nextjs websites. In fact if I did that one day a year it would be a lot.
Cursor CLI, Codex and Gemini work too, but lag slightly behind in a variety of different ways that matter.
And if you think you’re getting better visual feedback through Cursor it’s likely you’re just not using Claude with your IDE correctly.
Also, cursor is both overpriced and very mediocre as an agent. Codex is the way to go.
Tools are for us to figure out what works and what does not. Saying be prepared to be disconnected sounds like slop by someone getting forced into someone else’s idea.
If someone has a great workflow using a tool like codex that’s great but it does not mean it has to work for me. I love using codex for code reviews, testing and other changes that are independent of each other, like bugs. I don’t like using it for feature work, I have spent years building software and I am not going to twiddle my thumbs waiting for codex on something I am building real time. Now I think there is an argument that if you have the perfect blueprint of what to build that you could leverage a tool like codex but I am often not in that position.
Once we collectively start actually engineering AI coding systems rather than trying to surf on vibes their power will become much more apparent to the naysayers who haven't invested the time in the processes and tools.
As for backing it up, if you want to hop on my company github you can check out the spark graphs for my projects, and feel free to poke around the code I've spent time tightening to see that it's not slop (have fun with the async simd rust in valknut/scribe), and keep in mind I have large private projects (>200k) that are active as well. I've probably delivered 400k LoC in the last month with >60% coverage on large codebases, 99.99% AI generated.
Honestly if it were any faster I would want a feature to slow it down, as I often intervene if it's going in the wrong direction.
The biggest long-term risk to the AI giant's profitability will be increasingly capable desktop GPU and CPU capability combined with improving performance by local models.
Whenever I experiment with agent frameworks that spawn subagents with scoped subtasks and restricted context, things go off the rails very quickly. A subagent with reduced context makes poorer choices and hallucinates assumptions about the greater codebase, and very often lacks a basic sense the point of the work. This lack of situational awareness is where you are most likely to encounter js scripts suddenly appearing in your Python repo.
I don’t know if there is a “fix” for this or if I even want one. Perhaps the solution, in the limit, actually will be to just make the big-smart models faster and faster, so they can chew on the biggest and most comprehensive context possible, and use those exclusively.
eta: The big models have gotten better and better at longer-running tasks because they are less likely to make a stupid mistake that derails the work at any given moment. More nines of reliability, etc. By introducing dumber models into this workflow, and restricting the context that you feed to the big models, you are pushing things back in the wrong direction.
I they don't see a viable path forward without specialty hardware
Negative experiences include times when I am lazy, turn off my brain and just accept LLM output. I am also a little skeptical about automating email handling, etc. that is cool technology but how useful is it, really? I can imagine insiders talking between themselves saying "feel the bubble!" but when talking with reporters they talk like "feel the AGI" or "oh no, our AI tech is so strong it will take over the world" - excellent strategies for pumping stock prices and valuations.
These things are somewhat useful, but it doesn't come for free, and I'm talking externalities here, which are not priced in.
So basically idea, model with very same capabilities, but distilled and optimized to have less size and faster inference.
I cannot promise 100x speedup, but I think 10x is very real.
https://openrouter.ai/rankings
It says "Grok Code Fast 1" is ranked first in token usage? That's surprising. Maybe it's just OpenRouter bias or how the LLM is used.
I would have assumed Claude would be #1
It's pretty good tbh. Some quirks but it's efficient at making changes and seems to understand code pretty well.
(LLMs seem to think Go embeds can use ../../style relative paths, they cannot. And when they notice it doesn't work like that, they use the weirdest shit to try to fix it.)
If you want better speeds, your coding agent might perform better outside US office hours :)
Having it integrated into my IDE sounds like a nightmare though. Even the "intellisense" stuff in visual studio is annoying af and I have to turn it off to stop it auto-wrecking my code (eg. adding tonnes of pointless using statement). I dont know how the integrated llm would actually work, but I defo dont want that.
This is the magic sauce compared to copy-pasting snippets to a web browser.
It can automatically read code, search through it and modify multiple files automatically. Then it can compile it, run tests, run the actual application to check it works etc.
But when it doesn’t output what you want you spend mental energy and extra time reorienting to get back on track.
About 50% of the time it works every time.