> There seems to be a strong bias where using AI feels like you're making a lot of progress very quickly, but compared to manual coding it often seems to be significantly slower in practice.
This metric highly depends on who uses the AI to do what, where strong emphasis is on "who" and "what".
In my line of work (software developer) the biggest time sinks are meetings where people need to align proposed solutions with the expectations of stakeholders. From that aspect AI won't help much, or at all, so measuring the difference of man hours spent from solution proposal to when it ends up in the test loops with and without AI would yield... very disappointing results.
But for troubleshooting and fixing bugs, or actually implementing solutions once they have been approved? For me, I'm at least 10x'ing myself compared to before I was using AI. Not only in pure time, but also in my ability to reason around observed behaviors and investigating what those observations mean when troubleshooting.
But I also work with people who simply cannot make the AI produce valuable (correct) results. I think if you know exactly what you want and how you want it, AI is a great help. You just tell it to do what you would have done anyway, and it does it quicker than you could. But if you don't know exactly what you want, AI will be outright harmful to your progress.
the venn diagram of people who say "AI produces useless results I have to 100% throw away" and people who say "I've never successfully delegated parts of large software development to junior programmers" is a circle
I get a lot more done with lot less frustration giving my work to Claude than to a junior dev quite frankly and I've managed many groups over my career.
the value of the junior dev is the hopes that they'd be a senior dev someday, I dont have a solution to that problem. But in my current capacity where the only devs I'm "managing" these days are via open source contributions, they're already gone - 100% of what I get is through their own work with LLMs (which I have to spend more time correcting than if I used the LLM myself).
> And they don’t travel very far, so only nearby microphones would “hear” the tag. That makes the devices inherently private, Deng said, because other people wouldn’t detect any activity unless they were within a meter or so.
It would seem these things don't really produce loud noises, so probably not adding much to the noise pollution that already exists in our environments. At the same time it seems the statement kind of negates the "point" of this tech, that you don't need an active (energy consuming) device close to the source of the events that you want to detect. So not sure of how to interpret it.
I’m interested in having an alarm for my door and the door to my workshop, which doesn’t have power. It would be great to have one “listening station” mounted on my home that can detect sounds from both devices. It’s not that I don’t have power available somewhere, it’s that I don’t have power available in EVERY place I’d want to use them, and don’t want to bother with a battery for every sensor.
I'm firmly in the LLM fanbase. Not because I can't type code (was doing it for over 17 years, everywhere from low level hardware drivers in C to web frontend to robot development at home as a hobby - coding is fun!), but because in my profession it allows me to focus more on the abstraction layer where "it matters".
I'm not saying that I'm no longer dealing with code at all though. The way I work is interactively with the LLM and pretty much tell it exactly what to do and how to do it. Sometimes all the way down to "don't copy the reference like that, grab a deep copy of the object instead". Just like with any other type of programming, the only way to achieve valuable and correct results is by knowing exactly what you want and express that exactly and without ambiguity.
But I no longer need to remember most of the syntax for the language I happen to work with at the moment, and can instead spend time thinking about the high level architecture. To make sure each involved component does one thing and one thing well, with its complexities hidden behind clear interfaces.
Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.
I generally do have that mindset, but over the past 1y of Claude code I do notice that I’m clearly losing my understanding of the internals of projects. I do review LLM generated code, understand it, no problem reading/following through. But then someone asks me a question, and I’m like… wait, I actually don’t know. I remember the instructions I gave and reviewing the code but don’t actually have a fine-details model of the actual implementation crystallized in my mind, I need to check, was that thing implemented the way I thought it was or not? Wait, it’s actually wrong/not matching at all what I thought!
It’s definitely becoming uncomfortable and makes me reconsider my use of Claude code pretty significantly
reminds me of the experience of reading a math text without doing the exercises, thinking that you've understood the material, and then falling flat on your face when you attempt to apply your "understanding" to a novel problem. there's a significant difference between passively reading something and really putting active effort into it. only the latter leads to actual understanding ime
Same experience. I've been writing code for many decades, but that experience doesn't mean I can remember what I read when reviewing generated code. I write small, focused commits, but I have to take a day off each week to make changes by hand just to mentally keep up with my own codeset knowledge, and I still find structures that surprise me. It's not necessarily that the code quality is poor, but it's not like I (thought) I had designed it. It's lead to a weakening of my confidence when adding to or changing existing architecture.
I've had this issue too, and I feel it was an important lesson—kind of like the first time getting a hangover.
On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
> On the other hand, LLM-generated code comments better than I do, so given a long enough time horizon, it could be more understandable at a later time than code I've written myself (we've all had the experience of forgetting how things work).
Writing and rewriting piece of software performs what is called "spaced repetition" [1].
You ask questions about code when you implement something and if you cannot answer these questions, you go to code to find answers out and refresh your understanding of it.
For this to work you have to be interested in the understanding of the code and code should be created at the pace you can keep up.
Software engineers usually do create code economically because they need to remember and understand it. Vibe coders do not have this particular constraint, they just do not aim for most understandable code possible. Even if there are more comments in code.
I do think that this is natural. When you use LLM coding tools, you're becoming a lot more like an architect/staff/manager, rather than the direct coder. You're setting out the spec, coming up with the design, and coming up with the high level structure of the project.
However, this comes at the cost of losing track of the minute details of the implementation because you didn't write it yourself. I find it a bit analogous to code I've reviewed vs code I've written.
However, I've found using AI for code structure summary and questioning tends to be a good way to get around it. I might forget faster, but I also pick it up faster.
I've found that for non-trivial features, I typically benefit from 3-4 rounds of: are you sure this isn't tech debt, are you sure this is thoroughly tested for (manually insert the applicable cases, because they aren't great at this, even if explicitly asked), are you sure this isn't re-inventing wheels, adding unnecessary complexity by not using existing infrastructure it should or that other existing code would not benefit from moving to this, are you sure you can't find any bugs, in hind sight, are you sure this is the best design?
Then, after it says, yes I'm sure this is production ready and we're good to move on, you have Codex and Gemini both review it one last time, and ask it to address their feedback if it's valuable or not.
After all this, it's the only time I'll look at the code and review it and make sure it's coherent.
Until then, I assume it's garbage.
I'd estimate this still improves velocity by 10x, and more importantly, allows me to operate at a pace I couldn't without burning out.
it's very different. LLMs don't behave like people. they don't learn.
i don't mind managing people, but i don't want to manage machines unless i can control them with the precise languages that the commandline and programming languages use. prompting a LLM is to vague an interface for me, the outcome is to unreliable, to unpredictable.
One-off tasks and parts of the stack that already have lots of disposable code do not need the same scrutiny as everything else. Just as there is a broad continuum of code importance, there is a broad continuum of testing requirements, and this was the case before AI. Keeping this in mind, AIs can also do some verification and testing, too.
> Engineers who refuse to, or can't, or won't utilize the benefits that LLMs bring will be left behind. It's just the way it is. I'm already seeing it happening.
Any examples how you see some engineers being left behind?
> Any examples how you see some engineers being left behind?
I don't know where you live, but around where I live in Denmark you'd fail for not using AI at a senior interview in a lot of places. Even places which aren't exactly AI fans use AI to some extend.
The biggest challenge we face right now is figuring out how you create developers who have enough experience to know how to use the AI tools in a critical manner. Especially because you're typically given agents for various taks, which are already configured to know how we want things to be written.
Around here on your southern neighbour, everyone is supposed to be doing AI and being evaluated by this, yet in many projects if clients don't sign off on the use of AI tools, there is no AI to use anyway.
Additionally there are the AI targets set by C suites based on what everyone is saying on TV, and what we can actually deliver based on the available data sets, integration points, and naturally those sign offs for data governance, and hallucinations guardrails.
I was just giving them an anecdotal example of what they were asking for. I think the answer is somewhere in the middle, but I'm not in a position to push any form of change on the C levels.
I've noticed that back in Europe everyone's in a panic mode, but that's because of the inferiority complex most people have vs both US and China. It's unwarranted.
I'm starting to notice how those who don't use AI end up having to hand tasks over to people who can get them done quicker.
It is anecdotal for sure, but it's a pattern that seems to be emerging around me that expectations of velocity increases, and those who don't use AI can't keep up.
Shit processes. I don't know what places most of those people work at that crap is being merged into production at insane pace. You would expect any serious piece of software would be important enough to have the code be reviewed by at least one human.
Kind of.... I don't know. To get placed such requirements from the top down and not fight back, just take it head on, not even maliciously, don't even oppose it on a technical basis, just be like "yeah, you've now gotta ship faster or you're left behind, so therefore LLMs must be the future!", no critical thought attached. Is this shit coming from experienced engineers?
Preposterous we're relying on "it's better because I feel like", "dudes who don't use it are falling behind at work", "they ask for it in job interviews".
Again, I have to point out that AI is not an abstraction layer. It blows my mind that engineers with years of experience somehow don’t understand this.
It would be an honor to be “left behind” by people who practice their craft with such carelessness.
(Frankly, I should probably stop replying to self-professed LLM boosters entirely since there’s a good chance I’m just chatting with an LLM.)
I do a hybrid, where I keep lowest tier subscriptions but choose to watch content off of our media server setup at the highest available quality, without advertisement.
I don't mind paying for what I consume, but God damn is the value proposition at the floor currently. Here even the rather expensive mid tier subscription gives you 1080p at most with all the big players. It's as if they somehow converged to this model and aren't competing anymore. Coincidence, I'm sure.
Exactly we don't, and what's worse is that the "content" is getting to the point where we need _content_ blockers.
I recently got hit by an "article" that promised to tell me which three AAA games would be released with PS Plus soon. A three point bullet list was all I wanted. Instead I got pages after pages of word-manure about nothing at all for reasons I don't even understand. At the end of it I still couldn't tell you which three games the article was supposed to tell me about.
I foresee a bleak feature where we will deploy AI as "content blockers" to extract the useful content from the word-manure that is becoming the preferred way of working among internet "authors".
The PS Plus One is a gaming console or something to that effect. “But Henriette,” my grandmother asked, “which AAA titles will be released for Xbox”?
My grandmother is a gamer. But a bit senile. She had her formative gaming years on the XBox, you see. What she actually meant to ask was: which titles for the PS Plus One?
My dad too has been asking me that question. Or he did until he tragically died in a car accident last week.
So which AAA games will be released for PS Plus One soon or soon-ish?
I really had to ponder that question while driving my Tesla Cybertruck to the gas station. Indeed, which games are that? It’s on everyone’s lips or mouth.
Which brings us to this article. You have been wondering the same thing, haven’t you? If so you are in good company, like that of my beloved grandmother and dear departed father.
Sony says that they will reveal which three AAA titles will be released for PS Plus One in the fourth quarter of 2027.
I think we'll be soon at the point where articles are written by asking AI to extend a three point bullet list to 30 pages, and read by asking AI to summarize articles into a three point bullet list.
This drives me nuts. It's been going on for years that a simple "if this, do that" deal is encoded in an overly elaborate 10 minute long YouTube video where at least 9 minutes of it is filler. You know, when you start skimming the comments to see if anyone bothered with summarizing it.
AI amplifies the problem by making it easier to produce filler, but the problem is whatever metrics are behind the monetization. You need users to "engage" with your content for at least x amount of time to earn y amount of money, while instead the earnings should be relative to and directly derived from how useful the content is to how many users.
Exactly how did you "get hit" by an article? Did somebody hack your computer and pointed your browser to it? Or did somebody ambush you on your walk to work and show a magazine with the article into your face?
If you seek out content from low quality sources, you get the low quality treatment. The only way for consumers to fight this is by paying for good quality content, which is often possible.
Burger King isn't going to improve the quality of their burgers or service by customers complaining. They'll do something when they see customers going somewhere else.
A notification on my phone. I don't know what produced it exactly, but it was probably connected to my google account (sigh!) somehow.
It's something that happens rarely enough for me to not having developed an automatic "aw hell nah, no f-ing way" filter towards it anyway, and I (naively) did click the notification and "got hit" by the article.
Yeah. In these cases it's not like anyone is going to spin up their own instance and start competing with you.
Government / handles society-critical things code should really be public unless there are _really_ good reasons for it not to be, where those reasons are never "we're just not very good at what we're doing and we don't want anyone to find out".
Some months back I would have agreed with you without any "but", but it really does help even if it only takes over "typing code".
Once you do understand the problem deep enough to know exactly what to ask for without ambiguity, the AI will produce the code that exactly solves your problem a heck of a lot quicker than you. And the time you don't spend on figuring out language syntax, you can instead spend on tweaking the code on a higher architecture level. Spend time where you, as a human, are better than the AI.
I've recently worked extensively with "prompt coding", and the model we're using is very good at following such instructions early on. However after deep reasoning around problems, it tends to focus more on solving the problem at hand than following established guidelines.
Still haven't found a good way to keep it on course other than "Hey, remember that thing that you're required to do? Still do that please."
I (deep, deep in embedded systems) have seen this too often, that code is incredibly complex and impossible to reason around because it needs to reach into some data structure multiple times from different angles to answer what should be rather simple questions about next step to take.
Fix that structure, and the code simplifies automagically.
I think it boils down to how companies view LLMs and their engineers.
Some companies will do as you say - have (mostly clueless) engineers feed high level "wishes" to (entirely clueless) LLMs, and hope that everyone kind of gets it. And everyone will kind of get it. And everyone will kind of get it wrong.
Other companies will have their engineers explicitly treat the LLMs as collaborators / pair programmers, not independent developers. As an engineer in such a company, YOU are still the author of the code even if you "prompted" it instead of typing it. You can't just "fix this high level thing for me brah" and get away with it, but instead need to continuously interact with the LLM as you define and it implements the detailed wanted behaviors. That forces you to know _exactly_ what you want and ask for _exactly_ what you want without ambiguity, like in any other kind of programming. The difference is that the LLM is a heck of a lot quicker at typing code than you are.
This metric highly depends on who uses the AI to do what, where strong emphasis is on "who" and "what".
In my line of work (software developer) the biggest time sinks are meetings where people need to align proposed solutions with the expectations of stakeholders. From that aspect AI won't help much, or at all, so measuring the difference of man hours spent from solution proposal to when it ends up in the test loops with and without AI would yield... very disappointing results.
But for troubleshooting and fixing bugs, or actually implementing solutions once they have been approved? For me, I'm at least 10x'ing myself compared to before I was using AI. Not only in pure time, but also in my ability to reason around observed behaviors and investigating what those observations mean when troubleshooting.
But I also work with people who simply cannot make the AI produce valuable (correct) results. I think if you know exactly what you want and how you want it, AI is a great help. You just tell it to do what you would have done anyway, and it does it quicker than you could. But if you don't know exactly what you want, AI will be outright harmful to your progress.
reply