My colleague who didn’t ask nor describe his changes now generates descriptions and code comments through AI and it doesn’t improve anything. It’s verbose, imprecise, confusing, and irritating.
I wonder if and how much communication reduced with my other colleagues. I guess probably a bit where they now ask AI (first). But not significantly, in my team, luckily. We still regularly talk. But maybe it’s on a path of reduction right now. I would find it sad and bad as well.
It really is a very visible demonstration of human faultiness.
A reasonable engineering approach would have been an interesting new technology with open discussion and assessment and expansion of exploration. Instead, we get hype cycles and hyperbole claims and lies primarily driven and publicized and repeated as market marketing and investor marketing and an industry driven by money and investment rather than technology and reasonably explorative and increasing usage.
It’s sad and tragic. But not surprising. It’s a consequence of human psyche, social constructs and market and society system structure.
When I hear my colleague does a presentation differently for internal towards developers with more reasonable AI takes and a different one for external which basically practically joins the AI hype instead of voicing boundaries, it’s pretty sad that it can’t be honest communication throughout and be understood as such.
I don’t see it as an isolated fault of “corporate leadership” as in of development factories/teams. It’s a broad issue, from the AI companies, press hype, industry hype, to then corporate and broader industry leadership eating it up and implementing and expecting marketing and hype claims.
What kind of criteria or tests are you imagining?
A certificate after a test would only show capability, not continued practice. So my confidence in it wouldn’t be very high. Demonstrated practice seems more applicable than some cert some time ago. Some people chase certs to check boxes rather than prove or apply the practice.
Where can I find your blog? ;)
I hope my drive-by PRs don’t come off in the same way.
For example, as the simplest no-description, no-comment example, when I see typos or wording errors in text on a random blog I check if there’s a direct way to contribute - to GitHub edit and submit a PR, and when there is, I do that.
There’s nothing for me to say or describe, really, and it’s not like I interacted with their project or community before or even plan to after. (Sometimes I do look into the issue tracker etc depending on the project or website. But that’s beside the raised concern.)
I see it more of a collective and open collaboration. But that’s not necessarily visible on the receiving end.
Their first comment provided reasoning. This “because that’s the way it is” framing is unfair.
The decision to use a non-deterministic system is a decision you can attribute risk and risk assessment to.
The non-deterministic nature and risk is something we should consider and take into account just like any other attribute and property of algos, tools, systems, libraries, etc.
I have a colleague where I get more confused when they explain things to me. I have others I can understand just fine, because their explanations make logical and structural sense.
Reasonable questions about surrounding context and environment and common understanding aside, having to do questions to “fix” bad communication and explanations sucks.
I think the title and this 30s framing sucks, but the other/later points they make are broadly good guidelines. A mindset of trying to understand context and environment surrounding the question or change at hand. It’s certainly necessary to maintain and improve long running projects.
As a software developer I’ve always been a product engineer as well. AI tools did not change that for me.
Coding, reviewing, and ops is certainly not gone nor disappearing fast for me.
So my main point is to stop asking whether and how code review in its current form can be saved, but to have an open conversation about what we are trying to achieve here and the costs and benefits of alternative models.
What would these other models be? The article assumes LLM-generated code leads to the loss of current review processes, which they call ‘modern reviews’.
I feel like my team does and will continue to do reviews for the same reasons and with the same gains as before. LLM may generate code, but I expect my colleagues to take ownership of whatever they produce, to understand it, take responsibility, and describe it. (Which is an issue/gap for some, but that was an issue even before generating code.)
Where is this quoting from?
00:00 Intro
00:48 Why write a compiler in JavaScript
07:29 Why rewrite the compiler in Go
14:49 LLMs for large migrations
20:12 Why Javascript is so popular
26:32 Why ever use Javascript on the backend
32:59 What it takes to build a programming language
37:06 Will there be fewer languages in 10 years
42:57 Hands on engineering vs delegation
49:14 Why fast tooling matters more now
51:16 AI software engineering predictions
58:52 The most technically challenging work
01:02:04 Top book recommendation
01:03:50 Advice for his younger self
01:05:00 Outro
Just summarizing the title teasers:
10x faster by switching from JavaScript to Golang. Rust was not feasible because it does not have a GC/does not support circular dependencies, and they have many of those, and did not want a rewrite but a minimal effort switch.
AI may produce a lot more code, but what code does “90% of code” refer to. AI is not capable of novel or complex stuff, you still need humans in the loop. Juniors remain significant to train them into seniors.
deleted by creator
I think I still have a tab open with/about Navidome somewhere up my long list of open tabs 😬
DDOS is most effective on expensive endpoints. A git clone isn’t exactly cheap. Fetching is especially expensive if you vary the revisions you fetch.
Does GitHub have an alternative here? A Git-compatible protocol with anonymous access that is DDoS-resilient?
Does all of that access really need to be anonymous access? I get that it’s convenient. But let’s be practical; they have to manage anonymous bot spam somehow.
Our aim is to make public repositories accessible without authentication as much as possible. However, like much of the Internet, we continue to see significant increases in the volume of robot traffic recently which has increased the need for verification, for example CAPTCHAs.
As I expected, it’s about combating (excessive) bot traffic.
“If you submit a PR, no hard feelings, we’re just going to go and represent it for you as issues and discussions.
They’re saying, “We’re not feeling negatively, but we’re closing your PR to turn it into an issue and discussion”. I wonder if the one on the receiving end will have hard feelings.
This metadata is only for media streams, not something that would be embedded as metadata in a file?