Yep. When the AI push took off earlier this year at my job. All the suite people and even my my boss were pushing it. Saying it’ll improve dev times by 50%.
I hadn’t really used AI much since trying copilot for about a year. With varying levels of success and failure. So after a few days of trying it out I landed on the similar conclusions to this article. Without being able to test the code being put into my editor quickly writing code will never ever be the bottleneck of the systems.
The testing portion isn’t just me testing locally, it has to go through QA, integration tests with the 3rd party CRM tools the customers use, internal UAT and customer UAT. On top of that things can come back that weren’t bugs, but missed requirements gathering. That time is very rarely moved much by how quickly I can type the solution into my editor.
After explaining this to my boss he seemed to understand my point of view which was good.
6 months into the new year? No one is talking about AI at my job anymore.
My dev environment on code change takes 3-4 minutes to restart so getting it right in as few try’s as possible is a goal so I can move on.
Now imagine how much of an improvement it would be to get those 3-4 minutes down to 3-4 seconds. AI can improve dev times by 50%? How about fixing the testing infrastructure to improve dev times by 6000%?
But remember, "sexy" exists at all layers, I had people distract teams for some agile subtrend because it sounded sexy, and dev managers ran with it. It's not necessarily c-suite and AI, it's a flaw in human groups
You’re telling me. Since I started a few years ago I’ve complained about start up times and we’ve never been given time to fix it. We’re using a 12 year old version of a framework. We have finally convinced management and this year we have time to upgrade it. Updating versions should give us back hot reloading and reduce that but… we’ll see.
A lot of software is a people problem. Not a machine one.
If the LLM writes bad code, the tests it writes will be to that code, not what the actual business requirements are. Asking it to do both is essentially asking it to make up its own BS then justifying it via "tests."
Not necessarily trivial, sometimes code and tests are subtly wrong where it takes more time to verify and find the bug than to write it yourself without the bug in the first place. And often after a while people do blindly commit because reviewing code all day can drain one's energy than coding. That becomes the real danger to a business.
At the end of the day, reviewing a test is much easier than reviewing code. The code generated by the LLM might be complex and hard for me to understand, but I can review the test code pretty quickly and knowing in confidence that if the code passes this test, then it's mostly correct.
Technology informs behavior, of course that is true otherwise apps like TikTok wouldn't exist. The truth is LLMs cause such issues over time. The fact that you can drive a car without knowing how the engine works is because the engine wasn't built probabilistically at the factor, there wasn't a worker deciding whether or not to put a particular screw in. You're arguing the wrong analogy. And if you don't understand the code you're emitting (whether by an LLM or yourself), then you're honestly not an engineer, just a code monkey.
Who said I rejected it? Did you see my other top-level comment in the thread? My only point was that it's not good for both creating tests and writing the code for those tests, because the business logic itself could be wrong. I make no other judgment on LLMs.
tests generally should be written from the requirements, not from the code, to ensure the code actually does what it's supposed to.
This is why it's a good idea to have the spec first: you can then ask the LLM to reference the spec to write the tests, and then afterwards, ask it to make the test pass by changing the implementation.
That’s crazy, ai has been tremendous at helping us understand legacy code bases no one could decipher, or using it to talk to business to get clearer requirements and make sure we are capturing it all. Literally no one ever said code was the bottleneck and llms solve the real bottleneck. Insane to be proud that you fought to hamstring your organ
ai has been tremendous at helping us understand legacy code bases no one could decipher
I’m also in a position where archeology trips aren’t uncommon but you’d be mad to rely entirely on LLMs for this. Yeah they’re a decent tool and I’m glad to have them, but they couldn’t spot Chesterton’s fence if they stumbled directly into one of its posts which is a key part of dealing with legacy code.
They absolutely can if you understand how to use them. If you’re just going “copilot tell me about this repo” yes it’s going to fail. But if you manage the context and then spin up agents to map repos and build knowledge graphs, then you’re using ai correctly. You would be a bit mad to have any tool at your fingertips limited by your imagine and saying the tools don’t work
By definition an LLM only grasps the language though and that’s hardly the most important thing in debugging legacy code.
The legacy code I deal with isn’t bad because the developers didn’t give it shit rather non-technical business factors are what makes it a tangled nightmare and the code is just working around concepts that were shitty to begin with.
For cleaning up that mess you need a mix of understanding the code, understanding the business decisions that made the code bad, and all the tribal knowledge that says x was done y way for z reason. Just relying on the code alone as a source of knowledge is like digging yourself out of a hole when you don’t know which way is up in my opinion.
I’m not saying this from an ‘AI bad’ position, I’m saying it from a don’t lean too much on one tool position.
That’s reductive to say it “only grasps language” considering that code is literally language . I just had Claude code use agents break down the vscode repo with 40k files and 2.5 million loc and have it rewrite it in another language, and it worked reasonably well within like 20 minutes. This is obtuse, these things are amazing tools if you understand how they work and how to use them.
If there's no explanation of business logic, no amount of understanding the code will make one understand the outside business world that created such code, whether that's an AI or yourself. That is the fundamental issue, I could ask AI to do everything you said but since it doesn't know about my specific business because the legacy code has no explanations of it, it will be unable to grasp why certain things like numbers and functions exist.
You’re missing my point, debugging isn’t just about the code because you need to understand the bigger picture surrounding the code. The LLM by definition is blind to that, you can find yourself debugging the same bugs again and again because they’re created through faulty business premises the LLM has no real comprehension of other than through the code. These faulty premises aren’t always represented in the code!
No amount of code can solve what’s often fundamentally a people problem, and LLMs are no substitute for genuine institutional knowledge. You have to know the depth of the shit you’re in before you start shovelling it, and code is just one thing that can be shit.
You are missing the point - use the llm to build knowledge graphs that have that bigger picture. And now you did it for everyone and not just you. You’re doing it wrong
You can’t build a knowledge graph about stuff you don’t know about though, and what I’m saying is the LLM is necessarily blind to the human factors that conspire to make a codebase shitty.
You can’t abstract people problems away with code, all you end up with is shitty code eventually.
You absolutely can. You don’t need to know, code is code. Methods do things. Your knowledge graphs can be traversed with an llm and some rules. This is absolutely doable.
Why do you have a monomaniacal obsession with code though? Our job isn’t to write code it’s to solve problems, it doesn’t matter if your code is perfect if the business logic it captures is bullshit then you will continue to have bugs as time goes on. Part of debugging is finding out where the business logic is bad, which LLMs by definition can’t do because they’re only looking at code.
Using a tool is one thing but using it as a crutch is quite another.
I do not have any obsession, quite the opposite. I am literally saying that code is inconsequential, it’s building the business layer extraction tools with knowledge tools to no longer have to worry about legacy code issues
I get it, you have to use the tool correctly and despite my cynicism I'm not adverse to using it. However, if I have to type a short novel for it to understand what's going on the value of the tool is pretty low.
ai has been tremendous at helping us understand legacy code bases no one could decipher
I keep hearing that but the tests I've performed regarding that have been... lacking. yeah it might point out some stuff, but the actual subtleties, edge cases, weird interactions.... . I work on a huge codebase, maybe it's better in smaller ones.
completely anecdotal I know, but I'm really underwhelmed.
My dev environment on code change takes 3-4 minutes to restart so getting it right in as few try’s as possible is a goal so I can move on.
The testing portion isn’t just me testing locally, it has to go through QA, integration tests with the 3rd party CRM tools the customers use, internal UAT and customer UAT.
Sounds like this is the main issue, not necessarily AI itself. At least on regular full stack projects of mine, with hot reload I can see changes instantaneously so using Cursor significantly speeds up that part of experimentation with different code approaches for example.
That is the main issue while developing the app. Which is one of the reasons I brought these issues up to my boss. To do a reality check. Luckily my boss is pretty reasonable.
6 months into the new year? No one is talking about AI at my job anymore.
Lucky you. We got the village idiot of CTOs after our recent exec shuffle, and he's doubling on AI despite no one asking for it and our pleas to fix actual problems ignored.
Accelerate our cloud and security policies? Nah
Bring teams closer? Nah, fuck that back to functional silos you go!!
Fix tooling and provide better production support? Lol, not my problem.
6 months into the new year? No one is talking about AI at my job anymore.
Good for you.
I'm more in the data science space. And I just had to "rescue" some model + simple prediction tool from the dead because apparently management still wants to keep it around albeit no one uses it. But it's an AI model (DNN) so we must absolutely use and keep it even if it adds no value.
do you have unit tests that cover at least 90% of your codebase? Do you have working functional tests that accurately simulate every real user behavior? Have you written every possible productivity enhancing tool that your team can think of? Do you write accurate implementations of every possible feature idea before you commit to officially supporting the feature?
if you answered ‘no’ to any of those questions, then there’s a situation where writing the code was actually a bottleneck.
"Have you written every possible helpful tool that your team can think of?" needs to be weighed up against "Is your team resourced to support every possible helpful tool your team can think of?"
Code is an asset but it is a depreciating one, like a building. Do you want a massive house with hundreds of bedrooms and bathrooms? Can you afford to furnish, clean and maintain them?
Code can be an asset but it's also a liability. If you write code that costs you more in terms of maintenance and making the system harder to change than how much it benefits you you'll be worse off.
Writing the code isn't the bottleneck there, designing the tests correctly is. Planning, researching, and implementing the tests correctly is much harder than physically touching the keyboard in the correct spots.
Do you know if code coverage is a good metric for your unit tests?
Do you know which user behaviors are "real"?
Do you know what tools would actually be helpful to your team?
Do LLMs write code for features well enough that you can know if you should commit to officially supporting them?
There have been plenty of times where I LLMs have failed to generate the thing i want them to, and I give up and just write the code myself. In those cases, using the LLM was wasted time.
This has happened to me a few times now. It seems to get into a cycle of three or four answers and I'll say "no, this doesn't work because of x and y reasons..." - "You're right, here is a better solution..." and it becomes clear that it isn't going to come up with an answer, so I've just gone ahead and done my job as I always have, but I just wasted time trying to save some time using AI.
It's great for putting together small peices of functional code that I can then assemble into something bigger, or putting together a set of test data.
Yes! The amount of time I see people optimizing for the wrong problem is insane. They end up with beautiful solutions for problems that do not exist or it will be forever before they manifest. You don't need to optimize for a billion users when you don't have 10 users.
If you believe writing is not a bottleneck, would you agree to insert a one second pause after your every keystroke?
Writing IS a bottleneck for many people. You can easily observe that at work - people that type faster often times type more. They write more detailed messages on Slack, more detailed task descriptions, more detailed design documents.
Wanna feel the pain of a slow typer? Change your layout to Colemak or Dvorak, and switch keycaps so you could type while looking at a keyboard. Try to work like that or write an email. This is a daily experience for some people!
People who think the actual physical act of writing/typing is not a bottleneck are either above-the-average typers themselves, or they are just coping because they have no idea how much typing fast could improve their lives.
Hmm... How can we make software heavier? There's a startup opportunity there somewhere. Of course I do have the patent on 'fat bits', which can store more 1 or 0 in the same space, so I might have a foot in the door already.
Rock star dev of a team of rock stars? Get told you need to live at work or get fired.
Be a fuck up on a team of absolute fuck-ups? Promoted to the moon, and then they get to wander from org to org, leaving a trail of collateral damage in their wake.
The subsequent revisions to the review system merely made it less transparent. No numbers, same stack rank.
I am told by friends who are still there that it finally changed for the better.
The "it's totally not stack ranking" was during the Ballmer years, yes.
Nadella's MSFT apparently actually did away with it, but I still tell my friends there, when they asked me if I wanted to come back, I'll price in the bullshit I had to put up with, and that means I'll want more compensation than MSFT would be willing to pay for the position.
It was great up until January 2023. It's been downhill since then. Morale is horrific today. I was fired last fall for "lack of performance" five months after a strong Connect (performance review). Speaking to folks across the country in the time since and they're just hoping they don't get caught in the next layoff.
...This post is wrong in more ways than I can count.
First off, absolutely not. I do not think you know what proprietary lock-in means. It certainly doesn't refer to QoL features.
Second, every language is proprietary. I'd love for you to try and design a language that wasn't proprietary.
Third, Microsoft is famous for providing enterprise support for a very long time beyond the life of their technologies, while also establishing a path to migration, usually supported by their tools.
Like - your post is so thoroughly incongruous with both the realities of the industry and the topic at hand that I almost think you just responded to the wrong post. It's hard to fathom how ignorant it is.
Everything in the Microsoft ecosystem is related. By design. The network effect is very strong in operating systems and associated software. Unkind ad hominem attacks aren't going to impress anyone here.
Unkind ad hominem attacks aren't going to impress anyone here
You're not even remotely on topic. You're so far off topic and yet it's very clear that you think what you're saying is irrelevant. Of course I'm going to highlight your ignorance.
I have read this thread with interest thus far. As far as I can tell they are right on about prop software etc and looking at your comment history you seem to fancy yourself some sort of professional troll who gets off on calling other people trolls or something.
As far as I can tell they are right on about prop software etc
But that isn't even remotely related to the topic. Any even halfway educated person would notice that. It's really difficult to believe you're approaching this issue in good faith. It looks a lot more like you got downvoted and now you're hopping on an alt to back yourself up.
There's still a lot of anti-Microsoft hate here. They prefer languages like Java, that are not at all owned by corporations led by a dictatorial narcissist.
Really, it's just that a lot of amateur developers inform themselves entirely through memes.
Same here. The Year of the Linux Desktop was 1995, for me. I can't believe the amount of bullshit/fees/malware/privacy disasters/changes for the sake of change that the MS user community puts up with.
If it was only limited to Reddit. There's even people in my company's Slack boasting how they're churning out 10 KLOC of code every day with their AI tools.
Java is worse because of its verbosity. Java is worse than almost anything because of the fucking RSI. I suspect Bill Joy is getting kickbacks from wrist surgeons.
LLMs don’t often write great code. Sometimes. Other times crap. So using them as the primary code writers puts a huge burden on the need for highly experienced code reviewers to look for completeness, security, etc. That’s a bottleneck but worse: in 5+ yrs, where O where do companies expect to get the sr engineers experienced enough with code details to review the LLMs work? There won’t be any—jr engineers who grew up piloting an LLM won’t know crap about the details. And you know greedy bastard companies are just gonna say screw it and slam the LLMs code into prod if it works anyway right? It’s gonna be a dumpster fire in a sea of gas. The fault is not LLMs. It’s the companies.
This seems to be mostly pedantry. When I say I am writing code I mean the act of actually thinking of what I am going to put there and type it out. I also don't think "writing a book" means just transferring an existing idea to paper.
It has nothing to do with being an "idiot". There are very intelligent people who think if you're staring out the window, you're not working. It's a matter of familiarity with the role.
Who said they were? Replace the word programmers above with doctors or lawyers, some things are just known to a certain industry's experts while those outside of them are not, that's just how expertise works. Perhaps you're inferring an air of superiority that they are not necessarily implying, it's hard to communicate such fine details over text.
But the more time I spend typing, the less time I spend thinking, so optimising the typing allows me to spend more time thinking. As a thought experiment: if you spent some time thinking, and then could just click your fingers and have all the code look exactly like how you imagined it, would that not be an incredibly superpower for speeding up your programming? You could experiment with different ways of structuring your code and see immediately which one worked best or made the most sense.
I can't speak much to LLMs because I don't use them very often, but from my own experience learning to touch type has made me a much better programmer because it makes the time between "idea has appeared in my head" and "idea is in the code" much shorter, which means I can get back to thinking much quicker.
Different strokes for different folks, I guess, but if I have an idea while typing, it means I need to context switch to write that idea down so I don't forget it, or maybe write a test for it to make sure I follow up on it later. Otherwise I'll be working on getting one part working and then I'll forget about it or be distracted about it.
For me, being able to type fast means that I can try out ideas fast though, so it still helps. If I typed slowly I wouldn't bother trying things out as often.
100% agree, otherwise vim/emacs users would be the top earners of this world. Wait, maybe they are.. ;-)
It's funny how much vim users harp on their "speed", as if the speed of text editing is the most important part of their job. Honestly, if you think your editing speed is your best feature as a dev, you're probably right.
Vim isn't about speed, it's about flow. Vim makes it easier for me to think while editing because I don't have to pause to look for things and move the mouse. That makes it easier to keep focused, and it makes it easier to try out new ideas, which means I don't have to keep as much in my head. And well, there are times where I already have a good idea of what I want to do. In those specific situations, editing speed can be a bottleneck. But it's mostly about flow.
When you internalize the keys, it becomes effortless. With a GUI there's a full feedback loop required: your eyes are watching the cursor as it moves to the button, verifying that it's "there" so you can click. With pure keyboard input, there's no information coming back from the computer, just the stream of commands being punched into the keyboard. To me it feels like how driving or walking playing videogames has stopped feeling like "ok move the leg, turn the wheel, press the button" and is now just "k I'm going that way now".
When you internalize the keys, it becomes effortless.
This is true with any input mechanism. If what you were saying were true, learning vim (or at least modal editing) would be part of every curriculum and required at every job. But I've worked with a lot of developers, and I have never seen any sort of correlation between preferred method of input and editing speed, nor between editing speed and productivity. There's simply no evidence to suggest it's any sort of benefit at all.
What I'm saying isn't vim-specific at all. In any software tool you want to become proficient with, you'll be faster if you internalize the hotkeys than if you always need to click through menus. If you've got the hotkeys internalized, you have less reliance on the visual feedback. How is that the least bit controversial? I'd be genuinely curious (and surprised!) if your experience is different from that.
Guis are awesome for discoverability. You can find all the available functionality just by clicking through. Hotkeys are awesome when you know what's there and just want to execute it as quickly as possible. I think that's the original point about flow.
In any software tool you want to become proficient with, you'll be faster if you internalize the hotkeys than if you always need to click through menus.
This is moving the goalposts. No one was discussing the value of hotkeys vs. multi-layered menus.
Guis are awesome for discoverability.
GUIs are awesome for usability. You can have every single advantage of pure text, plus a whole host more that are impossible in pure text.
Genuinely not trying to move the goalposts, just trying to be more general. Can you give me an example of a GUI element that you use in the context of editing text that you find useable and productive? I'm honestly curious to learn.
because I don't have to pause to look for things and fiddle with keyboard shortcuts.
This is one of the braindead takes I have seen in a while. The point of vim is you dont pause and look for things. Like lmao, that is what you have to do with GUIs.
You know I see way more unhinged people harping on vim than vim users acting elitist. It has to be some inferiority complex, right? Like I don't go around saying "GUI users are so fucking stupid lol", is that what you imagine in your head?
New flash: no one gives a fuck how you prefer to edit code.
It's funny how much vim users harp on their "speed", as if the speed of text editing is the most important part of their job. Honestly, if you think your editing speed is your best feature as a dev, you're probably right.
What, you didn't say this out of the blue lmao?
Brah, you never mentioned your editor, I'm just calling you out. It's just fascinating to me how many people need to release their anger on vim for no reason. Like can you explain that to me?
Yep. It's this. The speed you gain is just a side effect. It's more about removing distractions to your train of thought by taking away as much of the context switching as possible.
I used to prefer emacs and I'm only less than a year into using Vim, but I think I like the experience better. I used to loathe the jumping between command and insert mode, but now it just feels intuitive. It feels like "talking" to your text editor using its own language.
I still have plenty to learn, but I feel quite productive with it. When I say Vim though, it's not just vanilla Vim or its several incarnations, but also the emulators. I love IntelliJ but I also like Vim, so I use IdeaVim for example. On Firefox, I use Vimium. Even in Obsidian I use the Vim bindings.
For me, the "speed" aspect is not about how long it takes me to enter code, it's about the "million papercuts" of waiting for the editor's visual response to every input. The accumulated delay isn't a lot, but each of these microdelays has the potential to stop my train of thought.
E.g., in a typical graphical text editor, if I want to do a search-and-replace, it goes something like this: press Ctrl+F to open the search/replace dialog, wait for the dialog to open, look at the dialog to see whether it's in search-only or search-and-replace mode, tab to the control that changes that if needed, tab to the "search" textbox, look at what's already there, delete it and write the search term I want, tab to the "replace" textbox, look at what's already there, delete it and write the replacement I want, find the "replace all" control, verify that it's on, then hit "Enter" (or click the "OK" button). There's about half a dozen points here where I need visual feedback from the editor before I can continue to make inputs, and each of these stops my flow for a split second. And if I'm working over a remote connection, or the system is under very heavy load (e.g. because the IDE is continuously recompiling the code to keep completion suggestions and such up to date), then those delays can get much longer.
Meanwhile, in vim, I can just type :%s/search-term/replacement/g<Enter>, and even if I'm editing in an SSH session on a remote RPi connected over a dialup modem connection to another continent, the effective delay is still zero, because there is no point at which I need to wait for any visual feedback.
So in a way the "speed" that's being boosted here isn't the typing speed, it's the thinking speed.
I mean, yes, I can also perform a lot of editing operations slightly faster than I could in a more "conventional" editor, but that's marginal, and not the point at all. It's all about the flow and those micro-delays.
For me, the "speed" aspect is not about how long it takes me to enter code, it's about the "million papercuts" of waiting for the editor's visual response to every input.
You're basing this on decades-old stereotypes. Any modern GUI is going to be instant. Vim is only any faster when unmodified - yet every single developer uses a ton of plugins. You have to, because it's featureless out of the box. But these plugins can make vim awfully slow.
Neovim was created because vim refused to add parallel processing of plugins, infamously resulting in minute-long load times in some extreme cases. I've noticed in the past that, for several of my vim-obsessed coworkers, my VSCode launched faster than their terminal editor. You should try profiling your own client - you'll very likely be surprised by what you find.
The reality is that vim just isn't impressive by modern standards. Modal editing is still of value, but of course, every modern IDE supports it.
Meanwhile, in vim, I can just type :%s/search-term/replacement/g, and even if I'm editing in an SSH session on a remote RPi connected over a dialup modem connection to another continent, the effective delay is still zero
Perfect example. I get this same feature in VSCode. I get that this was impressive in the 90's, but it just isn't anymore.
You're basing this on decades-old stereotypes. Any modern GUI is going to be instant.
That's not the point. The point is that vim's keyboard-centric UI is faster than instant. You cannot click a button that isn't on screen yet, you can't type into a text box before it appears, but you can type vim commands before the editor is ready to execute them.
yet every single developer uses a ton of plugins.
I don't. ftplugin, a couple custom rules and macros in .vimrc, that's basically it. You only "have to" use a ton of plugins if you want to turn vim into an IDE; but if you use it as a text editor, then it's pretty near perfect out of the box.
I've noticed in the past that, for several of my vim-obsessed coworkers, my VSCode launched faster than their terminal editor. You should try profiling your own client - you'll very likely be surprised by what you find.
~/ > time vim -c :q
vim -c :q 0.05s user 0.03s system 96% cpu 0.078 total
I think I'm good on that front.
The reality is that vim just isn't impressive by modern standards.
I don't need "impressive"; I just need "robust, battle proven, minimal, effective".
Perfect example. I get this same feature in VSCode. I get that this was impressive in the 90's, but it just isn't anymore.
Again, it's not about "impressive". Of course you can do these things to various extent in other editors, they all took inspiration from vim, and my argument isn't so much for vim itself per se, but for the text editing paradigm it represents. I use actual vim, because it implements the paradigm efficiently, and there isn't really anything I need beyond that, so I don't see a reason to switch.
"Faster than instant" is of course a bit tongue-in-cheek.
What I mean by that is that your commands and the UI's responses do not need to run in lock-step (issue command, look at response, issue next command) - you can issue commands at whatever rate you want, and the UI will process them in order, presenting the results as they become available. Even when responses are literally instant (i.e., there is zero processing time involved), you still need to process the visual information in order to issue the next command, so "instant" is still slower than "type-ahead". That's what I meant by "faster than instant".
This is correct for professional software engineering teams but for solo (or a small team of) developer startup founders for example, writing code often is the bottleneck. I have limited time after work to code and vibe coding an MVP to test out various ideas has completely changed how I can prototype ideas quickly to create products I can sell, and I suspect that's true of many others.
I have limited time after work to code and vibe coding an MVP to test out various ideas has completely changed how I can prototype ideas quickly to create products I can sell, and I suspect that's true of many others.
This kind of attitude is fucking toxic.
You are making a product to sell which means it should do what you say it does safely and at least mostly reliably.
Churning out low quality bullshit to sell to suckers makes you a con artist not an entrepreneur.
Churning out low quality proof of concept stuff is pretty common for startups, though. Something that runs, but might not scale whatsoever, maybe it has a lot of bugs, might be an unmaintainable chaotic mess, potential security issues that have not been addressed, etc. But if it's enough to demonstrate to investors that your product has promise, you get money, and then you can more or better people to do make a better version. Rinse and repeat, and it gets better with time.
At some point you do need various parts of the product to meet high levels of quality and safety, but not necessarily from the very start.
Should've read my other comments then because that's where that quote comes from, can't get the full context from just the top level post if you're going to be engaging in a discussion that I've already been in the midst of. To be honest, I knew the sort of person like you would reply to my comment, that's why I preempted it by talking about prototypes and not full production scale products, which, again, I clean up and polish.
Prototypes are supposed to be throwaway code, but they're not because they look like they work and when people are looking to win the appstore lottery and they don't have a problem they're trying to solve but are instead looking for "products" looking like they work is a pay day
AI crap needs more than "polishing" especially if you've been vibe coding it.
But that's literally what I said above, "Prototypes are not shipped, they are for testing purposes only." Sounds like you're talking yourself into a circle and imagining yourself to be right without even reading what other people written. You're essentially arguing against a strawman you yourself have built.
Good thing I'm not talking about a company with salespeople now, isn't it? I'm talking about myself amd the prototypes and products that I make and now you're shifting the goal posts because you have no retort to the original comment.
Lmao. Obviously you need to know how to sell if you want to run a startup, no one's gonna buy your shit otherwise, it is not sufficient to just make some app and think people will come running over to buy it. Next time you build something and then tell me how that goes in terms of making money from it, sounds like you have literally no experience.
This is honestly the most naive take in this thread, and I don't even know what else to tell you or what your argument now even is (since you quoted me and replied with a goalpost shifting response yet again) so have a good day.
This is honestly the most naive take in this thread, and I don't even know what else to tell you or what your argument now even is (since you quoted me and replied with a goalpost shifting response yet again) so have a good day.
You act and sound like someone who wants money more than solving problems, you "prototype" through AI to get products out to sell.
You claim you clean up (though that's not how prototypes are supposed to work), but frankly I don't believe you because you talk like every other app store concartist I've ever met and not at all like an engineer.
I honestly don't think you do much of all to the AI code, I think you on sell it as fast as you can.
You're free to believe whatever you want to believe, but frankly I don't even think you're an engineer in the first place, and again misunderstand what prototypes are. Have fun continuing to shit post in your nation sub.
It does mean something, not sure why it wouldn't. It means to not code anything yourself and instead let the AI code everything for you, as was defined originally by Andrej Karpathy.
There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs
Yeah, sort of. It depends on the complexity of the particular piece you're trying to prototype, and especially, how common the requisite patterns are in the training dataset. I've found it actually amazing at prompting me to get moving, because it's like the code equivalent of generating lorem ipsum text, throwing it in your design mockup and going "huh, actually yeah maybe if we change this..." and then off I go, instead of staring at the blinking cursor just churning it over mentally. Somehow, when I'm just in a blank file, I get stuck in that mental churn cycle, but if I can have something even minimally coherent spit out onto the screen, even though it usually doesn't even compile, suddenly I escape my own head and even though I end up completely re-writing everything that was generated, it was like the push I needed to get going.
Absolutely. It triggers my ADHD brain to be able to move past my perfectionism, to not need to start from a blank slate, a form of writer's block. With previous models I agree it wouldn't often compile but with Cursor using Claude 4, it autonomously detects compilation errors and fixes itself.
Now I feel more like a PM, telling it that such and such doesn't work and to fix it, than a real developer now, which is fine because they're all still prototypes. Once I'm ready for production, I clean up the code myself and polish it up.
The apps I'm making aren't too complex, just CRUD web and mobile apps, which is very common in the data sets, I certainly wouldn't use it for embedded, games, or very specific niche development.
I totally agree with the op and there is an incredibly elegant solution to this: using AI at scale in a team means involving it in design, planning, testing and code review support, and therefore also in writing the code. So let's use AI to address the real bottlenecks.
It’s the same reason why no-code options are so stupid. Writing code isn’t the hard part. Knowing what needs to be done, verifying it works as expected, communicating how it works, etc is the big part of the work (like the article said).
A lot of people don’t understand the difference between prescriptive developers and adaptive developers. You can give an adaptive developer the destination (ie the objective), and they’ll draw the map on their own and make it happen. Prescriptive developers need the map drawn for them, and they’ll follow it exactly even if the map is wrong or outdated.
No-code is a trap where they convince product owners they don't need programmers at all. Then they realise that they cannot write programs, even in their "no-code" environments. So it gets handed off to engineers who despise what has been inflicted on them for spurious reasons.
Can confirm. Azure Logic Apps is one of Microsoft no-code/low-code tools, and it is quite literally the worst piece "tech" I've ever had to work with (I've got 20+ years in the industry). It's actually insane how bad it is in every single aspect.
And this has been going on in waves since the invention of the punch card.
Oh, look, we can just use punch cards instead of wires, now we don't need engineers to wire programs into the computer, ordinary users can just punch them into cards, and all the engineer needs to do is load the cards into a magazine!
Oh look, we now have a computer program that can translate programs written in mnemoics into machine code; we no longer need engineers to do that translation by hand, ordinary people can now type their programs directly into the computer in human-readable form, and the computer will do the rest!
Oh look, we have made a COmmon Business-Oriented Language that looks exactly like English; we no longer need engineers to deal with pesky assembly language, now ordinary business people can write the software themselves!
Oh look, a Structured Query Language that looks exactly like English; now we don't need custom computer programs to retrieve information from a database anymore, users can just write what they want, and the computer will do the work!
Oh look, a visual code editor; now we don't need engineers to write computer programs anymore, users can just visually drag small blocks around and combine them into more complex programs that do exactly what they want!
Oh look, a no-code web platform; now we don't need web developers anymore, people can just install the platform and configure it to do whatever thye want - select a theme, define some rules, install some plugins, off you go!
And look what happened.
Punchcards were practically never made by nontechnical users - rather, programmers would move from plugging wires to punching holes.
Assemblers made programmers more productive, but practically nobody that wasn't a programmer could make anything nontrivial in it.
COBOL programmers are in crazy high demand, and approximately nobody ever wrote anything more complex than a 10-line COBOL program who wasn't an actual programmer.
SQL is still a thing, and it's useful, but realistically, the people who use SQL are never non-technical users, they are DBA's, programmers, tech experts.
Visual code editors never really took off; those who use them are either programmers dealing with the mess some non-technical boss made deep in Dunning-Kruger Valley, or young programmers-to-be making their first steps at an early age (think Scratch), or experts coming from domains in which building up functionality by combining modules and connections into graphs is a natural paradigm, such as audio engineering or electronics.
No-code web platforms are used for extremely limited run-of-the-mill applications (e.g. Wix), where there's not much configuration to begin with, and you're really just using the same code as everyone else with a thin cosmetic veil on top; and they are used by expert web developers to build complex things more easily and efficiently.
The common pattern: except for absolutely trivial applications, none of these things has delivered on the promise of taking the engineer out of the loop and allowing non-technical users to directly instruct the machine to get it to do what they want. In the better scenarios, the tools helped increase developer productivity, but at least in some, it's a net loss, where the tools just complicate the expert's work without being viable as a replacement of that expert.
The real choke point is turning fuzzy objectives into something everyone can see, poke holes in, and sign off on.
What’s worked for me is treating requirements like code: I write a one-pager ADR before touching a keyboard, pair with the domain expert to fill gaps, then turn that doc into high-level tests in Gherkin. Those tests act as living specs and force early conversations-if a scenario is hard to phrase, the requirement isn’t clear yet. Automated contract tests catch drifting assumptions later, making verification less painful than giant QA spreadsheets.
Tools help but only when they reinforce that loop. I’ve used Postman collections to demo endpoints to non-tech folks, wired Terraform plans to show infra costs up front, and finally leaned on DreamFactory to spin up throwaway APIs instantaneously so the team can focus on behavior, not boilerplate. Every piece is there to shorten feedback chains, not replace thinking.
Spend twice the time on shaping the map and the code writes itself.
No code is stupid for a somewhat different reason, it's usually because they're closed source locked down platforms that you can't extend or modify if you want to go even slightly outside what they're designed for. I think AI that interacts with actual code is different, you still own the code so it solves the above problems with no code solutions, but I will say that knowing what one wants is the hardest part, as you say and as the article says.
imo the speed of writing out code is an underappreciated bottleneck. Not the speed of writing code in the linear sequence of "write -> commit -> review -> deploy", but in the process of experimenting with a bunch of different approaches (to the algorithm, to the interface design, to the separation of responsibilities, which dependency to pick...) to see what shakes out as the best, most maintainable solution in practice, to suss out the gotchas in the implementation that weren't obvious when you were writing up the ticket, etc.
That said, it's a better argument for good editors and investing in faster build times/tests than for forcing AI everywhere.
There is a big, big personality thing in here, that you actual care to do that and not just ship the first thing that barley works and fulfills the task described.
Looking at most software, they just ship the first shitty version and hope for the best.
For the first year I was a paid programmer, I was hunting and pecking with four fingers.
Still managed to give myself and RSI, probably from looking down (a lot of wrist pain starts as pinched cervical spine nerves.
Learned to touch type Dvorak as part of rehab, but didn't really get that much faster until I got code refactoring tools.
But nobody that I'm aware of has substantially expanded the set of automatic refactors since sometime around 2010. I think generative AI could probably make suggestions here, as well as in attempting to resolve merge conflicts.
AI is just going to make these bottlenecks even more pronounced because it’s creating a chasm of knowledge that someone now has to cross when something goes wrong. You and no one else in your org has worked on the feature that now needs to be fixed or extended. Now you need to figure the entire thing out and hope it’s not a nightmare (it will be). These scenarios are common without AI, but now the fuckers who work on the code don’t even know what’s going on.
You can always use the tried and true method of cutting out words from a language reference, mixing them up, and then selecting them randomly into a sequence. Of course you have to have a protagonist and a love interest. A dog is always a nice touch.
I'm gonna bookmark this article as a way to describe my frustrations with the AI craze, this is good and I like it.
My one thought if OP is taking constructive criticism is I wish it had a section / a bit more on why the other aspects of our day-to-day is important: code review, debug, testing, QA, etc. Honestly know some engineering managers that would take this article as a reason to remove those aspects of the software process as well, no matter how inadvisable. I read some O'Reilly book on Google's engineering practices and to misquote it, it generally said "if the pure goal by engineering management is to push code quickly, increase velocity, and/or get tickets done, then removing all non-code-writing processes, the processes that save their ass, is the best way to do that."
On the positive aspect though, I am absolutely with OP that the easiest part of my day is writing the boring boilerplate, render tests, CRUD operations that AI can replace. It also is the item I spend the least time on because it's so easy. The parts of my day that actually take up time are the hours spent with design and product to nail down possibly vague requirements, back-and-forth with QA and/or other SMEs, and usually a few hours of code reviews if it's near the end of the sprint. How hard my day was is directly related to my time spent in Teams, not my time spent in IDEs.
Great post, and I agree with a lot of it — but I think it's missing a key point.
The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. All of this wrapped inside the labyrinth of tickets, planning meetings, and agile rituals.
The author mention code reviews, mentoring, testing, etc. as the bottlenecks. But honestly a lot of the bottlenecks are just... people being people.
We get tired, we procrastinate, we forget. Sometimes a PR doesn’t get reviewed because someone just didn’t feel like dealing with it today.
LLMs don’t fix that. If anything, they add more pressure to a system already full of human friction.
I think you're essentially repeating what they are implying, it's not the actual code reviews themselves but the "human overhead of coordination and communication" which is what you said phrased differently.
Fair point, but I wasn’t just rephrasing. “Human overhead” usually means meetings, coordination, that kind of thing. I’m talking about the messy human side: burnout, procrastination, not being in the mood to review a PR, ignoring a ping like it’s a WhatsApp message you don’t want to deal with haha.
It’s not process overhead. It’s life. And it slows things down way more than we like to admit (at least me, ye?)
Nope. LLMs have not cracked writing code. It's a nonsensical argument to begin with. You need a code review because writing code is hard. Not as some external process to sprinkle fairy dust on it before sending it into production.
Communications - if you build the wrong thing, it doesn't matter how well you build it. Meetings are not communications. Meetings are usually just micromanagement. Documentation is not communications. That is usually just micromanagement as well.
Tech debt - If you can't finish what you are building then it probably wasn't even worth starting. Tech debt is where the art of programming really comes to play. It's avoidance is a combination of workflow, tech stack, programmer skill, architecture, design, flexibility, and a slew of other skills; and very importantly culture.
Another related skill is leadership. This is not management, and is not necessarily a programmer. A successful project requires leadership. Management is for processes like assembly lines. Leadership is for battles. Software is a battle, not an assembly-line. Someone has to identify, and then inspire people to a vision. This is a team effort. I've said this a zillion times, managers whine about "hearding cats"; leaders get the cats to follow them.
I almost got fired on the spot once for mouthing off at a CTO and telling him he should incorporate a minimum WPM typing requirement for engineers, since he was so big on using git metrics analysis software that ranked everyone in the company by lines of code.
(And not all lines of code were good! You had to be writing new lines or fixing someone else's new lines or you were junior garbage).
I hear the stories about how xx% of new code written at some new company are written by AI. But at the end of the day, one of two things is happening:
you're going to Prod with code you don't understand, the software engineering equivalent of buying stock in companies you can't describe
you're spending the same time reading the AI code, critiquing and refactoring the AI code, getting severely burned once in a while by the AI code, and finally understanding what you check in well enough that you can take it to the bank - you can confidently build on it next release and you can produce answers when it blows up in prod
You're saving a lot of time and likely a lot of money with #1, until your momentum wears out and gravity takes over.
I would bet that in more than 80% of cases, the original IntelliSense, which I believe shipped with Visual C++ 4'ish in the mid 90s, did more for outright/net engineering efficiency than AI does today.
I'd argue you shouldn't be checking generated code into git, unless you're only generating it "once" and it will be hand maintained. You'd check the bash generator in of course.
The overarching point is that software engineers do a lot more than just "type" code. Particularly at smaller orgs, the most effective people do a little of everything, and AI can be involved in most of it but it's not going to replace anyone.
I'd argue you shouldn't be checking generated code into git, unless you're only generating it "once" and it will be hand maintained. You'd check the bash generator in of course.
Normally, yes.
But there are cases where you want to use a script to generate a starting point, run it once, and then apply per-case edits to it. E.g., suppose you are writing a replacement for an existing CRUD application, and just to get you started on the data model, you dump the database structure from the old version and use that as the initial version of your database setup script for the new version - but then you clean that up, edit it into shape (possibly in a semi-automated fashion, e.g. editor macros, sed scripts, etc.), and track all that in source control. In the end, you could still argue that pg_dump or whatever tool you used wrote 95% of that code, but that doesn't mean you could check in the original pg_dump invocation instead of the actual SQL script that's going to be used in production.
Also, "95% of the code" doesn't necessarily mean "95% of the code that's in git", it can also mean "95% of the code overall", or a number of other things. In that sense, even just deciding what does and does not count towards "lines of code in the project" is iffy at best.
The physical act of typing has never been a bottleneck, except maybe to Java programmers, who I swear are perverts who are turned on by pushing keys.
I look at the screen for 5-10 minutes, type a few characters, and stare at the screen some more. I could probably have used a 300 baud modem to filter my keyboarding for most of my career coding, and not noticed.
(Not my reading of stuff I need to do the job, though, of course. I need lots of bandwidth for that.)
Yes, but try running a graphical IDE in a remote desktop on that kind of connection. It's not the keystrokes that are the problem, it's the visual feedback.
There's an underrated advantage of LLMs: they are a lot better at graphical design than most programmers. "I" made an internal tool at work with a LLM a week ago, and it created a web interface with a tasteful gradient on a button. A gradient! I had literally never used a gradient in actual decades of making "programmer UIs".
When Fred Brooks wrote "The Mythical Man Month" he never really mentioned the writing of the software as the big time suck. It was all this other stuff mentioned in the article (except agile, of course, but waterfall has it's time wasting "ceremony" equivalents).
No, there can absolutely be phases in software development where writing code is the bottleneck. You know what you want to do, you have pretty clear picture of it and most of the work is just writing the damn code.
But even for that kind of software, even if that happens: That's where it ends. The rest of the lifetime of the software beyond that burst of development is maintenance, reading, fixing, evolving.
My personal objection to those who tell me to rely on LLMs for coding: we have invented programming languages to allow us to express our thoughts in an unambiguous way. I need the rigorous syntax and semantics of the programming language to understand what is it I'm trying to build.
I think, like the author says, human coordination is the biggest challenge.
For example I will finish the planning, implementing and testing of a feature, but then can't release, because there's other stuff on the quality branch that's not yet been released, or someone pushed to it something untested! It's silly things like that which slow down teams.
There are many different bottlenecks at different times in the process.
Sometimes you debug and the bottleneck is a single missing character.
Sometimes you have a really hard architectural problem and thinking for a day or two is the bottleneck.
Sometimes you don't have product-market-fit and trying different business models in the bottleneck.
Sometimes, you know exactly what you want to build and writing the code is the bottleneck.
Saying that generating lines of voice isn't the bottleneck and that LLMs can't solve the bottleneck is reductive. Sometimes it is the problem and sometimes LLMs battle diminish it. Not always but sometimes.
The bottleneck is compilation times, people not knowing what they want till they have it and realise they want something different, and limited amount of working memory resulting in logical errors, requiring iterative improvement via debugging.
I might spend two, maybe three hours a week writing code. As someone who generally knows what they're doing I still fail to see what AI brings to the table.
qtipbluedog@reddit
Yep. When the AI push took off earlier this year at my job. All the suite people and even my my boss were pushing it. Saying it’ll improve dev times by 50%.
I hadn’t really used AI much since trying copilot for about a year. With varying levels of success and failure. So after a few days of trying it out I landed on the similar conclusions to this article. Without being able to test the code being put into my editor quickly writing code will never ever be the bottleneck of the systems.
The testing portion isn’t just me testing locally, it has to go through QA, integration tests with the 3rd party CRM tools the customers use, internal UAT and customer UAT. On top of that things can come back that weren’t bugs, but missed requirements gathering. That time is very rarely moved much by how quickly I can type the solution into my editor. After explaining this to my boss he seemed to understand my point of view which was good.
6 months into the new year? No one is talking about AI at my job anymore.
tdammers@reddit
Now imagine how much of an improvement it would be to get those 3-4 minutes down to 3-4 seconds. AI can improve dev times by 50%? How about fixing the testing infrastructure to improve dev times by 6000%?
flyinghi_@reddit
No, that’s not sexy enough
agumonkey@reddit
But remember, "sexy" exists at all layers, I had people distract teams for some agile subtrend because it sounded sexy, and dev managers ran with it. It's not necessarily c-suite and AI, it's a flaw in human groups
MoreRespectForQA@reddit
agile at least had support among devs until the agile-consulting-industrial complex took over.
tdammers@reddit
What if I somehow use AI to make that turnaround 6000% faster?
DangerousCan7636@reddit
similar gains if you get off reddit
tdammers@reddit
Touché.
Professional_Top8485@reddit
Testing? Infrastructure? QA 😂
qtipbluedog@reddit
You’re telling me. Since I started a few years ago I’ve complained about start up times and we’ve never been given time to fix it. We’re using a 12 year old version of a framework. We have finally convinced management and this year we have time to upgrade it. Updating versions should give us back hot reloading and reduce that but… we’ll see.
A lot of software is a people problem. Not a machine one.
xFallow@reddit
Absolutely imagine if we replaced hours of useless meetings with coding time
Most senior engineers and team leads I know complain they don’t get enough time to code
PoL0@reddit
venture capital says meh
devraj7@reddit
Don't ask the LLM to just write code for you, ask it to write tests for its own code. It's incredibly effective.
Femaref@reddit
tests generally should be written from the requirements, not from the code, to ensure the code actually does what it's supposed to.
devraj7@reddit
Which is exactly why it's useful to ask both code and tests from the LLM, there is no difference with what you just said.
kronik85@reddit
except the quality of tests can be quite poor, but if they go green everyone's happy.
broke a feature at work that way. never trust an LLM.
devraj7@reddit
Why such a radical take? "Never" is such a closed minded take.
Right now, I would say, trust but verify.
In ten years from now? You will probably regret writing "never".
kronik85@reddit
trust but verify is a witty paradox.
you verify because you don't trust.
you think Reagan actually trusted the Russians during the Cold war?
zxyzyxz@reddit
If the LLM writes bad code, the tests it writes will be to that code, not what the actual business requirements are. Asking it to do both is essentially asking it to make up its own BS then justifying it via "tests."
devraj7@reddit
But you are there, you are not going to blinding commit and push that, are you?
You can inspect both the code and the tests and it's pretty trivial to get a quick sense of what's working and is not.
zxyzyxz@reddit
Not necessarily trivial, sometimes code and tests are subtly wrong where it takes more time to verify and find the bug than to write it yourself without the bug in the first place. And often after a while people do blindly commit because reviewing code all day can drain one's energy than coding. That becomes the real danger to a business.
devraj7@reddit
That's a human problem, nothing to do with LLM's.
At the end of the day, reviewing a test is much easier than reviewing code. The code generated by the LLM might be complex and hard for me to understand, but I can review the test code pretty quickly and knowing in confidence that if the code passes this test, then it's mostly correct.
zxyzyxz@reddit
Technology informs behavior, of course that is true otherwise apps like TikTok wouldn't exist. The truth is LLMs cause such issues over time. The fact that you can drive a car without knowing how the engine works is because the engine wasn't built probabilistically at the factor, there wasn't a worker deciding whether or not to put a particular screw in. You're arguing the wrong analogy. And if you don't understand the code you're emitting (whether by an LLM or yourself), then you're honestly not an engineer, just a code monkey.
devraj7@reddit
Of course, but the reality is much more nuanced than that.
They cause issues, sure. But what issues do they solve?
Analyze this objective, assess the pros and cons, then make a decision.
Be open minded and rational.
zxyzyxz@reddit
Who said I rejected it? Did you see my other top-level comment in the thread? My only point was that it's not good for both creating tests and writing the code for those tests, because the business logic itself could be wrong. I make no other judgment on LLMs.
kronik85@reddit
if you don't understand what the code does you sure as shit shouldn't be relying on an LLM test to prove it to you
MarekEr@reddit
You shouldn’t push any code you don’t understand.
steveklabnik1@reddit
This is why it's a good idea to have the spec first: you can then ask the LLM to reference the spec to write the tests, and then afterwards, ask it to make the test pass by changing the implementation.
2this4u@reddit
Even Google have admitted it's only a 10% velocity benefit, and you know that's from the most optimistic look at metrics they can contrive
cbusmatty@reddit
That’s crazy, ai has been tremendous at helping us understand legacy code bases no one could decipher, or using it to talk to business to get clearer requirements and make sure we are capturing it all. Literally no one ever said code was the bottleneck and llms solve the real bottleneck. Insane to be proud that you fought to hamstring your organ
colei_canis@reddit
I’m also in a position where archeology trips aren’t uncommon but you’d be mad to rely entirely on LLMs for this. Yeah they’re a decent tool and I’m glad to have them, but they couldn’t spot Chesterton’s fence if they stumbled directly into one of its posts which is a key part of dealing with legacy code.
billie_parker@reddit
lol this is one of the things they do really well
cbusmatty@reddit
They absolutely can if you understand how to use them. If you’re just going “copilot tell me about this repo” yes it’s going to fail. But if you manage the context and then spin up agents to map repos and build knowledge graphs, then you’re using ai correctly. You would be a bit mad to have any tool at your fingertips limited by your imagine and saying the tools don’t work
colei_canis@reddit
By definition an LLM only grasps the language though and that’s hardly the most important thing in debugging legacy code.
The legacy code I deal with isn’t bad because the developers didn’t give it shit rather non-technical business factors are what makes it a tangled nightmare and the code is just working around concepts that were shitty to begin with.
For cleaning up that mess you need a mix of understanding the code, understanding the business decisions that made the code bad, and all the tribal knowledge that says x was done y way for z reason. Just relying on the code alone as a source of knowledge is like digging yourself out of a hole when you don’t know which way is up in my opinion.
I’m not saying this from an ‘AI bad’ position, I’m saying it from a don’t lean too much on one tool position.
cbusmatty@reddit
That’s reductive to say it “only grasps language” considering that code is literally language . I just had Claude code use agents break down the vscode repo with 40k files and 2.5 million loc and have it rewrite it in another language, and it worked reasonably well within like 20 minutes. This is obtuse, these things are amazing tools if you understand how they work and how to use them.
zxyzyxz@reddit
If there's no explanation of business logic, no amount of understanding the code will make one understand the outside business world that created such code, whether that's an AI or yourself. That is the fundamental issue, I could ask AI to do everything you said but since it doesn't know about my specific business because the legacy code has no explanations of it, it will be unable to grasp why certain things like numbers and functions exist.
colei_canis@reddit
You’re missing my point, debugging isn’t just about the code because you need to understand the bigger picture surrounding the code. The LLM by definition is blind to that, you can find yourself debugging the same bugs again and again because they’re created through faulty business premises the LLM has no real comprehension of other than through the code. These faulty premises aren’t always represented in the code!
No amount of code can solve what’s often fundamentally a people problem, and LLMs are no substitute for genuine institutional knowledge. You have to know the depth of the shit you’re in before you start shovelling it, and code is just one thing that can be shit.
cbusmatty@reddit
You are missing the point - use the llm to build knowledge graphs that have that bigger picture. And now you did it for everyone and not just you. You’re doing it wrong
colei_canis@reddit
You can’t build a knowledge graph about stuff you don’t know about though, and what I’m saying is the LLM is necessarily blind to the human factors that conspire to make a codebase shitty.
You can’t abstract people problems away with code, all you end up with is shitty code eventually.
cbusmatty@reddit
You absolutely can. You don’t need to know, code is code. Methods do things. Your knowledge graphs can be traversed with an llm and some rules. This is absolutely doable.
colei_canis@reddit
Why do you have a monomaniacal obsession with code though? Our job isn’t to write code it’s to solve problems, it doesn’t matter if your code is perfect if the business logic it captures is bullshit then you will continue to have bugs as time goes on. Part of debugging is finding out where the business logic is bad, which LLMs by definition can’t do because they’re only looking at code.
Using a tool is one thing but using it as a crutch is quite another.
cbusmatty@reddit
I do not have any obsession, quite the opposite. I am literally saying that code is inconsequential, it’s building the business layer extraction tools with knowledge tools to no longer have to worry about legacy code issues
TwentyCharactersShor@reddit
I get it, you have to use the tool correctly and despite my cynicism I'm not adverse to using it. However, if I have to type a short novel for it to understand what's going on the value of the tool is pretty low.
PoL0@reddit
I keep hearing that but the tests I've performed regarding that have been... lacking. yeah it might point out some stuff, but the actual subtleties, edge cases, weird interactions.... . I work on a huge codebase, maybe it's better in smaller ones.
completely anecdotal I know, but I'm really underwhelmed.
zxyzyxz@reddit
Sounds like this is the main issue, not necessarily AI itself. At least on regular full stack projects of mine, with hot reload I can see changes instantaneously so using Cursor significantly speeds up that part of experimentation with different code approaches for example.
qtipbluedog@reddit
That is the main issue while developing the app. Which is one of the reasons I brought these issues up to my boss. To do a reality check. Luckily my boss is pretty reasonable.
TwentyCharactersShor@reddit
Lucky you. We got the village idiot of CTOs after our recent exec shuffle, and he's doubling on AI despite no one asking for it and our pleas to fix actual problems ignored.
Accelerate our cloud and security policies? Nah
Bring teams closer? Nah, fuck that back to functional silos you go!!
Fix tooling and provide better production support? Lol, not my problem.
But AI? Whip ya dick out and let's get measuring!
....yeah, I'm job hunting.
Extension-Pick-2167@reddit
same here
RationalDialog@reddit
Good for you.
I'm more in the data science space. And I just had to "rescue" some model + simple prediction tool from the dead because apparently management still wants to keep it around albeit no one uses it. But it's an AI model (DNN) so we must absolutely use and keep it even if it adds no value.
Zealousideal-Ship215@reddit
do you have unit tests that cover at least 90% of your codebase? Do you have working functional tests that accurately simulate every real user behavior? Have you written every possible productivity enhancing tool that your team can think of? Do you write accurate implementations of every possible feature idea before you commit to officially supporting the feature?
if you answered ‘no’ to any of those questions, then there’s a situation where writing the code was actually a bottleneck.
AmazonGlacialChasm@reddit
Lol, as if 90% of test coverage is a good metric to start.
Bubbly_Safety8791@reddit
"Have you written every possible helpful tool that your team can think of?" needs to be weighed up against "Is your team resourced to support every possible helpful tool your team can think of?"
Code is an asset but it is a depreciating one, like a building. Do you want a massive house with hundreds of bedrooms and bathrooms? Can you afford to furnish, clean and maintain them?
Adding more code has diminishing returns.
Krackor@reddit
Code can be an asset but it's also a liability. If you write code that costs you more in terms of maintenance and making the system harder to change than how much it benefits you you'll be worse off.
aurath@reddit
Writing the code isn't the bottleneck there, designing the tests correctly is. Planning, researching, and implementing the tests correctly is much harder than physically touching the keyboard in the correct spots.
AlSweigart@reddit
I see your point, but also:
Do you know if code coverage is a good metric for your unit tests?
Do you know which user behaviors are "real"?
Do you know what tools would actually be helpful to your team?
Do LLMs write code for features well enough that you can know if you should commit to officially supporting them?
There have been plenty of times where I LLMs have failed to generate the thing i want them to, and I give up and just write the code myself. In those cases, using the LLM was wasted time.
roscoelee@reddit
This has happened to me a few times now. It seems to get into a cycle of three or four answers and I'll say "no, this doesn't work because of x and y reasons..." - "You're right, here is a better solution..." and it becomes clear that it isn't going to come up with an answer, so I've just gone ahead and done my job as I always have, but I just wasted time trying to save some time using AI.
It's great for putting together small peices of functional code that I can then assemble into something bigger, or putting together a set of test data.
CreditOverflow@reddit
Yes! The amount of time I see people optimizing for the wrong problem is insane. They end up with beautiful solutions for problems that do not exist or it will be forever before they manifest. You don't need to optimize for a billion users when you don't have 10 users.
Strus@reddit
If you believe writing is not a bottleneck, would you agree to insert a one second pause after your every keystroke?
Writing IS a bottleneck for many people. You can easily observe that at work - people that type faster often times type more. They write more detailed messages on Slack, more detailed task descriptions, more detailed design documents.
Wanna feel the pain of a slow typer? Change your layout to Colemak or Dvorak, and switch keycaps so you could type while looking at a keyboard. Try to work like that or write an email. This is a daily experience for some people!
People who think the actual physical act of writing/typing is not a bottleneck are either above-the-average typers themselves, or they are just coping because they have no idea how much typing fast could improve their lives.
SCI4THIS@reddit
Didn't Windows ME pay programmers per LoC? I thought the conclusion of that was that programming value and amount of code are unrelated.
chat-lu@reddit
Isn’t one of Bill Gates’ famous quotes that measuring progress per line of code is like measuring the progress of building a Boeing 747 by weight?
kisielk@reddit
That’s how the soviet union measured productivity, by weight. Led to a lot of factories producing very heavy furniture.
Full-Spectral@reddit
Hmm... How can we make software heavier? There's a startup opportunity there somewhere. Of course I do have the patent on 'fat bits', which can store more 1 or 0 in the same space, so I might have a foot in the door already.
Snoo23482@reddit
Just rewrite it in Java.
Humdaak_9000@reddit
Dude still embraced Jack Welch's bullshit.
LordoftheSynth@reddit
The stack ranks were brutal.
Rock star dev of a team of rock stars? Get told you need to live at work or get fired.
Be a fuck up on a team of absolute fuck-ups? Promoted to the moon, and then they get to wander from org to org, leaving a trail of collateral damage in their wake.
The subsequent revisions to the review system merely made it less transparent. No numbers, same stack rank.
I am told by friends who are still there that it finally changed for the better.
I'll never go back.
sloggo@reddit
Wasn’t that stuff after bill gates tenure, technically?
LordoftheSynth@reddit
The "it's totally not stack ranking" was during the Ballmer years, yes.
Nadella's MSFT apparently actually did away with it, but I still tell my friends there, when they asked me if I wanted to come back, I'll price in the bullshit I had to put up with, and that means I'll want more compensation than MSFT would be willing to pay for the position.
TwatWaffleInParadise@reddit
It was great up until January 2023. It's been downhill since then. Morale is horrific today. I was fired last fall for "lack of performance" five months after a strong Connect (performance review). Speaking to folks across the country in the time since and they're just hoping they don't get caught in the next layoff.
MoneyisPizza@reddit
What happened in January 2023?
TwatWaffleInParadise@reddit
First big round of layoffs post-COVID
Humdaak_9000@reddit
I've spent my entire career avoiding microsoft shit, and especially windows coding. For the most part I've been successful.
I'd have made a lot more money if I enjoyed shoving my dick in shit for a buck.
KevinCarbonara@reddit
Microsoft technologies are easy to write in and very regularly offer a better quality of life than the competition. That's how they survive.
iheartrms@reddit
That's a funny way of saying proprietary lock in.
KevinCarbonara@reddit
...This post is wrong in more ways than I can count.
First off, absolutely not. I do not think you know what proprietary lock-in means. It certainly doesn't refer to QoL features.
Second, every language is proprietary. I'd love for you to try and design a language that wasn't proprietary.
Third, Microsoft is famous for providing enterprise support for a very long time beyond the life of their technologies, while also establishing a path to migration, usually supported by their tools.
Like - your post is so thoroughly incongruous with both the realities of the industry and the topic at hand that I almost think you just responded to the wrong post. It's hard to fathom how ignorant it is.
iheartrms@reddit
There have only been antitrust trials and consent decrees...
KevinCarbonara@reddit
...Unrelated to their development tools.
Good lord. You're really not educated on this at all, are you?
iheartrms@reddit
Everything in the Microsoft ecosystem is related. By design. The network effect is very strong in operating systems and associated software. Unkind ad hominem attacks aren't going to impress anyone here.
KevinCarbonara@reddit
You're not even remotely on topic. You're so far off topic and yet it's very clear that you think what you're saying is irrelevant. Of course I'm going to highlight your ignorance.
CybersecurityCareer@reddit
I have read this thread with interest thus far. As far as I can tell they are right on about prop software etc and looking at your comment history you seem to fancy yourself some sort of professional troll who gets off on calling other people trolls or something.
KevinCarbonara@reddit
But that isn't even remotely related to the topic. Any even halfway educated person would notice that. It's really difficult to believe you're approaching this issue in good faith. It looks a lot more like you got downvoted and now you're hopping on an alt to back yourself up.
pheonixblade9@reddit
yeah, C# is a great language, and visual studio/vsc are best in class.
KevinCarbonara@reddit
There's still a lot of anti-Microsoft hate here. They prefer languages like Java, that are not at all owned by corporations led by a dictatorial narcissist.
Really, it's just that a lot of amateur developers inform themselves entirely through memes.
pheonixblade9@reddit
Ironic, given Java's history.
omac4552@reddit
try jetbrains rider
Humdaak_9000@reddit
Maybe now, but the last time I programmed windows what was available was win32 and whatever crappy C++ wrappers were shipped with VC6.
iheartrms@reddit
Same here. The Year of the Linux Desktop was 1995, for me. I can't believe the amount of bullshit/fees/malware/privacy disasters/changes for the sake of change that the MS user community puts up with.
chat-lu@reddit
Stack is back! But now you are stacked on your use of AI.
KevinCarbonara@reddit
It did. Then it got worse again.
light-triad@reddit
I thought that was more of a Balmer era policy.
campbellm@reddit
It was not.
justinlindh@reddit
That's why I just follow the conjoined triangles of success.
ticklesac@reddit
And now they teach it at business schools
campbellm@reddit
Wow, that's something I haven't heard mentioned in a long, long time. Nice one.
apnorton@reddit
Don't worry, I've seen a bunch of pro-AI-code people on reddit boasting at how many kLOCs they can churn out in a day with AI assistants.
Everything old is new again! 😩
delicatedelirium@reddit
If it was only limited to Reddit. There's even people in my company's Slack boasting how they're churning out 10 KLOC of code every day with their AI tools.
jmon__@reddit
Crazy! Some of the best work my teammates or myself had done was getting things done in less lines of code... Or even removing lines of code
KevinCarbonara@reddit
Literally never heard that in my life. Did you just make this up on the spot?
kronik85@reddit
https://skeptics.stackexchange.com/questions/27901/has-any-programmer-ever-been-paid-per-line-of-code
apparently Microsoft and IBM got into it over who gets more profit for a joint venture based on kLOCs each company contributed.
seems unlikely he'd be a proponent of paying per LOC.
KevinCarbonara@reddit
But it was made up.
kronik85@reddit
The fact, sure. The rumor, no.
KevinCarbonara@reddit
...What the hell do you think the rest of us are discussing?
kronik85@reddit
the rest of us? it's just you and me buddy.
and we're discussing whether /u/SCI4THIS made up the idea that Microsoft paid per LOC...
Humdaak_9000@reddit
I suspect Java is worse.
KevinCarbonara@reddit
Java is worse? Than... Windows ME?
Do you have any idea what any of these technologies actually are or do?
Humdaak_9000@reddit
Java is worse because of its verbosity. Java is worse than almost anything because of the fucking RSI. I suspect Bill Joy is getting kickbacks from wrist surgeons.
colei_canis@reddit
I’m not sure you’ve written any Java, or used Windows ME for that matter.
LargeDietCokeNoIce@reddit
LLMs don’t often write great code. Sometimes. Other times crap. So using them as the primary code writers puts a huge burden on the need for highly experienced code reviewers to look for completeness, security, etc. That’s a bottleneck but worse: in 5+ yrs, where O where do companies expect to get the sr engineers experienced enough with code details to review the LLMs work? There won’t be any—jr engineers who grew up piloting an LLM won’t know crap about the details. And you know greedy bastard companies are just gonna say screw it and slam the LLMs code into prod if it works anyway right? It’s gonna be a dumpster fire in a sea of gas. The fault is not LLMs. It’s the companies.
Gwaptiva@reddit
Programming is thinking, not typing, so the bottleneck is clearly not the typing
PM_ME_UR_BRAINSTORMS@reddit
If typing was the bottleneck they would've been testing programmers on their WPM in interviews a long time ago.
Full-Spectral@reddit
I'd like you to type "memoization" one thousand times... starting now!
kronik85@reddit
imemoization
yy999p
Additional-Bee1379@reddit
This seems to be mostly pedantry. When I say I am writing code I mean the act of actually thinking of what I am going to put there and type it out. I also don't think "writing a book" means just transferring an existing idea to paper.
DarkTechnocrat@reddit
Only programmers know that “programming” is not the same as “typing”. It’s useful to distinguish them for the rest of the population.
Additional-Bee1379@reddit
Sorry but I could not help but feel a feeling of pure cringe when I read that. You know not everyone who is not a programmer is an idiot right?
DarkTechnocrat@reddit
It has nothing to do with being an "idiot". There are very intelligent people who think if you're staring out the window, you're not working. It's a matter of familiarity with the role.
zxyzyxz@reddit
Who said they were? Replace the word programmers above with doctors or lawyers, some things are just known to a certain industry's experts while those outside of them are not, that's just how expertise works. Perhaps you're inferring an air of superiority that they are not necessarily implying, it's hard to communicate such fine details over text.
Additional-Bee1379@reddit
Come on
iheartrms@reddit
We know that. Non-programmers (our management) often do not.
MrJohz@reddit
But the more time I spend typing, the less time I spend thinking, so optimising the typing allows me to spend more time thinking. As a thought experiment: if you spent some time thinking, and then could just click your fingers and have all the code look exactly like how you imagined it, would that not be an incredibly superpower for speeding up your programming? You could experiment with different ways of structuring your code and see immediately which one worked best or made the most sense.
I can't speak much to LLMs because I don't use them very often, but from my own experience learning to touch type has made me a much better programmer because it makes the time between "idea has appeared in my head" and "idea is in the code" much shorter, which means I can get back to thinking much quicker.
ChampionshipSalt1358@reddit
I often come up with my best ideas as I am typing. Removing typing from the equation doesn't actually speed up my process much.
MrJohz@reddit
Different strokes for different folks, I guess, but if I have an idea while typing, it means I need to context switch to write that idea down so I don't forget it, or maybe write a test for it to make sure I follow up on it later. Otherwise I'll be working on getting one part working and then I'll forget about it or be distracted about it.
PaddiM8@reddit
For me, being able to type fast means that I can try out ideas fast though, so it still helps. If I typed slowly I wouldn't bother trying things out as often.
zackel_flac@reddit
100% agree, otherwise vim/emacs users would be the top earners of this world. Wait, maybe they are.. ;-)
Joke aside, this article is on point. We make it like writing code is the hard part, but it never was.
KevinCarbonara@reddit
It's funny how much vim users harp on their "speed", as if the speed of text editing is the most important part of their job. Honestly, if you think your editing speed is your best feature as a dev, you're probably right.
PaddiM8@reddit
Vim isn't about speed, it's about flow. Vim makes it easier for me to think while editing because I don't have to pause to look for things and move the mouse. That makes it easier to keep focused, and it makes it easier to try out new ideas, which means I don't have to keep as much in my head. And well, there are times where I already have a good idea of what I want to do. In those specific situations, editing speed can be a bottleneck. But it's mostly about flow.
KevinCarbonara@reddit
That's funny, GUIs make it easier for me to think while editing because I don't have to pause to look for things and fiddle with keyboard shortcuts.
j_gds@reddit
When you internalize the keys, it becomes effortless. With a GUI there's a full feedback loop required: your eyes are watching the cursor as it moves to the button, verifying that it's "there" so you can click. With pure keyboard input, there's no information coming back from the computer, just the stream of commands being punched into the keyboard. To me it feels like how driving or walking playing videogames has stopped feeling like "ok move the leg, turn the wheel, press the button" and is now just "k I'm going that way now".
KevinCarbonara@reddit
This is true with any input mechanism. If what you were saying were true, learning vim (or at least modal editing) would be part of every curriculum and required at every job. But I've worked with a lot of developers, and I have never seen any sort of correlation between preferred method of input and editing speed, nor between editing speed and productivity. There's simply no evidence to suggest it's any sort of benefit at all.
j_gds@reddit
What I'm saying isn't vim-specific at all. In any software tool you want to become proficient with, you'll be faster if you internalize the hotkeys than if you always need to click through menus. If you've got the hotkeys internalized, you have less reliance on the visual feedback. How is that the least bit controversial? I'd be genuinely curious (and surprised!) if your experience is different from that.
Guis are awesome for discoverability. You can find all the available functionality just by clicking through. Hotkeys are awesome when you know what's there and just want to execute it as quickly as possible. I think that's the original point about flow.
KevinCarbonara@reddit
But that is the topic.
This is moving the goalposts. No one was discussing the value of hotkeys vs. multi-layered menus.
GUIs are awesome for usability. You can have every single advantage of pure text, plus a whole host more that are impossible in pure text.
j_gds@reddit
Genuinely not trying to move the goalposts, just trying to be more general. Can you give me an example of a GUI element that you use in the context of editing text that you find useable and productive? I'm honestly curious to learn.
TheTomato2@reddit
This is one of the braindead takes I have seen in a while. The point of vim is you dont pause and look for things. Like lmao, that is what you have to do with GUIs.
You know I see way more unhinged people harping on vim than vim users acting elitist. It has to be some inferiority complex, right? Like I don't go around saying "GUI users are so fucking stupid lol", is that what you imagine in your head?
New flash: no one gives a fuck how you prefer to edit code.
KevinCarbonara@reddit
You so clearly do. I'm sorry your butt is hurt, but don't go whining to me.
TheTomato2@reddit
What, you didn't say this out of the blue lmao?
Brah, you never mentioned your editor, I'm just calling you out. It's just fascinating to me how many people need to release their anger on vim for no reason. Like can you explain that to me?
KevinCarbonara@reddit
Alright, so you're just trolling. I guess that's settled.
TheTomato2@reddit
I guess its on me, I should have expected this level of discourse lol.
extra_rice@reddit
Yep. It's this. The speed you gain is just a side effect. It's more about removing distractions to your train of thought by taking away as much of the context switching as possible.
jrop2@reddit
In addition to these points, for me Vim makes editing fun: it gamifies text-editing for me.
extra_rice@reddit
I used to prefer emacs and I'm only less than a year into using Vim, but I think I like the experience better. I used to loathe the jumping between command and insert mode, but now it just feels intuitive. It feels like "talking" to your text editor using its own language.
I still have plenty to learn, but I feel quite productive with it. When I say Vim though, it's not just vanilla Vim or its several incarnations, but also the emulators. I love IntelliJ but I also like Vim, so I use IdeaVim for example. On Firefox, I use Vimium. Even in Obsidian I use the Vim bindings.
tdammers@reddit
For me, the "speed" aspect is not about how long it takes me to enter code, it's about the "million papercuts" of waiting for the editor's visual response to every input. The accumulated delay isn't a lot, but each of these microdelays has the potential to stop my train of thought.
E.g., in a typical graphical text editor, if I want to do a search-and-replace, it goes something like this: press Ctrl+F to open the search/replace dialog, wait for the dialog to open, look at the dialog to see whether it's in search-only or search-and-replace mode, tab to the control that changes that if needed, tab to the "search" textbox, look at what's already there, delete it and write the search term I want, tab to the "replace" textbox, look at what's already there, delete it and write the replacement I want, find the "replace all" control, verify that it's on, then hit "Enter" (or click the "OK" button). There's about half a dozen points here where I need visual feedback from the editor before I can continue to make inputs, and each of these stops my flow for a split second. And if I'm working over a remote connection, or the system is under very heavy load (e.g. because the IDE is continuously recompiling the code to keep completion suggestions and such up to date), then those delays can get much longer.
Meanwhile, in vim, I can just type
:%s/search-term/replacement/g<Enter>, and even if I'm editing in an SSH session on a remote RPi connected over a dialup modem connection to another continent, the effective delay is still zero, because there is no point at which I need to wait for any visual feedback.So in a way the "speed" that's being boosted here isn't the typing speed, it's the thinking speed.
I mean, yes, I can also perform a lot of editing operations slightly faster than I could in a more "conventional" editor, but that's marginal, and not the point at all. It's all about the flow and those micro-delays.
KevinCarbonara@reddit
You're basing this on decades-old stereotypes. Any modern GUI is going to be instant. Vim is only any faster when unmodified - yet every single developer uses a ton of plugins. You have to, because it's featureless out of the box. But these plugins can make vim awfully slow.
Neovim was created because vim refused to add parallel processing of plugins, infamously resulting in minute-long load times in some extreme cases. I've noticed in the past that, for several of my vim-obsessed coworkers, my VSCode launched faster than their terminal editor. You should try profiling your own client - you'll very likely be surprised by what you find.
The reality is that vim just isn't impressive by modern standards. Modal editing is still of value, but of course, every modern IDE supports it.
Perfect example. I get this same feature in VSCode. I get that this was impressive in the 90's, but it just isn't anymore.
tdammers@reddit
That's not the point. The point is that vim's keyboard-centric UI is faster than instant. You cannot click a button that isn't on screen yet, you can't type into a text box before it appears, but you can type vim commands before the editor is ready to execute them.
I don't.
ftplugin, a couple custom rules and macros in.vimrc, that's basically it. You only "have to" use a ton of plugins if you want to turn vim into an IDE; but if you use it as a text editor, then it's pretty near perfect out of the box.I think I'm good on that front.
I don't need "impressive"; I just need "robust, battle proven, minimal, effective".
Again, it's not about "impressive". Of course you can do these things to various extent in other editors, they all took inspiration from vim, and my argument isn't so much for vim itself per se, but for the text editing paradigm it represents. I use actual vim, because it implements the paradigm efficiently, and there isn't really anything I need beyond that, so I don't see a reason to switch.
KevinCarbonara@reddit
...It's not, and there's no point discussing this with someone who thinks it is.
tdammers@reddit
"Faster than instant" is of course a bit tongue-in-cheek.
What I mean by that is that your commands and the UI's responses do not need to run in lock-step (issue command, look at response, issue next command) - you can issue commands at whatever rate you want, and the UI will process them in order, presenting the results as they become available. Even when responses are literally instant (i.e., there is zero processing time involved), you still need to process the visual information in order to issue the next command, so "instant" is still slower than "type-ahead". That's what I meant by "faster than instant".
tikhonjelvis@reddit
There are a lot of Emacs users at Jane Street, so you might be onto something.
zackel_flac@reddit
As a vimmer myself, I can't complain!
zxyzyxz@reddit
This is correct for professional software engineering teams but for solo (or a small team of) developer startup founders for example, writing code often is the bottleneck. I have limited time after work to code and vibe coding an MVP to test out various ideas has completely changed how I can prototype ideas quickly to create products I can sell, and I suspect that's true of many others.
recycled_ideas@reddit
This kind of attitude is fucking toxic.
You are making a product to sell which means it should do what you say it does safely and at least mostly reliably.
Churning out low quality bullshit to sell to suckers makes you a con artist not an entrepreneur.
rollingForInitiative@reddit
Churning out low quality proof of concept stuff is pretty common for startups, though. Something that runs, but might not scale whatsoever, maybe it has a lot of bugs, might be an unmaintainable chaotic mess, potential security issues that have not been addressed, etc. But if it's enough to demonstrate to investors that your product has promise, you get money, and then you can more or better people to do make a better version. Rinse and repeat, and it gets better with time.
At some point you do need various parts of the product to meet high levels of quality and safety, but not necessarily from the very start.
Mysterious-Rent7233@reddit
Do you know what the words "test" and "prototype" mean?
recycled_ideas@reddit
Since I don't see this statement anywhere in the post I replied to, no I didn't ignore the thing OP didn't fucking say.
I do. Prototype means "make it cheaply so we can ship it" and test means "don't". At least to most people looking to cut costs to sell shit.
zxyzyxz@reddit
Should've read my other comments then because that's where that quote comes from, can't get the full context from just the top level post if you're going to be engaging in a discussion that I've already been in the midst of. To be honest, I knew the sort of person like you would reply to my comment, that's why I preempted it by talking about prototypes and not full production scale products, which, again, I clean up and polish.
recycled_ideas@reddit
The fact that you can say this means that any cleaning and polishing you've done is worse than the AI.
Sales guys force prototypes to be shipped all the fucking time.
KevinCarbonara@reddit
Oh, wow. You really have no idea what... any of these terms actually mean.
recycled_ideas@reddit
Prototypes are supposed to be throwaway code, but they're not because they look like they work and when people are looking to win the appstore lottery and they don't have a problem they're trying to solve but are instead looking for "products" looking like they work is a pay day
AI crap needs more than "polishing" especially if you've been vibe coding it.
zxyzyxz@reddit
But that's literally what I said above, "Prototypes are not shipped, they are for testing purposes only." Sounds like you're talking yourself into a circle and imagining yourself to be right without even reading what other people written. You're essentially arguing against a strawman you yourself have built.
zxyzyxz@reddit
Good thing I'm not talking about a company with salespeople now, isn't it? I'm talking about myself amd the prototypes and products that I make and now you're shifting the goal posts because you have no retort to the original comment.
recycled_ideas@reddit
Yes, and you talk like a sales guy, as almost all start up people are.
zxyzyxz@reddit
Lmao. Obviously you need to know how to sell if you want to run a startup, no one's gonna buy your shit otherwise, it is not sufficient to just make some app and think people will come running over to buy it. Next time you build something and then tell me how that goes in terms of making money from it, sounds like you have literally no experience.
This is honestly the most naive take in this thread, and I don't even know what else to tell you or what your argument now even is (since you quoted me and replied with a goalpost shifting response yet again) so have a good day.
recycled_ideas@reddit
You act and sound like someone who wants money more than solving problems, you "prototype" through AI to get products out to sell.
You claim you clean up (though that's not how prototypes are supposed to work), but frankly I don't believe you because you talk like every other app store concartist I've ever met and not at all like an engineer.
I honestly don't think you do much of all to the AI code, I think you on sell it as fast as you can.
zxyzyxz@reddit
You're free to believe whatever you want to believe, but frankly I don't even think you're an engineer in the first place, and again misunderstand what prototypes are. Have fun continuing to shit post in your nation sub.
zxyzyxz@reddit
Username checks out
stumblinbear@reddit
This kind of attitude is fucking toxic.
KevinCarbonara@reddit
Probably because you're using the term "vibe coding" as if it actually means something
zxyzyxz@reddit
It does mean something, not sure why it wouldn't. It means to not code anything yourself and instead let the AI code everything for you, as was defined originally by Andrej Karpathy.
KevinCarbonara@reddit
No. This doesn't mean anything at all.
zxyzyxz@reddit
Great, take it up with Karpathy.
IHeartMustard@reddit
Yeah, sort of. It depends on the complexity of the particular piece you're trying to prototype, and especially, how common the requisite patterns are in the training dataset. I've found it actually amazing at prompting me to get moving, because it's like the code equivalent of generating lorem ipsum text, throwing it in your design mockup and going "huh, actually yeah maybe if we change this..." and then off I go, instead of staring at the blinking cursor just churning it over mentally. Somehow, when I'm just in a blank file, I get stuck in that mental churn cycle, but if I can have something even minimally coherent spit out onto the screen, even though it usually doesn't even compile, suddenly I escape my own head and even though I end up completely re-writing everything that was generated, it was like the push I needed to get going.
zxyzyxz@reddit
Absolutely. It triggers my ADHD brain to be able to move past my perfectionism, to not need to start from a blank slate, a form of writer's block. With previous models I agree it wouldn't often compile but with Cursor using Claude 4, it autonomously detects compilation errors and fixes itself.
Now I feel more like a PM, telling it that such and such doesn't work and to fix it, than a real developer now, which is fine because they're all still prototypes. Once I'm ready for production, I clean up the code myself and polish it up.
The apps I'm making aren't too complex, just CRUD web and mobile apps, which is very common in the data sets, I certainly wouldn't use it for embedded, games, or very specific niche development.
kiinaq@reddit
I totally agree with the op and there is an incredibly elegant solution to this: using AI at scale in a team means involving it in design, planning, testing and code review support, and therefore also in writing the code. So let's use AI to address the real bottlenecks.
OrchidLeader@reddit
It’s the same reason why no-code options are so stupid. Writing code isn’t the hard part. Knowing what needs to be done, verifying it works as expected, communicating how it works, etc is the big part of the work (like the article said).
A lot of people don’t understand the difference between prescriptive developers and adaptive developers. You can give an adaptive developer the destination (ie the objective), and they’ll draw the map on their own and make it happen. Prescriptive developers need the map drawn for them, and they’ll follow it exactly even if the map is wrong or outdated.
G_Morgan@reddit
No-code is a trap where they convince product owners they don't need programmers at all. Then they realise that they cannot write programs, even in their "no-code" environments. So it gets handed off to engineers who despise what has been inflicted on them for spurious reasons.
OrcaFlux@reddit
Can confirm. Azure Logic Apps is one of Microsoft no-code/low-code tools, and it is quite literally the worst piece "tech" I've ever had to work with (I've got 20+ years in the industry). It's actually insane how bad it is in every single aspect.
tdammers@reddit
And this has been going on in waves since the invention of the punch card.
And look what happened.
Punchcards were practically never made by nontechnical users - rather, programmers would move from plugging wires to punching holes.
Assemblers made programmers more productive, but practically nobody that wasn't a programmer could make anything nontrivial in it.
COBOL programmers are in crazy high demand, and approximately nobody ever wrote anything more complex than a 10-line COBOL program who wasn't an actual programmer.
SQL is still a thing, and it's useful, but realistically, the people who use SQL are never non-technical users, they are DBA's, programmers, tech experts.
Visual code editors never really took off; those who use them are either programmers dealing with the mess some non-technical boss made deep in Dunning-Kruger Valley, or young programmers-to-be making their first steps at an early age (think Scratch), or experts coming from domains in which building up functionality by combining modules and connections into graphs is a natural paradigm, such as audio engineering or electronics.
No-code web platforms are used for extremely limited run-of-the-mill applications (e.g. Wix), where there's not much configuration to begin with, and you're really just using the same code as everyone else with a thin cosmetic veil on top; and they are used by expert web developers to build complex things more easily and efficiently.
The common pattern: except for absolutely trivial applications, none of these things has delivered on the promise of taking the engineer out of the loop and allowing non-technical users to directly instruct the machine to get it to do what they want. In the better scenarios, the tools helped increase developer productivity, but at least in some, it's a net loss, where the tools just complicate the expert's work without being viable as a replacement of that expert.
zxyzyxz@reddit
It's almost as if programming is the process of thinking through solving a problem, not the specific technology used to do so.
tdammers@reddit
Nah, that's ridiculous.
LimeGreenDuckReturns@reddit
As a game developer who regularly has to suffer the horrors that some incompetent fool has managed to cobble together in unreal blueprints.
I hear you.
IssueConnect7471@reddit
The real choke point is turning fuzzy objectives into something everyone can see, poke holes in, and sign off on.
What’s worked for me is treating requirements like code: I write a one-pager ADR before touching a keyboard, pair with the domain expert to fill gaps, then turn that doc into high-level tests in Gherkin. Those tests act as living specs and force early conversations-if a scenario is hard to phrase, the requirement isn’t clear yet. Automated contract tests catch drifting assumptions later, making verification less painful than giant QA spreadsheets.
Tools help but only when they reinforce that loop. I’ve used Postman collections to demo endpoints to non-tech folks, wired Terraform plans to show infra costs up front, and finally leaned on DreamFactory to spin up throwaway APIs instantaneously so the team can focus on behavior, not boilerplate. Every piece is there to shorten feedback chains, not replace thinking.
Spend twice the time on shaping the map and the code writes itself.
zxyzyxz@reddit
No code is stupid for a somewhat different reason, it's usually because they're closed source locked down platforms that you can't extend or modify if you want to go even slightly outside what they're designed for. I think AI that interacts with actual code is different, you still own the code so it solves the above problems with no code solutions, but I will say that knowing what one wants is the hardest part, as you say and as the article says.
Additional-Bee1379@reddit
Also they are horrible with both copying things and source control.
ben0x539@reddit
imo the speed of writing out code is an underappreciated bottleneck. Not the speed of writing code in the linear sequence of "write -> commit -> review -> deploy", but in the process of experimenting with a bunch of different approaches (to the algorithm, to the interface design, to the separation of responsibilities, which dependency to pick...) to see what shakes out as the best, most maintainable solution in practice, to suss out the gotchas in the implementation that weren't obvious when you were writing up the ticket, etc.
That said, it's a better argument for good editors and investing in faster build times/tests than for forcing AI everywhere.
RationalDialog@reddit
There is a big, big personality thing in here, that you actual care to do that and not just ship the first thing that barley works and fulfills the task described.
Looking at most software, they just ship the first shitty version and hope for the best.
dontcomeback82@reddit
Is a balance, you don’t want to pre optimize every design or implementation. It doesn’t need to be perfect, just a reasonable step forward
bwainfweeze@reddit
For the first year I was a paid programmer, I was hunting and pecking with four fingers.
Still managed to give myself and RSI, probably from looking down (a lot of wrist pain starts as pinched cervical spine nerves.
Learned to touch type Dvorak as part of rehab, but didn't really get that much faster until I got code refactoring tools.
But nobody that I'm aware of has substantially expanded the set of automatic refactors since sometime around 2010. I think generative AI could probably make suggestions here, as well as in attempting to resolve merge conflicts.
And that would be enough for this hype cycle.
Temporary_Event_156@reddit
AI is just going to make these bottlenecks even more pronounced because it’s creating a chasm of knowledge that someone now has to cross when something goes wrong. You and no one else in your org has worked on the feature that now needs to be fixed or extended. Now you need to figure the entire thing out and hope it’s not a nightmare (it will be). These scenarios are common without AI, but now the fuckers who work on the code don’t even know what’s going on.
shevy-java@reddit
It indeed is not!
The thinking part is the biggest problem.
doterobcn@reddit
I've always struggled with blank page, so for me starting a project was always the bottleneck.
Full-Spectral@reddit
You can always use the tried and true method of cutting out words from a language reference, mixing them up, and then selecting them randomly into a sequence. Of course you have to have a protagonist and a love interest. A dog is always a nice touch.
DerkaDurr89@reddit
Maybe it's time for comp-sci grads to get MBA's so that C-suiters will finally listen to them.
schoeperman@reddit
I'm gonna bookmark this article as a way to describe my frustrations with the AI craze, this is good and I like it.
My one thought if OP is taking constructive criticism is I wish it had a section / a bit more on why the other aspects of our day-to-day is important: code review, debug, testing, QA, etc. Honestly know some engineering managers that would take this article as a reason to remove those aspects of the software process as well, no matter how inadvisable. I read some O'Reilly book on Google's engineering practices and to misquote it, it generally said "if the pure goal by engineering management is to push code quickly, increase velocity, and/or get tickets done, then removing all non-code-writing processes, the processes that save their ass, is the best way to do that."
On the positive aspect though, I am absolutely with OP that the easiest part of my day is writing the boring boilerplate, render tests, CRUD operations that AI can replace. It also is the item I spend the least time on because it's so easy. The parts of my day that actually take up time are the hours spent with design and product to nail down possibly vague requirements, back-and-forth with QA and/or other SMEs, and usually a few hours of code reviews if it's near the end of the sprint. How hard my day was is directly related to my time spent in Teams, not my time spent in IDEs.
poewetha@reddit
Great post, and I agree with a lot of it — but I think it's missing a key point.
The author mention code reviews, mentoring, testing, etc. as the bottlenecks. But honestly a lot of the bottlenecks are just... people being people.
We get tired, we procrastinate, we forget. Sometimes a PR doesn’t get reviewed because someone just didn’t feel like dealing with it today.
LLMs don’t fix that. If anything, they add more pressure to a system already full of human friction.
zxyzyxz@reddit
I think you're essentially repeating what they are implying, it's not the actual code reviews themselves but the "human overhead of coordination and communication" which is what you said phrased differently.
poewetha@reddit
Fair point, but I wasn’t just rephrasing. “Human overhead” usually means meetings, coordination, that kind of thing. I’m talking about the messy human side: burnout, procrastination, not being in the mood to review a PR, ignoring a ping like it’s a WhatsApp message you don’t want to deal with haha.
It’s not process overhead. It’s life. And it slows things down way more than we like to admit (at least me, ye?)
zxyzyxz@reddit
Yeah makes sense, I inferred that from the original post but maybe others didn't so thanks for adding that context.
billie_parker@reddit
Actually yes it has because you can use LLMs for that as well. If anything, LLMs are better at reading code compared to writing it.
CherryLongjump1989@reddit
Nope. LLMs have not cracked writing code. It's a nonsensical argument to begin with. You need a code review because writing code is hard. Not as some external process to sprinkle fairy dust on it before sending it into production.
weggles@reddit
There's a big push for efficiency at work. One of the things is using AI to be more productive.
... But our testers are consistently MONTHS behind AND they refuse to do test automation.
🤷♂️
chaotic3quilibrium@reddit
Excellent!
No matter how much the tools improve, there is no escaping the essential truth...
Success is earned by continuously working in the small with extreme delayed gratification.
Full-Spectral@reddit
Sounds like my love life...
LessonStudio@reddit
The two critical skills of a programmer are:
Communications - if you build the wrong thing, it doesn't matter how well you build it. Meetings are not communications. Meetings are usually just micromanagement. Documentation is not communications. That is usually just micromanagement as well.
Tech debt - If you can't finish what you are building then it probably wasn't even worth starting. Tech debt is where the art of programming really comes to play. It's avoidance is a combination of workflow, tech stack, programmer skill, architecture, design, flexibility, and a slew of other skills; and very importantly culture.
Another related skill is leadership. This is not management, and is not necessarily a programmer. A successful project requires leadership. Management is for processes like assembly lines. Leadership is for battles. Software is a battle, not an assembly-line. Someone has to identify, and then inspire people to a vision. This is a team effort. I've said this a zillion times, managers whine about "hearding cats"; leaders get the cats to follow them.
devraj7@reddit
Writing code is not the bottleneck, writing correct code is.
And the number of times that LLM's generate correct code faster than I can is increasing every day.
gameforge@reddit
I almost got fired on the spot once for mouthing off at a CTO and telling him he should incorporate a minimum WPM typing requirement for engineers, since he was so big on using git metrics analysis software that ranked everyone in the company by lines of code.
(And not all lines of code were good! You had to be writing new lines or fixing someone else's new lines or you were junior garbage).
I hear the stories about how xx% of new code written at some new company are written by AI. But at the end of the day, one of two things is happening:
You're saving a lot of time and likely a lot of money with #1, until your momentum wears out and gravity takes over.
I would bet that in more than 80% of cases, the original IntelliSense, which I believe shipped with Visual C++ 4'ish in the mid 90s, did more for outright/net engineering efficiency than AI does today.
tdammers@reddit
I have done projects where 95% of the code was written by a bash script. "% of code" is a complete non-metric, unless it's either "0%" or "100%".
gameforge@reddit
I'd argue you shouldn't be checking generated code into git, unless you're only generating it "once" and it will be hand maintained. You'd check the bash generator in of course.
The overarching point is that software engineers do a lot more than just "type" code. Particularly at smaller orgs, the most effective people do a little of everything, and AI can be involved in most of it but it's not going to replace anyone.
tdammers@reddit
Normally, yes.
But there are cases where you want to use a script to generate a starting point, run it once, and then apply per-case edits to it. E.g., suppose you are writing a replacement for an existing CRUD application, and just to get you started on the data model, you dump the database structure from the old version and use that as the initial version of your database setup script for the new version - but then you clean that up, edit it into shape (possibly in a semi-automated fashion, e.g. editor macros,
sedscripts, etc.), and track all that in source control. In the end, you could still argue thatpg_dumpor whatever tool you used wrote 95% of that code, but that doesn't mean you could check in the originalpg_dumpinvocation instead of the actual SQL script that's going to be used in production.Also, "95% of the code" doesn't necessarily mean "95% of the code that's in git", it can also mean "95% of the code overall", or a number of other things. In that sense, even just deciding what does and does not count towards "lines of code in the project" is iffy at best.
Floofymcmeow@reddit
Thank you! Always felt this way.
Humdaak_9000@reddit
The physical act of typing has never been a bottleneck, except maybe to Java programmers, who I swear are perverts who are turned on by pushing keys.
I look at the screen for 5-10 minutes, type a few characters, and stare at the screen some more. I could probably have used a 300 baud modem to filter my keyboarding for most of my career coding, and not noticed.
(Not my reading of stuff I need to do the job, though, of course. I need lots of bandwidth for that.)
Extension-Pick-2167@reddit
nah, we java devs have lombok annotations and use intellij to generate boilerplate
tdammers@reddit
Yup. I thoroughly dislike IDEs, but writing Java without one just sounds way painful.
stbrumme@reddit
That's still 38 bytes per second: more than 10x faster than even the best actually need for typing.
tdammers@reddit
Yes, but try running a graphical IDE in a remote desktop on that kind of connection. It's not the keystrokes that are the problem, it's the visual feedback.
FeepingCreature@reddit
There's an underrated advantage of LLMs: they are a lot better at graphical design than most programmers. "I" made an internal tool at work with a LLM a week ago, and it created a web interface with a tasteful gradient on a button. A gradient! I had literally never used a gradient in actual decades of making "programmer UIs".
iheartrms@reddit
When Fred Brooks wrote "The Mythical Man Month" he never really mentioned the writing of the software as the big time suck. It was all this other stuff mentioned in the article (except agile, of course, but waterfall has it's time wasting "ceremony" equivalents).
fforw@reddit
No, there can absolutely be phases in software development where writing code is the bottleneck. You know what you want to do, you have pretty clear picture of it and most of the work is just writing the damn code.
But even for that kind of software, even if that happens: That's where it ends. The rest of the lifetime of the software beyond that burst of development is maintenance, reading, fixing, evolving.
thbb@reddit
My personal objection to those who tell me to rely on LLMs for coding: we have invented programming languages to allow us to express our thoughts in an unambiguous way. I need the rigorous syntax and semantics of the programming language to understand what is it I'm trying to build.
gomihako_@reddit
Yes, isn't this the premise of cognitive load theory?
Extension-Pick-2167@reddit
Indeed, code isn't the bottleneck.
I think, like the author says, human coordination is the biggest challenge. For example I will finish the planning, implementing and testing of a feature, but then can't release, because there's other stuff on the quality branch that's not yet been released, or someone pushed to it something untested! It's silly things like that which slow down teams.
gwax@reddit
There is no one bottleneck.
There are many different bottlenecks at different times in the process.
Sometimes you debug and the bottleneck is a single missing character.
Sometimes you have a really hard architectural problem and thinking for a day or two is the bottleneck.
Sometimes you don't have product-market-fit and trying different business models in the bottleneck.
Sometimes, you know exactly what you want to build and writing the code is the bottleneck.
Saying that generating lines of voice isn't the bottleneck and that LLMs can't solve the bottleneck is reductive. Sometimes it is the problem and sometimes LLMs battle diminish it. Not always but sometimes.
jseego@reddit
Amen
StarkAndRobotic@reddit
The bottleneck is compilation times, people not knowing what they want till they have it and realise they want something different, and limited amount of working memory resulting in logical errors, requiring iterative improvement via debugging.
illuminatedtiger@reddit
I might spend two, maybe three hours a week writing code. As someone who generally knows what they're doing I still fail to see what AI brings to the table.
a_marklar@reddit
Well yeah. I'll just leave this hear for those who haven't seen it before No Silver Bullet