My friend works at a well-known tech company in San Francisco. He was reviewing his junior team member's pull request. When asked what a chunk of code did, the team member matter-of-factly replied "I don't know, chatgpt wrote that"
I wish my reports would use more AI tools for parts of our codebase that don't need a high bar of scrutiny, boilerplate at enterprise scale is a major source of friction and - tbh - burnout.
As a reviewer I'd push back, and say that I'll only be able to approve the review when the junior programmer can explain what it does and why it's correct. I wouldn't reject it solely because chatgpt made it, but if the checkin causes breakage it normally gets assigned back to the person who checked it in, and if that person has no clue we have a problem.
it's interesting to see the underlying anxiety among devs though I think there is a place in the back of their minds that knows the models will get better and better and someday could get to staff engineer level
Perhaps take intern's LLM code and have the LLM do the code review. Keep reviewing the code with the LLM until the intern gets it correct.
Can you imagine the fallout from this, though? Each and every line of code this junior has ever touched needs to be scrutinized to determine its provenance. The company now must assume the employee has been uploading confidential material to OpenAI too. This is an uncomfortable legal risk.
How could you trust the dev again after the dust is settled?
Also, it raises further concerns for me that this junior seems to be genuinely, honestly unaware that using ChatGPT to write code wouldn’t at least be frowned upon. That’s a frankly dangerous level of professional incompetence. (At least they didn’t try to hide it.)
Well now I’m wondering what the correct way would be to handle a junior doing this with ChatGPT, and what the correct way would be to handle similar kinds of mistakes such as copy-pasting GPL code into the proprietary code base, copy-pasting code from Stack Overflow, sharing snippets of company code online, and so on.
It's insulting that companies are paying people to cosplay as programmers.
Austen Allred is selling this as the future of programming. According to him, the days of writing code into an IDE are over.
i'm thinking like models get small enough, you fine tune them on your code, you add fuzzing, rewriting
it may not be bug free but could it become self healing with minimal / known natural language locations? or instead of x engineers one feeds the skeleton to chatgpt 20 or something and instead of giving you the result immediately it does it iteratively would still be cheaper than x devs
We can draw the line in many places.
I would take generated code that a rookie obtained from an llm and copied without understanding all of it, but that he has thoughtfully tested, over something he authored himself and submitted for review without enough checks.
(and honestly it's not like the past graduates were much better, but they didn't have chatgpt)
From the point of view of these sorts of developers they are being paid to make the tests go green or to make some button appear on a page that kindasorta does something in the vague direction of what was in the spec, and that's the end of their responsibility. Unused variables? Doesn't matter. Unreachable code blocks? Doesn't matter. Comments and naming that have nothing to do with the actual business case the code is supposed to be addressing? Doesn't matter.
I have spent a lot of time trying to mentor these sorts of devs and help them to understand why just doing the bare minimum isn't really a good investment in their own career not to mention it's disrespectful of their colleagues who now need to waste time puzzling through their nonsense and eventually (inevitably) fixing their bugs... Seems to get through about 20% of the time. Most of the rest of the time these folks just smile and nod and continue not caring, and companies can't afford the hassle of firing them, then you open LinkedIn years later and turns out somehow they've failed up to manager, architect or executive while you're still struggling along as a code peasant who happens to take pride in their work.
Sorry, got a little carried away. Anywho, the point is LLMs are just another tool for these folks. It's not new, it's just worse now because of the mixed messaging where executives are hyping the tech as a magical solution that will allow them to ship more features for less cost.
I asked one of the "AI" assistants to do a very specific algorithmic problem for me and it did. And included unit tests which just so happened to hit all the exact edge cases that you would need to test for with the algorithm.
The "AI assistant" very clearly regurgitated the code of somebody. I, however, couldn't find a particular example of that code no matter how hard I searched. It is extremely likely that the regurgitated code was not open source.
Who is liable if I incorporate that code into my product?
maybe I am just supremely lucky but while I have encountered people like (in the coding part) it is somewhat rare from my experience. These comments on HN always makes it seem like it's at least 30% of the people out there.
Not saying it's acceptable, but the first example is maybe worth a thoughtful discussion while the latter would make me lose hope.
I do agree that I feel much more productive with it LLMs though. Just being able to rubber duck my ideas with an AI and talk about code is extremely helpful, especially because I'm a solo dev/freelancer and don't usually have anyone else to do that with. And even though I don't typically use the code they give me, it's still helpful to see what the AI is thinking and explore that.
That's because they come across as result oriented, go getter kind of persons while the others will be seen as uptight individuals. Unfortunately, management for better or worse self selects the first kind.
LLMs are only going to make it worse. If you can write clean code in half a day and an LLM can generate a "working" sphagetti mess in few mins, management will prefer the mess. This will be the case for many organizations where software is just an additional supporting expense and not critical part of the main business.
One man's bug is another man's feature
On the other hand, I use d3.js for data visualization which has had a stable API for years, has likely hundreds of thousands of examples that are small contained in a single file, and has many blog posts, O'Reilly books, and tutorials. The LLMs create perfect data visualizations that are high quality. Any request to change one such as adding dynamic sliders or styling tooltips, for example, are done without errors or bugs. People who do data visualization likely will be the first to go. :(
I am concerned that new libraries will not gain traction because the LLMs haven't been trained to implement them. We will be able to implement all the popular libraries, languages, and techniques quickly, however, innovation might stall if we rely on these machines stuck in the past.
I've no idea whether in this case it directly copied someone else's work, but I don't think that it writing good unit tests is evidence that it did - that's it doing what it was built to do. And you searching and failing to find a source is weak evidence that it did not.
That doesn't make those places equivalent.
Copy / download some random piece of code, monkey around to change some values for your architecture and up we go. It works! We don't know how, we won't be able to debug it when the app goes down but that's not our problem.
And that's how you end up with bad examples or lack of exhaustive options in documentations, most tutorials being a rehash of some quickstart and people tell you "just use this helm chart or ansible recipe from some github repo to do what you want". What those things really install? Not documented. What can you configure? Check the code.
Coming from the dev world it feels like the infrastructure ecosystem still lives in a tribal knowledge model.
Get the fire lit with the explanation of where to get wood and how to light it in your condition so next time you don't need to consult you solution engine.
Also, the culture of don't care comes from somewhere, not ChatGPT
For them, this clearly sound like personal success.
There's also a lot of folks who view programming just as a stepping stone in the path to becoming well paid managers and couldn't care any less about all of the stuff the nerds speak about.
Kind of unfortunate, but oh well. I also remember helping out someone with their code back in my university days and none of it was indented, things that probably shouldn't be on the same line were and their answer was that they don't care in the slightest about how it works, they just want it to work. Same reasoning.
That's a fair point, but regardless of who wrote the code (or what tools were used) it should also probably be as clear as possible to everyone who reads it, because chances are that at some point that person will be elsewhere and some other person will have to take over.
We by default block any and all PRs that contain funky code: high cyclomatic complexity, unused variables, bad practise, overt bugs, known vulnerabilities, inconsistent style, insufficient test coverage, etc.
If that code is not pristine, it's not going in. A human dev will not even begin the review process until at least the static analysis light is green. Time is then spent mentoring the greens as to why we do this, why it's important, and how you can get your code to pass.
I do think some devs still use AI tools to write code, but I believe that the static analysis step will at least ensure some level of forced ownership over the code.
One the funnier reactions to "I got it from StackOverflow" is the followup question "From the question or the answers?"
If you just adds code, without understanding how it works, regardless of where it came from and potential licensing issues, then I question your view on programming. If I have a paint come in and paint my house and get paint all over the place, floors, windows, electrical socket but still get the walls the color I want, then I wouldn't consider that person a professional painter.
A free training program with a promise of a guaranteed high paying job at the end, where have I heard that before? Seems like their business model is probably to churn people through these sessions and then monetize whatever shitty chatbot app they build through the training.
I think what the junior did is a reason to fire them (then you can try again with better selection practices). Not because they use code from LLMs, but that they don't even try to understand what it is doing. This says a lot about their attitude to programming.
I can't wait to retire.
I like fully understanding my code and immediate toolchain, but my dev machine is kinda held together with duct tape it feels.
Wow. I am probably very lucky, but most of managers, and especially architects I know are actually also exceptional engineers. A kind of exception was a really nice, helpful and proactive guy who happened to just not be a great engineer. He was still very useful for being nice, helpful and proactive, and was being promoted for that. "Failing up" to management would actually make a lot of sense for him, unfortunately he really wanted to code though.
At this point in my career I rarely ever go to SO, and when I do it's because of some obscure thing that 7 other people came across and decided to post a question about. Or to look up "how to do the most basic shit in language I am not familiar with", but that role was taken over by LLMs.
Few decades down the road though we are likely to be viewing this current situation similar to how we're looking at 'human computers'[0] of yesteryear.
Reminds me of this: https://www.stilldrinking.org/programming-sucks
> people tell you "just use this helm chart or ansible recipe from some github repo to do what you want". What those things really install? Not documented. What can you configure? Check the code.
I mean, this is just wrong. Both Ansible roles and Helm charts have normalised documentations. Official Ansible modules include docs with all possible parameters, and concrete examples how they work together. Helm charts also come with a file which literally lists all possible options (values.yaml). And yes, checking the code is always a good idea when using third party code you don't trust. Which is it you're complaining about, that DevOps people don't understand the code they're running or that you have to read the code? It can't be both, surely.
> Coming from the dev world it feels like the infrastructure ecosystem still lives in a tribal knowledge model.
Rose tinted glasses, and bias. You seem to have worked only with good developer practices (or forgotten about the bad), and bad DevOps ones. Every developer fully understands React or the JS framework du jour they're using because it's cool? You've never seen some weird legacy code with no documentation?
Because that's the frustrating part; they're trivial issues, unreachable code and unused variables are harmless (on paper), just a maintenance burden and frustrating for whoever has to maintain it later on. But because they're trivial, the author doesn't care about them either. Trivial issues should be automatically fixed and / or checked by tooling, it shouldn't cost you (the reviewer) any headspace in the first place. And it shouldn't need explanation or convincing to solve either. Shouldn't, but here we are.
But yeah, the next decade will be interesting. I'm not really using it in my code yet because idk, the integration broke again or I keep forgetting it exists. But we integrated a tool in our gitlab that generates a code review, both summarzing the changes and highlighting the risks / issues if any. I don't like that, but the authors of merge requests aren't writing proper merge request descriptions either, so I suppose an AI generated executive summary is better than nothing.
But this is a fireable offense in my book.
These are young controls engineers at big companies. I won't say who, but many of you probably use one of their products to go to your own job.
I am not against using LLMs as a sort of rubber duck to bounce ideas off of or maybe get you thinking in a different directions for the sake of problem solving, but letting them do the work for you and not understanding how to check the validity of that work is maddeningly dangerous in some situations.
Not really. I'm mainly in code maintenance so good practices are usually those the team I join can add to old legacy projects. Right now trying to modernize a web of 10-20 old add-hoc apps. But good practices are known to exist and widely shared even between dev ecosystems.
For everything ops and devops it looks like there are like islands of knowledge which are not shared at all. At least when coming with a newbie point of view. Like for example with telemetry: people who worked at Google or Meta all rave about the mythical tools they got to use in-house and how they cannot find anything equivalent outside... and yes when you check what is available "outside" it looks less powerful and all those solutions feel like the same. So you got the FAANG islands of tools and way to do things, the big box commercial offering and their armies of consultants and then the OpenSource and Freemium way of doing telemetry.
Very strongly disagree, if anything it's the opposite. Many people read the knowledge shared by others and jump to thinking it's suitable for them as well. Microservices and Kubernetes got adopted by everyone and their grandpa because big tech uses them, without any consideration if its suitable or not for each org.
> At least when coming with a newbie point of view. Like for example with telemetry: people who worked at Google or Meta all rave about the mythical tools they got to use in-house and how they cannot find anything equivalent outside... and yes when you check what is available "outside" it looks less powerful and all those solutions feel like the same. So you got the FAANG islands of tools and way to do things, the big box commercial offering and their armies of consultants and then the OpenSource and Freemium way of doing telemetry.
The latter two are converging with OpenTelemetry and Prometheus and related projects. Both ways are well documented, and there are a number of projects and vendors providing alternatives and various options. People can pick what works best for them (and it could very well be open source but hosted for you, cf. Grafana Cloud). I'm not sure how that's related to "islands of knowledge"... observability in general is one of the most widely discussed topics in the space.
I think young people today are at severe risk of building up what I call learning debt. This is like technical debt (or indeed real financial debt). They're getting further and further, through university assignments and junior dev roles, without doing the learning that we previously needed to. That's certainly what I've seen. But, at some point, even LLMs won't cut it for the problem they're faced with and suddenly they'll need to do those years of learning all at once (i.e. the debt becomes due). Of course, that's not possible and they'll be screwed.
Move on to what?! Where does a junior programmer who doesn't understand what the code does moves on to?
I remember being a junior nearly 20 years back, a co-worker someone asked me how I'd implemented an invulnerability status, and I said something equally stupid despite knowing perfectly well how I'd implemented it and there not being any consumer grade AI more impressive than spam filters and Office's spelling and grammar checking.
Which may or may not be relevant to the example of your friend's coworker, but I do still wonder how much of my answers as a human are on auto-complete. It's certainly more than none, and not just from that anecdote… https://duckduckgo.com/?t=h_&q=enjoy+your+meal+thanks+you+to...
I've seen that, though fortunately only in one place. Duplicated entire files, including the parts to which I had added "TODO: deduplicate this function" comments, rather than change access specifiers from private to public and subclass.
By curious coincidence, 20% was also roughly the percentage of lines in the project which were, thanks to him, blank comments.
I’ve heard this sentiment several times over the years and what I think a lot of people don’t realize is that they’re just playing a different game than you. Their crappy code is a feature not a bug because they’re expending the energy on politics rather than coding. In corporations politics is a form a work, but it’s not work that many devs want to do. So people will say the uncaring dev is doing poor work, but really they’re just not seeing the real work being done.
I’m not saying this is right or wrong, it’s just an observation. Obviously this isn’t true for everyone who does a poor job, but if you see that person start climbing the ladder, that’s the reason.
To an extent. The failure modes are still weird, I've tried this kind of automation loop manually to see how good it is, and while it can as you say produce functional mediocre code*… it can also get stuck in stupid loops.
* I ran this until I got bored; it is mediocre code, but ChatGPT did keep improving the code as I wanted it to, right up to the point of boredom: https://github.com/BenWheatley/JSPaint
I usually learn it, by adapting it to my coding style, and documenting it. I seldom leave it untouched. I usually modify in one way or another, and I always add a HeaderDoc comment, linking to the SO answer.
So far, I have not been especially thrilled with the AI-generated code that I've encountered. I expect things to improve, rapidly, though.
> You are an expert in all these technologies, and that’s a good thing, because that expertise let you spend only six hours figuring out what went wrong, as opposed to losing your job.
see, everything around can be a tool. Sticks, screwdrivers, languages, books, phones, cars, houses, roads, software, knowledge, ..
in my rosy glasses this line stops at people (or maybe life-forms?). People are not tools. Should not be treated as such.
But that is not the case in reality. So anyone for whom other people are tools, will fail (or fall) upwards (or will be pulled there). Sooner or later.
sorry if somewhat dark..
Considering this was a sponsored link on HN, endorsed by Y Combinator, I'd say you have a ridiculous threshold for labeling something a "scam", except to the degree that the companies committing to hire these people are pretty unlikely to get whatever they were hoping to get.
If you change the programming language, the unit tests disappear and the "generated" code loses the nice abstractions. It's clearly regurgitating the Python code and "generating" the code for other languages.