> In "The pre-release suffix indicates a version is a pre-release. Pre-release versions sort before the corresponding release versions. For example, v1.2.3-pre comes before v1.2.3.", Why do they mention the sorting part? Whats the relevance?

Claude said:

> Good question! It's because Go's version resolution relies heavily on sorting/ordering to decide which version to pick. For example when you do go get golang.org/x/tools@latest — what's "latest"? Go needs to sort all available versions and pick the highest one. If pre-releases sorted after release versions, then v1.2.3-pre could be considered "newer" than v1.2.3, and @latest might accidentally give you a pre-release when you didn't want one. By explicitly saying pre-releases sort before their release counterpart, Go guarantees that:

@latest won't accidentally resolve to a pre-release v1.2.3 is always considered "higher" than v1.2.3-pre Version ranges and minimum version selection behave predictably

It's basically setting expectations — "don't assume pre-releases are newer just because they have extra stuff in the version string."

---

I wasnt' sure so then I asked:

> is that how go get works really or?

Claude:

> Honestly, I oversimplified it a bit! @latest in Go specifically means the latest tagged release version — it explicitly excludes pre-releases by definition, not just because of sorting. The sorting relevance is more about Minimum Version Selection (MVS) — Go's algorithm for resolving dependencies. When multiple modules in your dependency graph require different versions of the same module, Go picks the minimum version that satisfies everyone. For that algorithm to work correctly, versions need a well-defined order. So the sorting mention is more about making sure the ordering is unambiguous and predictable for MVS, rather than specifically about @latest behavior. I shouldn't have used that as the example

Happens every single time. A bit tiring

Comments URL: https://news.ycombinator.com/item?id=47708728

Points: 2

# Comments: 0

Unless you don't review every generated line manually, and instead rely on, let's say, UI e2e testing, or perhaps unit testing (that the agents also wrote). I don't know, perhaps we are past the phase of "double check what agents write" and are now in the phase of "ship it. if it breaks, let agents fix it, no manual debugging needed!" ?

Outside of work, yeah, everything is fine and there's nothing but the pure pursue of knowledge and joy.

When things go south, no penalization is made. A simple "post-mortem" is written in confluence and people write "action items". So, yeah, no need for the manager to get the blame.

It's all very shitty, but it's always been like that.

Mentioning LLM usage as a distinction is like bragging about using a modern compiler instead of writing assembly. Yeah it's faster, but so is everyone else code... Besides, I wouldn't brag about being more productive with LLMS because it's a double edge sword: it's very easy to use them, and nobody is reviewing all the lines of code you are pushing to prod (really, when was the last time you reviewed a PR generated by AI that changed 20+ files and added/removed thousands of lines of code?), so you don't know what's the long game of your changes; they seem to work now but who knows how it will turn out later?

Not necessarily true. A company that operates 100% remotely in country X not necessarily can hire people from other countries (and let them work there). I work for a french company, 100% remote. The company doesn't have branches in other companies, and so everyone works within France. This is ideal, because the HQ is in Paris, and many people don't (want to) live in Paris. Having to go to the office 2-3 times per week, makes it impossible for my company to hire outside of Paris... which is idiotic

Like, why on earth would I spent hours reviewing your PR that you/Claude took 5 minutes to write? I couldn't care less if it improves (best case scenario) my open source codebase, I simply don't enjoy the imbalance.

We care way less now about leetcode-like interviews (we used to have them before, but not anymore)

Testing the candidate's ability to "steer" agents seems to be like testing their ability to know the Java API or to recite SOLID by heart.

> 2. How are you currently preventing these "prompt-only" developers from slipping through your own interview loops?

We don't ask anymore leetcode. We keep the usual systems design interview in which usage of AI is not needed (or at least we don't allow it because in this kind of interview we are more interested in seeing how the candidate thinks and so on)

We have a new stage in our job interview, though: generic Q/A about the fundamental of software engineering/computer science. Again, we don't care anymore how candidates produce code. We care about what they know, and what they don't know. What's the scope of their knowledge, and when do they need to rely on AI to come up with an answer. Silly (non-real) example: "Can you write a program that detects if another program halts?". The people we want are the ones who would say something about the Halting Problem but also perhaps be practical and perhaps ask more questions about such a program requirements.

You get the point: we look for people with a good breadth of knowledge, who can communicate well and know their shit. Whether they can use tool x or y (including LLMs), comes for granted for such people

What we can do is to approximate. Newton had a good approximation some time ago about gravitation (force equals a constant times two masses divided by distance squared. Super readable indeed) But nowadays there's a better one that doesn't look like Newton's theory (Einstein's field equations which look compact but nothing like Newton's). So, what if in a 1000 years we have yet a better approximation to gravity in the universe but it's encoded in millions of variables? (perhaps in the form of a neural network of some futuristic AI model?)

My point is: whatever we know about the universe now doesn't necessarily mean that it has "captured" the underlaying essence of the universe. We approximate. Approximations are useful and handy and will move humanity forward, but let's not forget that "approximations != truth"

If we ever discover the underlaying "truth" of the universe, we would look back and confidently say "Newton was wrong". But I don't think we will ever discover such a thing, thereore sure approximations are our "truth" but sometimes people forget.

But juniors don't (usually) have the knowledge to assess if what the AI has produced is ok or not. I agree that anybody (junior or senior) can produce something with AI, the key question is whether the same person has the skills to asses (e.g., to ask the right questions) that the produced output is what's needed. In my experience, junior + AI is just a waste of money (tokens) and a nightmare to take accountability for.

Also, ideally, no requirement of a smartphone to send-receive data (it's ok to need a smartphone for the initial setup of the watch, though). I know about Pebble, but it doesn't have wifi. I know about some Garmins with wifi but for the kind of apps I want to write, the communication between the watch and the server has to be mediated by a phone. Also, correct me if I'm wrong, I don't want to pay $100/year just to be able to use my custom app in apple watches. I usually don't trust Google either (e.g., they discontinue everything in a blink of an eye).

So, what are my options?

Comments URL: https://news.ycombinator.com/item?id=47105086

Points: 35

# Comments: 25

I understand what the author means, but I think that in any human-2-human interaction, we are all entitled to at least basic courtesy. For example, if you show courtesy by contributing to an open source project and following all the guidelines they have, I think it's fair to assume that courtesy will be shown in return. I know that may be difficult to achieve (e.g., a high volume of noise preventing project authors from giving courtesy to those who deserve it), but that doesn'tt mean we are entitled to nothing. And this has nothing to do with open source or software; it's just common sense when dealing with people.

But yeah, if you contribute something of very poor quality (you didn't give it the attention it needed, it's full of bugs, or shows no attention to detail; or these days, it's packed with AI-generated content that makes it 10x harder to digest, even if the intention is good), then perhaps you are not entitled to anything