New GitHub Copilot research finds 'downward pressure on code quality'
visualstudiomagazine.com
visualstudiomagazine.com
It was much less effort to just write everything myself because I actually know what I want to write and fixing my own mistakes was easier than fixing the bot’s.
I weep for the juniors that will be absolutely crushed by this garbage.
As programmers we should be focusing effort on reducing boilerplate, so that it’s never needed again. Instead, we’ve created a boilerplate generator.
We use high level languages because they improve reading comprehension and save us time when writing. Having a copilot take on a major role allows us to fundamentally rethink programming.
A job spent mostly reviewing ai generated diffs sounds like a level of hell beyond even Dante's imagination.
Which completely contradicts your earlier point.
Why not just get copilot write assembly for you? Or, spit out raw machine code? Oh, that’s right, because you need to check that it hasn’t fucked something up. Which, when there’s a ton of boilerplate, is hard.
It’s arguable that programming language evolution stopped around the time Java was released (barring a few sprinkles here and there, like async/await, affine/linear types, etc.)
We haven’t had a major leap in language power for decades (not like the leap from assembly to procedural languages) - I believe it’s because Java popularised evolution through libraries - and for a long time that was fine, even if it did lead to language evolution stagnating.
But now we’ve hit a complexity threshold that demands an abstraction leap, but instead of looking for that abstraction leap we’re getting a computer to generate boilerplate for us, hoping it will dig us out of the complexity hole.
We’re still ways off having a computer maintain a complex code base over many years. So humans still have to do that. It’d be much easier if we remove the incidental complexity.
“The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.”
— Edsger W. Dijkstra
I call bullshit. Haskell, Rust, and Zig (and others) are revolutionary. Also: Rust and Zig are facilitated by LLVM.
Rust is basically an ML with a borrow checker, it's cool but not really a major leap in power over C++ (maybe a leap in freedom from bugs).
What does Zig do that's so revolutionary? Custom allocators are nothing new. And compile-time evaluation has been around so long some of us forgot we had it. Also Zig is working to step off LLVM.
I find co-pilot primarily useful as an auto-complete tool to save keystrokes when writing predictable context driven code.
Writing an enum class in one window? Co-pilot can use that context to auto complete usage in other windows. Writing a unit test suite? Co-pilot can scaffold your next test case for you with a simple tab keystroke.
Especially in the case of dynamic languages, co-pilot nicely compliments your intellisense
It needed some hand-holding in the early parts, but it was so satisfying to tab autocomplete entire blocks of descriptions and tests once it picked up context with my preferences.
Treat copilot to solve actual problems (y'know, the kind of stuff you are presumably paid to solve), and it falls completely flat.
Good to know, that means I'm still economically useful.
I'm using ChatGPT rather than Copilot, and I'm surprised by how much it can do, but even so I wouldn't call it "good code" — I use it for JavaScript, because while I can (mostly) read JS code, I've spent the last 14 years doing iOS professionally and therefore don't know what's considered best practice in browser-land. Nevertheless, even though (usually) I get working code, I can also spot it producing bad choices and (what seems like) oddities.
> I weep for the juniors that will be absolutely crushed by this garbage.
Indeed.
You avoid the two usual mistakes I see with current AI, either thinking it's already game over for us or that it's a nothing-burger.
For the latter, I normally have to roll out a quote I can't remember well enough to google, that's something along the lines of "your dog is juggling, filing taxes, and baking a cake, and rather than be impressed it can do any of those things, you're complaining it drops some balls, misses some figures, and the cake recipe leaves a lot to be desired".
You can tell it the code is bad and how, a lot of the times it will correct it. For some bs code that you have to write it is a great time saver.
Yes, I've even done that to see how well it works (my experience is that half the time it fixes the code, the other half it claims to but doesn't) — but I can do that because I can recognise that it's bad code.
I don't expect a junior to notice bad code, and therefore I don't expect them to ask for a fix. (I've also spent 6 months in a recent job just fixing code written by work experience students).
That is true. I actually seen instances of juniors struggling with code that doesn't work and frankly doesn't make sense, but they claim they wrote it :)
For the code questions that I ask, it is sometimes quite non-trivial to check whether the code is correct or not.
It never happened in my tests that it could correct incorret code that it generated. Typically, the bot then generated code that is wrong for sometimes a different and sometimes even a similar reason.
> For some bs code that you have to write it is a great time saver.
Again I disagree: the common case where you have to write BS code is when the abstraction is wrong. Implementing a proper abstraction that strongly reduces the BS code to write is the way to go.
Something can be very impressive without actually being useful, but that still doesn’t make it useful. There’s no market for a working dog that does a bad job of baking cakes and filing taxes, while dogs that can retrieve game birds or tackle fleeing suspects are in high demand.
But I disagree that half assed work is not useful. It's just lower usefulness. My laundry app isn't even half assed. The programmers couldn't even sort the room list (literal random order) or cache your most recent room. It's still better than the BS system they had before where I had to load a prepaid card and that machine was locked in a building that isn't open on weekends or after 6pm. I'm still immensely frustrated, but I don't want to go back to the old system.
Though I'll mention that my fear is that because so many people see LLMs as having far more utility than they offer, we'll get more shit like the above instead of higher quality stuff. Most issues are solved for me to be comfortable in my life, so I definitely value quality a lot more. Plus, reduces a lot of mental stress as I'm not thinking "how can the person that made this be so dumb? How do you learn how to program and not know what sort is?"
This is always really surprising to me that it appears to be these two camps. Though what frustrates me is that if you suggest something in the middle people usually assume you're in the opposite camp than they are. It reminds me a lot of politics and I'm not sure why we're so resistant to nuance when our whole job is typically composed of nuance.
Though I'll point out, I think it is natural to complain about your juggling dog dropping balls or making mistakes on your taxes. That doesn't mean you aren't impressed. I think this response is increasingly common considering these dogs are sold as if they are super-human at these tasks. That's quite disappointing and our satisfaction is generally relative to expectations, not actual utility. If you think something is shit and it turns out to be just okay, you're happy and feel like you got a bargain. If you're expecting something to be great but it turns out to be just okay, you're upset and feel cheated. But these are different than saying the juggling dog is a useless pile of crap and will never be useful. I just want to make that clear, so we avoid my first paragraph.
I could see someone making a case for this being that 'middle' group but there's a sour note to this process that I don't know from one week to the next whether I find it sneaky or delightful.
Someone else can make that argument, because I'm so sick of silver bullets and gold rushes that I just. don't. care. Sturgeon's Law applies (90% of everything is crap) and I'll listen just enough to see if anyone is proposing which bits are the 10% to keep a finger on the scale if I think it'll matter. But let everyone else bleed over this, because in another ten years they'll be laughing about how silly they were to think this was going to solve all of our problems or end our profession.
Software is eating most things. If something eats software, your employability will be the least of your existential crises.
I've heard this before, but do we? Which were those this from the past that we "stopped called AI and we just call algorithms"?
I see three categories:
(1) very complex algorithms that we never did call "AI".
(2) stuff we did call AI, and we still do - things like expert systems, or IBM's Watson, or game AI. We knew, and still know, that those weren't AGI.
(3) some stuff promoted as AI (like the "AI assistant" Clippy), but which, marketing materials aside, nobody really considered AI or called them that.
But I don't remember this demoting/relabelling of stuff from AI to "just algorithms". It might have happened with some stuff, but I doubt it was a "classic" development as its portrayed.
People in the field would probably say they fall under the AI umbrella, but it's not the common viewpoint. Either someone can conceptualize how they'd work (expert systems) or they've been watered down and turned commonplace (markov chains in software keyboards, identification in Facebook images), and either way it disassociates the technology with the "intelligence" part of "artificial intelligence", so is no longer thought of as part of it.
Some tool using it marketed as AI, I can believe. But then again, nested IFs have probably also been marketed as AI in some products.
Zealots on either side communicate at 100 times the rate of people who aren't so heavily invested.
My theory is the increase in available information is overwhelming everyone's cognitive abilities, and so jumping to reductive conclusions is just a natural defense mechanism, leading to increased polarization and reduced listening/tolerance skills. Certainly software engineers have an above-average tolerance for nuance, but even we have to pick our battles or risk drowning in the flood.
Where we have measurements for pretty much everything but people don't know measurements are proxies and not always aligned with goals. Like how a ruler doesn't measure meters, but meters according to the ruler and only at the ruler's precision level. I can totally get how people who don't work with these tools don't understand the nuances, but it confuses me with experts. Isn't expertise, by definition, contingent upon understanding nuance?
It seems that the more metrics we have available to us, the less we care about understanding how those metrics work and what their limitations are. That they just become black boxes.
I mean there seems to be a very common belief that you can measure visual image quality by measuring some difference between an intermediate representation of a classification model. Or a belief that entropy measures quality of speech.
I'm really concerned that Goodhart's Law might be one of the Great Filters.
-- Zapp Brannigan
A user with a balanced interpretation and somewhat neutral feelings about a topic generally won't feel like they want to add something to a discussion. A user with strong opinion will more likely engage with someone with posts with the opposite viewpoint or the same viewpoint.
HN is a bit of an exception because the community is reasonably high quality. But major platforms? The people who bother to write out long and neutral posts learned there is nothing to gain from doing that years ago.
Even here, depending on the felt "hotness" of the topic in the community, you might get a lot of negative sentiment for trying to find a middle ground or daring to look at generalized claims in more detail.
I think, in general, people now seem to require you to signal that you share their identification with a certain thought before an open discussion might become possible.
One important aspect seems to be that the higher your educational level, the more likely you are conditioned to identify with your own thoughts. This amplifies polarization on an intellectual level. There is something in it for the individual thinker taking on a new polarized belief. It adds to their identity.
The ultimate catch then is to take the position that I just outlined as an identity contrary to "all" others who are polarized. This is yet another trap.
Hence, the exercise is to practice not getting polarized while being compassionate to those who are. It's just a tendency of the human mind and nobody should be judged for falling for these traps. It's too easy to fall for it given our current conditioning.
AI is not all-powerful, but those things alone help me a lot when I'm brainstorming.
The reasonable camp doesn’t produce good sound bites.
“LLMs are the next disaster” (either by replacing workers or as a fraudulent product leading to a market crash) is more exciting than “another interesting tool that is useful for certain problems that don’t have other tools, and works pretty well but still needs some polish and safety work.”
Don't have me read 20 pages of docs just to integrate into a browser or a framework.. cutting the legwork essentially so I can keep my motivation and inspiration going.
wanting this is probably the worst possible use case for LLM code vomit
I way trying to say how ChatGPT is good in relative terms, not absolute.
Oftentimes it will produce code that’s outdated. Or, it will output code that seems great, unless you have an advanced understanding of the browser APIs and behaviors or you thoroughly test it and realize it doesn’t work as you hoped.
But it’s pretty good at getting a jumpstart on things. Refining down to best practices is where the engineer comes in, which is what makes it so dicey in the hands of a jr dev.
This matches my experience. When ChatGPT started going viral, I started getting a lot of PRs from juniors who where trying it out. Pretty much every single one was using depreciated API calls or best practices from 5-10 years ago. I'd ask why they chose to use an API that is scheduled to be removed in the next release of whatever library or system we are using.
ChatGPT does have it's place. But you need to understand the tools you're using. It can't be great for a first spike or just getting something working. But then you have to go and look at what it's doing and make sure you understand it.
Although it’s also hollowed out the group of people using StackOverflow (and perhaps stack overflow has restricted open access to its data for further scraping), so future iterations of LLMs will have less up to date training data to use.
IMO, one of the biggest problems with the way people use LLMs right now, is that they're being treated as a single oracle: to know Java, it must be trained on examples of Java.
It would be much better if their natural language comprehension abilities were kept separated from their knowledge (and there are development efforts in this direction), so in this example it would be trained to be able to be able to read a Java tutorial rather than by actually reading a Java tutorial, so when the overall system is asked to write something in Java, the language model within the system decides to do this by opening https://learnxinyminutes.com and combining the user query with the webpage.
I think this will help make the models more compact, which is a benefit all by itself, but it would also mean that knowledge can be updated much more easily.
Someone would have to actually do this in order to see if those benefits are worth the extra cost of having to load a potentially huge a tutorial into the context window, and likewise the extent to which a more compact training set makes the language comprehension worse.
I get a Free subscription to it by using my kids EDU email accounts. Which is handy :)
But I absolutely would not pay for it.
I recall the last time I tried using the chat feature to do something, the code it produced wasn’t very useful and it referenced chapters from a book for further information.
It was clearly just regurgitating code from a book on the subject, and that just feels wrong to me.
At least give credit to the Authors and reference the book so I can go read the suggested chapters LOL
What we have right now is a system to collect information about the sorts of problems developers want existing code to solve for them. We should embrace it.
Not the quote, but there was a Farside cartoon along those lines where the dog was being berated for not doing a very good job mowing the lawn:
https://i.pinimg.com/originals/22/22/79/222279ceaa98f293e76e...
A fence with a hole is useless even if it's 99% intact.
A lot of human jobs, especially white collar, are about providing reassurance about the correctness of the results. A system that cannot provide that may be worse than useless since it creates noise, false sense of security and information load.
- drinking glass that is 99% hole-free
- car that doesn't explode 99% of the time
- bag of candy where 99% of the pieces are not poisonous
In all of these cases, it's more optimal to start from scratch and build something that you know is 100% reliable than to start with whatever already exists and try to fix it after-the-fact.
Personally, I use AI to assist development, especially in unfamiliar stacks, but in the form of a discussion rather than code-vomit. It's primarily synthesizing documentation into more-specific whole answers and providing options and suggestions.
> - drinking glass that is 99% hole-free
This describes my travel flask when the screw cap is on and the slot in the cap is open; most of my drinking glasses have (and need) a much bigger hole-to-surface ratio to get the fluid in and for me to drink from.
More relevantly for the output of an AI: in cases where testing is easy, a system which has a 99% chance of a producing a saleable drinking glass and just discards the other 1% to recycling isn't unreasonable… provided you can be sufficiently confident about the test.
For AI, the quality of the automated tests of the output is a very solid "it depends on what you're doing".
A lot of the latter is caused by the former. It is a nothing burger compared to the shocking amount of hysteria on HN about AI putting programmers out of a job. You'd expect a programmer to know what his job is, but alas, apparently even programmers think of themselves as glorified typewriters.
I myself also don't know what's considered best practice in Javascript generally (browser or server-side), even though I also have to write it occasionally -- but I wouldn't feel safe trusting that ChatGPT suggestions were likely to be model current best practices either.
On what are you basing your thinking that ChatGPT is more likely than not to be suggesting best practices? (Real question, I'm curious!)
I phrased that part badly, you're not the only one to get that (unintended) meaning from my words; where I wrote:
> I've spent the last 14 years doing iOS professionally and therefore don't know what's considered best practice in browser-land
That was meant to convey my weakness rather than its strength. I can tell when ChatGPT makes a wild error, but that's all because I don't know JS best practices.
Essentially, you "like" correct (or manually corrected) generations and a vectorized version is stored and used in future similar generations. An example could be tell which table or foreign key is preferred for a specific query or that is should wrap columns in quotes.
From my preliminary tests it works well. I was able to consistently make it use correct tables, foreign keys and quotes on table/column name for case-sensitivity using only a couple of trainings. Will open a public API for that soon too.
I really worry that there are people out there who will anxiously mangle their company's data thinking what is being called AI, which doesn't exist yet, will save the day.
[1]: https://www.sqlai.ai/snippets/clroq0qn9001xqzqeidtm4jgx
So I changed how I use GPT (which I do through API. Much cheaper btw). I use it a lot like how I would use SO in the first place. Get outlines, understand how certain lines might work (noisy process here), generate generic chunks of code especially from modules I'm unfamiliar with. A lot of this can just be seen as cutting down time searching.
So, the most useful one: using it as a fuzzy search to figure out how to Google. This one is the most common pattern. Since everything on Google is so SEO optimized and Google clearly doesn't give a shit, I can ask GPT a question, get a noisy response that contains useful vernacular or keywords which I can then use to refine a Google search and actually filter out a decent amount of shit. I think people might read this comment and think that you should just build a LLM into Google, but no, what's going on is more complicated and requires the symbiosis. GPT is dumb, doesn't have context, but is good at being a lossy compression system. The whole reason this works is because I'm intelligent and __context aware__, and importantly, critical of relying on GPT's accuracy[0]. Much of this can't be easily conveyed to GPT and isn't just a matter of token length. So that said, the best way to actually improve this system is actually for Google to just get its shit together or some other search engine to replace them. Google, if you're listening, the best way you can make Google search better with LLMs is to: 1) stop enabling SEO bullshit, 2) throw bard into the side and have the LLM talk to you to help you refine a search. Hell, you can use a RL agent for 1 to just look how many times I back out from the links you send me or look at which links I actually use. Going to page 2 is a strong signal that you served shit.
[0] accuracy is going to highly depend on frequency of content. While they dedupe data for training, they don't do great semantic deduping (still an unsolved problem. Even in vision). So accuracy still depends on frequency and you can think of well known high frequency knowledge as having many different versions, or that augmentation is built in. You get lower augmentation rates with specific or niche expert knowledge as there's little baked in augmentation and your "test set" is much further from the distribution of training data.
Copilot has replaced almost all of the annoying tedious stuff, especially stuff like writing (simple) SQL queries.
“Parse this json and put the fields into the database where they belong” is a fantastic use case for copilot writing SQL.
(Yes I’m sure there’s an ORM plugin or some middleware I could write, but in an MVP, or a mock-up, that’s too much pre optimization)
ORM is more for future, because it abstracts away the database implementation, so you could in theory change the db or change some behaviour more simply.
E.g. if you add something like deleted_at column, ORM can have a single place where to configure system to use it, but if you have SQL queries lying around you may need to find all spots to add that to your where clauses everywhere.
But otherwise SQL is easier to work with in my view.
It's just a question of whether you want to use a toolkit to help the transformations, or if you want to 'do it by hand'.
On the other hand, I use ChatGPT (via the API) quite often, and it's very handy. For example, I wrote a SQL update that needed to touch millions of rows. I asked ChatGPT to alter the statement batch the updates, and then asked it to log status updates after each batch.
As another example, I was getting a 401 accessing a nuget feed from Azure DevOps - I asked ChatGPT what it could be and it not only told me, but gave me the yaml to fix it.
In both cases, this is stuff I could have done myself after a bit of research, but it's really nice to not have to.
Using Copilot is a skill though, you have to live with it and learn its limits and idiosyncrasies to get the most out of it.
highlights: "the ai" and i collaboratively came up with a new programming language involving defining a new tag type in YAML that lets one copy/paste from other (named) fragments of the same document (as in: `!ref /path/to/thing to copy`) (the turing completeness comes from self-referential / self-semi-overlapping references (e.g. "!ref /name/array[0:10]`) where one of the elements thus referred-to is, itself, a "!ref" to said array).
lowlights: as already alluded to, using very plausible, semi-deprecated API functions that either don't do what you think they do, or simply don't work the way one would think they do. this problem is magnified by googling for said API functions only to find cached / old versions of API docs from a century ago that further convince you that things are ok. nowadays, every time i get any google result for a doc page i do a little ritual to ensure they are for the most recent version of the library, because it is absolutely insane how many times i've been bitten by this, and how hard.
Likely you’d get much better results with GPT-4.
Echoing this, it takes longer to read code than to write it, so generally, if you know what you want to write and it's non-trivial, you'll spend more time groking AI-written code for correctness than writing it from scratch.
This is the real danger of this sort of thing. When your Copilot or whatever are good enough that they replace what is vastly superior for purely economic reasons.
I wrote about this trend applied to the unfortunately inevitable doom of the voice acting industry in favour of text-to-speech models a couple of months ago, using my favourite examples of typesetting, book binding and music engraving: https://news.ycombinator.com/item?id=38491203.
But when it’s development itself that gets hollowed out like this, I’m not sure what the end state is, because it’s the developers who led past instances of supplanting. Some form of societal decline and fall doesn’t feel implausible. (That sentence really warrants expansion into multiple paragraphs, but I’m not going to. It’s a big topic.)
By democratization, I mean that it enables one-one where previously there was only one-many: instead of the inversion of experience where the same unique app experience is shared by millions, a technology allows the interface to be tailored for an audience of one or dozens: missing toes and fingers, color blindness, particularly difficult and unique operating conditions, etc. Given those unique constraints the mediocrity provides at least some preferable solution. The downside of this is that it sets the floor a lot lower, and people who would never have even tried or contemplated trying typesetting will dabble with desktop publishing to achieve their ends.
Somebody on here gifted me with the word "procrustean" and I've taken it and put it in my Minsky fish tank. There are many reasons to eschew the trusted experts model: somebody who has made heads for pins for twenty years is incontrovertably an expert, but who cares? Our uncanny valley appears to be only a local minimum.
[PS, nobody understood my point but I thank them for the honest feedback.]
I’m in India at present, and a number of 18–25 year-olds ask me about learning to code (commonly because their college or University is teaching C/C++ and they have no idea). Somehow, they have more access to a computer than ever before, because most of them carry one on their person all day, and more information about this task than ever before, yet their computer, a phone, has been dumbed-down and locked-up in such a way that they can’t really use it to learn to code, because that’s something you do on Computers, and those are just on the campus or your laptop, Chris, or things like that.
Easier for the simple tasks, so that the more complex tasks that enough in a previous generation used to work for just don’t get reached, leaving over time perhaps a chasm, and fewer really skilled people in a society that may depend on them more than previously. The lower floor helps some who wouldn’t have got started before, but discourages others by making things too easy so they never find the challenge they seek.
This aligns with my observations. I don't use Copilot etc. but the other devs on my small team do. I've observed that I'm generally a faster and more confident type and coder - not knocking their skills, I'm just more experienced, and also spent my teens reading and writing a lot.
I've seen that it helps them in cases where they're less certain what they're doing, but also when they know what they're doing and it's quicker about it.
I am also able to intuitively predict that it is going to vomit out exactly what I want.
E.g. I know ahead of time what the 10 lines it will give me are.
LLMs give you plausible text. That does not mean it is logically coherent or says what it should.
I use a similar vscode assistant bit only for shorter code. I am able to complete code faster than an instructor on video.
I've definitely seen juniors just keep refining the garbage until it manages to pass a build and then try to merge it, though, and using it that way just sort of makes you a worse programmer because you don't learn anything and it just makes you more dependent on the bot. Companies without good code reviews are just going to pile this garbage on top of garbage.
A problem with Fortran compiler error and warning messages is that Fortran is largely a legacy language at this point, and most Fortran code hitting the compilers has already had its errors shaken out. New code, and especially new code from new Fortran users, is somewhat more rare -- so those error and warning checks are a part of the compiler that doesn't get as much exercise as one would like.
It's really bad at doing anything novel and complex, so don't use it for that. But doing trivial stuff with tech you are new to is great. If you're new to sql then it can write you a decent table schema with decent indexes and give you the correct insert/update/select queries. It can even do simple joins. But don't venture into some complex nested stuff. Don't.
I often request modifications to code segments, typically around 25 lines, to alter the reporting features to meet specific needs, such as group X and total Y on this page. GPT-4 responds accurately to these requests. After conducting a quick QA and test, the task is complete. This approach has been transformative, particularly effective for low-complexity tasks and clear-cut directives.
This process reminds me of how a senior programmer might delegate: breaking down tasks into fundamental components for a junior coder to execute. In my case, GPT-4 acts as the junior programmer, providing valuable assistance at a modest cost of $20 per month. I happily pay that out of pocket to save myself time.
However, much like how a younger version of myself asked why we had to learn math if the calculator does it for us, I know understand why we do that. I think the same thing applies here. If you don't know the fundamentals, you won't be effective. If GPT-4 had been around when I learned to write PHP (don't @ me!), I probably wouldn't understand the fundamentals as well as I do. I have the benefit of learning how to do it before it was a thing, and then benefitting from the new tool being available.
I also don't find the code quality to be any less, if anything what it spits out is a bit more polished (sometimes!).
Though standards have been going down, so maybe you are right.
I’d be more worried if I was somebody like Squarespace. When anybody can say “build me a neat looking website,” the business of selling templates looks rough.
Spend a bit in R&D to make sure they have a lock on ease of use at gen AI website building/modification, ideally starting from base templates and that's plug and play with their existing CMS.
If anything, doing that could even increase their market share to users for whom simple templating was either (a) not enough, or (b) still too complex without additional handholding.
For pretty much everyone, generative AI is a threat to those who stagnate in the status quo and an opportunity to those actively seeking growth and ever improved product market fit.
But I agree with this one more so, I did programming as part of my Comp Sci degree and my job doesn't require any programming. I didn't particularly like programming and would end up with 20+ tabs of various questions being asked with most of my time spend finding an answer to my question having to troll through what was often the cesspool of stackoverflow.
But having a tool where I can ask it questions about my code, code in general is hugely beneficial. I can write a block of code, or have it write a block of code, then have it explain to me how it's meant to be working. If I don't understand a particular component I can contextually ask it more questions.
I appreciate the expectation of code quality is higher in production, but from a personal learning standpoint for a learner its great.
I think a lot of the criticisms are premature, and it's more a stumbling step forward with need for support from additional infrastructure.
Where's the linter integration so it doesn't spit out a result that won't compile? Where's the automatic bug check and fix for low hanging fruit errors?
What should testing look like or change around in a gen AI development environment?
In general, is there something like TDD or BDD that is going to be a better procedural approach to maximizing the gains to be had while minimizing the costs?
A lot of the past year or two has been dropping a significant jump and change in tech into existing workflows.
Like any tool, there's the capabilities of the tool itself and the experience of the one wielding it that come together to make the outcome.
The industry needs a lot more experience and wisdom around incorporation of gen AI in development before we'll realistically have a sense of its net worth. I'd say another 2-3 years at least - not because the tech will take that long to adapt, but because that's how long the humans will take to have sufficiently adapted.
I already worked with a team of 20 something's who were generating mountains of full stack spaghetti on top of the basic CRUD framework I built them.
There's lessening incentive to build your TODO app from scratch when you can generate an "MMO framework" in 60 seconds.
The same way I first used firebase 12 years ago before trying to learn the basics of relational, and it was years before I finally arrived at the basics.
With all things around me there is a sense that technology is to be a saviour for many very important things - ev's, medicine, it, finance etc.
At the same time it is more and more clear to me that technology is used primarily to grow a market, government, country etc. But it does that by layering on top of already leaking abstractions. It's like solving a problem by only trying to solvent be its symptoms.
Quality has a sense of slowness to it which I believe will be a necessary feat, both due to the fact that curing symptoms will fall short and because I believe that the human species simply cannot cope with the challenges by constantly applying more abstractions.
The notion about going faster is wrong to me, mostly because I as a human being do not believe that quality is done by not understanding the fundamentals of a challenge, and by trying to solve it for superficial gains is simply unintelligent.
LLMs is a disaster to our field because it caters to the average human fallacy of wanting to reach a goal but without putting in the real work to do so.
The real work is of course to understand what it is that you are really trying to solve with applying assumptions about correctness.
Luckily not all of us is trying to move faster but instead we are sharpening our minds and tools while we keep re-learing the fundamentals and applying thoughtful decisions in hope to make quality that will stand the test of time.
In how far do you think LLMs stand in the way of that?
My experience has been very much the opposite: Instead of holding the hard part of the process up by digging through messy apis or libraries, LLMs (at least, in their current form but I suspect that this will theoretically simply remain true) make it painfully obvious when my thinking about a task of any significance is not sound.
To get anywhere with a LLM, you need to write. To write, you have to think.
Very often I find the most beneficial part of the LLM-coding-process is a blended chat backlog that I can refer back to, consisting of me carefully phrasing what it is that I want to do, being poked by a LLM, and me through this process finding gaps and clarifying my thoughts at the same time.
I find this tremendously useful, specially when shaping the app early, to keep track of what I thought needed to be done and then later being able to reconsider if that is actually still the case.
I recommend Rich Hickey's "Hammock Driven Development" talk. You don't solve hard problems by poking at it repeatedly until something works, that is the recipe for terrible code and abstractions. You instead take a step back from your computer and digest it until you come with a well-understood solution.
This approach is what separates the experienced engineer from the junior. Code is the least of your problems.
There are the John Carmack types, whose output depends on how much time on they spend at keyboard, and the Rich Hickey types, whose output depend on how much time they spend on a hammock with their eyes closed (or under the shower in my case). I am afraid I am of the latter type. My best solutions are found away from the keyboard, as I have learned to simply depend on my subconscious to process and digest them while I'm doing other things.
Check out that talk still, it has deep insight on how the human brain operates.
It's a tool. It doesn't make sense to blame the tool. Is it the screwdriver's fault it gets used as a hammer? Or a murder weapon?
Used intelligently Copilot & Co can help. It can handle the boilerplate, the mundane and free up the human element to focus on the heavy lifting.
All that aside, it's early days. It's too early to pass judgement. And it seems unlikely it's going to go away.
I think his insight applies nearly as well to using code generated by an ai.
IKEA furniture is a great example of this. I build my own furniture and being around it is a much much nicer thing than some piece of cardboard from IKEA.but it seems like cost, soeed an convenience are the most important thing in peoples minds.
Also: "The projections for 2024 utilize OpenAI's gpt-4-1106-preview Assistant to run a quadratic regression on existing data." ...am I to understand they asked gpt to do a regression on the data (4 numbers) rather than running a simple regression tool (sklearn, r, even excel can do this)? Even if done correctly, it is not very compelling when based off of 4 data points and accounting for my first concern.
They’re using GPT….to write code that does “quadratic regression” on two whole data points…which just extends the slope of each [2022, 2023] line one year further!
So quadratic regression makes it sound all fancy, but with two data points, it's literally just "extend the line straight". So the 2024 prediction is essentially meaningless.
We hope it leads dev teams, and AI Assistant builders, to adopt measurement & incentives that promote reused code over newly added code. Especially for those poor teams whose managers think LoC should be a component of performance evaluations (around 1 in 3, according to GH research), the current generation of code assistants make it dangerously easy to hit tab, commit, and seed future tech debt. As Adam Tornhill eloquently put it on Twitter, "the main challenge with AI assisted programming is that it becomes so easy to generate a lot of code that shouldn't have been written in the first place."
That said, our research significance is currently limited in that it does not directly measure what code was AI-authored -- it only charts the correlation between code quality over the last 4 years and the proliferation of AI Assistants. We hope GitHub (or other AI Assistant companies) will consider partnering with us on follow-up research to directly measure code quality differences in code that is "completely AI suggested," "AI suggested with human change," and "written from scratch." We would also like the next iteration of our research to directly measure how bug frequency is changing with AI usage. If anyone has other ideas for what they'd like to see measured, we welcome suggestions! We endeavor to publish a new research paper every ~2 months.
So, would a more accurate title for this be "New research shows code quality has declined over the last four years"? Did you do anything to control for other possible explanations, like the changing tech economy?
imo, this is just replacing one silly measure with another. Code reuse can be powerful within a code base but I've witnessed it cause chaos when it spans code bases. That's to say, it can be both useful and inappropriate/chaotic and the result largely depends on judgement.
I'd rather us start grading developers based on the outcomes of software. For instance, their organizational impact compared to their resource footprint or errors generated by a service that are not derivative of a dependent service/infra. A programmer is responsible for much more than just they code they right; the modern programmer is a purposefully bastardized amalgamation of:
- Quality Engineer / Tester
- Technical Product Manager
- Project Manager
- Programmer
- Performance Engineer
- Infrastructure Engineer
Edit: Not to say anything of your research; I'm glad there are people who care so deeply about code quality. I just think we should be thinking about how to grade a bit differently.
> Not to say anything of your research
The second statement isn't true just because you want it to be true. The first statement renders it untrue.
> I'd rather us start grading developers based on the outcomes of software. For instance, ... errors generated by a service
yeah you should click through and read the whitepaper and not just the summary. The authors talk about similar ideas. For example, from the paper:
> The more Churn becomes commonplace, the greater the risk of mistakes being deployed to production. If the current pattern continues into 2024, more than 7% of all code changes will be reverted within two weeks, double the rate of 2021. Based on this data, we expect to see an increase in Google DORA's "Change Failure Rate" when the “2024 State of Devops” report is released later in the year, contingent on that research using data from AI-assisted developers in 2023.
The authors are describing one measurable signal while openly expressing interest in the topics you're mentioning. The thing is: what's in this paper is a leading indicator, while what you're talking about is a lagging indicator. There's not really a clear hypothesis as to why, for example, increased code churn would reduce the number of production incidents, the mean time to resolution of dealing with incidents, etc.
> yeah you should click through and read the whitepaper and not just the summary. The authors talk about similar ideas
Ah, this whitepaper that's gated behind supplying my business email address?: https://www.gitclear.com/coding_on_copilot_data_shows_ais_do...
I read the article that was linked, which is generally what's expected of me on HN.
> The authors are describing one measurable signal...
I'm aware of the research around this topic, it's something I like reading about and I've read a lot of takes both academic and colloquial. That may be why I put that idea into words.
Maybe, just maybe, in our future interactions you can avoid being so unnecessarily hostile?
There is actual AI benchmarking data in the Refactoring vs Refuctoring paper: https://codescene.com/hubfs/whitepapers/Refactoring-vs-Refuc...
That paper benchmarked the performance of the most popular LLMs on refactoring tasks on real-world code. The study found that the AI only delivered functionally correct refactorings in 37% of the cases.
AI-assisted coding is genuinely useful, but we (of course) need to keep skilled humans in the loop and set realistic expectations beyond any marketing hype.
If Copilot gives me working code in the prototype stage, good enough that I can just move on to the next thing, my understanding is never going to be good enough that I can go in and structure everything correctly. It will effectively allow me to skip 90% of my workflow, but pay the price. That's not to say that Copilot can't be extremely helpful during the final steps of development.
If those findings are correct, I can't say that I'm surprised. Bad code is written by poor understanding and Copilot can't have any understanding beyond what you provide it. It may write better code than the average programmer, but the result is no better than the input given. People are extremely focused on "prompt engineering", so why act surprised when a poor "prompt" in VScode yields a poor result?
My experience is that Copilot is great at getting me started. Sometimes the code is good, sometimes it's mediocre or completely broken.
But it's invaluable at getting me thinking. I wasted a lot more time before I started using it. That might just be my weird brain wiring...
(Edited to sound less narky. I shouldn't post from a mobile device)
Copilot lets me get started, even if it's wrong sometimes. There have been times where I have been surprised by how it took something I wrote for a server, and presented the correct client-side implementation.
I've used it a few times to describe a problem and let it handle the solution. It's not very good, but I wonder if one should place more blame on PEBCAK and put more time into problem-description. I gave it a few more paragraphs to describe the problem, and eventually I could take it from there. It was still wrong, but enough to get me started. Immensely helpful that way.
Another aspect that I'm wondering about is if it will be able to do more with better documented code. Anyone have experience with that? I've started to write more doxygen comments, and hoping to see if there's a slow shift to more accurate predictions.
This is like writing in general. It's easy to edit crappy text you've written into something better.
It's completely impossible to do it to a text you didn't write at all.
LLM models are pretty good in doing the crappy first version. It might use abandoned packages or old APIs but the skeleton is there. It's not that hard to add some meat on the bones when the structure exists.
Recently I had to parse a pretty crappy XML format (planned by committee) with Go. I just fed the XML to GPT4 and asked it to parse specific values from it. It got like 95% there. I just had to do a few fixes and polish it a bit. Saved me a lot of headache and poking around in documentation.
I find stuff like Phind useful, in the sense that sometimes something happens that I don't understand, and 60% of the times Phind actually helps me to understand the problem. Like finding trivial bugs that I didn't spot because I'm tired, dumb, etc.
On the other hand, with Codeium, I guess it may be useful when you're just churning boilerplate code for some framework, but in my little expericence (writing scrapers and stupid data pipelines & vanilla JS + HTML/CSS) cycling through suggestions is very irritating, specially because many times it doesn't work. Most of the times for stupid reasons, like lacking an argument or something like that, but then it's time you have to spend debugging it.
Another problem I have is that I find there's a common style of JS which consist in daisy-chaining a myriad of methods and anonymous functions, and I really struggle with this. I like to break stuff into lines, name my functions and variables, etc. And so many times code suggestions follow this style. I guess it's what they've been trained on.
Codeium is supposed to learn from this, and sometimes it does, to be fair.
But what I worry the most is that, If I'm a junior and I let this assistants do the code for me ¿How the hell I'm supposed to learn? Because giving Phind context + questions helps me learn or gives me direction to go on find it by myself in the internet, but if the only thing I do is press tab, I don't know how the hell I'm supposed to learn.
I found a couple days ago that many people (including devs) are not using LLMs to get better but it's just a substitute of their effort. Isn't people afraid of this? Not because companies are going to replace you, but it's also a self-reflection issue.
Coding is not the passion of my life, addmitedly, but I like it. I like it because it helps me to make stuff happen and to handle complexity. If you can't understand what's happening you won't be able to make stuff happen and much less to spot when is complexity going to eat you.
BUT (and this is key), I've hand-written so many API specs in my career that 1) I was able to spot the issues immediately, and 2) I could correct them without any further assistance (refining my prompt would have taken longer than simply fixing the models by hand).
For stuff where you know the domain quite well, it's amazing to watch something get done in 30s that you know would have taken you the entire morning. I get what you're saying though, I wouldn't consider asking the AI to do something I don't know how to do, though I do have many conversations with the AI about what I'm working on. Various things about trade-offs, potential security issues, etc. It's like having a junior engineer who has a PHD in how my language works. It doesn't understand much, but what it does understand, it appears to understand it deeply.
My experience has been the opposite so far. I benefit much more from such tools when I can easily check if something works correctly and would have to learn/look up a lot of easy and elementary stuff to do it from scratch.
For example, adding to some existing code in a language I don't know and don't have time or need to learn (I guess not many people are often in that situation). I get a lot of hints for what methods and libraries are available, I don't have to know the language syntax, for easy few-line snippets (that do standard things and which I can test separately) the first solution usually just works. This is deliberately passing on an opportunity for deeper and faster learning, which is a bad idea in general, but sometimes the speed trade-off is worth it.
On the other hand, for problems where I know how to solve them, getting some model to generate the solution I want (or at least one I'm happy with) tends to be more work than just doing it myself.
I probably could improve a lot in how I use the available tools. Haven't had that much opportunity yet to play with them...
It may not be the passion of your life but I haven't seen anybody articulate better (in recent memory) what they want to get out of coding and how they evaluate their tools. Keep at it, don't change and you'll go places, you are definitely on the right path.
My biggest use for AI assistants has been speeding up test writing and any "this but slightly different" repetitive changes to a code base (which admittedly is also a lot of test writing). At least in intellij + GH, things like, a new parameter that now needs to be accounted for across multiple methods and files is usually a matter of "enter + tab" after I've manually typed out the first two or three variants of what I'm trying to do. Context gives it the rest.
In VSC with Codeium, the AI doesn't seem quite as up to snuff, and the plugin is written in such a way that its suggestions and the keys for accepting them seem to get in the way a lot. It's still helpful for repetitive stuff, but less so for providing a way of accomplishing a given goal.
I think your whole comment is excellent but I just wanted to tell you, you're on the right track here. Certain developers, and in particular JS developers, love to chain things together for no benefit other than keeping it on one line. Which is no benefit at all. Keep doing what you're doing and don't let this moronic idiom infect your mind.
It's the high-level code that can become an issue (structuring the state of your program, using dependency injection incorrectly, having a convoluted monad transformer stack, putting very specifically typed effects in your Reader etc.). If you make mistakes there, you will struggle to read, write and reuse code, and even then, not all is lost. If there's bad structure you can most often transform it into a good one. When there's no structure, that's a problem.
Seeing .map.filter becomes a quick pattern match. You know what's happening there. It does not matter if it's a named variable or just part of a long
a.map
.filter
.reduce
.map
I agree, if your goal is to hire a lot of people, then you might want a style that does not strain the pattern matching abilities too much. We can compare which style is the best for that.
Nothing stops you from extracting a sequence from a long chain into a function to reuse it elsewhere.
pipe(
object,
map,
filter,
...
)
The amazing part for me with the tech is when it matches my style and preferences - naming things the way I want them, correctly using the method I just wrote in place of repeating itself, etc.
I haven't used it much in blank or small projects, but I'd imagine I'd find it much less ideal if it wasn't so strongly biased towards how I already write code given the surrounding context on which it draws.
AI tools are akin to having a junior developer working for you. Except they are much much faster.
If you don’t know what you’re doing they just accelerate the pace that you make mistakes.
Honestly, this is brilliant. The other day I had to add table name prefixes to a SELECT statement column aliases, since such a feature just doesn't exist for some reason, a bit like:
-- fails because of duplicate column names (e.g. when creating a view)
SELECT
*
FROM table_a
JOIN table_b ON ...
JOIN table_c ON ...
...
-- this would solve my issue, if WITH_PREFIX did exist (or anything like it)
SELECT
table_a.* WITH_PREFIX 'table_a',
table_b.* WITH_PREFIX 'table_b',
table_c.* WITH_PREFIX 'table_c'
FROM table_a
JOIN table_b ON ...
JOIN table_c ON ...
...
SELECT
table_a.id AS 'table_a_id',
table_a.email AS 'table_a_email',
...
table_b.id AS 'table_b_id',
table_b.start_date AS 'table_b_start_date',
...
Aside from that, I just use the LLMs as autocomplete, which also encourages me to have good function naming, since often enough that's sufficient information for the LLM to get started with giving me a reasonable starting point. In particular, when it comes to APIs or languages I haven't used a lot, but the problems that I face have been solved by others thousands of times before. I don't even have to use StackOverflow much anymore.
That's why I bought Copilot (though JS/HTML autocomplete in JetBrains IDEs is visually buggy for some reason) and use ChatGPT quite a lot.
LLMs are definitely one of my favorite things, after IntelliSense (and other decent autocomplete), codegen (creating OpenAPI specs from your controllers, or bootstrapping your EF/JPA code from a live dev database schema), as well as model driven development (generating your DB schema migrations/tables from an ER model) and containers (easily packaged, self-contained environments/apps) and smart IDEs (JetBrains ones).
It seems like the process of reviewing its generated code to make sure all 40 columns are there and then either re-doing this or manually going through that list whenever the schema changes would take longer than just writing the script? And now you're asking your code reviewers to the same both boring-and-slow manual check on the commit rather than just reviewing the three lines of the script?
100%
And if you know what you are doing, they will accelerate the way you're building stuff.
I think companies will want more code faster to the extent that fewer people will emerge from the churn really knowing what they are doing.
Some younger developers have a very different attitude to code than what I was brought up with. They have immense disdain for the Gang of Four and their design patterns (probably without realising that their favourite frameworks are packed to the gills with these very patterns). They speak snidely about principles like DRY and especially SOLID. And on places like Twitter the more snide and contrarian you can be, the more engagement you'll get. Very disturbing stuff.
DRYing code repeated for the same reason is mostly good.
DRYing code coincidentally repeated for different reasons will sow code churn or inadvertent behavior shifts.
You're describing heaven for a maintenance programmer -- I'm only looking at the codebase because there's a bug in some component, I likely even have a stack trace. If can just read what that bit of code does top to bottom, fix the error in just that component, write a test and ship I'll send the original author chocolates.
Also, not all maintenance involves correcting inborn defects.
To first order :vimgrep is totally mechanical and brain-off repeat fix is super easy.
We just cant stand acting as if that random list of principles created by Java's OOP mind was some source of truth for software modeling.
We're just tired of seeing bilionth discussion about how to understand SOLID
You probably don't see people arguing against CAP theorem because it is not some arbitrary collection of ideas (not even fully authored by SOLID author) which composes fancy mnemonic
>There was already a backlash against DRY code occurring before "AI" assistants hit the market, sadly.
As everything else - DRY can be abused too and people backlash against acting as those things were flawless when they arent.
For example, take DRY. The important principle was never really about repeating code. It was about repeating ideas. For any given concept in your system, ideally there should be a single source of truth, and therefore a single place you need to understand or change if you’re working with that concept. It’s true that this means copying and pasting non-trivial amounts of code instead of creating a meaningful abstraction is often a bad idea. But it is also a warning that any time you do repeat an idea, you now have an ongoing liability because you need to keep those different representations in sync. That could refer to database migrations that define your schema and separate ORM class definitions, or an API you define in your back-end code and a client for that API you define in your front-end code, or a retained mode UI where you have a current value in some form field that corresponds to a specific value in your internal application state, or some invariant in your data model that can be represented in both types and unit tests.
People who object to combining duplicate or near-duplicate code that represents different ideas but happens to have a similar implementation at the time, on the basis that it’s a maintenance hazard for later on, aren’t wrong. They’re just objecting to a straw man that was never really the point of DRY in the first place, but has been treated as if it were due to some kind of cargo cult/gaslighting effect.
The question I have now is where and when in our industry do we expect new developers to learn these principles so they do understand them properly? Some people have a formal background in CS or the like, but not everyone does, and in any case it’s not necessarily the role of an academic CS course to teach a lot of practical software development skills. I had a discussion the other day about how when I was starting out, the senior developers would give real, substantial training to the juniors to help us learn and understand these principles, but with the job-hopping culture today and the resulting general aversion to hiring juniors as a long-term investment, that just doesn’t seem to happen much any more. There are formal courses that cost a lot by personal standards but almost nothing by business standards, but there must be a tiny proportion of new developers who actually get sent on them by their employers. There are a few books worth reading, but what 20-something in 2024 wants to deal with presentation as antiquated as ink on sliced bits of tree? I suspect a lot of what today’s up and coming developers learn about these ideas comes from sources like blogs and YouTube videos, where again there is some great material out there, but as ever the problem is finding it among all the poorly understood and dubiously presented dross.
And then we wonder why tools come along that seem like magic, producing a dozen lines of code in a heartbeat that seem to mostly work, and young developers think they’re great even while having little idea of all the deeper things that may be wrong with that code. It’s not really surprising, and I’m not sure it’s really anyone’s fault, but it’s definitely a problem and I wish I knew what we should do about it.
Immense disdain does accurately describe how I feel towards whatever it is happens in corporate codebases. No, creating layers upon layers of indirection via classes is not ok, no matter what your SOLID guru tells you. Best practices, DRY, and SOLID are just excuses.
For reasoning about larger chunks of code I find ChatGPT better than CoPilot as an LLM assistant. Trying to use CoPilot for making large sections of boilerplate like the kind you might see in a db->api->web project is just full of frustration. It doesn't realize it makes makes tiny inconsistencies everywhere so you are permanently babysitting. I think the key takeaway is that if you have repeated code (An entity, a DTO, a controller, a frontend component all sharing some set of names/properties) then its better to change jobs than change tools.
I am an experienced dev but new to ML so take with a grain of salt, but I really wonder if the future is going to be quality in the training sets rather than quantity. I have heard that the "emergent properties" don't seem really affected by bad data as long as the set is large enough, but at what point does this cease to be true? How do we guard against this?
I don’t know of too many people who would advocate replacing SQL with hand-written C manipulating B-trees and hash tables. Similarly, it’s pretty rare that you want to hand-roll a parser in C over using a parser generator DSL or even something like regex.
And the thing about AI is that their negative impact is clearly visible above the noise.
What I really want is a smarter intellisense, whereas Copilot is a dumber pair programmer. I want smart, style-aware, context-aware tab completion on boilerplate, not on business logic.
Unfortunately I think many people are using it for business logic and that seems to be the direction the product is going.
It helps me do things that I'd usually procrastinate from doing, yet I know how I can get them done. It is really a booster to ones performance if you know exactly what you want
These two observations aren't mutually exclusive. DRY-ness comes from a holistic understsanding of a system; you get similar results when you task a junior developer with little deep knowledge of a novel codebase with solving a problem and don't give them enough oversight; they'll tend to bull-rush through coding a solution with little-to-no knowledge of how the solution can be built out of the parts already existing in the codebase.
Cleanly enough that there's no room for debate, doubt or discussion?
(Edit. Not the same person. I keep making this mistake in discussion threads)
Previously I wrote:
> It's your tone of "this is obvious, people! Why are you still wasting time thinking about it?" that I'm taking exception to.
I would say instead of reacting to the rhetorical remarks, bring up the actual interesting discussion around it in your response.
Progress comes from human intellect, mediocrity comes from regurgitation.
I think this is related to the productivity wage gap. I’m being paid lower than I was in 2018 adjusted for inflation and I’m far more capable, producing far more value for my employer. As my tools get more valuable my labor gets proportionally less valuable. (A certain historical figure predicted this end state of capitalism).
Here’s another take: I don’t give a fuck about the code quality at my company. I’m not paid extra to write good code. My bonus is based on basically nothing I can influence. If the whole company goes out of business on Monday I’ll enjoy my long weekend.
To build a house, it used to be necessary to hire experienced craftsmen. Now most of it is delivered pre-fabricated to the building site and laborers hired for the day nail it together.
Cars used to be hand built by machinists and metalworkers. Now laborers tighten a bolt as cars roll by on an assembly line. Or a robot does it.
Computer coding is going the same way. We lived and worked through the craftsman stage. Now we're becoming laborers.
Couldn’t this equally be explained by the cost of refactoring becoming incredibly cheap? If most of your code is generated, and you don’t have to make the investment of hand crafting everything, aren’t you naturally going to be regularly replacing vast tracts? Obviously the trend may have implications, but in large part aren’t we just seeing the impact of code cheapening? Serious question.
For example, a few months ago I was rewriting some particularly tricky, opaque code from Ansible having to do with the conversion of symbolic "chmod" strings into numeric. Because I was coming from code that was so hard to reason about (a bug in it took me a couple days to understand and fix), I wanted something really obvious and well tested. ChatGPT helped with that. https://github.com/linsomniac/symbolicmode/blob/main/src/sym...
That said, I have issues with RSI, so every saved keystroke is extremely useful to me. I find Copilot's ability to accurately predict the next, say, ten words I'm about to type very useful.
The usual insult thrown at LLMs is that they're "fancy autocomplete". I think that's actually about right, and I'm extremely sceptical about any claims made about their critical thinking skills which I think are essentially non-existent. Where I differ with most AI-sceptics is that I think fancy autocomplete is incredibly valuable.
[1]: Let's say that's about a mid-sized function definition.
In a world where AI can read our codebase, ingest a prompt, and quickly output "correct" if not clean and concise code, and then be able to iterate on code with more prompt, do we need all the same patterns we used to adopt when humans were painstakingly writing every line of code?
This reminds of of the CISC to RISC migration - now that computers are in the loop writing the tedious parts, we don't need to burden our codebase with patterns meant to relieve humans from the tedium.
I find myself, for instance, writing more long form, boring configuration files that once upon a time I would have built some abstraction reduce the boilerplate and verbosity. But now that co-pilot can just auto-complete the next section for me, why bother?
That world does not exist, so currently this line of thinking is academic.
Perhaps it will exist in the future, but it's far from a certainty if that will come to pass, and unclear on what kind of time-frame. Personally I'm quite skeptical any of us will see it within our lifetimes.
> find myself, for instance, writing more long form, boring configuration files that once upon a time I would have built some abstraction reduce the boilerplate and verbosity. But now that co-pilot can just auto-complete the next section for me, why bother?
Again, so humans can understand it more easily.
"Poor code quality due to AI assistants GitHub Copilot and ChatGPT" [1](21 points, 2 days ago, 10 comments)
[0]: https://news.ycombinator.com/item?id=39142285 [1]: https://news.ycombinator.com/item?id=39144366 [2]: https://news.ycombinator.com/item?id=39156643 [3]: https://news.ycombinator.com/item?id=39164079
I tried it for code generation and it broke DRY multiple times. It's still faster for me to just build a thing without code generation. I'm not a wizard with my IDE, but I've gotten to a point where I'm pretty fast with some things I need to get done, it's muscle memory.
I am a bit fanatic about verbose variable names, and sometimes the AI creates terrible names for variables, which I go and change anyway.
Truth be told though, speaking as someone that still does not use LLM tools at work… “just OK” is totally viable for a lot of things. Prototypes yes, products expected to be around a while, maybe not.
When you're writing software that is touched fairly often, the "tribal knowledge" of how it works will likely live-on. You can be a little bit clever at times, you don't need to comment as heavily, and your variable names can be a bit wonky.
When you're writing software that is hardly ever touched ... everything needs to be crystal clear. Write lots of comments, explaining the "why" things are the way they are. You want to avoid cleverness except in the name of performance (but then comment how you expect it to work so that when someone comes along to change it, they understand wtf you are doing and the constraints you used to define the code). It's a totally different ballgame.
AI doesn't get this distinction, hell, most programmers don't either.
LLMs are ultimately going to be more valuable for reading code than writing it.
<hits the snooze button>
Someone wake me up in fifteen years when the next batch of students repeat history.
Overall from personal experience TFA's conclusions do seem correct to me, but I want to make sure we aren't confirmation biasing the interpretation of the data.
I think that's where it's competency really sits. It provides some interesting suggestions otherwise, but mostly it's these slam dunks that make me very happy with it.
I found that using ChatGPT to help me code led me to get working, well documented, code done much faster but it tend to also be somewhat more "naive" code: going for the obvious solutions even if their complexity is not optimal.
I have never not modified and refactored the code before implementing it.
The secondary use is as a duck to bounce ideas off. A duck that is not as smart as a human but always available. And I can ask stupid questions to check my understanding.
The final use is for code generation. If I’m super tired it can do trivial coding for me. Or if it’s boilerplate, which is very little code for me. Generally it doesn’t help a great deal within the IDE, and I’m not completely sure it’s a net win there yet.
It shows glimpses of being useful but rarely delivers usable code.
But probably the most off-putting thing I've experienced is an OKR session with 50 people in it, where a lead dev publicly opened chatgpt, prompted "how do we reduce the number of critical bugs by 30% in the next quarter", chatgpt came up with a generic response, everyone said "perfect", copy-paste that into Jira and call it a day. And I'm just sitting there and wondering if there was something rotten in my breakfast and I'm hallucinating. Unfortunately my breakfast was fine and that really happened. The few times I've tried using those, they were only helpful with dumb, repetitive and mundane tasks. Anything else, you have to rinse and repeat until you get a working solution. And when you read it(for those of us that do), you realize you might have been better off recruiting a freelancer from year one in University to spend a day mashing it up and likely coming up with something better.
But I bet much of those year ones would be doing this exact thing day in and day out until they come up with a solution: Occasionally I will grab my laptop and go work at a cafe on my personal projects for a change and I can't tell you how many times I've seen people just copy pasting stuff from chatgpt and pasting it back into their IDE/editor and calling it a day - students and clearly people who are doing this for a living. Not to mention copilot, that's the de-facto standard at this point.
In fact I had this conversation last year with a guy(developer) who is 20-something years older than me(so mid 50-s): most of the LLM's are trained on stuff that is in the documentation, examples, reddit and stackoverflow. It's only a question of time until the content found in those exact locations where the training data is pulled from will become more and more AI-generated, models will be re-trained on those and eventually shit hitting the fan. I don't think we are too far off from this event.
I don't think I can believe this story as told...
Every quarter HR requires that we write our "perspective" for the next quarter; what we are going to do and how we are going to improve ourselves. It's purely bureaucratic exercise, has no meaning and no impact on anything anybody does, but on an off-chance somebody reads it I cannot just fill it with nonsense. Writing something resembling sensible, in a stilted language required, always makes me struggle much more than writing code or something with meaning.
Strange that I haven't though about using an LLM or this before; seems like a perfect job for it.
But yeah, I abhor bureaucracy and trivial bs like the one you mentioned so I'm more than happy to outsource this issue to someone/something else.
And as we zoom out and think more farther into the future, I see it getting much worse. If AI is really doing all the "hard stuff", then the general human incentive to learn and do them at all quickly treads to 0. This isn't going to be everyone, I think some people will absolutely become "10x developers" or the equivalent for other domains. But all this will result in is more inequity, in my naïve view. The universe has a fundamental property that things move from higher energy states into lower ones. From a human POV, I think you could apply a similar idea, if the need to be smart quickly recedes, then in general we may degrade unaugmented human collective intelligence over time.
I don't know, maybe we'll figure something out to make it much easier to learn and ingest new concepts, but it seems more and more to me that the high obstacles for human brains learning things (with poor memory) is too big a bottleneck to overcome any time soon.
Many other mass produced products we buy today are clearly lower quality than ones crafted by artisans 50 years ago, and yet they do what we need them to do at a fraction of the cost.
I think that's a sweeping generalization. For example, it's much better to have a bunch of food that's mostly garbage than to have a famine where all food is super high quality. There were points in history where this choice was made (obviously unconsciously because the choice is too obvious to even think about). Other examples abound.
Technology often makes things much cheaper while reducing quality. Sometimes that's bad, sometimes it's great.
Like any idea about squishy human brains and its products it remains to be seen and can’t be as easily proven as for example research in Physics.
I would say current research has a probability of 50% of being correct at best.
Not without a solid result establishing so. But good luck with this, you'd probably need to compare our world with internet and a similar enough world but without it, which does not exist.
In any case, internet can't be reduced to "tiktok et al"
https://blogs.ubc.ca/etec540sept13/2013/09/29/socrates-writi...
This coupled with an broad interest in just about anything means I can often help people far outside my specific field, usually rather swiftly as well.
In a conversation with Phaedrus, Socrates worries that writing could impair human memory, as people depend on written words instead of recalling information. [0]
[0]: https://en.wikipedia.org/wiki/Phaedrus_(dialogue)#Discussion...
The question is will we one day have tools so powerful, that the human is vestigial, and tool (without human) is just as powerful and cheaper than tool (+ human)?
AI might replace it.
Writing "replaced" some forms of intellectual effort.
And it's yet to be seen how AI will play out.
I find that it is true that new mediums and new technologies for language have a numbing effect on certain senses and an amplification of others.
Writing is beneficial in one regard but does have an impact on memory. Epic poems of great length were memorized in their entirety, a skill that would be a lot easier to develop in a world without writing.
In already developed countries the Flynn effect seems to be reversing, ie IQ is leveling off or even dropping.
It's basically impossible to improve an adult's g-factor, for example. For children, things like nutrition and hygiene (e.g. no parasites) play a big role. But the kinds of things a human learns or tools they use doesn't significantly affect G-factor.
Qanon was purely a creation of the internet. Now go take a look at how many people believe one, many or all of the various Qanon alternative facts.
They don't prove that it makes people dumber. You have to quantify and qualify people and to define "dumb".
Maybe people are not actually dumber because of the internet, but the internet is very good at spreading ideas, including incredibly dumb ones, especially (because of how human beings work) those likely to cause feeling of outrage.
Maybe people are not dumber, just too defenseless against the scale of bullshit they are faced with because of the internet. Maybe internet is an incredibly good tool, but strongly requires good learning / training of critical thinking and there's not enough of this yet.
It's hard to argue that nowadays people believe more crazy stuff than before the internet was invented. (It's very easy, of course, to claim this, as many like to do.)
Taking into account that such blunt statements always hide a lot of nuances, this seems to capture the reality.
None of this really happened. I mostly use editor tools to automate away tedium that doesn't matter; I type "log.Inf<TAB>" and it adds "src/internal/log" as an import at the top of the file and types the o and open parenthesis for me. I have not forgotten how to do that myself, but it saves me a couple seconds. Calculators didn't really make people dumber, though I have to say that a lot of arithmetic I learned in elementary school did make me dumber ("touch math" was the killer for me; slows me down every time I do arithmetic in my head; I need some brainwashing program that deletes that from my brain). Spell check didn't make people worse at spelling; spelling things wrong still has a penalty (C-w to kill the last word and spell it correctly), so the incentive is to still to lurn how to spel wrds rite. Zoom meetings didn't ruin the corporate world; I personally found them very helpful for memorizing people's names with a high degree of certainty. You see it under their face for 40 minutes at a time, and you learn it fast. In real life, probably takes me a few weeks for people I only see once a week. So, honestly a benefit for me.
The current state of AI seems very similar to these technologies. I did a copilot free trial (and didn't renew it). With the free trial I think there were a couple things it was good at. One time I wanted a CPU profile for my app, so I just asked the AI to type it in. Open a file, check for an error, start profiling to the file, stop profiling, close the file. Would have taken me a minute or two to type in, but Copilot typed it in instantly. I also did something like "do the same as the function above, but for a YAML file instead of a JSON file". Again, super trivial to type in that code, it's really only one line, but the AI can handle that just fine in an instant. I don't really think it's more than slightly smarter IntelliSense, but without any access to the compiler toolchain, so it can sometimes just hallucinate stuff that doesn't exist.
I've found this to be kind of an interesting way to proofread documents and design APIs. Give ChatGPT a document you're working on, and then ask questions about it. If it gets the wrong answer, then your doc is no good! Similarly, ask it how to write some code using your new API (without showing it the API). Whatever it writes should be the surface area of your API. This avenue is pretty interesting to me, and it's not replacing humans, it's just a smarter rubber duckie.
Overall, I think we're in a little bit of a hype phase with AI. I look at it kind of like a dog that has read every book, if such a thing were possible. Pretty smart, but not quite human yet. As a result, it's not going to do well in the areas where people really want to apply it; customer service, insurance claims, loan underwriting, etc. But it is pretty good for asking questions like "does my document make sense" or "please find some boilerplate to cut-n-paste here, I am going to delete this before checking in anyway". Also not too bad at slightly modifying copyrighted images ;)
Every tool has this trade-off, and the existence of skills that will be lost is not evidence that the tool will do more harm than good. I don't think anyone here would argue that Socrates was correct that writing would be the end of memory and wisdom.
> To [Thamus] came Theuth and showed his inventions ... when they came to letters, "This,* said Theuth, "will make the Egyptians wiser and give them better memories; it is a specific both for the memory and for the wit."
> Thamus replied: "O most ingenious Theuth, the parent or inventor of an art is not always the best judge of the utility or inutility of his own inventions to the users of them. And in this instance, you who are the father of letters, from a paternal love of your own children have been led to attribute to them a quality which they cannot have; for this discovery of yours will create forgetfulness in the learners' souls, because they will not use their memories; they will trust to the external written characters and not remember of themselves. The specific which you have discovered is an aid not to memory, but to reminiscence, and you give your disciples not truth, but only the semblance of truth; they will be hearers of many things and will have learned nothing; they will appear to be omniscient and will generally know nothing; they will be tiresome company, having the show of wisdom without the reality."