buu700

The insinuation that I "want it to be true" is silly. Why would I want cancel culture to exist? I'd prefer that it not. I'd be thrilled if everyone were nice to each other, social media were a thriving hub of only productive good faith discourse, and reddit mods had no interest in censoring everyone and everything they personally disagree with.

It sounds like you find cancel culture inconvenient to acknowledge, for whatever reason, and want to project that cognitive dissonance onto others.

No, we don't all know that. There's a whole Wikipedia article on the subject: https://en.wikipedia.org/wiki/Cancel_culture. Denying its existence is just a lazy rhetorical tactic to deflect criticism of antisocial behavior and censorship.

> stating a fact is not what "virtue signalling" means and I wish people would bother to learn what words meant before they repeated them

Non sequitur. The factuality of cancel culture's non-existence is immaterial here. If a piece of writing includes a tangent that serves no other purpose than to signal to a subset of the audience that the author is "one of them", that's virtue signaling.

It would be equally illiberal to mandate that everyone do drugs or be polygamous. The illiberality is the imposition itself, not the quality of the imposition.

I don't do drugs or want other people to do drugs, but still don't think it's my or the government's business if people do so. That's a textbook liberal position on the issue.

I suspect that what such a person finds offensive isn't OOP's behavior (i.e. receiving a hair treatment without incident), but rather the thought in and of itself. Since they know that they can't credibly assault a person's character purely on the basis of an involuntary or intrusive thought, they have to settle for calling out some behavior as a stand-in for the thought. In an alternate timeline where OOP had apologized (which would really just be extremely socially awkward, not outwardly harmful), I'd bet on the former friend making the exact opposite stink and chastising OOP for failing to keep it to herself.

Another layer that wouldn't be surprising in this instance would be subconscious homophobia. The friend thinks she's upset at OOP for "victimizing" two poor strangers without their knowledge, but in reality she's disturbed by the sudden realization that she herself may have been or may one day become the unknowing object of such thoughts. Since she can't say as much without implying that she's categorically uncomfortable being around queer women, she reached for any excuse to turn it around on OOP and make herself feel like the good guy.

> I think there's a meaningful difference between being a genuine liberal who wants to change how American society thinks about sex, and being a partisan who wants to use puritan callouts as a cudgel on your enemies

I mean, those aren't just meaningfully different; they're entirely at odds with each other. You can't have a liberal attitude toward sex and a puritanical attitude toward sex at the same time.

Either way, if the alternative is the code not getting written at all, or having to make other significant compromises, the very edge case risk of AI randomly exfiltrating your code can be an acceptable trade in many cases. Arguably it's a lower risk than it would be with an arbitrarily chosen overseas developer/agency.

But again, I would very much like to see the tools providing this themselves, because the average user probably isn't going to do it on their own.

1: https://youtu.be/ef_3Wj4T_ts

Related to that is the proposal for `stabilityDays`, which seems way more practical: https://github.com/npm/cli/issues/8570#issuecomment-33004136.... So rather than merely saying "I only want package versions more than N days old", you'd be adding the requirement that "...and also they should have gone at least N days without a subsequent patch release". e.g. if mylib@6.0.0 is released, only to be quickly followed by 6.0.1 and 6.0.2, you ideally wouldn't want to risk ever installing the probably-broken 6.0.0 or 6.0.1 based on luck of the draw; the better behavior would be to stick with the last 5.x release until 6.0.2 has aged past the threshold.

It's also not literally called "YOLO mode" universally. Cursor renamed it to "Auto-Run" a while back, although it does at least run in some sort of sandbox by default (no idea how it works offhand or whether it adds any meaningful security in practice).

Vendors should really be encouraging this and providing tooling to facilitate it. There should be flashing red warnings in any agentic IDE/CLI whenever the user wants to use YOLO mode without a remote agent runner configured, and they should ideally even automate the process of installing and setting up the agent runner VM to connect to.

My position is that where a developer might have historically said "ideally I'd do X, but given my current timeline and resource constraints, doing Y with some new dependency Z would be the better short-term option", today that tradeoff would be influenced by the lower and decreasing cost of ideal solution X.

Maybe you understood my initial comment differently. If you are saying you disagree with that, then either you believe that X is never ideal — with X being any given solution to a problem that doesn't involve installing a new dependency — which is a black-and-white position; or you disagree that AI is ever capable of actually reducing the cost of X, in which case I can tell you from experience that you would be incorrect.

> If you ask AI to implement something that appears in its training data

This qualifier undermines everything that comes after. Based on what are you assuming that an exact implementation of X would always appear in the training data? It's a hypothetical unspecified widget; it could be anything.

> Maybe the situation is different in front-end land

Frontend definitely has more obvious examples of X. There are many scenarios where it wouldn't be that complicated to implement an isolated UI component that does exactly what you need without any clear vulnerabilities, where in the past it would have saved time to build on top of a third-party subset or variation of that UI even when it wasn't the optimal long-term solution.

It's not a frontend-specific comment, but maybe frontend better illustrates the principle. While backend examples might be more niche and system-specific, the same tradeoff logic applies there too; e.g. in areas like custom middleware or data processing utilities.

Ultimately, the crux of what I'm saying has nothing to do with what those X and Y scenarios are. Continuing to bring up scenarios where dependencies are useful is a non sequitur to my original comment, which was that AI gives us a lot more optionality on this front.

If a given project has time/budget to prioritize consistent rigorous documentation, of course it should consider doing so. AI's ability to reduce the cost of doing so is a good thing.

These days, lots of my commit messages are drafted by AI after having chatted at length about the requirements. If the commit message is wrong or incomplete, I'll revise it by hand or maybe guide the AI in the right direction. That tends to be a much more useful and comprehensive description of the commit's intent than what I would naturally find worthwhile to write on my own.

OP's approach is interesting as well, at least in principle, and if it works well it might be the next best option in the absence of a chat log. It should just make sure to focus on extracting the "why" more than describing the "what".

The idea of that is horrifying. I can't imagine voluntarily putting myself through that in the absence of some sort of extreme drought situation. Personally, I'd be miserable without 64 - 128oz of water first thing in the morning. I've long suspected that a lot of people who think they're addicted to caffeine are really just chronically dehydrated.

It's probably been a decade or so at this point since I've consumed caffeine with any regularity, but on the odd occasion that I do have a cup or two of coffee, I wouldn't say the effect is particularly remarkable. I guess it just affects everyone differently.

If what you need happens to be exactly what the library provides — nothing more, less, or different — then I see where you're coming from. The drawback is that the dependency itself remains a liability. With such an obscure library, you'll have fewer eyes watching for supply chain attacks.

The other issues are that 1) an obscure library is more likely to suddenly become unmaintained; and 2) someone on the team has to remember to include it in scope of internal code audits, since it may be receiving little or no other such attention.

> On the other hand, I would be shocked if I had ever used more than 5% of the standard library in the languages I work with regularly.

Hence "non-core". A robust stdlib or framework is in line with what I'm suggesting, not a counterexample. I'm not anti-dependency, just being practical.

My point is that AI gives developers more freedom to implement more optimal dependency management strategies, and that's a good thing.

> unlikely to be improved by that team replicating the parts of the library they need into their own codebase

At no point have I advised copying code from libraries instead of importing them.

If you can implement a UI component that does exactly what you want and looks exactly how you want it to look in 200 lines of JSX with no dependencies, and you can generate and review the code in less than five minutes, why would you prefer to install a sprawling UI framework with one component that does something kind of similar that you'll still need to heavily customize? The latter won't even save you upfront time anymore, and in exchange you're signing up for years of breaking changes and occasional regressions. That's the best case scenario; worst case scenario it's suddenly deprecated or abandoned and you're no longer getting security updates.

It seems like you're taking a very black-and-white view in favor of outsourcing to dependencies. As with everything, there are tradeoffs that should be weighed on a case-by-case basis.

* Introducing a library with two GitHub stars from an unknown developer

* Introducing a library that was last updated a decade ago

* Introducing a library with a list of aging unresolved CVEs

* Pulling in a million lines of code that you're reasonably confident you'll never have a use for 99% of

* Relying on an insufficiently stable API relative to the team's budget, which risks eventually becoming an obstacle to applying future security updates (if you're stuck on version 11.22.63 of a library with a current release of 20.2.5, you have a problem)

Each line of code included is a liability, regardless of whether that code is first-party or third-party. Each dependency in and of itself is also a liability and ongoing cost center.

Using AI doesn't magically make all first-party code insecure. Writing good code and following best practices around reviewing and testing is important regardless of whether you use AI. The point is that AI reduces the upfront cost of first-party code, thus diluting the incentive to make short-sighted dependency management choices.

Of course it's up to developers to weigh the tradeoffs and make reasonable choices, but now we have a lot more optionality. Reaching for a dependency no longer needs to be the default choice of a developer on a tight timeline/budget.

If what you're saying is that your current experience involves a lot of process and friction to get small changes approved, that seems like a reasonable use case for hand-coding. I still prefer to make changes by hand myself when they're small and specific enough that explaining the change in English would be more work than directly making the change.

Even then, if there's any incentive to help the organization move more quickly, and there's no policy against AI usage, I'd give it a shot during the pre-coding stages. It costs almost nothing to open up Cursor's "Ask" mode and bounce your ideas off of Gemini or have it investigate the root cause of a bug.

What I typically do is have Gemini perform a broad initial investigation and describe its findings and suggestions with a list of relevant files, then throw all that into a Grok chat for a deeper investigation. (Grok is really strong at analysis in general, but its superpower seems to be a willingness to churn on sufficiently complex problems for as long as 5+ minutes in order to find the right answer.) I'll often have a bunch of Cursor agents and Grok chats going in parallel — bouncing between different bug investigations, enhancement plans, and one or two code reviews and QA tests of actual changes. Most of the time that AI saves isn't the act of emitting characters in and of itself.

Maybe some future version of agentic tooling will decimate software engineering as a career path, but that's just another way of saying that everyone and their grandmother would suddenly have the ability to launch a tech startup. Having gone through fundraising in the past, I'd personally prefer to live in a world where anyone with a good idea could get access to the equivalent of a full dev team without raising a dime.

This is a bit of a reach. There's no reason to assume that the entire project would only be using one endpoint, or that AI would have any trouble coding against the REST API instead if instructed to. Using the official SDK is a safe default in the absence of a specific reason or instruction not to.

Either way, we're already past the point of demonstrating that AI is perfectly capable of writing correct pseudocode based on my description.

> Coding speed is very much not a bottleneck in Emacs.

Of course it is. No editor is going to make your mind and fingers fast enough to emit an arbitrarily large amount of useful code in 0 seconds, and any time you spend writing code is time you're not spending on other things. Working with AI can be a lot harder because the AI is doing the easy parts while you're multitasking on all the things it can't do, but in exchange you can be a lot more productive.

Of course you still need to have enough participation in the process to be able to maintain ownership of the task and be confident in what you're committing. If you don't have a holistic view of the project and just YOLO AI-generated code that you've never looked at into production, you're probably going to have a bad time, but I would say the same thing about intern-generated code.

> I’m more for less feature and better code.

Well that's part of the issue I'm raising. If you're at the point of pushing back on business requirements in the interest of code quality, that's just another way of saying that coding speed is a bottleneck. Using AI doesn't only help with rapidly pumping out more features; it's an extremely useful tool for fixing bugs at a faster pace.

    import { env } from './env';
    import { v4 as uuidv4 } from 'uuid';
    import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';
    import sharp from 'sharp';

    async function retry<T>(fn: () => Promise<T>, maxAttempts: number): Promise<T> {
      let attempt = 1;
      while (true) {
        try {
          return await fn();
        } catch (error) {
          if (attempt >= maxAttempts) {
            throw error;
          }
          const delayMs = Math.pow(2, attempt - 1) * 100;
          await new Promise((resolve) => setTimeout(resolve, delayMs));
          attempt++;
        }
      }
    }

    export async function processAndUploadImage(s3: S3Client, imageData: Uint8Array): Promise<string> {
      let metadata;
      try {
        metadata = await sharp(imageData).metadata();
      } catch {
        throw new Error('Invalid image');
      }

      if (metadata.format !== 'png') {
        throw new Error('Not a PNG image');
      }

      if (!metadata.width || !metadata.height || metadata.width !== metadata.height || metadata.width < 100) {
        throw new Error('Image must have a 1:1 aspect ratio and resolution >= 100x100');
      }

      const resizedBuffer = await sharp(imageData).resize(100, 100).toBuffer();

      const key = `${uuidv4()}.png`;

      const command = new PutObjectCommand({
        Bucket: env.IMAGE_BUCKET,
        Key: key,
        Body: resizedBuffer,
        ContentType: 'image/png',
      });

      await retry(async () => {
        await s3.send(command);
      }, 100);

      return key;
    }

You still need reference information of some sort in order to use any API for the first time. Knowing common Node.js AWS SDK functions offhand might not be unusual, but that's just one example. I often review source code of libraries before using them as well, which isn't in any way contradictory with involving AI in the development process.

From my perspective, using AI is just like having a bunch of interns on speed at my beck and call 24/7 who don't mind being micromanaged. Maybe I'd prefer the end result of building the thing 100% solo if I had an infinite amount of time to do so, but given that time is scarce, vastly expanding the resources available to me in exchange for relinquishing some control over low-priority details is a fair trade. I'd rather deliver a better product with some quirks under the hood than let my (fast, but still human) coding speed be the bottleneck on what gets built. The AI may not write every last detail exactly the way I would, but neither do other humans.

Collaborating with AI also speeds this up a lot. For example, it's much faster to have the AI write a code snippet involving a dependency/API and manually verify the code's correctness for inclusion in the spec than it is to read though documentation and write the same code by hand.

The feat of implementing that function based on my description is well within the capabilities of AI. Grok did it in under 30 seconds, and I don't see any obvious mistakes at first glance: https://grok.com/share/c2hhcmQtMw_fa68bae1-3436-404b-bf9e-09....

The fact that you're able to confidently take what I wrote and stretch it into pseudocode with zero deviation from my intended meaning proves my point.

I can't directly compile that into instructions which will make a CPU do the thing, but for the purposes of describing that component of a system, it's at about the right level of abstraction to reasonably encode the expected behavior. Aside from choosing specific libraries/APIs, there's not much remaining depth to get into without bikeshedding; the solution space is sufficiently narrow that any conforming implementation will be functionally interchangeable.

AI is just laying bare that the hard part of building a system has always been the logic, not the code per se. Hypothetically, one can imagine that the average developer in the future might one day think of programming language syntax in the same way that an average web developer today thinks of assembly. As silly as this may sound today, maybe certain types of introductory courses or bootcamps would even stop teaching code, and focus more on concepts, prompt engineering, and developing/deploying with agentic tooling.

I don't know how much learning syntax really gatekeeps the field in practice, but it is something extra that needs to be learned, where in theory that same time could be spent learning some other aspect of programming. More significant is the hurdle of actually implementing syntax; turning requirements into code might be cognitively simple given sufficiently baked requirements, but it is at minimum time-consuming manual labor which not everyone is in a position to easily afford.