Also, when you consider the age difference between the two, Wireguard is OpenVPN plus the learnt lessons.
We should remember that we learn by failing.
Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.
Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.
The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.
Before OpenVPN there was IP-in-IP encapsulation, which is as simple as a VPN can get (no encryption, but that hadn't been invented yet). Wireguard is basically IP-in-UDP plus encryption. You know what else is basically IP-in-UDP plus encryption? IPsec, and it really sucks, for the same reasons OpenVPN does.
I'll personally pay (and do pay) for good development tools. I prefer free software tools primarily due to ethical and philosophical reasons (and I also want my code doesn't depend on any tool which can't be obtained in the future), but I have a couple of non-blocker, high quality, yet closed source tools in my arsenal.
> if your employees do not care (they are optimising for salary & time spent not code quality)...
From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I'd love to be wrong, very wrong about this, actually.
They don't care about maintainability because they're not going to be debugging it at 1am on Friday night but mainly because if something is wrong they have lots of people below them to blame for it.
Developers, however, are still responsible for the code! We must review the AI....all 80k lines of code it generated yesterday. If we don't then we are at fault. And we must go full throttle of course. So ....not be picky and retrograde about accepting what is generated.....
IOW we know who is going to get screwed and it isn't them.
Yeah but I mean, what is their compensation based on? I'm genuinely pretty curious about the point you're making here. I don't know anything about underwriting or how that profession works or how it is analogous to what you see as the future for software developers. But it seems interesting and possibly insightful.
I often have to ask myself if I’m asking for something different because of preference or need. I don’t really know what others are doing but I see this comment a lot about needing to always correct agents. I can’t figure out if it’s an exaggeration or not because once I’ve planned how I want something done I pretty much have zero need to intervene.
Impossible to know without doing a detailed comparison. Are you using the same LLMs? Are your criteria for correcting the output the same? Are you working on similar code? Are your plans and prompts the same?
It's fine to have preferences. The biggest problem with bikeshedding is the time spent (wasted) debating. But you don't have to debate the AI, you just tell it your preferences, and ideally encode them so that they are repeatable.
Of course it's fine to have preferences. I think you missed the nuance. Bikeshedding implies the time is wasted because the topic wasn't important in the first place. The color of the bike shed, as it were, has nothing to do with the storing of the bikes.
I am equating the nerve that develops in people that get lost bikeshedding (wasting time on inconsequential parts of the problem) with fighting an llm on inconsequential implementation details.
We most certainly agree: what matters should always be the actual requirements (functional, security, performance, etc.) You can't bikeshed an important topic. Everything else is implementers decision. In my experience an experienced engineer understands the difference and trusts implementers to make the decisions that they do own.
No I understand the nuance. But it's only bad to have preferences about things that barely matter if you waste time on them. You don't have to fight the llm, you just tell it what you prefer and it does that, that's what's great about them. (If it is not listening to your directives, then you have other problems.)
You use the intentionally vague word "implementers" to abstract whether you're delegating to a human or to an AI. But the key point is that these are not the same thing. If I'm delegating to a person, that person is the "implementer". If I'm using an AI to generate an implementation, I am still the "implementer", it is merely a computer program working on my behalf.
Directing an AI's work is not "fighting it". You keep characterizing it that way, but it's the wrong characterization. "Implementer" is not blurry at all. Humans are responsible for the things they implement, whether or not they use AI tooling to do that implementation.
Is that my characterization? This subthread is about how it’s so time consuming fixing every little thing the AI does to be just like you would have done. My challenge to that sentiment is “give it some freedom, don’t micromanage it.” That’s all.
I understand the boundaries of ownership and responsibility. That’s why I can tell you if you are spending inordinate amounts of time correcting AI code then you’re doing something wrong. Either write the code yourself or reassess your ownership boundaries. You’re acting as a manager of a team of agents in an agentic coding paradigm. Managers don’t tell me how to write code.
> From what I see is it's mainly managers and higher brass who doesn't care about code quality and sustainability, and aims to drive time to market metrics down aggressively with AI.
Trends over time will drive more observable changes. If a whole generation of programmers picks up bad habits that their managers don't care about (think very junior), that will take some time to play out. It's like children's literacy. You don't notice overnight, but a decade of neglect and you have a reading problem in kids.
Yes, this is why it's good that we're having these debates. We should keep having them. Personally, I am not yet convinced that this is a real problem. But I also haven't yet worked on a team with people who have entered the field in the last few years.
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
I think that's true but it's a special case. AI is here to stay and with AI coding IS faster and quality is better than ever before. Ideally you want your luddite fired along with the slop generators and keep the ones who are using AI and taking their time to deliver a maintainable code.
"Luddites" can just be the ones pointing out the Emperor's new clothes have a big hole in them. Removing them is just ensuring that whatever mistakes you're making get reinforced.
> ... with AI coding IS faster and quality is better than ever before.
Is this claim based on something?
I'm not against or "for" AI (whatever that means), I try to use it as effectively I can, but for me it's not at all obvious that quality is better than ever before.
Speed I can buy, especially in new projects and utilities, but quality? At least I haven't seen this in practice, if anything I'm just seeing more code, issues, PR's and pressure ==> more slop, more bugs, less quality.
You can always say "skill issue" and "process issue", but that's partly my point here, AI doesn't magically solve this.
Presumably it is based on that person's personal experiences, like your own comment and all the other comments here?
Speaking for myself, based on my own personal experiences, quality is by far the bigger advantage of these tools. It has never ever been easier to write automated tests and to automate tedious manual validation. I'm running my code through like 10x more paces than I ever did before, because I can just say "hey try running this in these twenty different ways" (including with browser automation, if that's relevant), without needing to either do the tedious steps to run all that or to take the time to write a script to do it, and to compile and attach the findings to the PR. This saves me hours to days of work on validation, but the reality is that I just wouldn't have spent that time in the past, I just stopped at a lower bar for quality, because I couldn't justify the ROI for spending all that time on it. But now the ROI is huge, so it's a no brainer.
If people are not taking advantage of this, then yes, that is literally a skill issue.
For some reason this reminds me A LOT of past discussions about microservices, most wonderful on paper and forever debated, but I've never seen it work out perfectly in practice, for me it's mostly been a cluster F in most companies that adopted them.
Currently I see AI similarly, in theory perfect, in practice I don't see the claimed effects. So yes, skill issue, but skills are relevant and your company probably can't hire a rockstar team (if that matters in the future).
But your comment on personal experiences was very good! Spot on, we are all biased, easy to forget. Thank you for that.
> If people are not taking advantage of this, then yes, that is literally a skill issue.
...or domain. You said "including with browser automation", so you do web or web-adjacent development.
Not all of us are doing that. What I work on doesn't have any UI or output besides a log file most of the time, but it connects to many places and does many things like an octopus, but nobody sees that, but feels that it's there because their environment keeps on working.
I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
The octopus you just described sounds to me like an excellent example of what having the ability to more easily do tedious validation is most useful for. If you know that the "environment keeps on working", there must be some way for you to observe that fact. And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes. I find it so much easier to do this exact kind of thing now. Or, "easier" really isn't the right word. It's that the activation energy is low enough now that I'm able to do a lot of things up front that I used to rely on runtime monitoring to validate.
I guess YMMV, and it's not magic, but for me it totally changes the calculation on when it makes sense to automate something (like that chart from the old xkcd about how many times you'll do the thing and how long it takes to automate) in a way that means I'm doing a bunch of things that are useful for quality that just would never have passed the bar in the past.
> I said "if that's relevant" and you jumped to "this guy just makes websites". I do many things.
I didn't. I made a guess. I might be wrong, that's OK. I love to be wrong, because I learn things by being wrong. Also no offense was intended, and I don't consider webdev inferior anything. What I tried to mean is, if AI has more training data for a domain, it does better. If you fire the same model on a niche domain, it falls flat.
> If you know that the "environment keeps on working", there must be some way for you to observe that fact.
Yes.
> And if it is an octopus, it is likely difficult and/or to change the conditions and observe the correctness with respect to those changes.
Nope. On the contrary, because there's so much innate knowledge that is required to know what to do, simulating in mind, deploying and testing on real world is much easier and faster than letting loose an ML model on it. You need real data, real data comes in slow, but you can catch problems early and easily.
Considering it's a niche area, AI also doesn't have much training on that domain, so it's doubly inapplicable for what we do.
> but for me it totally changes the calculation on when it makes sense to automate something ... (snipped for brevity)
It's great that if it works for you, but YMMV part is way more correct than people want to accept and want to learn. AI is a pneumatic hammer, but not everything is a nail which can be driven in with that.
When it works, it works. When it doesn't, well people still pretend it does or insists it shall. We must accept the limitations.
> deploying and testing on real world is much easier and faster than letting loose an ML model on it.
No this is what you're not getting. It is "doing the things I would do to deploy and test in the real world, but faster and in the background while I do other things", it is not "letting loose an ML model on it". This is the new capability. If you have any process like "do {action}, wait until {something}, check {something}, determine if it matches expectation", it is now possible to run that loop way more times in way more variants without either spending the time on it synchronously oneself or writing a script to do it. (If you do that specific action loop often enough, it's probably worth writing the script anyway, but that's also much quicker to do now.)
The AI doesn't need training on the domain, it just needs to be told "these are the things I would do, please do them for me and report back".
I'm sympathetic to not everything being nail-like, but I really think you're leaving a lot of chips on the table if you can't imagine any of this kind of action-check-evaluate loop you have that you could offload.
I'm saying you could do more things. Instead of waiting until a new thing is merged so that it can be deployed and waiting for monitoring to catch issues, you could be deploying pre-merge to testbeds, using different variants of the code or different configurations of the whole system or different inputs to exercise edge and corner cases. Maybe it's too complex of a system to set up that kind of testbed or simulation? Well, it's easier to do that now too! I can spin up and down environments, either with containers on my workstation, or in cloud deployments, that I would have not attempted in the past, because it would have taken me too long to set them up. But now it doesn't take that long, and I find it super valuable to be able to try more things out. (Cost is still a real constraint, I'm not saying that constraints magically no longer exist.)
Obviously I have no idea what your work looks like! But what I'm saying is that time savings are not just time savings. There can be a point at which the time savings bring you under an "activation energy" such that it unlocks a new capability, not just a speedup. And some of those unlocked capabilities can be directed toward improving the quality of software. And I think that's awesome and useful, is my prevailing point here. I won't claim that it will usher in an industry wide improvement in quality or anything, but for me personally, I'm making better software more quickly now, and I'm very pleased that I can do that.
I fully agree with this point about quality. I am doing so much more testing than I used to, because I have so much more time to do it, and it's so much easier to automate the more tedious kinds of validation.
Maybe it's true that lots of people aren't taking advantage of this and are shipping trash, but that's their own problem, and there have always been people who do the job poorly.
That's true, but it doesn't have to stay in this form.
> with AI coding IS faster and quality is better than ever before.
Citation needed, because the last study I read about was painting a completely different picture about code quality. Also, just because the AI pulling and remixing code from a known repository with high quality doesn't mean your code will be at the same quality automatically. Passing tests is not enough.
> Ideally you want your luddite fired along with the slop generators.
The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this. AI doesn't know your history and trade-offs. These guys do, and can guide you to clear.
AI can't.
Believing that AI will create bug-free code from start is believing that Rust is the silver bullet.
The reason that we can (not that everyone, or even most people will) create higher quality software now is that it is now much easier to try out a bunch of edge and corner cases, which would have previously often required a prohibitive amount of time to set up and run. It's a dream! I can certainly believe that people aren't taking advantage of this, but they should be!
But I totally agree with you about the measurement problem. I think it's a very difficult time to be a hiring and firing manager.
> The thing is it's not possible to see who generates slop and who generates code, and if you fire the only people who knows about the codebase intimately, you'll be on a very exciting, possibly fatal ride. I don't recommend this.
This is exactly what I said in my top comment. This is a huge problem.
"Just do everything to hold things together, and let me abuse you without complaint" is exactly the kind of patronizing sentiment that infests the tech adjacent scene these days.
The answer to that is "Fuck you, no. I have worth, and you will respect it". Gilded Age paternalisms are not something that needs to be brought back into vogue unchallenged, especially when the intent is to keep the rabble quiet, and the checks rolling in and up.
No, the luddite is the person in one bad location on the continuum, opposite the AI psychotic on the other bad end of the spectrum. The person holding everything together is the one applying wisdom to the use of tools for the things they are good at while avoiding the things they are bad at, rather than blindly following one ideology or its opposite.
Sorry, but you're distorting my framing of the term in my original comment.
I labeled the person who uses AI to generate code and uses their brain and wisdom about the system to refine that code as the luddite since they will work slower when compared to other "higher performers" who don't care about the code quality.
In my framing I'm aware that the person is not a luddite per-se, but will look like it since they will be slower while trying to create better code, albeit using AI in the process as well.
Citing myself:
> Any employee who cares about code quality will become a poor performer with a red luddite label because they dare to change what the AI has emitted for them.
Chances are high the luddite is the one with the deepest understanding about the product and the code base - the one who is actually passionate about the project and actually cares.
Maybe? This does not seem to be in evidence to me. In my experience thus far, this seems to be way more of a personality and ideology split than a depth of understanding split. On my teams thus far, I've seen the deepest experts land on opposite sides of this question.
That could be the case. But if other companies figure out a way to deliver good code with AI, then the company with the luddites is going bankrupt. Luddites are better than slop generators, but both are worse against a developer with AI who actually cares and has a deep understanding of the code base and programming.
Well, and that's how you get enshittification everywhere. Everyone just cares about time to market, consumers are left to drown among a sea of slop, and honest businesses go down because they cannot stand a chance against slop peddlers flush with VC money.
Enshittification happens after the company was quick to deliver a working solution. They successfully captured the market, killed off the competition and now they are ready to start milking the customers who have no other choice.
AI slop can actually help with this, because it reduces the cost of replacing their enshittificated software.
The reason its hard to dethrone Facebook, Instagram, YouTube, Twitch, etc. Is not because it's hard to recreate the software (it may or may not be) it's because of network effects, budgets, etc.
And unless you have ownership level stake in the company, you *shouldnt* care about what happens downstream of selling labor to the company. Yes, I highly recommend 8 and skate.
Ive seen soooo many people burnt out, or "ive given years to the company and i got hit with layoffs", or "$200 software would have saved $1000000 when I brought it up to them". And companies will throw you away the MOMENT your usefulness is gone, even if just perceived. So, use them just as much as they use you.
And that idea of slacker is ALSO a way to generate more money for you, by slyly withholding or slowing work. I didnt get my paltry 3% last year. Inflation up 15% or whatever stupid number. But I can control how much work I do, so my effective wage/hour stays with inflation.
Save your caring for your personal projects, nonprofits you help at, your and family/friends labor you help with.
With some. You insisted, so let's get into the details.
1. Caring about the company when you are a worker and not owner?
Yes and no. I don't care about the company. I do care about what I do. It's a self-respect matter. I do good work not because I'm a slave to company, but because of self respect. My deal is simple: "I'll do my best to produce the best artifact and push the company further as long as it doesn't conflict with my personal principles, you'll buy that time for that amount of money".
I have a simple, foundational rule: I'll sleep sound at night, and this rule is rooted in my ethics. So, I don't shortchange anyone, incl. my employer. If terms change between us, we will discuss, but this probability is not a reason to do shitty work (or optimize for money, or which sugarcoated absurdity others name this).
2. Companies will throw away/layoff people with no notice?
Yes, this is bad. This is life. It's not nice, fair or acceptable, but without unionization, you can't act against this. So, you either try to change this or you just accept it. Realities of work life is not a predicament to shortchange your employer again.
This is as absurd as saying "I'll die anyway, why do all these things? I can just die on-demand".
Meaningless...
3. Work slowage (work-to-rule) as a counter to low/no pay raises in accordance to general inflation
We can accept that, but you all shall really unionize. It's not scary. Try organizing. It's a force multiplier.
4. Invest emotional and physical labor in ventures you gain completely out of
Everybody should have hobbies either productive or unproductive. I can't find the question.
There are companies where you can spend years doing as you describe. More and more, though, you’re competing with people who care even though they don’t own, put in the same effort YoY, and invest in their job. Companies love these employees.
So I guess it really depends on your values and what you want out of life. If you enjoy hobbies and time outside of work, sure find a job where you can coast. Don’t get frustrated when you get laid off just find another place to work. Etc.
Plenty of people want to grow within the industry and build a career, though. And many have what we call basic self-respect and care about how they are perceived.
> and aims to drive time to market metrics down aggressively with AI.
Go fast and break things has been a mantra for how long?
I think a lot of the laments about "good" code are really about "ownership" - and as someone who spent most of my working career in OTHER peoples code bases I have seen some things. There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
The increased cadence from AI is just speed running to the legacy code base.
The answer: express the concern, and reiterate it after every issue that arises because of increased complexity. Start building a plan on how to "unravel" the mess, how to migrate things in place, how to start drawing boundaries in your systems. The system is designed to reward heroes who fix problems - you want to be super man who stops the bridge from falling apart, not the engineer who pushes the costly fixes it before it does.
> Go fast and break things has been a mantra for how long?
Practically since eternity, but just as we learnt to manage current rate of "fast" and "breakage", somebody attached a solid booster behind us. So we're trying to understand what happened and what's happening and what will happen.
> I think a lot of the laments about "good" code are really about "ownership"
People owning what they did, have responsibility and initiative about doing better is always a good thing, yes.
> and as someone who spent most of my working career in OTHER peoples code bases I have seen some things.
I can understand that, I'm sorry you had to go through this.
> There are a lot of you who think that your code bases are "great" when they are NOT. Personal understanding is not a good measure of quality.
My codebases are as great as my knowledge. I love when someone reads my code and points where I f'ed up. I also love to show what I did has achieved something I was aiming for and discuss how to achieve it betterer.
> The system is designed to reward heroes who fix problems...
And this is the problem. Because I work silently and diligently build something looking unimpressive while working like an atomic clock without any problems.
I have paid a relatively big price for a software which does a simple thing: Drawing diagrams. The application? It's called OmniGraffle Pro. That simple looking program drawing diagrams can do flowcharts to scaled architectural or industrial diagrams and everything in between.
Try replicating it with a couple of agents. Not the capabilities, but the performance, stability and dependability and sustainability as well.
Same is true for my favorite text editor on macOS, BBEdit, or IDE of choice, Eclipse. I can increase the number of examples.
These tools are valuable not because they are expensive. They are valuable, or indeed priceless, because of the polish they have. The small features make no sense for a beginner or how they cope when things get absurdly haywire.
Immediate features make us excited and they are easier to replicate because they are visible, but things like performance, dependability, error recovery or the small tweaks they have gone through in the last decade are not, and this is what matters.
We're exploring computing via AI again, and we act as that we did nothing in the last 60 years or so. Software and computing is much deeper than it looks at the surface, and we'll learn this in a very very painful way, again.
This. I happily pay for IntelliJ software (even though basically everything else I use is FLOSS). It is not really this feature or that feature of WebStorm that makes it worth while, but just that 40+ hours of the weeks it just works. For normal stuff, for edge cases, small projects, big repos. When I need something, it just works (with out me needing to fiddle with an agent to build me some brittle scripting that will kinda work today, but break tomorrow....).
Same is possible in KDE. Combined with hot corners, you can become "blazingly fast".
Once a colleague seeing me work looked at my screen, lifted his head and pointed to my colleague saying "Have you seen how this guy work, he's a maniac!".
Mastering the tool you have always brings speed and smoothness into your process, one step at a time.
Any app can has its extensive set of keyboard shortcuts, but when it comes to DE itself, it's not always the case.
Microsoft has Meta+ and Alt+ combinations dime a dozen, and it's consistent across versions. KDE has extensive programmability which allows you to design you own. Both allows you to pack so many features into a small number of keys and work across applications or in general without thinking.
A terminal? It appears. A window? You call it without thinking. Ran out of space, a new desktop is just an instinct...
I’m a Mac dude through and through but its shortcuts don’t hold a candle to windows alt shortcuts. In windows, alt shortcuts are progressively revealed to the user and the entire UI is operable without having to memorize a series of hand cramping shortcuts.
> but that is a small price to pay for an everyday peace of mind.
Running an AMD card on my Dekstop system. It's invisible as an Intel on-board graphics card, and this is a great thing.
Much greater than rebooting to a black screen because NVIDIA decided to not support your GPU anymore because it finished its economic life for the company, not you.
Also don't forget calibrated screens, great speakers, long-life (you can use one for a 7-8 years without even trying), and durable keyboards which doesn't become smeared wear-fests which defaces itself within a single heavy development session.
I always run Linux (Debian primarily) on my desktops and servers with a zealot-ish dedication, but what Mac and macOS brings to the table as a portable machine is irreplaceable with anything else.
Even a top end ThinkPad with a well groomed Linux distribution can't come close, sorry.
It wasn't that long ago they had terrible keyboard lifespans which could be a death knell for the laptop, and overheating CPUs which limited performance way behind spec. They've come far in recent years, and I certainly wouldn't be sad if it was my main machine yet I don't expect them to be an outlier forever.
In some dimension Apple (and any serious manufacturer) is always going to be ahead - and they certainly are in non-gaming portable CPU/GPU combos right now. Alas, they aren't ahead in many other dimensions; my Fedora X1 Carbon is my strong preference over my M4 macbook pro and a large part of that is the basic usability of the system and window manager (sway), which is something Apple will never match until we meaningfully switch interaction paradigms.
> It wasn't that long ago they had terrible keyboard lifespans which...
Yes, their butterfly switch keyboards were really bad. I skipped that generation. I own machines from 2006, 2014 and 2020.
> and overheating CPUs which limited performance way behind spec...
Apple unfortunately does this sometimes, but interestingly just before changing CPU architectures (Power to Intel, Intel to ARM). I sometimes think whether it was semi-intentional. I don't blindly support them, however.
> that is the basic usability of the system and window manager (sway), which is something Apple will never match until we meaningfully switch interaction paradigms.
I'm way faster in my Debian + KDE system as well, but portables are always secondary machines for me, so Mac doesn't bother me much.
Also, I like running different operating systems and paradigms at the same time, so I can learn from all of them while developing some stuff for myself and others. However, as I said multiple times over the years, macOS is the "alternative" OS for me, not the primary one. Linux has that part for the last 20+ years.
I think most of the problems were down to Intel. They were consistently over promising and under delivering. I wouldn’t be surprised if this was what drove Apple to create the M series processors.
> What will have been lost? Perhaps just "The pleasure of finding things out".
I'll kindly disagree on this front, because when I'm walking a path toward solving a solution, I mark a lot of steps for possible diversions to other paths hence solving adjacent or different problems with the method I have at hand.
Currently, AI takes us from A to B, and is improving on that front. However, the paths in science are not lines, but a trees. Methods are cross-pollinated from each other.
Human intuition enables this cross-pollination. AI works with a laser focus. Human intuition and resulting wide perspective sow the seeds for solutions in many areas at once.
I recognize that if a document were to be published tomorrow containing solutions to all formulated open problems in mathematics we will have gained very little in mathematical understanding.
But surely, if we know that the dead ends of exploring a problem are valuable, we should be able to explore them even if a solution is already known. It just requires that the mathematics community reshapes itself. And it must. Two years from now people might be able to run the computation that solved NS on their Iphone.
I'm sure that whatever has been discarded during the NS exploration as a dead end you would be able to rediscover using purpose built tooling in the near future. The purpose of human mathematicians in the medium term might be to explore dead ends, and to provide human insights as context to attack other problems. But whether this type of work will remain necessary in the long term im not sure.
> But whether this type of work will remain necessary in the long term im not sure.
Any and every capability AI can demonstrate today is the result of us, humans doing it in the first place for a very long time. The transfer method of these abilities is a subject of another comment, but as Microsoft and NVIDIA puts it, it's a theft of unprecedented scale [0].
AI labs dream of recursive self improvement as an escape from that, but until we arrive there, humans have to do something so AI can do it as well.
And, as of fully autonomous self driving which should have arrived 5 years ago, RSI and AGI is just around the corner, a corner with a radius so large that it never ends.
We dream of building utopias with these tools, but it's a path to dystopia paved with stones made from utopic dreams.
I dont disagree. Clearly AI leans on the cumulative cognitive labor of humanity without porpper attribution. This is in part due to the design of these sytems. Information is compressed into the weightspace in ways we dont understand, and a concept becomes unlinked from its origin.
We should remember that we learn by failing.
Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.
Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.
The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.
reply