They attempt to sell it at market-rate which, assuming the previous owner intentionally under-valued the house, would earn them money that they can use to continue the program.
What if they have a backlog of inventory that they can't sell at "market rate"? Are the taxpayers just supposed to take a loss because of this brilliant tax assessment scheme?
The idea is that the houses are being bought by the government because they were erroneously valued by the owner under market rate. That presumably gives them room to come down from "market rate" to actual market rate (the rate it sells at on the market).
The only way to end up with a loss is a coordinated attack by owners and potential buyers: to intentionally understate the value, and then to hold off ANYONE attempting to purchase before the market sale price is below the compelled price. So multiple rich people lose their houses in a naked gambit to bankrupt the government. I mean... I guess it could happen? But at that point, it's open class warfare.
That must be a small percentage of the Steam Deck userbase that's impacted by this as I have the OLED model and it does not flicker or cause _me_ eye strain, even when at the absurdly low brightness levels it can reach.
Isn't this what good commit messages are intended to address? If a person has gone so far as to allow an agent to write all their code, they're likely having it commit on their behalf too.
Writing a skill / set of rules around what makes a good commit message would encourage the LLM to record it's reasoning (however much we truly consider it to be "reasoning").
Personally, guiding junior teammates down the path away from purely "Writer of Code" to "Implementer of Functionality" has been working well for me.
If you get them involved in the design process, they feel heard. Feeling heard is one surefire way to have a person feel involved. Feeling involved fosters a sense of ownership and pride which in turn helps keep a person engaged.
Yeah I like that, there’s probably something to this full stack builder persona that could keep people motivated long term. So long as they feel ownership, seems like that’s a pretty good bet for long term engagement
I'm personally amazed that _Large_ OSS projects don't have the appropriate automation in place to prevent non-compiling or non-linter-passing submissions.
- Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
This might be my bias showing, but these are items I would consider table-stakes for a project of a certain size / level of popularity.
It feels like a lot of the "AI is shit at contributing" problems could be addressed in part by better automated checks and balances.
Those things cost resources, and now you're introducing a new attack vector: open up a bunch of shit PRs, burn a lot of cash for the target organization.
You're right. It doesn't solve for all scenarios and doesn't block malicious actors.
I do believe, however, that it would have a meaningful impact on the "drive-by" PRs that keep being used as examples; the thoughtless, throw-spaghetti-at-the-wall PRs that do not have malignant intent behind them.
Many large OSS projects would have the resources to eat that cost with Donors, Sponsors, and OSS hand-outs. That's why I clarified in my original post because I know this is not a general solution.
The problem is you can get the LLM to iterate until it compiles and lints and even passes LLM review, but will that actually improve the quality of the contribution or just produce more line noise to mechanistically meet criteria?
To large complex projects often the kernel of an idea is the core value of a contribution, and it can take a lot of iteration to figure out how to structure it. Token bashing until CI is green does nothing to ensure the best approach is selected.
> The problem is you can get the LLM to iterate until it compiles and lints and even passes LLM review
Worst of both worlds with this, if you're doing it in a github workflow. You wind up effectively paying for the testing/validation layer of someone else's irresponsible LLM use.
For sure, but that's not what I was referring to in my posts. I'm specifically referring to the callout that the contributions are so low quality they don't even pass linting or compile.
I could have been more explicit on that nuance, I suppose.
That's why you sandbox. You can mitigate most low-hanging DoS fruits by running your server side hooks in a per-tenant cgroup that limits CPU and memory usage. One tenant per public key for trusted contributors, and one general-purpose tenant shared by all new/unknown contributors.
Can't you prevent pushing from the client side with pre-commit hooks? I would expect a hook to fire on the developer's computer that prevents them from even committing/pushing (unless they nuke the hook in their local repo copy).
You have to manually install hooks in your local repository. They aren't propagated as part of the repo. Git has intentionally made hooks require a very explicit opt-in.
> Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
Git supports pre-receive hooks. But big multitenant forges like GitHub.com don't allow you to configure them because they're difficult to secure well. (Some of their commercial features are likely based on them, though.)
If you self-host a forge, though, you can configure arbitrary pre-receive hooks for it in order to do things like prevent pushes from succeeding if they contain verifiably working secrets, for example. You could extend that to do whatever you want (at your own risk).
At the end of the day, LLM slop PR spammers are essentially adversarial actors. Git hooks are ultimately a tool for good faith developers within a given community (your team, your company, your regular contributors) in maintaining good hygiene and avoiding lapses into preventable mistakes. That's true for all CI, too.
And the truth is, too, that it's super easy for an LLM agent to run a build and tests. Good faith contributors using LLMs will never open PRs that don't build not because they're willing to "go the extra mile" and do manual work, but because they give the slightest fuck and have any respect or consideration for the humans they're working with.
LLM spam presents a different problem than any of that stuff was meant to solve. It's a malicious act, and you're right that tooling that burns the defender's compute can't be a solution. :-\
One of my pet peeves with git (and systems both similar, and based on it) is that automated tests run after you've made the commit and push.
In my mind the commit (let alone the push to a publicly accesible server) should be done after, and only if, the automated tests are successfully executed. And there's no easy way to implement this, other than having a dirty branch that you discard after rebasing onto a more long lived one.
There are lots of reasons to commit when things are yet working. How else would you share code that you need help with?
The solution is gated merges. No merging to main unless ci passes.
Every org I have worked at bemoaned a flaky release process and refused e2e black box acceptance tests because "they are too slow." And every org I have worked at has realized they were wrong. We got appropriate gates that run in 5 minutes and an ops person is the only person who can force past any gate in case of emergency.
Guardrails like this only become more important with the accelerant that is ai.
You can use a pre-receive hook on a git server to reject pushes that fail compilation. Downside is that it requires admin access on git forges, so you're only able to do this if you self-host.
I mean even having linters and everything still creates a whole bunch of noise in their PR section, not to mention that a lot of the changes I make to stuff that's written by codex is not stuff that's caught by linters.
It's just bad/wrong/context lacking decisions and mental models it introduces, that if not carefull will just create a massive mess of a codebase. (I know, because I've tried, and had to deal with it)
And if someone vibecodes a PR and it works, why dont they just share the prompt so a repo owner could vibecode it themselves?
Don't disagree, but the "if you're doing it right" is a big asterisk for an open source project with people you have no idea what quality bar they're at.
And in my experience it's quite hard to figure that out by quickly looking at it.
Not to mention that contributions on github (almost?) never include the prompt chain anyway, so the status quo is even worse
Honestly, I think this is a stepping stone towards replacing industry CAD modeling tools.
AI _can_ work with 3D models already, but it's really bad at it. CAD requires an extra level of control and I think this is where I could see AI companies wanting to get a foot in the door.
e.g "Let's build an adapter between 2in BSP Male and 3/4in NPT Female threads with a third Hose Barb outlet with the following properties..."
Essentially yes. I'm not gonna pretend it's better or even equivalent but it's not terrible. If you want a car with incredible audio there's plenty of options, but some people don't care and just want the cheapest car possible and they'll listen to music through a bluetooth speaker during their commute.
reply