TomasBM

For starters, I'd love to see someone with hiring or legislative power tackle the subject of displacement without being dismissive.

For example, anyone who dedicated a bit of brainpower could understand that prompt engineering was bullshit from the beginning. Yet today we're still seeing it being rehashed as an alternative to knowledge work in the form of harnessing, guardrailing or context engineering. This is scaleable neither size-wise (how many different wrapper-builders do you really need?) nor time-wise (how long until model providers vertically integrate that, too?).

The reactions that we see today - the calls to ban AI or implement UBI, or even the race to escape the "permanent underclass" - are some symptoms of this lack of direction, IMO.

Personally, I'd like to see:

- Automation tax in line with displacement, which is then directly funneled to services and fund pools that mitigate the effects of displacement. If you want to reduce the winner-takes-all outcome, you should provide the capital to many more to own the automation tech, robots, whatever.

- Firing moratoria as an industrial policy tool. IIRC, the Chinese implemented something of this sort: you can automate, but you have to retain a certain amount of jobs. Obviously, it's a transitional solution.

- Aggressive expansion of software- and model-auditing & engineering jobs and education. If this is the direction, more people should be able to understand the systems in detail, not fewer.

You're not alone. I was never attached to coding by hand much, but I also don't understand the laid-back attitude of some people in this profession.

Sure, we can develop familiarity with tools and build cool stuff, but this is no different than knowing how to configure your washing machine (IMO). You could, of course, build a software-equivalent to a laundromat or a professional laundry service, but how many of those are needed?

Don't get me wrong: I think automation is cool and all, in washing and software development both. But if the profession of me and much of the labor force depended on handwashing skills, I'd love to see the displacement being taken more seriously.

That depends on the model and the toolkit it uses. In my experience from using Claude Code (Max, Opus 4.5+) intensely for the past six months, I maybe had 3 instances where the implementation broke functionally. And all of these breaking changes were resolved by Claude.

Obviously, this won't apply to every context: I work primarily with well-known langs (e.g., Python, JS), small to medium codebases (<500k LoC, for sure), and relatively few co-developers.

This is actually a good idea.

I mean, not sure if everyone wants that for their project, and there will surely be plenty of trade-offs.

But it would be a very good compromise: You (the maintainer) get only human-generated PRs in the canonical project, and they (pro-AI contributors) get a lower-threshold sandbox to play with. Best case scenario, you cherrypick the pre-filtered golden nuggets to bring back to the canonical project.

Isn't that what I'm already doing? I assume that the author believes that he's right often enough to argue his position(s), but feels dejected without being proven wrong at the end of the argument.

But there's another important point here: the answer to the "am I really right?" question isn't always clear at the start of every argument.

Unless you believe there's room for (dis)proving your position, or getting some nuance on a topic [1], it's not a debate or an argument - it's a lecture. And lectures depend on other social dynamics which don't apply here.

[1] For example, maybe there are other reasons behind the position that the person can't express easily, or maybe you're actually arguing about different things.

I like this - thanks for sharing!

Definite agree on having human-based redundant systems.

But I think the point the parent commenter made is: if there's not a functional difference in the result (i.e., job satisfies the definition of done), it doesn't matter if the AI generated the code or did the diagnosis.

But I think it's also fair to say that the process matters, even if the result is the same. If something exists for our benefit (e.g., there's no real alternative to learning-by-doing, and people need to know stuff for safety/security reasons), and we're fine with the trade-off, there's no reason to just give up the process to the AI.

Other than the obvious, self-reflective question that the author doesn't pose - "what if I'm the one who's wrong?" - I think it's worth arguing if the conditions are right.

Because I also like being correct, a debate to me has become something of a game where (ideally) we both win in both end scenarios: either my thinking was correct, and now I verified/validated it, and got you to think differently; or my thinking was incorrect, and you corrected it for me (or helped me get there).

However, I implicitly figured out that there are some qualifiers to actually getting the benefits:

- Can I be, and remain, polite and reflective? If not, my personality or knee-jerk responses will always get in the way of an argument's benefits.

- Is the subject sensitive to the person for whatever reason? If yes, any argument inadvertently becomes a signal of a person's worth.

- Are we in a competitive setting (e.g., corporate meeting, or larger social group)? If yes, any argument inadvertently becomes a social status competition.

- Do I know how to stick to the issue (instead of moving goalposts), and stop when the debate gets overwhelming (too long, too much difference)? If not, I'll overstep the boundary after which it isn't mutually beneficial anymore.

These are not easy to figure out, and sure, maybe stop arguing with most people if the conditions aren't right.

But unless you stop communicating altogether, I don't see how you can stop arguing with people in general.

Seems like this policy would apply pretty well regardless of who/what generated the code.

Well, unless you needed those million copies for whatever reason, that is an example of spam or denial-of-service, regardless of how it's generated.

And I'm not disagreeing - it is hard to anticipate what needs verifying, regardless if it's functional or non-functional.

But if it's not a spam submission, you could probably design tests or static/dynamic analysis tools that can verify those million copies much faster than manual reviews.

Good point. Even if you submit small, verifiable and readable changes, you can still overload the review process by submitting too many of them (e.g., 100s of PRs).

But I'd argue that some projects [1] could benefit from the speed (and sometimes, quality) of AI code generation without filtering by something that's difficult to identify (i.e., is it truly human-generated).

One way could be to constrain the size of each commit and PR, and invest more heavily into the review process (e.g., tests, static/dynamic analysis, sandbox deployments), so even if you get 100s of contributions, you can knock each out quickly.

Obviously, easier said than done. And at that point, you may as well use the AI to make the commits yourself, instead of relying on community contributions.

[1] Of course, this is only the case if the project's only purpose is to be a tool, and not also an educational reason for humans to learn how to code - in which case, it makes sense to invest more into identifying the "cheaters".

I think that's completely fair.

There are also plenty of valid personal reasons for refusing to generate code with AI - learning-by-doing and ownership of the result being the main ones, IMO.

> everybody wants to let AI do their work for them, but nobody wants to be downstream of AI work.

This is also true in my experience. But in my work, I found that I don't care how the code or comment was generated, as long as it doesn't try to overload my brain with irrelevant and obfuscated things, and as long as the person is not pretending that it's true, verified or their own creation (when it isn't).

If you have some requirements/specifications, and the piece of code fits them, then it runs.

Alternatively, if you have some vague idea [1] about what you expect to see/have, and the running code satisfies that idea, then it also runs.

Obviously, there are plenty of non-functional specs (e.g., security, cleanness, readability) that a code should probably fulfill before one finds it acceptable, but these are also not somehow impossible for state-of-the-art models to satisfy.

[1] Vibe, if you prefer, tho I dislike the term. Another related term is eyeball estimation.

Interesting initiative. What are the guiding reasons behind these lists?

I can't think of a functional reason for a no-AI policy: if it runs, it runs, regardless of who or what made it.

Also, even if you avoid AI-generated slop, you can't really avoid the human-generated or human+AI-generated slop that passes your filters.

Still, I can definitely think of good non-functional reasons: provenance, accountability, proof-of-work, encouraging people to write code themselves, empirically tracking how humans develop codebases, etc.