EastLondonCoder

no profile record

Submissions

Show HN: Kolibri, a DIY music club in Sweden

kolibrinkpg.com

143 pointsby EastLondonCoderقبل 5 أشهر31 comments

comments

EastLondonCoder

قبل 24 يومًاdiscuss

[flagged]

EastLondonCoder

الشهر الماضيdiscuss

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.

EastLondonCoder

الشهر الماضيdiscuss

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?

EastLondonCoder

قبل شهرينdiscuss

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

EastLondonCoder

قبل 3 أشهرdiscuss

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.

EastLondonCoder

قبل 4 أشهرdiscuss

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.

EastLondonCoder

قبل 4 أشهرdiscuss

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.

EastLondonCoder

قبل 4 أشهرdiscuss

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.

EastLondonCoder

قبل 4 أشهرdiscuss

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.

EastLondonCoder

قبل 4 أشهرdiscuss

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: [email protected]

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.

EastLondonCoder

قبل 4 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.

EastLondonCoder

قبل 5 أشهرdiscuss

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.