> I see companies adding more sloppily written features with AI
I think this is a side-effect of the old product management process adapting to AI. We (as an industry) were never very good at defining features rigorously, because there was a smart human in the loop who had to implement the feature and could push back on sloppy definitions.
Whereas security bugs are easy for the LLM to define and fix.
this. Is the judge really going to be "oh wow, thank you so much for helping us find this bug"? I suspect not. I suspect it'll be "you get 5 years banged up in solitary for attempting to pervert the course of justice"
So if I make $0.10 of profit, all my decisions are validated?
What if we knew that Maccas could have made $20 billion, but ignoring qualitative data reduced their profits to $8.563 billion. Do those decisions still look smart?
Purely anecdotally, over the last few weeks I've noticed a significant uptick in articles trying to convince me how awesome AI is doing. And that's from a pretty high baseline of articles that were already telling me how I should really appreciate how awesome AI is.
It's almost as though there's some worry that the wheels are going to come off before the right people are able to cash out.
isnt it how marketing is done these days? people/companies buy views, clicks, articles, posts on social media saying how great something/someone is or how its changed their life etc etc.
it really becomes hard to separate the wheat/chaff for alot of these things...
The way I separate oponion from marketing wich is, admitedly not the best method, is to look if it is written by a random guy on a blog, or by an account with a for profit organization behind it, the former can definetly be wrong since its just a random guy on a blog, the latter is almost certainly marketing, even random accounts social media pushes are most likely just ads.
It feels like Im in a different world than this author. Cluade code is now more reliable and trustworthy than most of my coworkers but this author hasnt seen a single AI initiative succeed? Seems like theyre just being obtuse because the only other explanation I can think of is user error.
I think there's a huge difference between someone using AI to help them build something, and a large organisation attempting to become "AI Native", whatever that means.
We saw the same during the dot com boom - lots of companies trying to become "dot coms" because that did good things to their share price and they could answer investor questions, but no-one actually in the org knew wtf they were supposed to do to make the company an actual dot com. Trying to define what a "dot com" actually was, was difficult enough. Then the bubble collapsed and investor pressure on change relaxed, and a quarter of a century later we're pretty relaxed that some companies exist almost solely on the internet, and others don't. Both for reasons that mostly make sense.
It'll be the same with AI - the bubble will collapse, the pressure will relax, and we'll go on to have some companies almost entirely built out of AI, and others not.
But the poor management folks who have to come up with some answer about how to make their organisation "AI native" immediately - you could not pay me enough to do that job.
Let's assume that instead of leetcode, the company had decided that the qualifying test for programmers would be sketching a vase of flowers (about as relevant as leetcode for commercial programming).
Your friend would have spent three weeks practicing their sketching, right? And they would have made a decent drawing at the interview. And that would have the exact same ROI as spending those weeks on practicing leetcode.
The point is not that studying leetcode is good ROI. The point is that large orgs are testing for something that isn't relevant to commercial coding.
This is classic Streetlight Effect [0]. Just because it's easy to test leetcode, and it appears to have something vaguely to do with coding, it gets used.
Like I said in other posts, I would use the "pick a bug and fix it" method. But I'd also screen down from 100 candidates to ~20 or so before getting into technical interviews.
And, again, I don't think leetcode will scale well to 100 interviews either. You need technical staff in that interview room, and if you subject your team to 100 technical interviews using leetcode they're not going to be happy about it.
Agree 100%. The problem is that leetcode problems are nothing like the actual practice of writing commercial code. Writing good commercial code is about keeping things as simple as possible, as clean as possible, as readable as possible. Use libraries for the complex stuff, don't invent complex solutions. And, as you say, use standard data structures whenever possible. Don't optimise early. Don't fix performance bottlenecks unless you actually know they're causing a problem in production. And even then, throwing more hardware at the problem is often better than making the codebase more complex. None of this is anywhere near what leetcode tests.
The best interview method I've seen is getting the candidate to work for a day or two alongside the team. The second-best was picking a bug from the current repo and working it out together with the candidate, getting them (or in this case, me) to work out why the bug was happening, work out a solution, code up the solution, and commit it back to the repo as a PR.
Yeah, I've only seen it work for the last few applicants, but it did work really well.
The "pick a bug and fix it" scales better, though still not to 100 applicants.
Though I'd say putting 100 people through leetcode interviews would still break a talent acquisition process. I've been part of this kind of process before (though with arbitrary code problems not leetcode) and it was hell for the entire team going through it. Nothing got done for weeks while they were dragged into endless tech interviews.
This is why we pirate movies (and books, which have the same problem on proprietary e-readers). It's not about getting things for free, it's about actually owning the thing we bought.
My experience with Fable is that it eats all my tokens and returns something I didn't ask for.
I realise this might be a skill issue.
I prefer models that are less "smart" but faster. Do the thing I asked you to do, immediately, and if you can't tell me and we'll work it through. Iterate faster not smarter.
I think this is a side-effect of the old product management process adapting to AI. We (as an industry) were never very good at defining features rigorously, because there was a smart human in the loop who had to implement the feature and could push back on sloppy definitions.
Whereas security bugs are easy for the LLM to define and fix.
reply