In the US, it seems corruption is only allowed at the top. If you tried to bribe your way out of a traffic ticket as a regular person, you'd get in big trouble, then meanwhile the president pardons wealthy fraudsters [1].

Meanwhile, in countries like Russia, everyone can get in on the action. A colleague of mine told me if he were to get drafted to the war, he knew exactly how much to pay and who to pay off locally to get his name off the list. It's equal opportunity corruption.

[1] - https://techcrunch.com/2025/03/28/nikola-founder-trevor-milt...

I added a Claude skill (/gather-history) that consolidates the history of our session(s) specific to the change into a series of: decision log, involvement (how much did I write vs. AI, how many refinement iterations, reviews, etc.) that I can then include in the PR. So far this has been helpful for my colleagues to understand how I arrived at the change and how thoroughly it's been developed.

There are some opinions that using LLMs to write code is just a new high level language we are dealing in as engineers. However, this leads to a disconnect come code-review time, in that the reviewed code is an artifact of the process that created it. If we are now expressing ourselves via natural language, (prompting, planning, writing, as the new "programming language"), but only putting the generated artifact (the actual code) up for review, how do we review it completely?

I struggle with what feels like a missing piece these days of lacking the context around how the change was produced, the plans, the prompting, to understand how an engineer came to this specific code change as a result. Did they one-shot this? did they still spend hours prompting/iterating/etc.? something in-between?

The summary in the PR often says what the change is, but doesn't contain the full dialog or how we arrived at this specific change (tradeoffs, alternatives, etc.)

How do you review PRs in your organization given this? Any rules/automation/etc. you institute?

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

Points: 8

# Comments: 9

The idea that Claude/Cursor are the new high level programming language for us to work in introduces the problem that we're not actually committing code in this "natural language", we're committing the "compiled" output of our prompting. Which leaves us reviewing the "compiled code" without seeing the inputs (eg: the plan, prompt history, rules, etc.)

In the pre-gen-AI days, if an engineer put up a PR, it implied (somewhat) they wrote their code, reviewed it implicitly as they wrote it, and made choices (ie: why is this the best approach).

If Claude is just the new high level programming language, in terms of prompting in natural language, the challenge is that we're not reviewing the natural language, we're reviewing the machine code without knowing what the inputs were. I'm not sure of a solution to this, but something along the lines of knowing the history of the prompting that ultimately led to the PR, the time/tokens involved, etc. may inform the "quality" or "effort" spent in producing the PR. A one-shotted feature vs. a multi-iteration feature may produce the same lines of code and general shape, but one is likely to be higher "quality" in terms of minimal defects.

Along the same lines, when I review some gen-AI produced PR, it feels like I'm reading assembly and having to reverse how we got here. It may be code that runs and is perfectly fine, but I can't tell what the higher level inputs were that produced it, and if they were sufficient.

Google Glasses - dead

Apple Vision Pro - dead

FB/Meta x RayBan - dead soon(?)

It seems they can’t get over the social hurdle of having a camera strapped to your face, and the effects of that on people around you. I think the tech is neat, but not socially accepted as a concept to make it viable. My sister is big into tiktok and filming all the time, and it personally makes me hesitant to be nearby as I’m not comfortable being filmed all the time.

I've been in big tech for 12+ years now. The first handful of years are definitely a grind to earn your spot, get a couple promos. After that though, it can become quite a bit easier to coast if that's what you're looking for. People know you, know you're probably valuable cause you're "senior" or "staff" and still here, and likely leave you alone. But yeah, as a newer engineer these days, it still requires the initial commitment to earn the privilege of coasting in a big tech company.

Over the years, I learned that a lot of one's value as an engineer can come from knowing how things actually work. I've been in many meetings with very senior engineers postulating how something works arguing back and forth, when quietly one engineer taps away on their laptop, then spins it around to say "no, this is the code here, this is how it actually works".

not trying to argue, just curious.

I think the SEA and SF tech scenes are hard to differentiate perfectly in a HN comment. However, I think any "Seattle hates AI" has to do more with the incessant pushing of AI into all the tech spaces.

It's being claimed as the next major evolution of computing, while also being cited as reasons for layoffs. Sounds like a positive for some (rich people) and a negative for many other people.

It's being forced into new features of existing products, while adoption of said features is low. This feels like cult-like behavior where you must be in favor of AI in your products, or else you're considered a luddite.

I think the confusing thing to me is that things which are successful don't typically need to be touted so aggressively. I'm on the younger side and generally positive to developments in tech, but the spending and the CEO group-think around "AI all the things" doesn't sit well as being aligned with a naturally successful development. Also, maybe I'm just burned out on ads in podcasts for "is your workforce using Agentic AI to optimize ..."

- Deviation in consistency/texture/color/etc.

- Obvious signs related to the above (eg: diarrhea, dehydration, blood in stool).

Ultimately though, you can get the same results by just looking down yourself and being curious if things look off...

tldr: this feels like literal internet-of-shit IoT stuff.

My most recent role the entire company of ~200 was remote, and so there was rarely the expectation of immediacy in a response. If something was truly urgent you'd be paged.

During my day I try to minimize interruptions by batching them. I will largely ignore Slack, and as notifications come in I glance and determine quickly if it really is urgent or if it can wait. If it can wait, I will punt all of those messages to a "remind me later" of a few hours, and get back to my task. I think this keeps my "recovery time" small as I'm not looking too close at these messages. It's not perfect, but definitely helps over pausing my "real work" to fully dive into each notification or ask.

Meanwhile ungodly amounts of money are being used so some boomer can generate a AI video of a baby riding a puppy.

Overall, I think this kind of thing is very positive for the health of building software, and morale to show that it is a priority to actually address these things.