Comment by paytonjjones
9 days ago
Obviously security is the bigger issue, but reading through this, all I could think about was how many tokens it must have spent doing all that to fix 2 lines of CSS
9 days ago
Obviously security is the bigger issue, but reading through this, all I could think about was how many tokens it must have spent doing all that to fix 2 lines of CSS
Lines of code for a bugfix is a really bad proxy for effort required.
You should estimate how much time it would have taken a human
30 seconds or a minute? Look at the diff he links to: https://github.com/datasette/datasette-agent/commit/a75a8b72...
Every browser has an inspector that can show you which element is causing overflow. You walk through the tree, find the offender, and add min-width or overflow. Zero tokens, just like in the old days!
Now, granted, because the garbage LLM code he’s working with has CSS inside HTML inside JavaScript inside Python (I wish I were kidding), finding the styles in his codebase might’ve taken a minute. But even then!
Yeah looking at that diff it should be very quick. My point was mostly that it was a bad metric, not if was correct or not in this particular case. I'm sure everybody's had a bugfix that took days to debug and it was just a couple of lines to fix.
Or sometimes a fix is obvious, but because it requires changing the code of a dependency, it's actually quite tedious to implement.
I was thinking of this too. It did all that what not only for a single line that is a simple thing even for someone new to web coding. That's to say the process matters more.
> Zero tokens, just like in the old days!
because you zero rate your own human attention, which you should value
1 reply →
A small diff /= a small change! They are completely separate things. Quite often a small diff is hours of actual work. Even in this case _finding_ those lines could have taken work - we don't really know.
1 reply →
5 minutes if you know CSS. And if you don’t, about the time for you to ask someone that knows CSS. In the worst case, the amount of hours to learn CSS.
So if you’re doing web pages, learn CSS.
Generally, if you’re doing something that directly involves X, learn how X works.
ADDENDUM
In most jobs, you’re going to be involved in only a few distinct technologies, learn those well and life is going to be easier. And most are transferable to the next job.
ain’t no one learning all of that
I looked at the screenshot and for the rest of the article wondered if it would be as simple as `overflow-x: hidden`.
And to my surprise it was.
This would’ve take a frontend dev 10 seconds to deduce and another 10 seconds to confirm.
The thing that puzzles me is that I would expect overflow-x: hidden to result in text typed into that textarea being wider than the page and being invisibly truncated on the right hand side.
But that's not what happens. And in fact, when you start typing in the textarea the horizontal scrollbar vanishes - it's only there when the textarea is empty.
Am I misunderstanding anything here? Seems like it's some weird Safari bug, since Firefox and Chrome don't have the problem.
1 reply →
I mean - that looks like a pretty easy CSS fix to play around with in developer tools, and I'm not even a frontend person. Maybe a few minutes max?
$12 worth, it seems
Imagine telling someone in 2015 that you can just tell your computer to fix a 2-line CSS bug and it only costs $12
'only'? A web developer did not cost 12*30=360$ an hour in 2015, and that's assuming that going "ugh, whatever. I'll just hide the problem with overflow:hidden instead of finding the underlying cause" takes him or her 2 minutes and isn't already the dev's initial reaction
Another way of looking at it is using as much electricity as a normal person in a high-income country uses across ~3 days to add overflow:hidden in the end. Of course, the path to get there did a lot more, but you don't know that beforehand if you don't take a quick peek and make an architectural decision about what the solution should be that gets implemented
3 replies →
Or even in 2026. You absoutely will pay a human that for that work.
1 reply →
It’s simple: if you have to fix 2 lines of CSS you should definitely not use Fable. Only use it for complex and long running tasks :)
I don't think it's that simple. (I generally agree with you; I just that that oversimplifies.)
Another model might have used fewer tokens, but come up with a fix that was 1000 lines when the right fix was only 2 lines.
"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."
I'm convinced this is going to be the summary of the 2020 decade...
To be fair, they did stop to think if they should. The decided that they shouldn't and went ahead and did it anyways.
If we're in a simulation, maybe it's a simulation about the dangers of AI.
If we're in a simulation, we are AI. But someone could be studying what happens when AI makes its own AI.
1 reply →
This one of the places to manufacture the consent for that to take place, because we are commenting within an organization that has given the money to ensure it that what could be is done. Most people clapped and made money, who cares what happens next, making money is the only good that matters.
[flagged]
I understand this perspective. I'll just note that as the abilities increase, the intent is to have some non -coding IC or TPM/manager literally just managing some LLMs and cutting out some software engineers. The goodness is specifically to wholly replace people who code first and foremost, at least partially. It just has to cost less tokens than the equivalent wage is the pricing goal.
And people who use LLMs to talk for them (e.g. email, slack) are deplorable. A completely disrespectful use case in my view.
The desire to get rid of software engineers is bizarre - because at the root of it, developers were there not to just write the code, but to ask right questions and based on these question build right things.
I've met in my professional life some managers or other middlemen who would be profoundly incapable of producing correct software no matter how smart of an AI agent they have access to. One of those - you don't know what you don't know.
But, I guess this is the world we live in now. Going to be Mortal Kombat for positions in companies where software engineers are actually valued.
5 replies →
It seems that you've not worked out how to harness the LLM as a tool to improve your qualified knowledge and abilities in a domain, and have instead focused on whether or not its a crutch for lack of knowledge or laziness.
When paired with your skill and knowledge, it is a force multiplier. You maintain control, the ability to direct, structure, strategise, and refine.
That some are using it as the entire brain does not mean that this is how everyone is using it, or how you must use it. The models can be fantastic at breaking past certain issues, surfacing qualified information, and surfacing related distributed information to help you acquire it and pick up what you need on niche topics quickly. Something as basic as copilot hooked into sharepoint can make life a lot easier when you are in a big org. Something like claude code or codex can be great at hunting down issues in an unfamiliar code base rapidly. Whether or not you outsource the thinking component is entirely up to you, but ignoring the productivity side of the tool because it can do some of the thinking is a case of focusing too hard on the negative.
Im not denying its usefulness for Q&A on docs/code as a search tool. Im talking about people who use it design and write their code, people who are offloading problem solving altogether, they aren't faster.
1 reply →
Yeah there are some tasks which it is a definite speed-up but I think overall its probably only marginally beneficial. Which is why, ~6 months into 10x productivity we aren’t seeing ai boosters shipping 5 years worth of software.
It’s possible to produce 10x the lines of code.
But that’s not the same as producing 10x functionality that will be used or is wanted by users or customers.
You're fighting a battle you can't win. Doesn't care what you think about those using LLMs, they will outproduce you and in corporate environments, shipping things is paramount. If I can ship 5 more things simultaneously with AI, I'm going to beat you even if you think you're creating "better" software.
Example of whats been shipped?
19 replies →
They don't out perform me though...
Consider this. U have a website. U have to translate to xx languages. Can u write it faster than an AI? If so how much faster can u do this?
Is it valuable to u? Is it valuable to a Chinese person? A Spaniard?
Google Translate counts as AI.
Don't feed the troll.
[flagged]
I pay $100/month to Anthropic and $100/month to OpenAI at the moment, plus whatever I spend on their APIs (usually less than $20/month for each, I use the subscriptions for most things.)
A couple of months ago I was paying $200/month for Anthropic and $20/month for OpenAI. I decided to split it evenly to get full access to both of their offerings.
I've actually chosen not to sign up for their free plans for open source maintainers, because paying the regular subscription price feels more honest, given that I write about them so much.
I do have the free GitHub Copilot for open source maintainers deal - I've had that for years. Given how much code I have published on GitHub over the decades I feel less conflicted about that one.
I sometimes get preview access to models, which includes the ability to use them for free during the preview. That comes with a big catch though: I can't publish any of the code that I write using those previews while the model is still unreleased.
As a result I don't use those preview tokens much at all, because the vast majority of my work is open source and I don't want restrictions on when and where I publish the code I'm producing.