It doesn't even have to be that. Take that and bump it 5 times like a million dollars. Throw in more cash if they can increase Firefox's market share. Have clauses to penalize anything about opt-out telemetry or anti-privacy features. I'm happy to add more carrots as well as more sticks.
All said and done, that will still be way more reasonable than that ludicrous salary.
> The actual answer to this is terrible. Courts had to trust the computer was correct. There was a common law presumption that a computer was operating correctly unless there is evidence to the contrary
That is just mind bogglingly stupid - who the hell are the idiots who wrote a law like that? Any of them wrote a line of code in their life?
It's incremental, and goes back to things like clocks.
Imagine a witness says "I saw him go into the bank at 11:20. I know the time because I looked up at the clock tower, and it said 11:20".
Defence argues "The clock must have been wrong. My client was at lunch with his wife by 11:15".
Clocks are simple enough that we can presume them to correct, unless you can present evidence that they are unreliable.
This presumption was extended to ever-more complicated machines over the years. And then (fatally) this presumption was extended to the rise of PROGRAMMABLE computers. It is the programmability of computers that makes them unreliable. The actual computer hardware rarely makes an error that isn't obvious as an error.
The distinction of software and hardware is a relatively recent concept for something as old as common law.
Isn’t it a similar case in the USA where intoxication breath test computers are similarly obscured from scrutiny? People have argued that they have a right to “face their accuser” and see the source code only to have that request denied. So, black box.
Breathalyzers aren't typically considered sufficient evidence in of themselves to convict (or exonerate), iirc many PDs have a policy of treating a breathalyzer hit as probable cause more than anything and then either they throw you in the drunk tank if you don't demand a blood test to verify, or, if they want to actually prosecute you, they get a warrant for a blood test.
AIUI breath test only establishes probable cause. If you fail a breath test you are taken for a blood draw.
Breath test results are routinely challenged (sometimes successfully) by demanding records showing that the device has been tested and calibrated according to the required schedule.
I meant courts should've called in multiple expert witnesses and even computer forensics companies. This case looks like government or in this case courts colluded with British Post Office.
> Perhaps also on the software engineer who testified repeatedly under oath that the system worked fine, even as the bug tracker filled up with cases where it didn't
Partly on account of the "perhaps" in the original, and partly because I have seen (elsewhere) "just doing his job" defenses.
In corner cases, culpability for uncertain expertise can be a tricky issue - you may recall the case of the Italian geologists, a few years back, indicted for minimizing the risk of an earthquake shortly before one occurred - but the case here seems pretty clear-cut (again, I'm speaking morally, not legally.)
It is 80/20 again - it gets you 80% of the way in 20% of the time and then you spend 80% of the time to get the rest of the 20% done. And since it always feels like it is almost there, sunk-cost fallacy comes into play as well and you just don't want to give up.
I think an approach that I tried recently is to use it as a friction remover instead of a solution provider. I do the programming but use it to remove pebbles such as that small bit of syntax I forgot, basically to keep up the velocity. However, I don't look at the wholesale code it offers. I think keeping the active thinking cap on results in code I actually understand while avoiding skill atrophy.
well we used to have a sort of inverse pareto where 80% of the work took 80% of the effort and the remaining 20% of the work also took 80% of the effort.
I do think you're onto something with getting pebbles out of the road inasmuch as once I know what I need to do AI coding makes the doing much faster. Just yesterday I was playing around with removing things from a List object using the Java streams API and I kept running into ConcurrentOperationsExceptions, which happen when multiple threads are mutating the list object at the same time because no thread can guarantee it has the latest copy of the list unaltered by other threads. I spent about an hour trying to write a method that deep copies the list, makes the change and then returns the copy and running into all sorts of problems til I asked AI to build me a thread-safe list mutation method and it was like "Sure, this is how I'd do it but also the API you're working with already has a method that just....does this." Cases like this are where AI is supremely useful - intricate but well-defined problems.
> once I know what I need to do AI coding makes the doing much faster
Most commenters on this paper seem to not respond to the strongest result from it. That is, the developers wrongly thought and felt that using AI had sped up their work. So we need to be super cautious about what we think we know.
It's often said that π is the factor by which one should multiply all estimates – reducing it to ɸ would be a significant improvement in estimation accuracy!
I think it’s most useful when you basically need Stack Overflow on steroids: I basically know what I want to do but I’m not sure how to achieve it using this environment. It can also be helpful for debugging and rubber ducking generally.
i don't mean to pick on your usage of this specifically, but i think it's noteworthy that the colloquial definition of "rubber ducking" seems to have expanded to include "using a software tool to generate advice/confirm hunches". I always understood the term to mean a personal process of talking through a problem out loud in order to methodically, explicitly understand a theoretical plan/process and expose gaps.
based on a lot of articles/studies i've seen (admittedly haven't dug into them too deeply) it seems like the use of chatbots to perform this type of task actually has negative cognitive impacts on some groups of users - the opposite of the personal value i thought rubber-ducking was supposed to provide.
There is something that happens to our thought processes when we verbalise or write down our thoughts.
I like to think of it that instead of having seemingly endless amounts of half thoughts spinning around inside your head, you make an idea or thought more “fully formed” when you express it verbally or with written (or typed) words.
I believe this is part of why therapy can work, by actually expressing our thoughts, we’re kind of forced to face realities and after doing so it’s often much easier to reflect on it. Therapists often recommend personal journals as they can also work for this.
I believe rubber ducking works because in having to explain the problem, it forces you to actually gather your thoughts into something usable from which you can more effectively reflect on.
I see no reason why doing the same thing except in writing to an LLM couldn’t be equally effective.
Indeed the duck is supposed to sit there in silence while the speaker does the thinking ^^
This is what human language does though, isn't it? Evolves over time, in often weird ways; like how many people "could care less" about something they couldn't care less about.
Well OK, sure. But I’m having a “conversation” with nobody still. I’m surprised how often it happens that the AI a gives me a totally wrong answer but a combination of formulating the question and something in the answer made me think of the right thing after all.
All those things are true, but it's such a small part of my workflow at this point that the savings, while nice, aren't nearly as life-changing to my job as my CEO is forcing us to think it is.
Once AI can actually untangle our 14 year old codebase full of hosh-posh code, read every commit message, JIRA ticket, and Slack conversation related to the changes in full context, it's not going to solve a lot of the hard problems at my job.
Some of the “explain what it does” functionality is better than you might think but to be honest I find myself called on to work with unfamiliar tools all the time so I find plenty of value.
The issue is that it is slow and verbose, at least in its default configuration. The amount of reading is non trivial. There’s a reason most references are dense.
> But nothing will make them stick to the one API version I use.
Models trained for tool use can do that. When I use Codex for some Rust stuff for example, it can grep from source files in the directory dependencies are stored, so looking up the current APIs is trivial for them. Same works for JavaScript and a bunch of other languages too, as long as it's accessible somewhere via the tools they have available.
Hm, I never tried codex so far, but quite some other tools and models and none could help me in a consistent way.
But I am sceptical, because also if I tell them explicitel, to only use one specific version they might or not might use that, depending on their training corpus and temperature I assume.
Learning the thing. It’s not like I have to use all the libraries of the whole world at the job. You can really fly over a reference documentation if you’re familiar with the domain.
If your job only ever calls on you to use the same handful of libraries of course just becoming deeply familiar is better but that’s obviously not realistic if you’re jumping from this thing to that thing. Nobody would use resources like Stack Overflow either if it were that easy and practical to just “learn the thing.”
Absolutely this. For a while I was working with a language I was only partially familiar with, and I'd say "here's how I would do this in [primary language], rewrite it in [new language]" and I'd get a decent piece of code back. A little searching in the project to make sure it was stylistically correct and then done.
> and then you spend 80% of the time to get the rest of the 20% done
This was my pr-AI experience anyway, so getting that first chunk of time back is helpful.
Related: One of the better takes I've seen on AI from an experienced developer was, "90% of my skills just became worthless, and the other 10% just became 1,000 times more valuable." There's some hyperbole there, I but I like the gist.
100% agreed. It is all about removing friction for me. Case in point: I would not have touched React in my previous career without the assist that LLMs now provide. The barrier to entry just _felt_ to be too large and one always has the instinct to stick with what one knows.
However, it is _fun_ to go over the barrier if it is chatting with a model to get a quick tutorial and produce working code for a prototype (for your specific needs) where the understanding that you just developed is applied. The alternative (without LLMs) is to first do the ground work of learning via tutorials in text/video form and then do the cognitive mapping of applying the learning to one's prototype. I would make a lot of mistakes that expert/intermediate React developers don't make on this path.
One could argue that it shortcuts some learning and perhaps the old way results in better retention. But, our field changes so fast... and when it remains static for too long, projects die. I think of all this as accelerant for progress in adoption of new ways of thinking about software and diffusing that more quickly across the developer population globally. Code is always fungible, anyway. The job is about all the other things that one needs to do besides coding.
Agreed and +1 on "always feels like it is almost there" leading to time sink. AI is especially good at making you feel like it's doing something useful; it takes a lot of skill to discern the truth.
It works great on adding stuff to an already established codebase. Things like “we have these search parameters, also add foo”. Remove anything related to x…
The problem is I then have to also figure out the code it wrote to be able to complete the final 20%. I have no momentum and am starting from almost scratch mentally.
This is just not true in my experience. Not with the latest models. I routinely manage to 1-shot a whole "thing." e.g. yesterday I needed a Wordpress plugin for a single-time use to clean up a friend's site. I described exactly what I needed, it produced the code, it ran perfect first time and the UI looked like a million dollars. It got me 100% of the way in 0% of the time.
I'm the biggest skeptic, but more and more I'm seeing it get me the bulk of the way with very little back-and-forth. If it was even more heavily integrated in my dev environment, it would save me even more time.
We noticed a lot of tools neglect international use cases, so from the beginning we've focused on building with global flexibility in mind. About 80% of our customers are US-based, but we have users all over the world and offer international tax presets and account types.
Exactly. The database level RLS has to be honoured even by the model. Let the "guard" model run at non-escalated level and when it fails to read privileged data, let it interpret the permission denied and have a workflow to involve humans (to review and allow retry by explicit input of necessary credentials etc).
My main challenge is that we don't have wired ethernet access in our rooms so even if I bought a mini-NAS and attached it to the router over ethernet, all "clients" will be accessing it over wifi.
Not sure if anyone else has dealt with this and/or how this setup works over wifi.
There is also power line Ethernet adapters that are well above 300mbps. Even if that's the nameplate speed on your wifi router, you won't have as much fluctuation on the power line. But both adapters need to be on the same breaker
I think they are making me more productive in achieving my targets and worse in my ability to program.
They are exactly like steroids - bigger muscles fast but tons of side effects and everything collapses the moment you stop. Companies don't care because they are more concerned about getting to their targets fast instead of your health.
Another harmful drug for our brain if consumed without moderation. I won't entirely stop using them but I have already started to actively control/focus my usage.
Your steroids comparison made me think of Cal Newport's recent blog post[1] where he argues that AI is making us lazy. He quotes some researchers who hooked people up to EEG machines then had them work. The people working without AI assistance incurred more brain "strain" and that's probably a good thing.
But even he doesn't think AI shouldn't be used. Go ahead and use it for stuff like email but don't use it for your core work.
I haven't read the entire paper, but just looking at the abstract and conclusion it ironically seems...lazy? Like we're going to have some people use ChatGPT 4 times in 4 months and draw conclusions on long-term brain activity based on that? How do you even control for noise in such a study?
I'm generally sympathetic to the idea that LLMs can create atrophy in our ability to code or whatever, but I dislike that this clickbaity study gets shared so much.
Of all the things I think AI shouldn’t be used for AI is one of them (unless you’re like completely illiterate). Whenever I get a “project status update” and the section header emojis show up I instantly just want to throw that garage in the trash.
Calculators are a very narrow form of intelligence as compared to the general-purpose intelligence that LLMs are. The muscle/steroid analogy from this same discussion thread is apt here. Calculators enhanced and replaced just one 'muscle', so the argument against them would be like "ya but do we really need this one muscle anymore?", whereas with LLMs the argument is "do we really even need a body at all anymore?" (if extrapolated out several more years into the future).
All said and done, that will still be way more reasonable than that ludicrous salary.
reply