- ticketing system with Stripe payments and QR scanning at the door
- Instagram/media ingestion for the club site
- genealogy tool with GEDCOM import
- scripts for downloading/archiving public-domain film material
- playlist/library tooling for DJ use
- music collaboration/sync tool for Ableton projects
- normal work stuff in a much larger existing codebase
I have become a lot more strict about process after being burned a few times. Mostly: make the change small, be clear about what it is supposed to do, check the assumptions before coding, use tests/logging/manual checks as evidence, and don’t merge anything I can’t review and explain myself.
I think the really dangerous part here is not just “surveillance bad”.
It is that AI removes the labour cost that used to limit surveillance.
CCTV was already a problem, but someone still had to watch it, search it, interpret it, escalate it. AI changes that. It makes surveillance searchable, scalable and administratively useful. The shift is from “you may be observed” to “your behaviour can be continuously machine-interpreted”.
That changes the moral shape of the state.
A democracy can have police, courts, borders, audits, fraud detection, and public order. I don’t think the serious argument is that no one should ever be watched. The question is asymmetry.
A free society cannot survive if ordinary citizens become more transparent to the state and its contractors than the state is to them.
The principle should be:
privacy for persons, transparency for power.
Police bodycams should make police accountable. Procurement should be inspectable. Algorithmic decisions should have audit trails. Whistleblowers and journalists should be protected. Public systems should be legible to the public.
What worries me is not only some cartoon version of Orwell. It is the boring version: safety dashboards, risk scores, fraud detection, productivity analytics, immigration enforcement, “trust and safety”, compliance automation, procurement contracts.
The boot does not always arrive as a boot. Sometimes it arrives as infrastructure.
And the hard question is not whether surveillance can create order. It obviously can. So can a prison.
The question is whether it creates accountable power afterwards.
A panopticon may produce “best behaviour”, but only by turning citizens into managed subjects. I have been trying to understand this fetish for controlling people through coercion that seems so prevalent in certain new modern business contexts, like amazon warehouse workers and delivery employees.
The only thing it creates is resentment. Is that how you want to build a company or society on. Resentment?
> Is that how you want to build a company or society on. Resentment?
I think this misunderstands their goals. They don't care how society/a company is built. All they care about is that they are the one building it and that they are at the top of the hierarchy.
Just like with the startups and tech companies they built, they see speed as a critical advantage so that they can be the first-mover and establish a moat. Long-term viability and health is a distant secondary or even tertiary concern. If the panopticon and some weirdly neofeudal technofacist society can be built faster than something more egalitarian, then that neofeudal technofacist society is - from their perspective - better and that is what they will bias towards and build.
The panopticon concept from Bentham was interesting because even if there was only a small chance that you might be observed, at any given time, then people would act as if they were being observed. Even if they weren't.
We have had that kind of system, now, for just about everything. Not just from the Big Brother direction, but also the Little Brother direction. At any time, a mob of people might decide to pull up your old digital footprint and condemn you for it.
Likewise, even before AI, at any time the IRS could decide to audit your past tax filings, or data breaches could expose your personal secrets, or street camera can nab you for a traffic violation, or someone could decide to pull up surveillance footage and get you for something, and so on.
The exact degree of difference between the two systems is significant, but much of the marginal psychological burden of such things has already been paid by everyone living in industrial civilization. And, as with the panopticon, just the small chances of active monitoring already provided 80% of the sought-after result.
Indeed, that kind of condition is what people like Ted Kaczynski were so bothered by decades ago.
Those living in the epicenters of civilization, like those in the largest cities, have basically been under almost constant surveillance now for decades.
This is not even a given. A panopticon tends to produce risk-aversion and metastasize Goodhart's Law. People do what they think they're expected to do and interpret vague rules in the most conservative way even if it's absurd/inefficient/immoral, or follow poorly drafted rules to the letter. There is a reason "work to rule" is a manner of labor strike.
> I have been trying to understand this fetish for controlling people through coercion that seems so prevalent in certain new modern business contexts, like amazon warehouse workers and delivery employees.
This tends to happen in rote unskilled jobs because they have to process however many packages per unit time and if workers spend 90% of each hour processing packages instead of 99.9% then they need 11 workers instead of 10. Even there it often doesn't work; results in high turnover or having to pay more to retain workers.
For the vast majority of jobs it doesn't even come close to working because the job isn't simplistic and uniform enough to have everything mapped out in advance. But some people have enough hubris to think they can run the bottom from the top.
1. Boring Orwell: Continuous surveillance is already present in the form of cameras in streets, shops, schools, cars, buses, homes, etc. AI can and absolutely will be used to continuously monitor these feeds.
I'm afraid it won’t help as much as we’d like. The algorithm might consider thousands of parameters all of which have scientifically been shown to correlate with some outcome.
A famous example is a denied credit application where one parameter is the battery level of your mobile.
A trail won’t help you decipher why the algorithm decided a particular action.
If an algorithm can't be explained that way, I propose that it's a shit algorithm that shouldn't be used in production in places where its directly blocks people actions
That article was flagged because it seemed fabricated by AI (see one of the comments).
I understand your wish to have simple rules that you can understand but I’m afraid this is often not the case with machine learning algorithms, e.g. neural networks.
People at large became surprisingly fine with heavy surveillance state. It’s not even in any election issue agenda, completely ignored by everyone.
Another unpredictable outcome of social media I guess.
Something about stalking people online and digital exhibitionism, pushed the Overton window of surveillance.
To people like me, who do not have such loud and transparent online presence, this is unsettling. I only now crash head first into modern mentality as it is starting to affect me.
I wonder how long will I be able to evade the databases. Up until now it has been not that hard as long as you have a lot of money, live analog life, pay in crypto/cash and avoid big cities.
"In the U.S., the number of civilians whom police have killed annually has only increased each year since the widespread adoption of body camera equipment,"
That is a near textbook case of abusing statistics. Those things are completely independent variables. Perhaps "civilians" (as opposed to what, military?) killed by police increased because crime increased. Or population increased. Or laws changed. Or bullets changed.
Why would we expect widespread adoption of bodycams to decrease the number of criminals shot and killed by police? That starts with the spurious assumption that the police are randomly shooting and killing citizens in droves without cause and bodycams would put a stop to it. As it turns out, this isn't happening, so bodycams have no influence on the variable.
There's no need to read the rest of that article if the authors are trying to secretly sell such a pejorative opinion.
I invite you to go watch a couple hundred bodycam vids on YouTube. It may change your perspective on what police deal with. What I see consistently, regardless of department, is police bending over backwards and using all kinds of non-lethal force, to the point of risking their own lives, before using lethal force. There are well-publicized exceptions but in the vast majority of cases, the officers are facing someone using lethal force against them.
Some of these videos are the result of FOIA requests. Please, make FOIA requests and post these videos where the police are acting so egregiously. We deserve to know the truth about this!
Some less than positive-for-police videos I've seen-
- a weak police officer doesn't take control of the situation and the officer standing behind the first one is shot and killed
- an officer, while chasing a suspect, tazes him as he exits the median grassy area and enters a lane of traffic. The suspect was killed by traffic.
- a forfeiture case where someone's life savings (cash) were confiscated without due process during a traffic stop
If every violation gets captured hopefully we can have law enforcement and judges that can use their discretion to make sure the "spirit of the law" is what actually results in punishment. Or we fire 80% of them if an AI can outperform them.
By spirit of the law I mean: rolling a stop sign at 1am on a flat country road is not the same as rolling a stop sign in a busy parking lot.
Unfortunately, history shows many, many examples of selective enforcement that are used to push racist agendas by the enforcers.
Also, I suspect that there will not be anywhere near enough judges to allow people to question the inevitable mistakes that are made if AI is involved. Arguably, most societies don't have enough judges to deal with simple matters such as speeding/parking tickets.
1. No one is foregoing the revenue from even minor infractions.
2. There won’t be a human in the loop. You thought Judge Judy was bad? Try Judge AImy.
How do I know this? Having copped three speeding fines last year via speed cameras, two of which were for driving 43km/h in a 40 zone. One of which I disputed with dash-cam footage showing it was a brief overtaking acceleration when a truck came to a stop in an intersection. Outcome? “No. Speed camera never lies. But feel free to waste more time and money getting this before a human.”
Maybe not "you", but how motivated are you to be in control? Not as much as those who angle for the CEO and board chair roles, or to be kingmakers, or to run for various offices. And they very much tolerate being feared.
It's essentially the TVtropes Fascist but Inefficient, but it takes out the grunt work.[1]
The other thing that comes to mind here is Brazil, the movie directed by Terry Gilliam - the inefficiency of the state is part of what makes it evil because it mostly doesn't care if it gets stuff wrong - I wonder how machine intelligence may change that.
Ellison was among several prominent tech billionaires and executives whose names were mentioned in the multi-million-page tranches of documents made public by the Department of Justice.
Surely you will provide the context of those mentions for us to review? You won't just let us assume they are innocuous mentions like you intended. Right?
It does. It's still a good text. It's also definitely a result of human-AI collaboration (to what extent - hard to say; could be AI edits in human-written text, could be a longer prompt and AI expanding it, something like that).
The it's-not-X-it's-Y formula is the most visible tell. It's overused, being used, I think, 3 times, with 2 being slightly less obvious. This-was-X-and-now-it's-Y is also overrepresented.
It's still not a bad comment. We can discuss it just fine. What we can't do now is assume this is entirely an EastLondonCoder's text, so we can't use it to form an opinion of that person (whether good or bad) based on its content (since we don't know how much of it comes from that person, and how much from the machine). Some will also form an opinion (good or bad) about the poster simply because they used AI.
That's an Internet discourse of 2026, in my experience. I wonder what's next.
Single sentence paragraphs for rhetorical emphasis. I count six of those.
Abrupt or elliptical sentences, often with a melodramatic tone. Example: "AI changes that." "It obviously can. So can a prison."
Inconsistencies one wouldn't expect a human to make: "fraud detection" is ok in paragraph 5; worrisome in paragraph 9.
I'm not vehemently against using AI as a drafting tool, but if I were to do that, I would be inclined to signal that somehow to avoid the appearance of dissimulation; just as I would if I were paraphrasing another author.
If the points are good, then good. If you didn't notice the AI tells, does it really matter? It's still intelligible discourse.
Is there an actual quantitative check that says "AI or not AI"? I'm genuinely curious.
So far as I can tell, AI prose checking - at least vs the frontier models - has been little better than vibe-based. Which, well, that's just another way of saying Red doesn't like Blue. And we got enough of that.
> Is there an actual quantitative check that says "AI or not AI"? I'm genuinely curious.
There are plenty of them that will give you a number, Pangram is a commonly-used one. Of course, whether they actually work well is a different matter. In my experience they have a huge false positive rates. I haven't tested the inverse.
Man, just write your own comments yourself, no need to use AI-generated ones. You are making good point but the twitter-AI-slop style makes it really annoying to read.
> this fetish for controlling people through coercion that seems so prevalent in certain new modern business contexts, like amazon warehouse workers and delivery employees.
The only thing it creates is resentment. Is that how you want to build a company or society on. Resentment?
"Resentment" is a bad-faith interpretation at what it creates. What it creates, and why you see so much of it, is a powerful mechanisms to automate routine business of management and extraction of value.
Hate that I'm biting on this, but this isn't constructive, whereas AI generated or not, the comment above is. It is the top one, it is succinct, and it articulates the point clearly.
You seem to lament AI and given the context of that comment, the author presumably does too. The world is moving faster and faster towards AI first so kicking an screaming "That's AI" will not help. AI generated noise sucks, nut this is not it. We're moving closer and closer to a self-censored, milquetoast internet. Don't bring down a person for putting themselves out there, instead build on their case or build one of your own if you disagree. Shitting on well articulated points only pushes them further out of common discourse. We are all strangers on the internet and owe each other nothing, including this feedback, so do with it what you will.
I simply disagree. If I wanted an LLM's opinion, I would forego HN entirely and just use ChatGPT. I browse forums like this to get organic opinions from real people.
When I see someone post an LLM reply, it makes me wonder - is the reply synonymous with their actual opinion, only formatted better? Or are they attempting to disguise an LLM output as something of their own? The former I am much more OK with, but the latter irks me for reasons I haven't fully considered and you have me thinking about.
"Calling out" AI comments has felt like somewhat of a duty, heh, but maybe we've reached a point of no return. I still value a real, organic opinion, though, no matter how well an AI can summarize it.
It clearly matters to him, and perception is not really a choice.
Personally, I've grown somewhat allergic to "AI-isms", and I'd rather not be (this example is still somewhat acceptable though). I also don't understand how we haven't trained this particular, obnoxious writing style out of them by now...
I wouldn't consider this something that really matters to me, though. I'm not up in arms over it. It's not an insurmountable annoyance. It didn't ruin my day. (LOL, the other comment about "perceived duality"... It's really not that deep!)
I didn't know I was going against the grain, though. It seems folks here are perfectly fine with AI discourse. How do we even know when a user is real? I digress.
I’m working on something close to that. At the moment it’s just for ableton. The idea is to be able to sync a daw project, binaries will be saved on cloudflare and then use git for certain cases where it’s possible to merge. In case one person is working on a bass line and another is working on a guitar part. I’ve been using git for this workflow but the idea to have use interface that’s legible for non git users
I think the article make some great points, however this part is not even wrong:
"The obvious objection is that code produced at that speed becomes unmanageable, a liability in itself. That is a reasonable concern, but it largely applies when agents produce code that humans then maintain. Agentic platforms are being iterated upon quickly, and for established patterns and non-business-critical code, which is the majority of what most engineering organizations actually maintain, detailed human familiarity with the codebase matters less than it once did. A messy codebase is still cheaper to send ten agents through than to staff a team around. And even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today. The liability argument holds in a human-to-human or agent-to-human world. In an agent-to-agent world, it largely dissolves."
LLMs are not conscious, that means left on their own devices they will drift. I think the single most important issue when working with LLMs is that they write text without a layer that are aware what's actually being written. That state can be present in humans as well, like for example in sleepwalking.
Everyone who's tried to to complete vibe coding a somewhat larger project knows that you only get to a certain level of complexity until the model stops being able to reason about the code effectively. It starts to guess why something is not working and cannot get out of that state until guided by a human.
That is not new state in the field, I believe all programmers has at points in their career come across code that's been written with developers needing to get over a hard deadline with the result of a codebase that cannot effectively be modified.
I think for a certain subsets of programming projects some projects could possibly be vibe coded as in that code can be merged without human understanding. But it has to be very straightforward crud apps. In almost everything else you will get stopped by slop.
I suspect that the future of our profession will shift from writing code to reading code and to apply continuous judgement on architecture working together with LLMs. Its also worth keeping in mind that you cannot assign responsibility to an LLM and most human organization requires that to work.
I think some type of tickets can be done like this but your trusted user assumption does a lot of work here. Now I don't see this getting better than that with the current architecture of LLMs, you can do all sorts of feedback mechanisms which helps but since LLMs are not conscious drift is unavoidable unless there is a human in the loop that understands and steers what's going on.
But I do think even now with certain types of crud apps, things can be largely automated. And that's a fairly large part of our profession.
I’ve done a event ticket system that’s in production. Stripe integration, resend for mailing and a scan app to scan tickets. It’s for my own club but it’s been working quite well. Took about 80 hours from inception to live with a focus on testing.
I’ve done some experiments with reading gedcom files, and I think I’m quite close to a demoable version of a genealogy app.
Biggest thing is a tool for remotely working musicians. It’s about 10000 lines of well written rust, it is a demoable state and I wish I could work more on it but I just started a new job.
But yeah, this wouldn’t have been possible if I hadn’t been a very experienced dev who knows how to get things live. Also I’ve found a way to work with LLMs that works for me, I can quickly steer the process in the right way and I understand the code thats written, again it’s possible that a lot of real experience is needed for this.
I don’t really find “can the model produce good code?” that interesting anymore. In the right workflow, it plainly can. I’ve gotten code out of LLMs that is not just faster than I’d write by hand, but often better in the ways that matter: tests actually get written, invariants get named, idempotency is considered, error conditions don’t get silently handwaved away because I’m tired or trying to get somewhere quickly.
When I code by hand under time pressure, I’m actually more likely to dig a hole. Not because I can’t write code, but because humans get impatient, bored, optimistic and sloppy in predictable ways. The machine doesn’t mind doing the boring glue work properly.
But that is not the real problem.
The real problem is what happens when an organisation starts shipping code it does not understand. That problem predates LLMs and it will outlive them. We already live in a world full of organisations that ship bad systems nobody fully understands, and the result is the usual quagmire: haunted codebases, slow change, fear-driven development, accidental complexity, and no one knowing where the actual load-bearing assumptions are.
LLMs can absolutely make that worse, because they increase the throughput of plausible code. If your bottleneck used to be code production, and now it’s understanding, then an organisation that fails to adapt will just arrive at the same swamp faster.
So to me the important distinction is not “spec vs code”. It’s more like:
• good local code is not the same thing as system understanding
• passing tests are not the same thing as meaningful verification
• shipping faster is not the same thing as preserving legibility
The actual job of a programmer was never just to turn intent into syntax anyway. Every few decades the field reinvents some story about how we no longer need programmers now: Flow-Matic, CASE tools, OO, RUP, low-code, whatever. It’s always the same category error. The hard part moves up a layer and people briefly mistake that for disappearance.
In practice, the job is much closer to iteratively solving a problem that is hard to articulate. You build something, reality pushes back, you discover the problem statement was incomplete, the constraints were wrong, the edge case was actually central, the abstraction leaks, the user meant something else, the environment has opinions, and now you are solving a different problem than the one you started with.
That is why I think the truly important question is not whether AI can write code.
It’s whether the organisation using it can preserve understanding while code generation stops being the bottleneck.
If not, you just get the same bad future as before, only faster, cleaner-looking, and with more false confidence.
Senior frontend/product engineer focused on high-performance, tool-like interfaces for expert users. Strong on component architecture, accessibility, profiling-driven performance, and the “last 10%” polish (latency, UX sharpness, reliability) that keeps teams out of refactor holes. Comfortable owning frontend architecture end-to-end in small, high-agency teams; background includes realtime/concurrent UI systems and long-lived products where correctness matters. AI-assisted workflow when useful, gated by small diffs and tests so speed compounds rather than creating debt.
This was my first literary experience, my mother read it to me when I was three years old. Seeing Janssons rendering of Smaug made me remember it was this version she read for me.
I don’t use plan.md docs either, but I recognise the underlying idea: you need a way to keep agent output constrained by reality.
My workflow is more like scaffold -> thin vertical slices -> machine-checkable semantics -> repeat.
Concrete example: I built and shipped a live ticketing system for my club (Kolibri Tickets). It’s not a toy: real payments (Stripe), email delivery, ticket verification at the door, frontend + backend, migrations, idempotency edges, etc. It’s running and taking money.
The reason this works with AI isn’t that the model “codes fast”. It’s that the workflow moves the bottleneck from “typing” to “verification”, and then engineers the verification loop:
-keep the spine runnable early (end-to-end scaffold)
-add one thin slice at a time (don’t let it touch 15 files speculatively)
-force checkable artifacts (tests/fixtures/types/state-machine semantics where it matters)
-treat refactors as normal, because the harness makes them safe
If you run it open-loop (prompt -> giant diff -> read/debug), you get the “illusion of velocity” people complain about. If you run it closed-loop (scaffold + constraints + verifiers), you can actually ship faster because you’re not paying the integration cost repeatedly.
Plan docs are one way to create shared state and prevent drift. A runnable scaffold + verification harness is another.
Now that code is cheap, I ensured my side project has unit/integration tests (will enforce 100% coverage), Playwright tests, static typing (its in Python), scripts for all tasks. Will learn mutation testing too (yes, its overkill). Now my agent works upto 1 hour in loops and emits concise code I dont have to edit much.
Totally get it, and I think we’re describing the same control loop from different angles.
Where I differ slightly is: “100% coverage” can turn into productivity theatre. It’s a metric that’s easy to optimize while missing the thing you actually care about: do we have machine-checkable invariants at the points where drift is expensive?
The harness that’s paid off for me (on a live payments system) is:
- thin vertical slice first (end-to-end runnable, even if ugly)
- tests at the seams (payments, emails, ticket verification / idempotency)
- state-machine semantics where concurrency/ordering matters
- unit tests as supporting beams, not wallpaper
Then refactors become routine, because the tests will make breakage explicit.
So yes: “code is cheap” -> increase verification. Just careful not to replace engineering judgement with an easily gamed proxy.
- small club website: https://www.kolibrinkpg.com
- ticketing system with Stripe payments and QR scanning at the door
- Instagram/media ingestion for the club site
- genealogy tool with GEDCOM import
- scripts for downloading/archiving public-domain film material
- playlist/library tooling for DJ use
- music collaboration/sync tool for Ableton projects
- normal work stuff in a much larger existing codebase
I have become a lot more strict about process after being burned a few times. Mostly: make the change small, be clear about what it is supposed to do, check the assumptions before coding, use tests/logging/manual checks as evidence, and don’t merge anything I can’t review and explain myself.
reply