kristopherleads
Joined 2 years ago
Karma
28
Submissions
30
Member since
Aug 8
Recent submissions
Comment · 4 months ago
Comment · 6 months ago
I'm at the point where I might start professionally using a voice changer. I mean what in the world, my guy?
Comment · 6 months ago
Here's a hot take for you: the industrial space needs to be braver. A lot of the conservatism was earned with time and experience - but it's about time for us to be braver in what, and how, we adopt at scale.
Walk into any plant floor in 2026 and you’ll see something that should be shocking - but somehow isn’t. The PLC running the line was likely designed in the early 2000s. The protocol it’s speaking was probably standardised in 1979. The HMI looks like Windows 95 had a baby with a calculator. And somewhere in the back office, a tired controls engineer is gluing it all together with VBA and ladder logic - and, probably, hopes and prayers.
And this isn’t a story about technical debt. Technical debt implies a deliberate trade-off - you took a shortcut, you know about it, and you’re planning to fix it. What we have in industrial automation is something stranger and harder to talk about: a kind of institutional fear. We are not stuck on legacy protocols because they are the best tool for the job. We’re stuck on legacy protocols because nobody wants to be the person who broke the line.
And the worst part about all of this is that the caution I’m talking about has fundamentally metastasised into something much worse - it’s become an excuse. And the people paying the price are not the vendors, not the integrators, and not even the engineers - it’s the end users. Operators, technicians, plant managers, and ultimately the customers downstream who deal with the consequences of systems that should have been retired a decade ago.
The industrial space needs to be braver. Not reckless, not credulous, not chasing every new acronym that comes out of a vendor pitch deck - but braver than the version of itself that has been hiding behind earned caution as a justification for not doing the harder work. I think FlowFuse represents a much braver way forward, honestly - and I think I have a pretty strong argument for that case in this article.
The frontier technologies are here. The new protocols are here. The new providers are here. The end users have been waiting.
It’s time we stopped making them wait.
Read more: https://kristopherleads.substack.com/p/heres-a-hot-take-for-...
Comment · 6 months ago
Don't we already have this in HTML5?
Comment · 6 months ago
Funnily enough, I only use the phone bumping feature when AirDrop is broken and won't detect I'm literally right next to my spouse.
Comment · 6 months ago
I 100% agree with you that in a perfect world the submitter should be doing the review work. But the reality is that we don't live in a perfect world - and just sticking our fingers in our ears and shouting it's not our job isn't going to make data breaches less common or code better quality. Accordingly, if we accept that we can't make vibe coders better stewards (although I absolutely do think we can help in that regard, and I suggest ways to do that in the post), then we have to do our part of improve it somehow.
Comment · 6 months ago
Vibe coding is in the news these days, and for largely negative reasons. And in many cases, fair enough - vibe coding has been associated with severe lapses in security, both in terms of the products they create and the platforms used to develop them. For many, vibe coding is just not worth what you get from it - and it’s facing huge pushback in dev spaces.
Here’s the thing though - the problem was never the vibe coding. The problem is the approvals process that allows vibe coded content to proliferate unchecked. This may seem a bit of victim blaming, so let me set an expectation here - if you’re looking for a tech bro to tell you that vibe coding is the future and anyone against it is a luddite, that’s not what this article is about. I don’t think vibe coding is the best thing since sliced bread - but I also don’t think it’s the worst thing to happen in development.
What I do think it has done, however, is expose some critical flaws in the way that software - especially open-source software - gets built and released.
So let’s talk about that.
Comment · 10 months ago
Hey all,
FlowFuse has built out an agentic solution for AI-powered flow inspection and development called FlowFuse Assistant - and we just released it to the Node-RED community via an open source node!
FlowFuse Assistant brings a ton of features for Node-RED users, including:
- A function builder - Function node Code Lens - JSON generation in all typed inputs and JSON editors (like the inject node, change node, template node, etc) - Flows Explainer - HTML, VUE, and CSS generation in FlowFuse Dashboard ui-template nodes - Context-aware inline and multi-line code completions for functions, templates, and tables
I recently did a video highlighting the release - you can see that here https://www.youtube.com/watch?v=Osgli5cdWPY.
Try it out, and let us know what you think!
Comment · 10 months ago
I really think the answer here is human-in-the-loop. Too many people are thinking that AI is a full on drop-in replacement for engineers or managers, but ultimately having it be an augment is the magic. I work at FlowFuse so super biased, but that's something I've really enjoyed with our MCP and Expert Assistant - it's built to help you, not to replace you, so you can ask questions, get insights, etc. faster.
I suppose the tl;dr is if you're generating bugs in your flow and they make it to prod, it's not a tool problem - it's a cultural one.
Comment · 1 year ago
Was just on a Lufthansa and then United flight - both of which did not have WiFi. Was wondering if there was something going on at the infrastructure level.
Comment · 1 year ago
What's the inclusivity reasons? I'd be interested in understanding a bit more about that.
Let me know what you think! I'm using it as my daily driver and I have to say - huge improvements all around!