Writing Code Was Never The Bottleneck
LLMs make it easier to write code, but understanding, reviewing, and maintaining it still takes time, trust, and good judgment.
This is something I've said for a very long time. Everytime some RAD or "low code" tool claims that it will make developers obsolete because "you won't need to write code"! I know that I'm going to need to help some BA use that tool and that there will be a tiny little box hidden in that tool somewhere which let's me write code to work around its limitations.
LLMs are useful to a developer as a cordless drill is to an engineer.
Software development is about understanding logic, data structures, and how to solve business problems with computers. A language is simply what we use to do that.
The tech lead at my team started using AI to do code reviews he can't be bothered to properly do himself. His suggestions during reviews are now shit. I hate the future. I'm seriously thinking on taking a leadership position just because how much I hate this dynamic, to shield others and discourage AI usage from a higher ground.
Using AI just to be lazy is by far the worst use case. It should be a tool made for speeding up repetitive work, and its output (if important) should always be reviewed by humans.
Exactly what I see at work. I have a 'senior' C++ team lead which I have to explain over and over that for concurrent access of variables in device drivers one needs meticulous locking of shared variables. He was helding the view that when one thread is modifying a variable and another one is only reading it, then it's no race condition - even if the code crashes. And he still responds with generated code and suggesting names of members that don't exist.
wow, I hate that guy
This would infuriate me to no end. It's literally the definition of a data race. All data between threads needs to either be accessed through synchronization primitives (mutexes, atomic access, etc) or needs to be immutable. For the most part, this should include fds, though concurrent writes to stderr might be less of an issue (still a good idea to lock/buffer it and stdout though to avoid garbled output).
Exactly.
It's been so long since I've had to worry about this type of race condition, and like you...it infuriates me reading that comment.
Omg this is so true, I had 3 engineers which supposed to work on component. It took me almost a day to explain context, requirements and how work is split. Two of them were busy with other work. One did their part. After reviewing I realized they still lack understanding and need to rework what was done.I made an experiment and implemented whole thing myself. Since coordination part was eliminated it took me 3 times less than initially estimated.
That's also why good, experienced developers are so exponentially more valuable on complex systems. They need less coordination than multiple people doing the same thing, and that saves time. Plus really good people are also masters of technical communication which get straight to the points which are really relevant.
Not only are generally experienced developers really valuable, but developers experienced with the project they work on.
It takes a long time to actually understand everything in a large project, and if you do, you save a ton of time because you just know a lot of context already. No need to research or figure things out, you just know.
That's why the constant reorgs in larger corporations are incredibly hurtful to performance. If you want performance, let people stick to the few projects they know instead of switching stuff around all the time.
The main value I found from Copilot in vscode back when it first released was its ability to recognize and continue patterns in code (like in assets, or where you might have a bunch of similar but slightly different fields in a type that are all initialized mostly the same).
I don't use it anymore though because I found the suggestions to be annoying and distracting most of the time and got tired of hitting escape. It also got in the way of standard intellisense when all I needed was to fill in a method name. It took my focus away from thinking about the code because it would generate plausible looking lines of code and my thinking would get pulled in that direction as a result.
With "agents" (whatever that term means these days), the article describes my feelings exactly. I spend the same amount of time verifying a solution as I would just creating the solution myself. The difference is I fully understand my own code, but I can't reach that same understanding of generated code as fast because I didn't think about writing it or how that code will solve my problem.
Also, asking an LLM about the generated code is about as reliable as you'd expect on average, and I need it to be 100% reliable (or extremely close) if I'm going to use it to explain anything to me at all.
Where I found these "agents" to be the most useful is expanding on documentation (markdown files and such). Create a first draft and ask it to clean it up. It still takes effort to review that it didn't start BSing something, but as long as what it generates is small and it's just editing an existing file, it's usually not too bad.
Where I found these "agents" to be the most useful is expanding on documentation (markdown files and such). Create a first draft and ask it to clean it up.
How would the thing know what you were thinking and intending, what were the requirements, constraints, pre- and postconditions? How do you work around the risk that you end up with something that looks like useful information - but isn't ?
Because you created a first draft. Your first draft should include all that info. It isn't writing the whole doc for you lol, just making minor edits to turn it from notes into prose.
Without that? No clue, good luck. They can usually read source files to put something together, but that's unreliable.
I don't use it anymore though because I found the suggestions to be annoying and distracting most of the time and got tired of hitting escape
Same. It took longer for me to parse and validate the suggestion as it did for me to just type what I wanted.
I do like the helper for more complex refractors.
Where you have a bunch of similar, but not exactly the same, changes to make.
Where a search & replace refactor isn't enough.
It manages to figure out what you are doing, highlights the next instance of it and suggests the replacement.
I don't think I've seen it make a mistake doing that, and it is a useful speedup.
I guess the LLM already has all the context: the needle, the haystack and the term.
25% business and product roadmapping, 15% discovery, 10% coding, 15% unit testing/debugging/refactoring, 25% scrum/huddle/other useless meetings, 10% answering stupid questions at the 11th hour about why we need this feature that they asked for.
An additional 100% we didn't plan for to make the damn thing actually work after delivery.
Not my experience. More like 50% coding/debugging, 25% meetings, 25% admin/helping people/procrastinating.
LLMs are great for rubberducking, to do pre-reviews, and sometimes code boilerplate (under supervision).
Nothing more IMHO
Nah, they're actually fantastic at brain numbing tasks. I like to feed it sql tables and have it act like an ORM, but without the tradeoffs of an ORM. I'd never do it manually, but it's far more readable and easy to work with
I also love using it for api's. You can feed it a response, say "hey, I just want the id, status, and amount" (or whatever) and it'll restructure the data for you
These are not hard problems... They are tedious ones though. They solve a problem by brute force, a problem we "solve" over and over because at the end of the day: programmers are lazy.
You can over engineer complex bindings until the cows come home, but a simple pattern with each field explicitly mapped is the best solution. It's just really, really annoying to actually do it
This short article is so true it hurts. And of course management never understood this in the first place.
I am programming since a looong time, but I somehow never learned to touch-type. In 2020, my org then had mandatory home office and I used a nice FLOSS program called "TIPP10" to learn it - 15 minutes every morning.
It is certainly a little distraction less, no question. But typing speed is not programming speed. The most time spent is wondering what the requirements should say, thinking about how to make something work, or wondering what a piece of code one needs to use is supposed to do. And only after that comes inquiring with people what they were meaning or thinking.
FLOSS program called "TIPP10"
Looks cool! Just weird that it doesn't provide the code hosted on a forge and gives a download of the source instead
This is why I rarely use AI for coding. How to put my thoughts into code is not my main concern. My main concern is that another person should understand my thoughts when reading the code.
Me too. If I have anything mildly complex to code, I'll be faster writing it myself than trying to come up with a prompt.
I agree with the sentiment, but was this article written by an LLM?
OK so you walk into your VP's office and tell him that vibe coding isn't a silver bullet. He tells you his boss told him to use AI for something, and all you've done with him is come with a problem and not a solution.
What then? You build an agentic pipeline to attempt to do code reviews and the other problems you say still exist? This article is incomplete.
BTW, when I think about it, this will make Open Source code more relevant, not less. Because such code is often developed and reviewed via text exchange, by people which know how to communicate in writing, and therefore is on average far better documented than typical company code, which in future thanks to LLMs will drown even faster in technical debt than it does already.
