When did HN become Reddit ? This is a real demographic shift I am seeing after a long time hiatus. The people who hate AI are largely those that lean far left and see themselves as liberal progressive.
I also see that and I'd say around Covid / past-Covid. More people became terminally online in those 6-12 months, like another eternal September.
Funnily you will always see some people waving the HN guidelines [1] flag: nooooo, don’t compare this site to Reddit. Yet there is another „rule” in the guidelines about politics being off-topic… which is the biggest symptom of HN turning into Reddit: General, especially US domestic, politics became excessively acceptable to be posted here. That wasn’t the case 10 years ago or more. Of course if you point that out then the „everything is politics” crowd will show up and the „should we close our eyes and ears to all the tragedies happening in the world”. Rinse and repeat.
That’s the problem with ambigous rules and to some extent why I still prefer Reddit. If you don’t like it you make a new sub, find another one etc. At least the bias is clearly known
perhaps for companies that are low balling compensation will not budge on leetcode and only those that see real uplifts from AI use will move away from it, testing more for holistic and experience based tests.
People forget skill is just a markdown file and I don't think TDD makes sense. It's more for specific niches like working on your custom codebase or some less beaten paths you take and save the lessons going forward
But everybody is free to choose how they work and it may be required in ways that we can't know about.
TDD sounds great on paper for agentic development but you quickly realize it balloons the token cost. Often I write some feature and then its repurposed or removed, code is refactored moved around as time goes. With TDD I would be taxed heavily and velocity slow to a crawl.
The waterfall approach is better after trying out TDD especially when you have a multi-agent setup. Also I found that in some cases the tests were just superficial hallucinations that never actually tested the components written or there some some context corruption and ultimately triggered a false positive that kicked off a completely unintentional refactoring.
My approach (with LLMs especially) aligns more with what's outlined in "Growing OO Software Guided by Tests" (https://growing-object-oriented-software.com/toc.html). Chapter 4 there says "First, Test a Walking Skeleton", and Chapter 5 has "Start Each Feature with an Acceptance Test". I think it comes down to: get something working end-to-end first in a verifiable way, and then keep refining both the feature and its tests (preferable with TDD).
I've noticed that LLMs tend to generate multiple testcases in one shot (which is not how humans usually go about TDD), and also they don't start with Integration Tests, unless instructed to do so.
Yeah I specifically tell it not to pre-emptively fix tests that it knows will break as a result of changes its making and instead limit itself only to creating new tests for new changes. I want to see the tests break, then we go through and review each set of breakages versus the mission and assess if they’re regressions or stale assertions. This is a) how I know it’s actually writing meaningful tests b) a very functional and useful form of “code review” versus just trying to catch problems by reading diffs and c) helped me find real problems and regressions.
Almost all the breakages after a big refactor are stale assertions but every time I catch a couple of critical problems that make the entire exercise very worth it.
The whole dev process is so fast compared to writing software manually that I find it absurd that I wouldn’t invest heavily in automated tests.
I was a big proponent of encoding TDD red-green-refactor methodology into my agent workflows until recently when I made the same realization after reading this study: https://arxiv.org/pdf/2602.07900
TLDR; it found test-writing volume only weakly correlates with success and that encoding test-writing principles did not move resolution rates but _did_ materially change cost. Encouraging tests cost +19.8% output tokens for 0% gain; discouraging them saved 33–49% input tokens for ≤2.6pp accuracy loss. Separately, imposing the TDD procedure specifically seems like it can backfire: it actually _increased_ regressions from 6.08% to 9.94%.
IMO, where tests clearly help is primarily as an "oracle" applied after generation. It gives the models a signal that enables them to verify and self-correct if necessary.
Very interesting paper and it lines up exactly with my observations. The ROI just isn't there writing tests up front and the conclusion in that paper lays it out clearly
Overall, these findings suggest that agent-written
tests often behave more like a habitual software-development rou-
tine than a dependable source of validation in this setting. More
agent-written tests do not mean more solves; what they more reli-
ably change is the process footprint—API calls, token usage, and
interaction patterns. Improving the value of testing for code agents
may therefore require better oracles and more actionable validation
signals, rather than simply inducing agents to write more tests.
> IMO, where tests clearly help is primarily as an "oracle" applied after generation
Bingo. I'm not against writing tests it's that the returns are better when its used as verification feedback and as "Oracle" exactly as you put it.
Just chiming in to say that I've seen the exact same that you have. Tests are better used to help validate that was was generated worked after the fact.
That, and even the absolute SOTA models still suck at writing tests.
Which shouldn't be surprising: humans suck at it too most of the time...
Absolutely, there's no reason to believe that agents will be more capable of writing tests than any other piece of code. The big pay off is actually verifying the code that was generated.
The paper focuses on two things: default behavior and behavior with a prompt to write at least one new test.
In general — just like with humans — I find "just add more tests" to be counter-productive.
Tests make sense in a testable architecture: TDD can encourage one to be implicitly used, but it is a design, architectural choice that should be made explicit (lean to functional code; use direct, explicit dependency injection; ensure test stubs are just variants of the real implementation and fully tested using the same test as the real one...). LLMs should be prompted with this guidance instead for proper value estimation.
you write a test, which is one extra function. and maybe a paragraph or so per feature ("i made a RED test"... "i made it GREEN"), everything else is the same between normal development and TDD. this is chump change compared to the rest of development, including thinking tokens
In what world or frame of reference would doing TDD have "little" bearing on output quality? If you build a system around satisfying some set of requirements it seems logical that output quality would have pretty heavy correlation.
It's possible to satisfy a set of requirements with code that's low quality. There's the maintainability of the code, for example, or the performance of the system.
They can't afford it because they have no customers, because they turn down small customers and then Stripe already has them when they become big enough for Adyen.
Well, it is signalling. It's signalling that there are competitors which are trustworthy enough for a government and it signals the overall trend one can observe how European governments detach from US companies. With some lower hanging fruit and some larger projects.
Most government processing is prohibited at Stripe that is why it always tends to be small. Too much risk being exposed to more regulatory scrutiny that is not worth it as payments processor.
> “Prohibited Businesses… Government services… Disbursement of government economic support, such as grant” [1]
[1]: https://stripe.com/en-br/legal/restricted-businesses
I had a repo with more than a dozen forks banned on GitHub for some unclear TOS violations. Ticket has been sitting for a week plus now, asking for clarification and guidance.
It's a running a fork (codeberg specific) of a fork of gitea called forgejo (https://codeberg.org/forgejo/forgejo) so it's not surprising. The people behind it were a bit miffed at Gitea doing some questionable commercial endeavors in their view and also not dog-fooding Gitea for Gitea.
I tried self hosting gitlab. I installed it and got miffed that it wouldn't let me change password complexity requirements for a user, so I left it but left it running for "maybe later".
Two weeks later it had spammed 50GB of logs to the disk and was idling at 11GB RAM. With zero repos and zero active users. I don't want a git interface to be full of bloat.
That's why I don't like it. I'm moving a client from gitlab to forgejo at the moment.
Gitlab's UI changes every now and then, for seemingly no reason. The UI is very full of stuff (hard to find your way around), and very slow. Notably in the past months, they've changed the issues/tickets board into a "work items" board which feels infinitely slower to load, has such a vague meaning that nobody can find it (especially when translated), and brings exactly 0 use to anyone i know. They just seem to be doing that with every feature and every part of the interface.
On the server side, gitlab was always very hard to selfhost with many moving parts, many requirements, and using much resources. gitlab-runner is not very explicit about things when you're not in the happy path (why is it not picking up jobs?).
I'm not even a minimalist. I've been running gitea/forgejo for the past 8 years or so and it's been a miracle in comparison: lightweight server, easy setup/upgrades, and super simpler UI/UX that everybody understands on the first try. Forgejo (gitea community fork) learns from everything that Github historically made good (UX) without any enshitiffication in sight (developed by a non-profit). I highly recommend it.
I was impacted. found weird spam repos that later were deployed on cloudflare redirecting my domains.
meanwhile the gitea running on my metalbox for nearly a decade has seen no compromise and 100% uptime when cloudflare has gone down repeatedly
im rethinking the whole "go where crowd is" , while great from evolutionary point of view, its the complete opposite. Where the crowd gathers online is the most dangerous place.
Linux is absolutely popular for servers. If you put a WordPress installation on the IPv4 address space, or any other kind of PHP you usually find a webshell has appeared after just a few minutes.
reply