It's glorious isn't it. We get free work done through subsidies. At the same time, this is what threatens my job, and the money for the subsidy is basically my own invested pensions.
The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
So it's already an improvement. Should it be manually read, comprehended, reviewed? Probably. But they can get to an improvement over what they did 2 years ago, with basically no effort. And then they can get a little bit further, with massive effort?
The "LLM-yolo" is a big knee in the cost/benefit curve. It's an improvement over their "old code". The only drawback is: it's still containing bugs, and now no one understands them. But that's not hitting them until that code has aged somewhat, so a year or two down the line.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
If mediocre code is better quality than what you wrote by hand, you've quickly discovered that you're incompetent.
> If mediocre code is better quality than what you wrote by hand
Most code I have seen and reviewed over my 25+ year programmer life has been no worse than mediocre LLM code.
It's not a massive sample, but to me it suggests, most code programmers write, is somewhere between bad and mediocre.
And here's the appeal of the models: if what you used to produced was bad-to-mediocre, and you can now do slightly better for much cheaper, that's a huge win.
> And here's the appeal of the models: if what you used to produced was bad-to-mediocre, and you can now do slightly better for much cheaper, that's a huge win.
And the guy you were responding to is seeing people produce worse code with LLMs (e.g. senior engineers pushing non-library bubble sort implementations, like they're in a high school programming class).
And if you're somehow right, it's not a "huge win" for you. It's a sign you're personally providing little value to the business, and sooner or later you'll need to find a new career.
What I'm saying is the quiet part out loud: A majority of coders and a majority of really IS bad. And now a lot of that code is actually better (big win).
Basically: the code was so bad before, that un-reviewed LLM-code is now better than the average contribution. That means, that at least short term, the vibe coding can increase quality.
The problem is that it also increases code volume (bad) and rapidly decreases understanding (even worse).
Yeah I've been experimenting with a bunch of different domains: 2D CAD, PCB design, coding obviously and recently I had Claude finish a project on all three fronts: finish the firmware(in rust because why not), change up a few components and finalise the pcb design, source all the non pcb components and do all the documentation for the installer. To be fair, it had a solid base to build from, but still, almost everything was "good enough", now I'm at work looking at PCB design that take the electrical engineers 8 weeks when I know I could have had two prototypes shipped and tested already. The fact is 90% of people are not doing the really hard stuff and Claude can just brute force pretty much any low to mid tier white collar task given enough information.
Code volume and understanding can be tackled with a proper system prompt. Even afterwards, apart from costing resources, a cross-model optimization can increase quality of the output.
Unix philosophy in the system prompt could be useful if the code wants to be worked on later again.
> Unix philosophy in the system prompt could be useful if the code wants to be worked on later again
There is no system prompt that can prevent this. If all you needed was some kind of rather short instruction we'd already have that baked into harnesses a long time ago. The problem is not that agents do not have the right instructions, they theoretically have everything there is to know about software architecture already in their training data.
They do have "everything" but that's too much, I think. They need to have direct instruction that is in the context, that is appropriate for the project and codebase at hand. In the whole universe of training data, there's every approach imaginable. What's needed is enough guidance to identify the right approach consistently.
I recognize that crafting a 'perfect' prompt is impossible, but neither is writing the perfect code, or even the 'perfect' code style guide. But it is 100% the kind of problem that can be iteratively improved to a point where it's much better than what you get by one-shotting everything without much consideration of these details.
I myself am maybe 5% sophisticated if 0 is I just discovered LLMs today, and 100 is the most skilled at using AI the world has seen. What I've learned so far is that I have a lot of room to improve.
Which is why I am actually not completely worried about the careers of current software engineers: If you brought in a bunch of non-engineers to prompt Claude to build and maintain an ERP system, or a social networking site, or an ad exchange, or even Shopify clone, I don't see those products being competitive with ones where engineers armed with the same LLMs are building them.
> They need to have direct instruction that is in the context, that is appropriate for the project and codebase at hand
> I recognize that crafting a 'perfect' prompt is impossible, but neither is writing the perfect code, or even the 'perfect' code style guide
This is not about "perfect code" or style guides. For code styles we have linters, that does not require any instructions. I'm talking about software architecture for large complex web applications that dozens of people (that also change frequently) contribute to and that is spread across many different repos/services and an environment with constantly changing business requirements.
The terms that are relevant here are: coupling, cohesion, vertical slices, module boundaries and so on. This is software architecture and coding agents are terrible at this and there is no prompt and no instruction fixes this that could reasonably fit into a context window. I don't even think that coding agents fail because the lack the instructions and therefore adding instructions won't fix these failure modes.
> What I'm saying is the quiet part out loud: A majority of coders and a majority of really IS bad....
How would you know "the majority" from your anecdotes? Maybe you just spent your career working with incompetent people who didn't care.
And actually there's a point I forgot to address earlier, in my first comment:
>>>>> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
People whose hand-written code is worse than "mediocre LLM-code with a mediocre LLM-review" are not going to discover the LLM-code is better, because they typically don't care. That's usually the whole problem with that kind of person.
> ...And now a lot of that code is actually better (big win).
> Basically: the code was so bad before, that un-reviewed LLM-code is now better than the average contribution. That means, that at least short term, the vibe coding can increase quality.
> The problem is that it also increases code volume (bad) and rapidly decreases understanding (even worse).
You're contradicting yourself here. Even accepting your statements uncritically, it doesn't sound like a "big win." It sounds like a marginal improvement that's ultimately self-defeating.
The problem with hand review I always had was trying to teach the other person. You don't want to present them with an avalanche of problems. So you pick the most important 5. Over time this iterates and you build someone good at what they do.
The good part of LLMs is you don't have to worry about overloading them: you can just outline every problem with the code they produce.
The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
There's also the problem of this ultimately being my code. It isn't Claude's - Claude isn't a person.
I still read the code. I use LLMs to review it. But I also review it myself. Ultimately its faster than before, and probably better quality (because I can just give all the problems to the LLM), but slower than people doing zero review.
> The bad part of LLMs is they don't really "get better" at this stuff. I'm not training a human, and there's a limited amount LLMs can learn. So the training phase never really ends - it's Eternal September.
After I give feedback to the AI I then ask it if we learned something and then I ask it to store that guidance in a relevant skill file.
I have skill files for everything and anything in my project. Three just for testing - one for frontend, backend, and e2e. I have one just for frontend forms. I have one for project terms, which I ask it to read before doing anything, so it keeps the terms in the project right. I have one for doing db migrations and one for doing backend routes. I have many tens of skills that have been slowly built up like this.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Not my experience at all. Mediocre LLM-code, mediocrely reviewed is a loaded footgun aimed at both your feet.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
Emphasis mine.
I can't phantom some that bad at coding. Using such exaggeration void your comment.
> The thing is: people quickly discover that even mediocre LLM-code with a mediocre LLM-review, is still better quality than what they hand wrote and hand-reviewed.
No, I find that most teams I've been on have 5% to 20% of their most artisan engineers actually giving a shit about the code, and gently coaching the other 95% to 80% of the engineers who are usually much more junior during code review to not push unmaintainable slop. If you're on a team that doesn't still have someone giving a shit, it's not a sign that there are no teams that don't give a shit, it's that you're on a shit team.
There are also teams where the incentive is to get to pull request (or merge request) as soon as possible, so that you can move the ticket across the board and relieve downward pressure. That usually means pushing subpar code to PR that you know you'll spend another few hours fixing. EDIT: I bring this up because this can bias one's belief that humans produce poor quality code, when you're usually looking at the first draft that was incentivized to be pushed out "too early".
Anyway, if you're on a shit team, but you're still satisfying product and nothing is blowing up yet, there's a pretty good sign that your software has no moat and will be the first to be replaced by LLM-generated software on-demand. This is probably where most niche B2B back-office, front-office software sits. Stuff that sits somewhere in the realm of "We could probably do this in Excel if we wanted to."
These services were just the natural extension of the phonebook. At the exact same time as the phonebooks stopped being circulated, these services popped up online.
And since everyone's name, address and phone number was in the phone book (At least for their city) people didn't find it weird when it popped up online. Sure, to do the same thing for the whole country you'd need dozens of phonebooks for different areas, but it was just the same information.
Which makes me wonder: weren't there phonebooks in US cities and in other countries before? Were they incomplete/opt-in?
The key thing about the Swedish phonebooks were that they were opt-out, so people were basically all in the phone book. So even before the internet, it was just very natural that your name, address and phone number was public. "Getting someone's number" as in moves and TV wasn't a thing. You could just call anyone if you knew their name.
Yes, we had phone books. And it was useful. But they didn't generally include personal information such as birthdates, salary, etc. And it was easy to opt out. Additionally there were not a bunch of online services with financial impacts that used phone numbers are primary keys.
And, importantly, they were physical in a time when it was hard to collect and collate the data in all of them. In 1990, there were about 5,000 distinct "white pages" phone books in the US. And OCR was pretty crappy.
Also, in all the places that I lived, mobile numbers didn't end up in the phone books, only residential landlines did. I don't know if that was universal.
Right. It was harder to spoof my bank (since banking was an in-person affair), and steal all my money back then. Now, this information is available to anyone in the world, and there aren’t good protections. I don’t know the solution, but the world is a different place than it was in the days of white-pages.
In the UK, you could always choose to go 'ex-directory'. More and more people did over time I think and the personal part of the phone directory got slimmer and slimmer, basically just leaving the business part.
The F1 isn't just spectacle it's also something that should show real advancement in technology. They don't want to be seen as deliberately going back 20 years in tech.
But yes, they completely made the powertrains to opaque for the viewer, and they definitely missed the ball on the sound aspect.
I get that they need to look environmentally conscious but let's be honest: it's maybe one decade - two tops - until F1 is electric. Until then, why not just skip the hybrid bits and do loud and simple engines?
I was at a GP in september, something you do very much for the noise and spectacle - the race you follow best from your couch. And it was astonishing just how much better F3 and F2 sounds, compared to F1. And that surely can't be good for FIA.
> The F1 isn't just spectacle it's also something that should show real advancement in technology.
Maybe 30+ years ago. Carbon fiber parts, motors made of Beryllium alloys, the hybrid tech was interesting for a short while etc.
But then, either you want fun for the fans of the fossil engines OR you want advancement in technology. I don't think it can be combined anymore. My feeling is it will go the way of horse races, completely irrelevant to the broader transport technology, and won't go electric at all.
It's a shrinking market, but it surely doesn't help that people are simply boycotting US goods.
For example: Swedish sales for US wine was down around 20% in 2025. The overall decline was about 10%. In a shrinking market, you don't want to also have a shrinking market share.
I'm sure the figures are similar in other countries - and this year it's going to be very different in Canada as well. I imagine Canada was always a big importer of US wine seeing as it's close by and they don't have much domestic production.
Seeing many people comment that they drink less; I'm happy to report I still try to drink as often as I can (Which is still not as often as I want).
Yes, but many of those wineries import their grapes from California (or other places).
My wife and I participate in this boycott and were drinking a sparkling white from Mission Hill Winery which is one of the biggest BC wineries. We noticed the label said something like "Produced in Canada" and then listed grapes imported from California.
Wines that are produced from 100% BC grapes are labelled "BC VQA" and only 19% of the wines in BC are BC VQA.
This was a temporary measure for a couple vintages/years after a frost decimated nearly all the vines in the BC Okanagan. The regulators stepped in to allow relaxed importation rules to help wineries survive. A winery like Mission Hill typically grows and sources all of its grapes within BC.
I think this is temporary and related to crop failures when a lot of BC berries froze. AFAIK they grow their own grapes otherwise. Who knows for how much longer and if the climate will allow growing grapes sustainably at all in those places.
The wine from Canada is not good, unless you like dessert wine/icewine. Maybe there are some exceptions for riesling but it's too cold to grow nice vines there.
You can't be making such blanket statements. There are a lot of great wines. Some of the best syrah I've ever had is from BC, and there are plenty of other great wines.
My response to this would be drink more Syrah from Northern Rhone, because there is no producer in Canada that is producing Syrah anywhere near the quality (find me someone trying to claim they are; they cant the soil and climate are too different) . You can say it's subjective, but we both know it's not. I made one exception, Riesling, because their are some good expressions in cold weather.
I had wine from the niagara peninsula - it was either cabernet or a cab/merlot red blend. I enjoyed it as much as I enjoy most dry reds (which is a lot). It wasn't exactly the rival of France's appellations (high bar) but still very good.
That's because the LCBO has a monopoly on wine sales in Ontario and it's very difficult for Ontario wineries to get their good wines into the LCBO. It's a combination of shelf fees, minimum volume requirements, and an idiosyncratic evaluation system where their participation costs are not covered.
Spend some time at wineries on the Niagara escarpment and you'll find some great wines, especially whites that benefit from the limestone heavy soils. Even the large producers that have a poor public reputation for quality (Trius, Iniskillin, etc.) have much better wines available on site that never make it to the LCBO. For the most part (some exceptions), the people who run these wineries are wine enthusiasts who genuinely care about quality. Prices for that quality are higher than other wine regions with more favorable climates, higher production, and lower labour costs though, that is true.
> but it surely doesn't help that people are simply boycotting US goods.
Seems like that would be such a negligible number that, while it doesn't help, it doesn't hurt either. It's just statistically irrelevant when it comes to a global market like wine.
Exactly. Nobody was buying US wine, even the experienced winos and wine distributors for fancy dining that i've met here in Italy probably have never drunk US wine. Maybe new zeland, australia, south america, but i've never heard of somebody drinking an US wine.
And they weren't boycotting it, it's just not a good enough deal to buy from our prospective, even when people are looking to spend good money, there is better stuff to buy from elsewhere.
I think that trying to explain the reduced sales of California grape growers in terms of an international boycott of US products seems like highly motivated reasoning, not factual reasoning.
US exports have been growing every year since the pandemic low of 2020
We obviously do not have full data for 2026, but the first half is higher than the same time in 2025. But this is really driven by economic activity, so if there is a global recession, you can expect fewer people to buy US goods, just as you can expect Americans to buy fewer foreign goods. The 2020 low was not because of a boycott, but a general economic decline, and as far as I am aware, no boycott of US goods has ever been detected in the trade data, it's always been a media affair or hyperlocalized (e.g. some people boycotting Apple or Windows or Google seem to be the most common media stories).
And I think this is a pretty general situation, e.g. consumer boycotts rarely show up in trade data - to hit trade data you need government sanctions, nothing else moves the needle.
Noted elsewhere, Canada accounts for more than a third of US wine exports [1], so the trade-war with Canada in 2026 surely wasn't helpful either to keep export-volume at 2025-levels...
In a story explaining California wine growers pain, be aware that 98% of California wine is consumed in the US. Exports are negligible.
This is like when a story about housing costs was posted and the Canadians chimed in that the US housing woes are due to not having access to Canadian lumber, and the board had to explain to him that that 80% of lumber used in US production is sourced domestically.
The story is way more complicated and hides where the pain points are.
The real average is closer to 25% of lumber coming from Canada but if you look at specific types like SPF which is important for framing, it’s almost evenly split between US domestic and Canada-sourced. Douglas Fir is heavily sourced from Canada. But some lumber like SYP is almost all US domestic.
And in terms of particular states, tariffing Canada sourced lumber has outsized impact because Canadian lumber has a freight advantage so getting US sourced lumber is going to drive up prices even if Canadian is avoided.
It wouldn’t surprise me if the wine story was equally complicated.
Apart from the inflation mentioned above, there are a multitude of factors at play that cannot be determined by just looking at aggregated numbers. The price of some goods, for example, has skyrocketed due to general scarcity (electronics, oil...). Fx got worse for the dollar vs other currencies. And are numbers only for goods, or do they include services?
It is definitely a reality that certain goods have seen localized boycotts, like alcohol in Canada, and some services have had to change (data sovereignty in Europe got a lot of traction).
I think comparing by tonnage would be more apt than comparing dollar figures which are subject to a lot of external factors, including currency exchange rates and inflation.
Also, the idea that California wine - of all products - is very sensitive to exports is a bit strange since although California wine sales account for more revenue than the entire wine industry of any other country -- 68 billion dollars worth of sales each year (https://wineinstitute.org/our-industry/statistics/california...), the state exports relatively little, only about a billion dollars of California wine is sold abroad. So 98% of California wine is sold within the US. Only 2% is exported.
And yet there are so many people on this board that are convinced that Europe, of all places, is somehow responsible for driving California wine grower sales woes.
It's pretty funny if you think about it, you have some Bosnian dude and when you tell him that Ford is facing a sales slump he immediately shoots back -- it's because the Bosnians are no longer buying Fords! Truly an amazing example of economic narcissism.
TOTAL Retail value (includes markups by wholesalers, retailers and restaurateurs), NOT Sales Revenue.
> "only about a billion dollars of California wine is sold abroad"
That's Sales revenue [1]
> "So 98% of California wine is sold within the US. Only 2% is exported."
The data is right on the page you shared.
Total shipments 2024 [0] (in millions of 9-liter cases):
California wine shipments to US and export: 232.3
California wine shipments to US: 203.5
--> Export: 28,8
So the export volume in 2024 appears to be >12%, not 2%
There's no data for 2025, but wine exports fell by ~20% in 2025 [1], if TOTAL wine shipments fell equally this is quite a strong dent in volumes already in 2025. So 2026 doesn't look rosy to begin with before any trade-war being added...
> "It's pretty funny if you think about it, you have some Bosnian dude [..]"
So by my thinking, one billion is not 12% of 67 Billion. Indeed, it is less than 2%.
> Let's not do that please.
I agree that we shouldn't do it, or rather that commentators shouldn't do it, but I don't agree that we shouln't talk about commentators doing this.
You literally have this situation. Only 2% of California wine goes to the export market at all, and people are literally arguing that their personal boycott of some nation that doesn't even account for a billion in sales is driving California wine export woes. It is a bizarre form of economic narcissism and my example was apt.
As already stated, this is the ESTIMATED RETAIL VALUE of the wine, NOT the Sales Revenue.
You then conflate this with the EXPORT VALUE of Californian wine, which is not the retail value but the price the winery is selling the wine for to a foreign buyer.
Apart from that the value also doesn't matter, in the context of AMOUNT of grapes purchased the QUANTITY of wine produced is more relevant than the VALUE created with it.
> "You literally have this situation. Only 2% of California wine goes to the export market at all, and people are literally arguing that [..]"
Again, it's not 2%. You literally need to read the sources you cited yourself. They provide good data to educate yourself and see where you're trying to force a conclusion without the proper facts.
And nobody is "arguing" what you state. The OP stated "It's a shrinking market, but it surely doesn't help that people are simply boycotting US goods." and you're trying to ridicule him for that without having any leg to stand on...
Does it matter? Both are small nations that do not account for even 1% of global wine consumption and not even one hundredth of one percent of California wine consumption.
Doesn't it seem like ethno-narcissism to think that a boycott by some members of a demographic responsible for less than one hundredth of one percent of sales is the reason why a specific foreign company is having struggles. When there is the very obvious explanation of the whole world drinking less wine. We are going to skip the obvious universal explanation and go to the niche ethnic explanation?
> seems like highly motivated reasoning, not factual reasoning
Drawing conclusions by presenting total US exports doesn't seem like factual reasoning. Most exports are of non-consumer products, which aren't as influenced by boycotts. A true analysis would take into consideration items that consumers can chose to boycott.
I don't find your general data on US exports very convincing for this case.
Is there any way to separate US exports of consumer products (which would be affected by consumer boycotts) vs. US exports for industrial products or capital goods (which I wouldn't expect to be affected by these boycotts)?
It is entirely possible that specific consumer-focused industries (wine, tourism, etc.) are being strongly affected by international boycotts and having decreasing exports, even while industry/capital-focused exports (petroleum, plastics, weapons, medical equipment, telecom equipment, data centre electronics, etc.) are increasing at a faster rate which would hide the consumer boycott effect in total export $.
This is an incredibly disingenuous and specious argument.
The discussion is about US wine production and consumption. You present the aggregate total vale of all US exports in US dollars to 6 significant digits. Does the variance of the volume of wine exports in litres even show up in those 6 signifcant digits?
Consider: (1) is six significant digits of precision justified, or is it insignificant accurancy? (2) Do those aggregate numbers take into account inflation? (3) Do those aggregate numbers take into account the (not insignificant) devaluation of the US dollar? (4) Do those aggregate numbers include both goods and services?
No, if you were to make an honest argument by quoting US exports, you need to limit it to the volume of US wine exports in litres. Misdirection can be a great tool of propaganda but is not a useful contribution to interesting intellectual discourse.
I responded to the claim that this was due to a boycott of US goods writ large, not a specific boycott about wine.
What would be the reason to boycott wine only and not other US goods? What about the US wine industry is controversial that does not apply to the other industries?
So I wrote that there is no evidence of boycotts showing up in trade data, which is true.
Then, after doing some digging, so I pointed out that almost none of California wines are exported anyway. So obviously this cannot be the result of foreign boycotts.
So let's get back to the "incredibly disingenuous and specious argument", and start with the dictionary definition of those and go from there, because that accurately describes how I view your response.
> I responded to the claim that this was due to a boycott of US goods writ large, not a specific boycott about wine.
While boycotting iPhones might be difficult, taking the Cabernet one shelf over takes almost no effort or negative impact to the consumer. It's rarely more expensive to switch from a US wine e.g. French or Australian. It's sold in the same store.
For the specific example of Sweden, every single wine bottle in every store is sorted by country in the store. And it sits above a price sticker with the flag of the origin country on it.
That's wildly different from similar choices e.g. when you pick a can of Hellman's Mayonnaise, there's no US flag under it. But for wine in particular, the country of origin is almost always known to the buyer and involved in the process, even if Sweden stands out as an extreme due to the flag being under the bottle.
That's why I believe the boycott which isn't a boycott on US wine but on US products in general, is _most notable_ for wine or in some other case not notable at all because it's a small effect and consumers don't always know what is American and what isn't (Hellman's example). But for wine, everyone knows.
The difference between the general slump in wine sales (10%) and the decline in US sales (20%) could have more factors, such as price. But it's easy to assume - and polls suggest - that consumers really do avoid the US wine.
I (a programmer) just did a pretty large task with Opus 5.5 that was a perfect fit for a big token eating task. It ate into my weekly budget in a way that made me have to use anthropics one-off "reset" they offer now.
Long story: we have a big legacy desktop app. It uses a big legacy UI component (a grid control), which we had a license for in an old version. Fast forward 20 years, and to be able to move to a new runtime for our app, we need to update the component. Someone had bought the company making the component and now charges north of $1k per developer per year. So instead of doing this, we had just lived with the very old version.
We had long thought of writing our own control to replace the proprietary, but it was always going to be a man-year of work we thought. But I thought I'd give it a try with AI now. I told Opus: look at our uses of that control (tens of thousands of lines of code, it has over 100 instances across our User Interface). Write a new control that would compile with the exact same app syntax. First just make a dummy implementation that throws on every call. Then start implementing. Make a test suite that can run both with our new control and the proprietary control, and test everything, every function that can be called in its public interface and every state that can be inspected from the public API. Verify that everything behaves exactly the same, and lock it in with thousands of tests. Finally, check that the control _looks_ exactly the same as the proprietary one. Render to bitmaps, figure out the rendering logic from observation, such as arithmetic for padding, font sizes, and so on. Compare pixels until it's exactly the same.
Basically: it was a mammoth coding task, but it was so extremely well specified that an LLM could easily just do it. It's a clean-room implementation of something with no tests, but we had a test double that could provide 100% of the expected behavior. The description was extremely short. "Make a new thing that works like the old thing, and prove that it does". Opus 5.5 finished this in a number of hours. 500 source files, several thousand unit tests, and html reports with image diffs from the reimplementation and the original control. It did not use any disassembly or such "cheating". Only observation of the public API and the behavior.
Do we need to deeply understand the implementation? Does the architecture matter? Not much in this case I'd argue. It was a black box to begin with and it remains a black box. If we notice a bug, we can always point it to the original proprietary control and say "there's a behavioral difference when doing X" and it will fix it, and lock it down with tests.
As a programmer it's kind of chilling. I had recreated for a few tens of dollars something that would cost $1000 per year to buy. Obviously it's not a complete implementation only the parts of the API we use. It likely still has some bugs. We don't get support, we get to maintain it ourselves. But the rate of reverse engineering this thing "black box" was frightening. It hasn't created anything novel. But we must realize that as programmers some times we have man-years of work that just isn't novel. And in the past, we didn't do this work at all.
I wonder if those who write and sell libraries like this will start having explicit no-reverse-engineering EULAs soon? Perhaps even explicitly mentioning AI/LLM use in analysis and reimplementation?_ Obviously the library we reimplemented was from 2005 so didn't mention AI... (It doesn't mention reverse-engineering either, luckily).
Most products do in fact have an anti-reverse engineering clause in their EULA, to be fair, it's been a standard EULA term for a long while. It's just that no one cares anymore...
Yes, and usually in the form "You may not reverse engineer, decompile, or disassemble the SOFTWARE or any of its constituents, except and only to the extent that applicable law expressly permits". (This is the concrete example from this software). And as far as I understand, this means that so long as you stay short of decompilation - you can reimplement as much as you want.
The law that covers this (in the EU) is EU Directive 2009/24/EC, where Article 5 is the reverse-engineering-without-decompilation.
> The person having a right to use a copy of a computer program shall be entitled, without the authorisation of the rightholder, to observe, study or test the functioning of the program in order to determine the ideas and principles which underlie any element of the program if he does so while performing any of the acts of loading, displaying, running, transmitting or storing the program which he is entitled to do.
This is pretty difficult to parse, but luckily there is a ruling from the European Court of Justice on this: SAS Institute Inc. v World Programming Ltd (Case C-406/10), delivered on May 2, 2012.
SAS Institute claimed that World Programming Ltd (WPL) infringed its copyright by studying the behavior of the SAS software system and writing a competing program (the World Programming System) that emulated its exact functionality and used the same data file formats. WPL did not have access to SAS's source code and did not copy any of its literal text or internal structural design.
CJEU:
> "It must therefore be held that the copyright in a computer program cannot be infringed where, as in the present case, the lawful acquirer of the license did not have access to the source code of the computer program to which that license relates, but merely studied, observed and tested that program in order to reproduce its functionality in a second program".
Which is a good find. But this is where I wonder if LLM-based reverse engineering is going to creep into either law (via lobbying) and/or EULA's, because this "observe every single state of the program for every single mutation" was simply not a viable mode of reverse engineering in the past. Or, it was at least always cheaper than just buying the software! Not so any more.
Or alternatively, that programs stop having so many observable states, making more things public. But for libraries as in this case, the whole product IS the public API. Without a rich public API, the library can't be sold. And with it, I can observe it and copy it - because it's internal workings are "too simple" not to be deduced from the public API. In short: a UI control is a ton of hard-to-write but easy to copy boilerplate code. And selling this has been an industry, but I wonder if it will be for very long.
"And as far as I understand, this means that so long as you stay short of decompilation - you can reimplement as much as you want."
Yes, but my point is that.... go on github, you'll find tons of decomps. And many more done just privately too. One of the No Man's Sky devtalks start with "yeah we decompiled the terrain generation from this other game, implemented it in our prototype, it didn't work okay, here's how we've learnt from it to make something better". This was in 2016. More recently, this has been going on way more openly, even full AI-assisted decomps thrown up onto GitHub casually. It might be the letter of law or included in Terms of Service but no one cares really.
I wonder why they chose to use the tiny watch-size amoled board for this. Wouldn't a multi effect UX be better with one of the 4-7" touchscreen boards?
Also: Am i reading it right that you can get an ESP32 with a 7" touch screen for like $30?
It's the author here. AMOLED is beautiful to look at. And you can stick this device on your guitar. Having said that, the same code can be compiled to any ESP32-S3, even headless boards, to use in a custom pedal (like the ones with Daisy Seed 3). CoyoPedal uses Gea Stack that allows us to target any device, including macOS and even the web, https://coyopedal.playtaurus.com has the exact same DSP and UI code built for WebAssembly.
Conversion of legacy nontrivial C++ code bases into Rust (or anything else for that matter) feels like it should be one of the "Millenium problems" for AGI. That and full self driving - including the nuances of gesturing to a human about who's going to reverse in a single lane in a snowstorm.
But if 50% of code can be converted automatically to safe idiomatic Rust? Great. Doesn't sound too far fetched. But yes, there's certainly a long tail here.
> Conversion of legacy nontrivial C++ code bases into Rust (or anything else for that matter) feels like it should be one of the "Millenium problems" for AGI.
Whilst I have no doubt that LLMs will be useful here, I still have reservations about validation. I think experience tells us that test coverage is generally insufficient to ensure functional equivalence, and not all components are well specified.
The 10% excel sheets are exactly the problem. You can replace 90% or even 99% with either some online simpler office suite or none at all. But it will turn out there are business critical things running in 2003 format excel sheets with macros and if anything stops working then the organization stops working. The person who made these sheets and macros has retired 20 years ago and "updating it" would require making a dozen little applications to replace them which would be a huge task.
The simple/cheap answer I think is to just keep the power users and legacy systems on the tools they need/want. Because that's where the pain point is that cause these projects to fail. If you aim for 100% you'll end up with 0% eventually. If you aim for 90%, you can do it.
But Microsoft know this, and would make sure that a 90% migration saves you much less than a 100% migration. Which is why this is so rare still.
(I think the number is probably 99% not 90%, but the point is the same)
How many people in most government positions are using Excel?
SaaS and mobile has taken over many apps. We sell SaaS to business and govt clients where most end users are either on a browser or a mobile app. There is a Windows application (path dependent history) but it is almost vestigial for configuration/management.
of people with a laptop? Maybe half (Just a guess). But most of those are not using it for anything complex. But it doesn't matter, it's that 1% of excel users and their sheet that is the problem. You'll find where it is WHEN you try to phase out excel. Not before. The report will be "I can no longer run our weekly report thing because google sheets/liberoffice doesn't run the macro and now we can't update the schedule for the drivers and they're angry, please advise". The solution, invariably, is not to throw a contractor at the problem and write a web service for it. It's to just let that sheet keep working another decade and pay the excel license. It's much much cheaper. But it also means that the long tail of Excel stays.
The long tail of ms Excel does not get replaced easily. For 90% of customers and 90% of workflows you see either no use of a program, or use cases that can be replaced with anything.
But eventually you'll find the power users who do business critical stuff in excel sheets that you notice can't be done in any other way, and if you stop doing it then people aren't paid in time or whatever.
This doesn't mean it's a good idea to not try this. But Microsoft also aren't dumb. They know exactly how common this is, and what fraction this is. And they will make sure that it costs little more to keep the Microsoft products across the org, than it costs to keep them for specific users and deal with the mess that happens.
This could be said for other things than Excel, but Excel has been one of those moats for decades now.
But the general usage of Excel is so negligible in terms of using its actual features that it can be easily replaced.
In my experience, non-basic formulas are beyond 99% of people and they use it simply for adding stuff up in a grid. This is why Google Sheets is used in many places as a replacement (even if it balloons RAM usage when presented with a large sheet of data), simply because all of the wonderful features of Excel are unused.
The most complex operation some people do seems to be lookup tables.
Whatever is in those Excel sheets. In any nontrivial org, you'll find it if you try. We found users designing roof trusses in Excel with heavy vbscript macros...
> ...Excel has been one of those moats for decades now...
I think if we focus on "has been", and not consider something dire like "will always be"...then i see it as an opportunity (and opportunity for LibreOffice and others like it). Because i do agree that a small % of people do use/need advance features from excel...so if i were the European Union, then i would gather such data for advanced usage (which is best done when pilots are rolled out), and throw a little money at addressing that (by a little, i mean little for big governments, so talking like a few million, etc.). I'd throw some money at the devs who contribute to LibreOffice, openDesk, whatever...and specifically address whatever shotcomings might exist in the free and open source offerings. Maybe its not an overnight solution, but it would serve to produce 2 things:
1. You pay devs to address the issue...reducing or removing any gaps between excel and offerings like LibreOffice, etc.
2. The devs you threw money at will gain ever more experience addressing needs for this now more expanded marketplace...creating possibly some more jobs and/or opportunites for more local vendors to support these govs, and any businesses that follow suit in adopting such open source offerings...
...I think these create or expedite a marketplace...and one that is not controlled by the U.s. or any single dominant player. So, i think while it might be slow, its a good long-term approach.
reply