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.

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".

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.

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

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.”

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.

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.

AI is not all-powerful, but those things alone help me a lot when I'm brainstorming.

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.

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.

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.

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.

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.

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...

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.

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

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!)

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.

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.

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

Treat copilot to solve actual problems (y'know, the kind of stuff you are presumably paid to solve), and it falls completely flat.

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.

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.

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)

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'.

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.

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.

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.

[1]: https://www.sqlai.ai/

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

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.

LLMs give you plausible text. That does not mean it is logically coherent or says what it should.

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.

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.

Likely you’d get much better results with GPT-4.

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.

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.

I use a similar vscode assistant bit only for shorter code. I am able to complete code faster than an instructor on video.

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.

As programmers we should be focusing effort on reducing boilerplate, so that it’s never needed again. Instead, we’ve created a boilerplate generator.

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 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!).

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.

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.

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.

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.

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.

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.

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.

[0] https://news.ycombinator.com/item?id=39168841

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.

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.

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?

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.

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.

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...

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.

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,
      ...
    )

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.

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.

100%

And if you know what you are doing, they will accelerate the way you're building stuff.

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?

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.

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.

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.

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.

To first order :vimgrep is totally mechanical and brain-off repeat fix is super easy.

Also, not all maintenance involves correcting inborn defects.

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

Progress comes from human intellect, mediocrity comes from regurgitation.

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.

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.

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.

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...

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.

"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

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.