CIRCLE WITH A DOT

Finishing off and making a demo video for the second iteration of my Controller server!https://twitch.tv/sleepytealcoder#Programming #SoftwareDevelopment #Twitch #VTuber #TypeScript #ItsMakingADemoVideoTimeYay

@aral I agree, and I am absolutely *not* against AI tools. But as wise people say — code is read much more than it is being written. This is why it should be easy to read. That’s one thing.The other is: I believe a lot depends on *how* you use the tools and your literacy in how they work and what to expect. AI is amazing at helping to *read* code exactly — analyze, travel all those paths that would take me hours to travel, and find out how things work, what the dependencies are and what the data flow is.

Fixing more bugs with the Controller server and Android client!https://twitch.tv/sleepytealcoder#Programming #SoftwareDevelopment #Twitch #VTuber #Kotlin #TypeScript #LittleBitFromColumnALittleBitFromColumnB

Fixing the annoying issue I have with Twitch token renewal on the Controller server then looking at bugs on the Android client!https://twitch.tv/sleepytealcoder#Programming #SoftwareDevelopment #Twitch #VTuber #TypeScript #Kotlin #WorkingOnBothSidesTodayHopefully

So many things I have scripts -- or even just aliases -- for people are spending a small fortune to reproduce in AI#AI #Softwaredevelopment

Three levels of AI in software development 🧠After my recent posts about vibecoding and devibecoding I want to zoom out a bit. I think there are three levels of using AI in software development — and they are really about risk.🟢 Level 1: passive AI usage. Autocomplete, code review, planning, answering coding questions, writing documentation. You stay in full control, AI just saves you time. Almost zero risk, immediate productivity gains.🟡 Level 2: vibecoding non-production code. Tests, internal tools, CI/CD scripts, prototypes. This is the sweet spot most teams underestimate. The upside is high but the blast radius is small — if a generated test is wrong it fails, if an internal tool has quirks nobody outside your team notices. Great place to learn what AI can and can't do. Level 3: vibecoding production code. This is where it gets real. By my definition from the earlier post: vibecoded code is code nobody on your team has fully understood. Shipping that to production is a conscious risk decision. The key insight: these aren't steps you walk through sequentially. It's a risk assessment. Level 1 and 2 are almost always worth it. Level 3 depends on your situation — a startup that needs an MVP in three months has a different equation than an enterprise with compliance requirements. And when level 3 code needs to grow up? That's where devibecoding comes in — turning code nobody fully grasps into code your team truly owns.Where does your team sit on this spectrum right now? #SoftwareDevelopment #AI #Vibecoding #Devibecoding #CodeQuality #DevLife #RiskManagement

@radicalabacus Love the archaeology metaphor. And I think you nailed the core difference — legacy code has a story, vibecode doesn't. Digging through an old codebase you can always ask "why did they do this?" and find an answer. With vibecode that question leads nowhere.Which makes me wonder: is devibecoding even the right response in every case? Maybe your instinct is the pragmatic answer — treat vibecode as a disposable draft. Use it to understand the problem space, extract the spec, then write it properly from scratch.That might actually be the most efficient form of devibecoding — not saving the code but saving the knowledge.

@Blf_tpe Totally agree — the intent is real and the community should meet that with openness, not defense. The people coming in through vibecoding are potential long term contributors and supporters. Your mom donating to Debian is living proof of that.The YouTube tutorial idea is exactly right. The technical barrier to contributing is lower than ever thanks to AI. But nobody teaches you how to write a good commit message, how to read contributing guidelines, or when NOT to open a PR. That cultural onboarding is the real gap.Maybe that's actually a community project worth vibecoding — an interactive guide for first time open source contributors.

@iskropixel I’d also recommend the #GetFediHired hashtag for extending the reach of your messages. Good luck!

Getting the service plugins to be called regularly then fixing some more bugs on the Controller server!https://twitch.tv/sleepytealcoder#Programming #SoftwareDevelopment #Twitch #VTuber #TypeScript #SoSleepyToday

Interesting read on heise.de: "From Output to Outcome" argues that dev teams should stop measuring success by features shipped and start asking: what actually changed for the user?The idea is simple but powerful — a feature is just output. Outcome is when a customer actually solves a problem faster, makes fewer errors, or needs less support. Developers are encouraged to ask "why are we building this?" before writing a single line of code. But here's where it gets tricky for B2B software: Your actual users and your paying customers are different people. The CFO signs the contract, the clerk uses the software daily — their definitions of "value" rarely align. You often have no direct telemetry. On-premise deployments, strict data policies, and months-long update cycles mean you may never see how a feature is actually used. Feedback is heavily filtered. It travels through support tickets, account managers, and customer success teams before it reaches the dev team — losing signal at every step. Outcomes are slow. In B2B, the real proof shows up at contract renewal time — sometimes a year later.So the question is: how do you build an outcome-oriented culture when the outcome is invisible to you? Is opt-in telemetry the answer? Closer collaboration with customer success? Structured user interviews? Or something else entirely?#SoftwareDevelopment #ProductManagement #B2BSoftware #AgileB2B

Interesting read on heise.de: "From Output to Outcome" argues that dev teams should stop measuring success by features shipped and start asking: what actually *changed* for the user?The idea is simple but powerful — a feature is just output. Outcome is when a customer actually solves a problem faster, makes fewer errors, or needs less support. Developers are encouraged to ask "why are we building this?" before writing a single line of code. But here's where it gets tricky for B2B software: Your actual users and your paying customers are different people. The CFO signs the contract, the clerk uses the software daily — their definitions of "value" rarely align. You often have no direct telemetry. On-premise deployments, strict data policies, and months-long update cycles mean you may never see how a feature is actually used. Feedback is heavily filtered. It travels through support tickets, account managers, and customer success teams before it reaches the dev team — losing signal at every step. Outcomes are slow. In B2B, the real proof shows up at contract renewal time — sometimes a year later.So the question is: **how do you build an outcome-oriented culture when the outcome is invisible to you?** Is opt-in telemetry the answer? Closer collaboration with customer success? Structured user interviews? Or something else entirely?#SoftwareDevelopment #ProductManagement #B2BSoftware #AgileB2Bhttps://www.heise.de/hintergrund/Von-Output-zu-Outcome-Entwickler-als-Produktgestalter-11204293.html?seite=all

Still refactoring the Controller server to make it not crash!https://twitch.tv/sleepytealcoder#Programming #SoftwareDevelopment #Twitch #VTuber #TypeScript #IAmLateButHere

@begasus @GIMP happy to see gtk running in Haiku! Wondering if latest gtk versions are also maintained for this OS