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

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?

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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.