EastLondonCoder

Some things I’ve used AI for the last year or so:

- 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.

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?

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.

Possibly, but probably not in less time and the point was partly learn to use agentic coding and also having it do exactly what I wanted.

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.

Location: Norrköping / Stockholm, Sweden (CET)

Remote: Yes (EU/UK preferred); hybrid Stockholm OK

Willing to relocate: No

Technologies: React, TypeScript, Next.js, UI architecture/design systems, accessibility, performance profiling, realtime/event-driven UI (WebSockets), Playwright/Vitest, Node.js, SQL (Postgres/SQLite), Rust

Résumé/CV: https://www.kolibrinkpg.com/CV.pdf

Email: jonatan.wallgren@gmail.com

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.

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

So yes: “code is cheap” -> increase verification. Just careful not to replace engineering judgement with an easily gamed proxy.

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

Plan docs are one way to create shared state and prevent drift. A runnable scaffold + verification harness is another.

I think the deluge on projects on show HN points to something real, its possible today to ship projects as a one man shop that looks like something that just a year or so would have required a team.

Personally I have noticed strange effects, where I previously would have reached for a software package to make something or solve an issue, its now often faster for me to write a specific program just for my use case. Just this weekend I needed a reel with a specific look to post on instagram but instead of trying to use something like after effects, i could quickly cobble together a program that was using css transforms that outputted a series of images I could tie together with ffmpeg.

About a month ago I was unhappy with the commercial ticketing systems, they were both expensive and opaque so I made my own. Obviously for a case like that you need discipline and testing when you take peoples money, so there was a lot of focus on end to end testing.

I have a few more examples like this, but to make this work you need to approach using LLMs with a certain amount of rigour. The hardest part is to prevent drift in the model. There are a certain number things you can do to make the model grounded in reality.

When the tool doesn’t have a reproducer, it’ll happily invent a story and you’ll debug the story. If you ground the root cause in for example a test, the model can get context enough to actually solve the problem.

Another issue is that you need to read and understand code quickly, but its no real difference from working with other developers. When tests are passing I usually do a PR to myself and then review as I usually would do.

A prerequisite is that you need tight specs, but those can also be generated if you are experienced enough. You need enough domain intuition to know what ‘done’ means and what to measure.

Personally I think the bottleneck will go from trying to get into a flow state to write solutions to analyze the problem space and verification.

I lived in London for 15 years. Southbank and the Barbican were some of my favourite places there.

Barbican is particularly interesting since its part of the city of London, and whereas the city mostly contains bad neoclassical designs that feel dystopian and inhuman Barbican feels like a fresh breath of air.

It has a human centric design and it uses water and greenery to temper the concrete.

Its interesting that crowds in connection to or within the southbank center also always feel lively. I'm uncertain of why, perhaps the concrete makes a counterpoint to humanness and makes us focus on the people in the vicinity.

Perhaps its the cultural programming. But the end result for me was that whenever I was around these blocks of concrete I was almost always in a good mood.

I think you are right, the secret is that there is no secret. The projects I have been involved with thats been most successful was using these techniques. I also think experience helps because you develop a sense that very quickly knows if the model wants to go in a wonky direction and how a good spec looks like.

With where the models are right now you still need a human in the loop to make sure you end up with code you (and your organisation) actually understands. The bottle neck has gone from writing code to reading code.

This matches my experience, especially "don’t draw the owl" and the harness-engineering idea.

The failure mode I kept hitting wasn’t just "it makes mistakes", it was drift: it can stay locally plausible while slowly walking away from the real constraints of the repo. The output still sounds confident, so you don’t notice until you run into reality (tests, runtime behaviour, perf, ops, UX).

What ended up working for me was treating chat as where I shape the plan (tradeoffs, invariants, failure modes) and treating the agent as something that does narrow, reviewable diffs against that plan. The human job stays very boring: run it, verify it, and decide what’s actually acceptable. That separation is what made it click for me.

Once I got that loop stable, it stopped being a toy and started being a lever. I’ve shipped real features this way across a few projects (a git like tool for heavy media projects, a ticketing/payment flow with real users, a local-first genealogy tool, and a small CMS/publishing pipeline). The common thread is the same: small diffs, fast verification, and continuously tightening the harness so the agent can’t drift unnoticed.

Haha, almost, we add an extra word and some signifiers.

"Vi ses i röken och dimman! "

It actually means something specific. We tend to use a smoke machine a lot on our nights, one time the police showed up because they thought the place was on fire. The symbols at the end signifies the electricity of nights and the headphones is of course a reference to our social media headphone walks.

This is fixed catchphrase we use in all our communications.

Totally fair. It’s a real monthly music night, not software.

The Show HN part is the site + media (so people can see the scale/atmosphere), and the thing we’re trying to share is the operating model: how you get strangers to show up alone, feel safe, and come back, without big budgets.

As the other poster commented Kolibri is hummingbird in Swedish. The name was inspired by 2 things. A feeling of lightness and ease connected with carefree summer nights and also the intros of all versions of pacific by 808 state.

Kul att höra från dig! Det är många olika personer runt Kolibri som känner dig från Berlin som t.ex. Henrik Maneuever så det var extra kul när du besökte oss.

Thanks you so much, Maria & Jonatan

We do agree with this, we both prefer attending small gigs ourselves for that exact reason. Also, all bands has to start somewhere, it takes many small gigs to create an audience and develop their craft. Writing and producing songs is one thing but there is no substitution to the experience to see what moves in people listening live. The majority big stadium bands started with endless small non paying gigs, this is the foundation of the music business.

You’re very welcome! Next one is Feb 27: Sydney Valette (Paris) + Coppia (Eskilstuna).

https://sydneyvalette.bandcamp.com/ https://coppia.bandcamp.com/

Nice, you’d be very welcome.

Strong spring lineup. Tonight is Hidden Lines, end of Feb Sydney Valette (Paris), and 20 March Liminal Project (UK) + Yugoslavia (ES) with Inåt Bakåt Records. On 11 April there’s a one-day festival in Norrköping (Kallsup, Poloklubben, Zack Zack Zack, etc.).

We’ve been experimenting a bit with how much we pre-announce (small room, and we don’t want to spread people too thin), but the schedule on the site is the best place to check. Instagram is our main outreach: @kolibrinkpg

Thanks. The idea came from trying to visualise “listening to music” in a way that actually works on social media without filming crowds inside a club. The constraint forced a better format.

OP here (Maria & Jonatan). This took off while we were asleep.

Maria is the creative force and writes Swedish very well. We used ChatGPT as a bouncing board to translate/tighten the English and get the story across. The piece reflects what we do, but in hindsight it probably ended up a bit over-polished.

Happy to answer questions.

A few concrete mechanisms that made this work (happy to expand):

  * “Host layer”: greeting newcomers + making it safe to arrive alone mattered more than we expected.
  * Curation as governance: coherent music changes how people behave in the room.
  * Offline outreach outperformed posting: visiting local businesses in person built trust faster than Instagram.
  * Scale changes the social physics; we stayed small on purpose.

This frames escalation as if it’s an inevitable byproduct of “not cooperating,” but that’s a choice. Sanctuary policies generally limit voluntary local participation (e.g., detainers without judicial warrants), they don’t “block” federal enforcement.

“If you don’t want door-to-door, cooperate” is basically saying federal agencies get to punish jurisdictions for lawful policy choices by switching to more coercive tactics. That’s not normal enforcement; it’s politicized leverage. And once you normalize that logic, it won’t stay confined to immigration.

[flagged]

“Optics” is the wrong frame: this is about legitimacy and consent. A referendum demanded by outsiders under pressure is just coercion with a procedural costume. Imagine Cuba proposing a referendum on Puerto Rico joining Cuba and calling it “bad optics” if people won’t play along, the absurdity is the premise, not the lack of voting.