jongjong

He is fighting a losing battle. That's why nobody in the administration cared. Academic integrity already doesn't exist anymore. As Nassim Taleb would say; there are plenty of highly educated idiots with PhDs.

Even the idea that MIT is somehow better than some other universities is itself a fiction. People are conflating financial success with academic ability. The former is mostly the result of social connections which are formed within the academic institutions and have very little to do with actual capabilities.

Universities should just sell degrees for a high price without requiring the students to attend. If they're rich enough, their skills aren't going to matter anyway; they'll succeed in their careers regardless so the university will still look good. 'Academic integrity' will be intact. Especially true for business, economic degrees or other humanities.

I don't know which country this is but this sure seems like a country where doctors have an incentive to maximize the amount/cost of treatment.

I've seen the two extremes in different countries; either they have a tendency to maximize the complexity of the medical situation, or they minimize it "Don't worry, it's just stress" - I've been to different doctors in different countries and I see a pattern based on the country and the incentive structure. In some countries, they will send you off to do a scan for the slightest malaise.

I don't think it's about quality/coverage of public healthcare (at least not on its own; I have not seen a clear pattern across this axis). I think the difference is to do with the referral system. In countries where you can't go directly to a specialist and need a referral from a General Practitioner/Physician first (I.e. in order to get a refund), you tend to get more false negatives from the GP which block you from going to the next stage "It's nothing, just stress-related." In countries were you have the option to go directly to a specialist, they tend to be much more trigger-happy in terms of giving you a full workup and GPs/Physicians will more easily refer you to a specialist.

And I feel like the attitude extends to the specialists themselves. I suppose making people go to a GP first creates a kind of efficiency and predictability which alleviates pressure to exaggerate the severity of the situation.

I found a DoS vulnerability in Coinbase several months ago on Hacker One. It took me literally 30 minutes to find. First time I did this in my life. I could craft a message cheaply which, when sent as the HTTP payload to a specific endpoint, would cause the server to hang for a full 30 or so seconds before getting a response. I could have easily scaled up that attack, cheaply...

I filed a report, they marked it as 'informative' and thanked me, recommended I keep looking for more vulnerabilities, but no payment at all; they said I had to be able to demonstrate major disruption of service... Which I presume is illegal. I literally showed them all the ingredients of the attack, the exact curl commands, payloads, the exact response delay could be easily be verified; you could see the server response slowing down proportional to the degree of nesting in the payload. I could execute it without authentication too; so it was essentially certain that the attack could be scaled but they made it impossible to get a reward.

The hardest part was writing the report which took several hours.

So yeah, 30 minutes of looking for a vulnerability, no prior experience in security research, first project I looked into on Hacker One, ever... A company in crypto sector which is a major target of hackers and takes security relatively seriously.

Imagine how insecure most software is! Imagine how bad most vibe-coded software is especially! Companies might as well run their servers directly inside Kim Jong Un's data center in North Korea.

North Korean hackers probably have a dashboard which shows more detailed and accurate platform analytics than what the founders of the company can see.

This isn't going to work because the LLM doesn't have enough context. Many security issues involve a failure mode which cuts across multiple parts of the code. A PR which seems perfectly valid on its own may be the missing piece which opens up a vulnerability. Each component may be fine on its own, but brought together, the system is vulnerable.

Think of a machine with interlocking gears; each gear may itself be perfect and may fit perfectly with each other, but then if a tiny pebble comes between them, the entire machine breaks. Maybe the problem here is that the final gear was too close to the ground and would catch stray pebbles kicked up by the wheel in front of it... The LLM couldn't know this unless it understood the full context in which the change occurred; not only the code, but the environment itself.

In a poorly designed codebase with hundreds of thousands of lines of code, it's impossible to have the full context of the code even. The architecture would lack proper separation of concerns to allow one to effectively establish an appropriate defense perimeter. In a poorly designed codebase, every part of the code can harbor a vulnerability.

It's like; if you don't have a proper access control layer which is automatically and declaratively enforced for all your endpoints, every endpoint will have to enforce security restrictions on their own; duplicating similar-looking code over and over. If one endpoint out of 1000 incorrectly enforces a security restriction, that could be a critical vulnerability.

Reading the comments here, I'm struck by how many people seem to view code quality as an optional thing. It's almost as if software can function correctly without it. But it can't. Code quality is not a nice-to-have, it's a must-have. For any moderately-complex offering. There's a certain level of complexity that you can never reach without a well designed codebase. Cannot reach no matter how many humans or AI agents you throw at the problem.

The idea that it's a 'nice-to-have' is an illusion. It's like if you borrowed a lot of money to fund your startup and you still have some cash in the bank; at that point, a viable business model might seem like a 'nice to have'.

It's only when the lender comes knocking and you don't have enough money to pay them that a viable business model suddenly becomes a 'must-have'.

The worse designed the code, the more frequently it has to be re-factored. I've worked on long running projects which required essentially no refactoring when implementing new features and I've also worked on projects which had to be re-written multiple times to accommodate requirement changes.

And this code is often full of security vulnerabilities. It's just hacks on top of hacks on top of hacks. You end up with 100K lines of code full of weird fallbacks, doing something which could have been done more reliably with just 1K lines of code.

I think author's comment about preferring systems which make invalid edge cases impossible rather than implementing fallbacks is hugely important. With the fallback approach; you end up implementing fallback on top of fallback on top of fallback... Each fallback seems to increase the amount of code exponentially and somehow it always creates new problems. This should almost be a 'General law of system design.'

Fallbacks reduce the risk of failure but make failures more complicated and harmful when they do happen.

As a software engineer, like the new coding environment which is being created by AI.

Big tech companies have created infinite work for me. The human developer has become a critical component of code execution. The human needs to always be present to handle the nearly infinite number of difficult unhandled exception cases which are guaranteed to occur from time to time.

The software engineer is no longer like a laborer, but more like a security guard who sits at his desk drinking coffee most of the time and only steps in on rare occasions when something goes wrong.

One thing that I'm certain of, is that there are always costs to writing more lines than what is necessary to solve a specific problem.

I've experienced this before AI, and I've experienced this, magnified, with AI.

For a well-designed project written by hand, you will work faster writing the code for new features by hand than the same project written with AI from scratch, using AI to write the new features.

But... If you have a well designed, human-written codebase, you will be faster if you generate the code for new features using AI than if you do it by hand... And you can maintain that speed for long periods of time if you use fine-grained prompts. What matters most is the quality of the codebase.

You can achieve the same degree of maintainability using AI from the beginning but you would have to make fine-grained prompts.

The gap is about making good engineering decisions. It just so happens that the value of good decisions compounds over time.

I feel like what should have happened with AI is that teams should have started to put more effort into planning and pre-implementation discussions. Second thing, team leads should have felt more comfortable to reject large Pull Requests.

When I see a large 10k-lines PR, I feel a sense of panic. In a corporate setting, I also feel a kind of pressure to approve; the more work was done, the more pressure there is to approve the PR. This is why I think up-front pre-implementation discussion and alignment has become essential.

You really can't have people going rogue and weaponizing their AI-generated lines to gain control of a project through the duality of brittleness + complexity.

Brittleness + Complexity = Control

This reminds me of how the founders of the so-called 'open source' cryptocurrency project I joined suppressed my work in the community.

They monopolize opportunities, suppressing natural-born entrepreneurs; force us into very narrow roles and fire us if we step out of line ever to slightly. Even when it is beneficial to them.

IMO, we should get rid of trademark laws. They didn't mind their LLMs ripping off people's copyrights. Why should anyone uphold trademarks?

If I work at Google and want to represent myself as Google, I should be able to.

I feel like, even if I don't work at Google, I should be able to use the logo. It's the consumer's mistake for inferring a relationship. I'm just showing a logo of a well known company and letting their dumbass jump to a conclusion.

I realise this but it's still incredible to think because that's about 22k applicants per company.

Even if that's just part of each company's total hiring pipeline, it's clear; something's wrong. I don't know how long this study has been running but 22k is a lot of people, even over a year. These companies are too big. That's the problem.

The current situation reminds me of how far we've come from old ideals of delaying gratification today in order to have more later.

It seems like this ideology has been corrupted into a short-sighted "Establish a monopoly position as soon as possible at all costs, don't worry about tomorrow."

It's ironic because monopolizing a sector by investing heavily and suppressing profits used to be a long term move but it seems to have become a short term move as investors are racing each other.

I think the discrimination aspect is downstream from this fact:

> We follow 3.4 million people who submit 4 million job applications to 1,700 job postings across 150 employers and 11 industry sectors. Each job application was assessed by an AI hiring tool built by a single third-party vendor.

3.4 million people applying to just 150 employers... Who are all using just 1 platform. WTF. This is where the discrimination is happening. Why the f do 3.4 million people feel forced to apply to just 150 employers and why the f do all these 150 employers feel forced to use just one platform. WTF.

I think part of the confusion is that the base isn't always clear. A lot of times, when first exposed to logs, we are shown only base 10 or base e so it's just written as the word log or ln... This omission obscures the meaning and versatility of the function. Log and ln are essentially presented as separate constructs. Which is retarded.

Personally I only remember being briefly exposed to log and ln in school. I don't recall doing any complex algebra with them. So when I started doing algebra with them at university, I had to kind of re-learn from scratch.

I asked Claude about the weird way I was taught logs and it said this, which I found interesting:

There's a broader pattern here that shows up all over maths: notation and procedures get taught as the primary object, with the meaning treated as optional enrichment that "advanced" students might appreciate later. For a lot of people it's backwards — the meaning is the cheap, load-bearing thing, and the procedures are what should be derived from it. Logs are maybe the most egregant case because the gap between "incomprehensible button" and "obvious once stated" is a single plain-English sentence.

It's crazy to think that if Elon Musk hadn't mentioned Schmidhuber, most people would have no idea.

It's nauseating how all the researchers who happened to work for big tech got tons of media coverage but Schmidhuber and his team were getting zero coverage yet they made massive contributions. I bet there are many others not mentioned.

Nobody even knows about Frank Rosenblatt. It's insane how distorted our perception of innovation is.

Even science has been corrupted. It makes one doubt every story we're told about who invented what.

I find my explanation simpler.

// The power to which I must raise 10 to get 100 is 2.

log10(100) = 2

// The power to which I must raise 10 to get 1000 is 3.

log10(1000) = 3

// The power to which I must raise 3 to get 27 is 3.

log3(27) = 3

Also it makes solving equations much more intuitive:

log3(x) = 4

^ This means; the power to which I must raise 3 to get x is 4. So it follows logically that if I raise 3 to the power of 4, I will get x. This makes it intuitive that this equation can be rewritten as:

x = 3 ^ 4

You don't even need to know the algebraic rule. I felt retarded when I figured this out. This was a rule I had memorized before. It's even dumber and easier to infer than the rule to compute derivatives. I wonder why teachers even bother to teach you all these rules when they could just explain the fundamentals to you.

It happened during college.

I had a weird relationship with Math growing up; I alternated between getting very high grades and terrible grades depending on the teacher. I didn't like all the notations and conventions of Math and the way it was taught, but I enjoyed it conceptually. It had ended badly in high school as I did poorly in advanced Math though I did quite well in all my other subjects so I got into a good Software Engineering degree at a top 50 university for engineering globally anyway.

But early in college, it occurred to me that I didn't understand Math concepts as intuitively as I understood programming concepts so I challenged myself to revisit everything from the beginning including numbers, addition, subtraction, fractions, roots, powers, probabilities, derivatives, integrals, vectors, matrices, calculus...

I had to free myself from thinking of Math as symbols on a piece of paper and think of it as being about actual quantities, transformations and combinations. I needed a completely new way to think about it and visualize every single step. When I was practicing calculus, I would stop at each step and try to visualize the equation. For example, when finding the 3D plane perpendicular to a point on a 3D curve, I would put effort into visualizing what happened to the equations across different dimensions at each step when I found the partial derivatives and combined them to get the 3D plane vectors.

My Math grades at university were quite good. I passed all the Math courses with ease and got several distinctions even.

I already feel like most established big company software projects are unmaintainable. With AI, it's going to be even more so.

Currently, even though a lot of software is unmaintainable in a general sense, there's usually some engineer somewhere you can go to who can fix any given part; there's somebody out there who understands what any given part does; or there's someone who could figure it out if given some time if a minor bug needs to be fixed. With AI, it's going to create a situation where there will be parts of the code which absolutely nobody in the world understands and AI agents won't know where to pull the context from to make sense of it either and there aren't enough attention heads to make sense of it. It won't be just unmaintainable, but absolutely unmaintainable; it will be physically impossible to fix a bug without introducing new ones.

That's a lot of ways to think about logarithms.

Logarithms are laughably simple once you've fully internalized the meaning of the log function; it simply answers the question:

"To what power must I raise the base to get the argument?"

This is why the output tapers out as you increase the argument; because even if you increase the argument exponentially, you only need a fixed increment in the power to reach that number... So if you increase the argument only by a fixed amount (linearly) instead of exponentially, then it makes sense that the output will grow sub-linearly.

I remember when I was doing algebra with logs many years ago at school, I was applying rules to remove the log from one side of the equation.

Then when I got to uni, I had to revise the rules but it was kind of silly of me because those rules can be trivially derived if you just think about what the log function means. Turns out I had been solving equations with logs throughout school without understanding what they even meant... It's only at university that I actually bothered to learn them.

Actually TBH. I didn't even fully understand powers for some time even though I was doing calculus with them at school. I only fully understood powers once I properly internalized the concept of k-ary trees as a proxy.

It's one thing to be able to apply something, another to understand it. And I think to innovate with something, as a tool, it's not enough to be able to apply it. You must understand it.

Also, I prefer having all the code inside a single 5000-lines file than split up into many small files representing incorrect abstractions.

The urge to split the code up since they beginning is generally a bad idea; it forces early abstraction; more likely to be wrong.

This seems more like a reflection of existing tech power structures and social dynamics rather than innovation.

The bottleneck to being a unicorn isn't so much innovation as it is access to capital. The chasm between the two seems to keep growing. Soon enough, they will be totally independent.

If current trends continue, I predict that in 5 years, for every unicorn startup, there will be many bootstrapped startups valued at peanuts providing far superior products for far lower costs. But they won't be able to access either capital or user traffic.

Sure that can happen. Could be a long-running feature branch whose functionality is relatively isolated from other parts of the code. Could represent a lot of actual functionality.

But in most situations when I see a PR over a few thousand lines to an existing codebase that's highly depended upon, my stress levels tend to spike. On particularly complex projects and critical component, I'd read every single line.

Some modules I worked on, I would barely trust myself adding 100 lines to it because of how many other developers' code is depending on it. Sometimes they may be using it in ways which were not officially supported but I don't want to break backwards compatibility anyway.

So on such module, I would panic if I saw even a 1k line commit from somebody else.

15k lines is a lot. Each line comes with a probability that it introduces a bug. For a junior dev, the probability may be that 1% of lines introduce a bug... For a senior, it might be 0.1% per line and for the world's best coder, it might be 0.01%... But with 15k lines, and whatever the exact bug probabilities are, it's highly probable that the code contains at least one bug no matter who or what wrote the code.

There were some good insights in there. I like the idea of changing the hiring interview process to focus on testing code review ability. I feel like this would have been useful even before AI.

A candidate who can identify tradeoffs present in some code and make insightful comments is likely good at systems thinking. It's a highly effective way to test someone's knowledge, intelligence and taste.

It's actually brilliant because it provides the company with a way to actually improve their engineering posture since the company could land on a candidate who is more skilled than the engineers doing the interviewing. Many times in my career, I met engineers who seemed mediocre at first because they didn't know a fraction of what I knew, but I later found out they also knew a fair amount that I didn't know.

I've even had an extreme experience in the past year where a colleague seemed to struggle with basic code constructs and for the first month I was thinking to myself "this guy doesn't know how to code". He asked really basic questions and said he didn't know because his background was Python and not Typescript... But I know both of these languages and I just couldn't make sense of this explanation given the kinds of questions he asked and mistakes he made. If I had been asked to review him at the time, I would probably have given him a pretty bad review but after about 1 month and a half, this guy accelerated and literally became the most productive engineer on the team. No leetcode coding test could have predicted this.

Most leetcode tech interviews are a series of puzzles which most company insiders can solve but they never include problems that the candidate could solve but which the interviewer could not.

Leetcode interviews are horrible because they test a tiny subset of moderately difficult questions under time constraints and ignore a much larger set of problems that are much more complex. There is an incorrect assumption that someone who can solve extremely complex problems can also solve moderately complex problems under time constraints. This is absolutely not the case. It's almost mutually exclusive in fact since people who work on complex problems don't have the time or interest to practice solving simpler problems so they can never solve those fast enough to compete with fresh university grads who have been practicing those for years and don't know anything else.

On a different topic, I was sceptical of this comment:

"I honestly think you can have a fifteen thousand line PR and say, I need a human to review these three lines."

15k lines is a lot of code. I could destroy any software project, irreparably with 15k lines of code and not one engineer out of hundreds would recognize it unless they read carefully. You can absolutely destroy a codebase with 15k lines of code, without any obvious backdoors or malicious code. How would I do it? I would invent counter-productive abstractions and write a lot of unit tests for them to lock down the design... Then I would watch other engineers build on top to further lock it down... Let the flawed design accumulate debt for a few years until the entire codebase becomes slow, insecure and totally unmaintable. Nobody would ever remember that I'm the one who set the project on a bad course. Nobody ever suspects the person who invents the complex abstractions and who everyone comes to with questions... Also most engineers are afraid to ask why we need a SocketContextManager or a TaskContextSwitcherMediator or the TaskOrchestrator and TaskOrchestratorFactory that comes with it... Nobody will ask why we need 10 different Helm charts to split things up into microservices... Nobody will ask why we need 1000 top level dependencies with a total of 10k nested dependencies. Nobody will question those decisions because they're afraid they will look dumb for questioning complexity.

You cannot question system complexity without acknowledging that you find something to be complex... And this can be turned against you; "Oh so this is too complex for you?"

So my view is that every single one of these 15k lines needs thorough analysis. Each of those 15k lines represent the branches from which the next generation of twigs will sprout. If that branch isn't pointing in the right direction, better just cut it off as soon as possible before it becomes a central part of the codebase.

True. I'm French native but my English is better (educated in Australia) so this created a weird situation for me where I got 14/20 for advanced words and 19/20 for expert words.

To be fair, I think I messed up a few advanced words by accident but I think the general pattern would hold because many of the expert level words seemed to have French root. So it felt like it got easier towards the end for me. Grandmaster words were a bit weirder on the whole.

I'm an engineer and read mostly non-fiction so this probably explains the gap too.

I'm in Australia and I have view on a mountain so I see too many trees to count. Proximity to a forest was top priority for me and my wife.

Having lived in Europe for many years before, this is something that's most striking about Australia. I live in a state with one of the highest population densities and yet it still feels very sparsely populated relatively speaking.

This is how I used to see it. It made my work feel special just knowing that other people would use it and appreciate it.

I think because I felt a stronger sense that other people were my kin.

Now I feel like I don't belong, I feel that I am different and I don't know how to interpret other people's appreciation because they probably don't feel it the way I do when I appreciate something. I feel more exploited than appreciated.

Part of me is wondering if some people who used my open source projects thought to themselves "What a sucker... Working for free so I can monetize his work." And getting some kick out of that. There's a fundamental difference of values there. It didn't occur to me that this is the lens through which a lot of people view the world.

I don't believe in that definition of altruism.

To me, true altruism is selfish. If helping people makes you feel good, then you're an altruist.

If helping others doesn't make you feel good innately but you do it all for others then I think there is some self-deception at play. Maybe it's a status or self-image thing? Because being an altruist is higher status and you want to see yourself as high status? I think you can always trace it back to a selfish motive at some level.

Denying the selfish root of altruism can lead to hypocrisy because there is a dissonance between who the individual really is in their natural state and who they want to believe themselves to be. They have to constantly work to be who they aspire to be; it's not second nature to them and they will frequently fall short whenever it slips their mind or when they occasionally give in to natural impulses. Good on them for trying I guess. Better than not trying at all. But they're not an altruist.

I believe Richard Dawkins' "The Selfish Gene" backs me up on this point. Altruism is a either a kin-selection process or a reciprocal (transactional) process.

You're right. I have certain values and I'm OK if others expect certain values from me. To me this is ideal. Friendships should not be based on superficial things like money or social status to the point that you have to constantly change yourself over time to maintain alignment.

If you pay attention, you will notice that this is how the vast majority of people operate.

To me, that's transactional. Having fixed core values and expecting other people to share certain core values is not transactional, it's genuine. These are the kinds of relationships which don't require constant maintenance; you can not talk with the person for years and then resume the friendship like no time has passed, no matter how your situations have changed. If you can change your values based on the latest social trends, then you have no values. The friendship is held together by mutual material benefits; that's transactional.

I have no genuine interest in being friends with people who don't have core values. Because then I'd know I'm only in it for the money, and that's a lot of work and stress for me. Maybe second nature to some people. But I'm no good actor. To me it's work.

My view of humanity is most people are actors and most people lie to themselves constantly.

Leaving a trace is something I've been grappling with which seemed incredibly straight forward initially as an open source developer.

These days, I find myself questioning for whom am I leaving a trace for? What kinds of humans or entities? Do I care about the kinds of entities who will inhabit the future? Or will their value system be so different to my own that I'd prefer not to have anything to do with them.

Beyond human nature itself, I take issue with the trend of how human nature seems to be changing over time; for the worse.

If they had kept their distance, they probably wouldn't exist today. The dependency on government has been critical for any tech company. They'd have been replaced by a different company that is willing to cater to the government's every whim.

That said, the founders of these companies could have lobbied the government to ban corporate lobbying.

It's like; if there's gov money on the table, then it'd be a mistake to let your competitor take it. However, if you ensure that government money is never on the table for anyone, then that's one less thing for everyone to have to compete over and throw money at. Everyone can save their money for other things.

The government should never have allowed political lobbying to become a competitive market.

Also, political campaigns should not be allowed to raise private funds. That is insane. The government should fund all candidates' campaigns and allocate equal funding. Candidates shouldn't be allowed to spend their own money on their own campaign either IMO.