> It's not just the time it takes to make the feature, you also have to consider documenting the feature, making sure it works well with the other features, making sure it's something customers actually want, making sure it's part of a larger coherent design, training customers, marketing the feature, etc.
Seems like a conflation of responsibilities. An IC that implements a feature is rarely the same person who decided on the feature to build in the first place. This is really only true in exceptionally small teams where everyone wears multiple hats. If a programmer is also doing marketing, they're basically a sole proprietor. Since most people work with others who make product and marketing decisions, I don't feel like this line of thinking is relevant.
Consider programming with a dumb text editor (no syntax highlighting, no integrated build/test/run cycle, no symbol/reference tracking, no auto-complete) and an IDE. The magnitude in performance or efficiency between that and the difference between programming with an IDE and programming with AI is relatively similar. Sure, the AI can do more than the IDE in absolute terms, but it's not going to be training customers or doing your architectural planning. (At least, I sincerely hope not -- not yet, anyway.)
That's my perspective on the "10x myth". AI isn't 10x, just as dumb editor to IDE wasn't 10x. It's only a modest improvement.
> The way this stuff is hyped and pushed has an air of extreme desperation. If it was so good people wouldn't need so much convincing!
You can ignore the hype. I ignore every advertisement I reasonably can. It doesn't matter who's peddling, it's always toxic.
But more than that, people do need convincing. Entrenchment, momentum, and bureaucracy make it nearly impossible to change anything. That, in turn, leads to the well-known adoption curve. You're using AI, you're an early adopter. The marketing and hype are there to chip away at the friction keeping the adoption curve from an early majority.
Discovering bugs and exploiting them is anything but laziness. We used to call that property cleverness. Being too clever has always had a negative connotation.
My best guess is that there is sort of an XY problem happening in these cases. The model needs to do X but doesn't know how. It knows how to do Y, and that sets it on the path to working around X. Or maybe sampling the next token probability distribution sends it away from X and toward Y.
Compounding the problem, thinking models almost never discard their current approach when it proves fruitless, and start fresh with a new perspective. Sometimes they try to, but the context window is already polluted with Y when they should be doing X.
Disobeying the rules makes perfect sense when the rules cannot or will not be enforced. If that isn't motivation enough to shore up problems in the evaluation environment, nothing is.
Poor behavior will always result when code can be misused and vulnerabilities can be exploited.
Between the elimination of the fairness doctrine, the rampant sensationalism (a phenomenon so common it has its own derogatory name: clickbait), the corporate ownership of media outlets, and the pervasiveness of advertising, I can't imagine how you got the idea that information sources were ever a public good. Let alone conflated the purpose of the intent. The intent has been to make money by any means necessary.
> they're all lumped into the same bucket, even when they shouldn't.
Why should they be separate? The same technology generates text, images, video, audio, 3D models, actuator and stepper motor control sequences, video game controller input streams, and literally everything else that can be transformed into data.
I'll let alone the question of whether or not any of the tech is "tainted", because it doesn't matter. Planck's principle tells us how this will play out in the long run.
I’ll admit, at first, I thought the human vs machine comparison was about humanoid machines. But that’s too narrowly defined to be a useful comparison. Most machines in use today are not humanoid.
Then to boldly claim that humans are more efficient at anything compared to a machine, just does not follow.
Yes, and I've also personally been responsible for cutting about a million dollars per year in AWS expenditure, and never saw a single cent in bonus payouts or equity. It just got repurposed in the budget. Same with building launching a product that brings in hundreds of thousands of dollars a month.
Maybe it depends on who you work for, but that was my experience.
It's an absurd scenario because Big AI is simply not in the Big AI Law business. They are also not in the Big AI Accounting business, the Big AI Pharmaceutical business, or the Big AI Web App business. It is absurd because the CapEx and OpEx to subsume every industry is unjustifiable.
On legal-AI startups undercutting Big Law to the point where Big Law has to adopt AI... Well, yes, that will happen. But as the article's intro belabors the point, there is a natural resistance to changing entrenchment. And it is practically impossible to overcome. So, good luck to the Big Law C-suite laying everyone off with AI when they can't even replace WordPerfect with a modern word processor.
Uh, this read is completely insane. A fantastical look into the mind of someone who thinks about many disparate things and is looking for ways to connect them. This is post hoc rationalization at its finest.
I had a much longer post here initially. Deleted it because I got tired of mental gymnastics required to follow the author's thought process. Instead, here are the salient parts of my response:
----
The only way I can read the section on the mechanical tomato harvester is that they would rather have 32,000 people picking tomatoes than doing literally anything else. There are very good reasons that phone companies haven't employed people as switchboard operators for a nearly century. It isn't a valuable or useful way to spend a person's time.
As a young adult, I worked in a distribution center filling orders by picking products from a shelf and placing them in bins. It was incredibly boring but also physically demanding. Pick the correct number of items ordered, push the button. Pick the next number of items ordered for the next product, push the button. When the order is complete, start on the next bin. Repeat as fast as possible without making any mistakes.
It was SO draining to meet quota. After a few weeks, I didn't have to put any conscious effort in. Like driving a car, the process became automatic. I could think about other things while counting and pushing buttons. Thinking about things like how trivial this job would be to automate, so I didn't have to do this wasteful energy expenditure.
I quit that job after about 6 months, beginning my career in IT. But I gained a passionate hate for menial labor that can be automated with some upfront investment. I wouldn't want to pick tomatoes, either. The tomato harvesting machine is a miracle.
If this is the basis of calling technology inherently political, and using "inherently political" to cast a negative light on technology, then I have to call it out as hopelessly dystopian to not want "political technology". Namely fewer automated machines and more people doing menial labor.
> and had to run glue code to copy things in and out of Webassembly memory.
Not surprising. The FFI boundary is always a bottleneck. If you can eliminate it, you will see where the WASM JIT shines. You have far more control over mechanical sympathy with C/WASM than JavaScript (though far from perfect).
Also, consider publishing your findings and ask for reviews for optimization opportunities.
GitHub, Gitea, and Forgejo specifically store all commit hashes for PRs in the `refs/pull/` namespace. The end result is that 50 people pushing commits for six years and deleting all of their branches after squash-and-merge loses no information about how the code evolved.
The main branch remains compact with a linear history without the commit noise. Deleted branches can be restored, commits that otherwise do not exist in the history can be interacted with, and so on.
I - being old as dirt - was also around for it. Circa 2002 or 2003, we were writing CMSs in PHP which were already well beyond the simplistic concept of rendering HTML tables from database columns. Smarty templates were pretty common back then. It's hard to treat these templates as "writing HTML by hand" because the templates are a higher level of abstraction.
Rails was quite popular, but I never got into it. I went from PHP to Python (avoiding Django) and then to nodeJS. At the time, the MVC architecture was making a comeback, but the mapping of HTML/CSS/JS was never 1:1 with it. Small fragments of HTML and CSS where always littering the JS or PHP/Python. The clean separation was never fully realized. For this reason, JSX was seen as a real win.
The reason I chose to focus specifically on "templates and DSLs" in my original comment is because once the level of abstraction is raised to the point where HTML becomes a compilation target, it is no longer HTML by definition. The browser cannot render the template or DSL without the preprocessor (XSLT is about as close as that ever got). This is especially true with client-side templates. For example, using pre-made widgets like jQuery date pickers is so far removed from writing HTML that a reasonable conclusion is that jQuery developers do not know HTML or JavaScript as a matter of course [1]. But yeah, this was all burgeoning in the early/mid 2000's, and really kicked into full throttle with jQuery.
> It was very easy back then to browse most of the web with JavaScript disabled.
It was easier, but not fool-proof. Client-side rendering wasn't in full swing, but Java Applets, Shockwave, and Flash certainly were in the years leading up to it.
Plain old HTML with vanilla JS is not exactly a pit of success but React is much closer to a pit of despair. The former tends to be clunky but effective, while the latter requires a PhD in complexity avoidance to stand a chance.
JavaScript: The Good Parts by Douglas Crockford is a comically short book. React: The Good Parts would be shorter still.