timjansen

I'm currently experimenting with a pi-agent-core-based operations agent. It's crazy how easy it is to set up one. Mine is already monitoring Downread; it fixed a DB lock issue by restarting the DB and is talking to me in a Slack channel while doing so. #buildinpublic

@ginandstocks @KnoblochJens @grok kannst du die Aussage oben erklären, wie es sein kann, dass Bewerbern auf Stellenanzeige gekündigt wurde? Ich würde gerne Wissen, ob KI im Sprachverständnis Menschen bereits übertrifft.

Mehr als 50% aller Bewerber auf unsere aktuellen Stellenanzeigen (IT Berufe) wurden in den letzten Wochen betriebsbedingt gekündigt. Das haben wir in der Höhe noch nie erlebt. Die offiziellen Statistiken geben noch gar nicht wieder was hier gerade passiert...

I have added a function that scans posts for links to other feeds, but that works mostly for tech blogs, because there are so many, always linking to easy other. It didn’t work for non-technical feeds.

I spent most of the day adding and categorising feeds for Downread. Currently I got 2.3k. AI is automatically pre-categorising and writing descriptions, but I am still deciding what will be in the catalog and often edit it. And of course, I need to find them. #buildinpublic

I tried the database with libsql locally, and as expected, these queries take under 1 ms. Either Turso just don't reserve a lot of capacity for the free plans, or my queries are so infrequent that the DB has to be loaded first... In any case, it's not fun to use Downread as an admin on a DB that slow. It's not even that bad for users, because most communication is async, so a slow DB is hardly noticeable. But as I am currently setting up data, it's quite annoying.

I started Downread on a local PostgreSQL database. Because I didn't want to manage a database, I first thought I'd just use a cloud DB. But I don't want a database that costs me an arm and a leg for a potentially free service, so cloud-based PostgreSQL services are ruled out. So I gave Turso a chance. The prices are fantastic. But the performance is, well... not good. Not sure whether the free plan is slower than the paid plans, which I could understand, but I can't find any indication of that on the pricing plan comparison... The DB is not that big. My main table, feeds, has 1600 rows. The whole DB has just 17 MB. Yet, even the simplest updates take a second. Admittedly, my rows are pretty large and can contain a list of 1000 timestamps and meta data of the last 10 posts as JSON. But 1.1s for updating a single number? Even more for updating several values? (Reading queries are more reasonable, but also not fast) I think I will try some alternatives. Local libsql, or going back to self-hosted PostgreSQL. I don't know yet. #buildinpublic

Here, it may look like Downread.com didn't make much progress late, but I have just been super busy. In the last few days, I have created a dashboard, added 1600 feeds with 77k posts to put some load on the server, fixed all the issues I discovered doing this, updated the coming-soon page, and added WebSub support. Next will be a third view for feeds. @buildinpublic

@kirapt0r Dieses Buch hat uns sehr geholfen, den Markt zu verstehen. Wir haben bestimmt 10 Angebote eingeholt, bis wir preislich da waren, wo wir hinwollten. Günstiger als Ikea trotz Aufbau. cleverkuechenkaufen.de

Der Einbauküchenmarkt ist fuckt. So ein intransparenter, verlogene und von der User-Experience losgelösten Bullshit erlebt man wirklich selten.

I was going to use BunnyNet as a CDN to store Downread's feed data (I only keep limited metadata in the DB; all posts are on the CDN), to store the React app itself, and to act as a proxy for the API servers. But bunny.net doesn't make it easy. Keeps caching API GET calls, has no easy way for a SPA to map paths, and the feed's CDN returned random 428 errors. Wasted more than one evening getting it all working. Trying Cloudflare now. Never used it before, and it's quite a beast, but after one afternoon, it looks like I'm good. #buildinpublic

The deployment does not use pipelines, but I use Claude to implement a CLI tool that can deploy, configure, and start/stop the server. That is not only simpler, but makes it easier to outsource work to agents.

I am currently working on deploying my RSS reader, Downread, on its first production home. Which is just a cheap VPN server, but that should be enough for now. I won't open it for users yet. It will collect feeds for at least one month before I even consider it. #BuildInPublic

I am reaching the point where Downread is becoming really usable and almost good-looking. Sharing some recent screenshots. In March, I will set up the servers and start collecting feeds for a possible launch in April. #BuildInPublic

@yummyCenturyEgg Even if they are not the road to AGI, they can replace most office workers. It’s just a matter of integrating them into processes. Software development is the first „victim“ because agents are easy to integrate into software workflows.

These market freakouts will keep coming until investors collectively conclude that LLMs are not on the road to AGI. Until then, volatility around the theme is a recurring issue. We are becoming Gods who are afraid to instill free will into our creations. It's a glorious disaster.

I am currently refining what I consider the most important feature of Downread: the 'new posts' stream. A (almost) infinite scrollable panel of your unread posts. This is what made Google Reader great for me, and I am so thrilled to have it back. #buildinpublic

Some thoughts after spending some more time with GPT-5.3 Codex (and comparing it to Opus 4.6): - Codex is generally much quicker, at least in the default mode - It's really great at understanding and fixing React code quickly. Opus tends to struggle with React when things are getting too complex, but Codex is great at it - Generally, for UI things, I prefer Codex now. It's just faster. - Codex also impressed me, creating SVGs and, in particular, SVG animations - Codex disappoints when writing backend code. I let both Opus and Codex write one of the last major backend pieces in Downread, the unified news feed, using the same prompt. Besides giving them an API outline, I also mentioned specific performance constraints and what to optimize for. Opus considered them and found a good solution. It needed some extra hints (namely, that users might have a thousand feeds and that its initial design wouldn't scale well), but it used them to improve its design. Codex, on the other hand, seems to be focused on writing the simplest possible solution. It ignored all my performance hints and found a simple solution, which certainly works, but would be far more expensive to run. #BuildinPublic

This weekend is bug-bashing weekend. Downread is close to becoming my primary RSS reader, but there are some annoying issues in the read-marker system. Hope to squash them all this weekend, so I can stop using Feedly. #BuildingInPublic

@Quasseell hat recht. Roboter haben im Gegensatz zu den anderen Beispielen wie LLMs die Möglichkeit, auszuprobieren, Fehler zu machen und daraus zu lernen. Die Trainingsdaten muss man sich schaffen, indem man tausende Roboter baut und sie wie Kleinkinder Tätigkeiten wie Greifen üben lässt. Und davon ausgehend die Schwierigkeit steigert. Das dauert natürlich und ist aufwendig. Sie werden nicht nächstes Jahr schon in der Fabrik nützlich sein - das glaube ich auch nicht. Aber wenn man hunderte Milliarden in Rechenzentren zum Training von LLMs investieren kann, kann man auch tausende Roboter von Menschen geleitet einfache Tätigkeiten üben lassen...

@quasseell "Jeder Fehlgriff eines Roboters in der Fabrik" das ist natürlich eine laechlich geringe, im Vergleich zur generativen KI praktisch nicht vorhandene Datenmenge. So hätten man Roboter auch schon in den 90ern trainieren können

Zu den humanoiden Robotern: Das Data-Gap 1. Das was wir als KI aktuell erleben, sind LLMs. Large langue models. Sie beruhen auf dem glücklichen Umstand, dass mit dem Internet absurd hohe Mengen an sprachlichen Trainingsdaten vorliegen. 2. Was wir zudem erleben, ist generative Bild/Video KI. Auch dieser Fortschritt beruht auf dem glücklichen Umstand, dass wir absurd hohe Datenmengen für das Training digital vorliegen haben. 3. Was wir zudem erleben, sind selbst fahrende Autos. FSD von Tesla funktioniert (leider prinzipiell unzuverlässig) aufgrund einer absurd hohen Menge an Trainingsdaten. Nun denkt Otto-Normal-IQ "Wir sehen so tolle Fortschritte bei 1,2, und 3. Nun kommen bald die Super Roboter. Die KI ist ja unaufhaltsam 1!!1!1!!" Das ist falsch gedacht. Woher soll eine große Daten-Basis für die Bewegung unserer 360 Gelenke kommen? Woher kommt die Datenbasis für die motorischen und planerischen Abläufe beim Einräumen einer Spülmaschine, beim Servieren von Getränken oder eines Batteriewechsel bei der Wanduhr? Diese Daten gibt es nicht, es gibt nichts was man in der notwendigen gigantischen Masse in ein neuronales Netz speisen kann. Während das Internet und digitalisierte Bibliotheken ein unerschöpflicher Steinbruch für Wörter und Pixel sind, gibt es kein „YouTube für haptisches Feedback und Drehmomente“. Man versucht es mit Simulation: Roboter trainieren in einer digitalen Physik-Engine (wie in der Matrix) Millionen von Stunden in Zeitraffer, in der Hoffnung, dass die echte Welt sich genauso verhält. Spoiler: Tut sie oft nicht, weil eine Wanduhr im echten Leben mal klemmt oder die Batterie ausläuft. Auch ist die Frage, warum man ein neuronales Netz damit trainieren soll, wenn man doch eh alle Bewegungen ausrechnen kann.

Is it weird that AI coding assistance is not giving me identity fracture? A lot of software developers are feeling disoriented and threatened these days. Programming by hand is clearly going the way of the buggy whip and the hand-cranked auger. Which is how we're finding out that a lot of people have their identities bound up in being good at hand-coding and how it feels to do that. That's not me. It's not me at all. Rather to my surprise, I don't miss coding by hand, not any more than I missed writing assembler when compilers ate the world and made that unnecessary. (That was in a couple years back around 1983, for you youngsters.) Maybe the fact that I'm not feeling any of this disorientation disqualifies me from having anything to say to people who are. On the other hand...if you can learn to emulate my mental stance and be completely unbothered, maybe that would be a good thing? So. If you're a programmer, and you're feeling disoriented, try this on for size: I like being a wizard. I like being able to speak spells, to weave complex patterns of logic that make things happen in the world. Writing code is a way to manifest my will. Yes, I've piled up a lot of arcane knowledge over the 50 years I've been doing this. But languages of invocation, they come and they go. Been a long time since I've had any use for being able to program in 8086 assembler, and that's okay. I have better spells now, and these days some rather powerful familiars. What I'm inviting you to do is think of yourself as a wizard. Not as a person who writes code, but as a person who is good at assuming the kind of mental states required to bend reality with the application of spells. And if that's who you are, does it matter if the spells are painstakingly scribed in runes of power, versus being spoken to an obedient machine spirit? It's all one; it's all the manifestation of will. Arcane languages come and go, machine spirits appear and then diminish to be replaced by more powerful ones, but you? You are the magic-wielder. Without you, none of it happens. Same as it ever was. Same is it ever was. And so mote it be.

@DerSpitzbub @honx @steipete @sabinedoering Veränderung?

@honx @steipete @sabinedoering was wollen die leute denn nicht

Der OpenClaw-Gründer Peter Steinberger entkräftet hier sachlich viele B/Doomer-Bedrohungsszenarien. Nun geht er zu OpenAI. Warum konnte oder wollte Europa dieses Talent nicht halten? Ums Geld allein ging es ihm ja ganz offensichtlich nicht. on.orf.at/video/14311959…