Tag: GenAI

  • Eight Myths on Software Engineering and GenAI – acm

    Actually, I just posted this on Mastodon, but I so agree to all those points that I want to reference them here on the blog as recommended reads as well.

    Generative AI is reshaping software engineering—but the narrative has gotten ahead of the evidence. Marketing claims, anecdotal wins, and misread studies have given rise to a set of persistent myths that are quietly driving poor decisions about AI adoption, tooling, and how to measure success.

    This article examines eight of the most common misconceptions.

    https://queue.acm.org/detail.cfm?id=3807963
    • Developers Spend Most of Their Time Writing Code
    • Writing Code Is the Bottleneck
    • Lines of Code Written by AI Is the Best Measure of Impact
    • AI Helps All Tasks and Engineers Equally
    • AI Will Turn Individual Developers into 10x Developers
    • It’s Up to Each Developer to Make AI Workgg
    • High-Performing AI Tools Will Be Adopted Automatically
    • With GenAI, Enterprises Can Innovate at Startup Speed

    See the full article here: https://queue.acm.org/detail.cfm?id=3807963

    Fediverse Reactions
  • Debugging with Mistral: Learning, Not Just Fixing

    Depending on which social bubble one is into, people are drawn to letting LLMs do everything. Latest tools promise to fully configure or even manage entire server setups. While that sounds amazing (and I want to try it out some time) that approach has some downsides:

    1. Loss of control: I don’t really know what’s happening under the hood. If something breaks, I’m left in the dark.
    2. Loss of Learning: I want to know / learn how and why things (don’t) work.
    3. Digital Sovereignty: Relying on an external connection is creating a hard dependency that I want to avoid. And hosting my own LLM isn’t an option as my mini PC doesn’t have the RAM or power for that.

    So, while these tools are impressive, they’re not for me — at least not now or not in my private useacse of maintaining my main home-server.

    But, that’s no reason to not leverage it at all!

    Learning by Watching

    Over the weekend, I stumbled upon a stupid issue: I was testing some new services on my mini PC, and at some point, things just stopped working. No clear error, no obvious misconfiguration — just a frustrating dead end. I was about to give up and reset all the config to my last checkpoint (which was – quite long back) when I decided to try something different:

    I gave Mistral Vibe access to my system — but not control.

    So what I did:

    • I started Mistral Vibe in my /opt directory where all my services are configured (configs, docker-compose.yaml, …).
    • I described the issue like “This service isn’t working as expected. What could be wrong?”
      In hindsight, I should have been more precise and add “Explain in each step why you are checking this and what you learned from the outcome for the next step“.
    • And then I started the (hopefully) fixing session. Mistral asked at every command if it is allowed to be executed once or always in this session. I always allowed “once” because
      • I wanted to be sure it’s not going mad!
      • I wanted to learn WHAT it was doing (and had I instructed properly, I could have read WHY …) and make up my mind about how the error was narrowed down by it – remember: I had run out of ideas myself already.
      • I wanted to see the outcome

    Together ee went through docker logs, checked running processes, connected to the shells in the contianer checking the inside-out connectivity and iterated through possible causes. And at each step, I asked myself:

    • Why are we running this command?
    • What information does it give us?
    • How does this help narrow down the problem?
    • DOES IT BREAK ANYTHING?

    In the end, Mistral identified a conflicting configuration — one I had overlooked, and even if I had seen it, I wouldn’t have had a clue which of the values would take precedence over the other …

    In the end, the service started working, and I had a clear summary of what went wrong. Luckily I didn’t have to ask a “give me a summary what went wrong” but it did it by itself. And I had learned a couple of ways to debug such scenarios.

    Learn, Not Just Fix

    This experience was prette new to me! The trick wasn’t to blindly trust the LLM or fully hand over control. Instead, it was about using the LLM as a learning partner by:

    1. Giving it context (logs and configs)
    2. Staying in the loop by executing commands one after the other, with enough time for me to understand what was going on.
    3. Learning from the process by watching the possibilities.

    Honestly: my past experiences with Linux debugging withLLMs were … well .. disastrous at best. But I never gave them enough context and this problem had a good scope because it HAD to be one of the config files in this directory and not some system setting SOMEWHERE else. – So there was also a good amount of paranoia involved as well.

    But this time and this way, it went well, I learned something, it worked, I have not created a dependency …

    And each time I allowed to read a .env file, I noted it to change all credentials n this file afterwards … Even if I pay my subscription and learning from is disallowed .. Mistakes can happen everywhere. Better be safe than sorry.

    Fediverse Reactions
  • Local Models for Coding

    Coding agents are becomming more and more popular (well – I guess). Yet the dependece to LLM providers is pretty obvious: Starting in June, GithubCopilot changed to usage-based billing. In April and June Anthropic’s Fable 5 and Mythos 5 being available, then not, then limited, … And since then I read more and more about locally hosting models.

    To be honest: I was quite sceptical and surprised at the same time.

    Sceptical because the larger models were always told to perform ways better and surprised to see those extremes: The outcry of Fable 5 (large frontier model) not being available – combined with “let’s self host models” (meaning a fall back to WAAYS smaller models – so why this outcry of Fable not being available …).

    But then also reading articles about “Best open-weight models for coding” (09 July, 2026) … So … do we really NEED the big models? Is it just hype? And how much (V)RAM and GPU do I need?

    Luckily, Birgitta Böckeler did a comparison in two articles where she’s testing different models:

    Overall though, the agentic coding capabilities are definitely very far away from what I’ve now become used to with bigger models.

    Check out her articles. I would say they are worth reading to get an impression of what you could expect.

    Fediverse Reactions
  • The Myth of the 2-Day Workweek: What History Tells us about AI and Labor

    I’ve heard this claim now really often: at conferences, in keynotes, even in casual conversations: “With AI, we’ll soon only need to work two or three days a week.” The narrative is seductive, I admit: technology will finally liberate us from the grind, freeing up time for creativity, family, leisure, hobbies – who would not want that? Who would not want to believe that? It sounds like StarTrek! Silicon Valley CEOs, futurists and tech optimists repeat this vision again and again, as if it were just a matter of time AI renders the 40-hour workweek obsolete.

    But at some point, I got suspicious. Not because I doubt the power of AI or so – it’s clearly heavily impacting industries. From manufacturing to customer service, IT itself, everything that has to do with digital imaging … GenAI is transforming several processes. — No, I got suspicios because I started to notice that every time someone made this claim, it was framed as a natural consequence of technological progress. As if history had a built-in mechanism to ensure that efficiency gains would automatically translate into more free time for workers. And that’s when I wondered:

    Why should a company just pay me the same amount even though I’m working significantly fewer hours? Did that ever happen before?

    Did the major technological revolutions – from the Industrial Revolution to the rise of computers (or the internet) – just simply lead to a work time reduction? I never heard or read about that. And in fact … usually productivity surged, but working conditions only improved when workers, unions, and governments forced the change to happen. Everything else would have been surprising! Businesses are profit-driven and not charitable organizations. Let’s look at historical examples to show how technological progress has not automatically reduced working hours.

    The Industrial Revolution

    The Industrial Revolution (late 18th to mid-19th century) introduced mechanized production, steam power, and factories. These innovations dramatically increased output, making goods cheaper and more abundant than ever before.

    Working Conditions

    Despite the productivity gains , working conditions weren’t so great (see for example Life in Great Britain during the Industrial Revolution). Working hours (12+ hours per day, often only with Sunday off) didn’t decrease and even child labor continued to exist.

    Working Hours Decrease

    The 8-hour workday didn’t emerge naturally from technological progress. It was mainly the result of decades of labor struggles, Unions, Strikes and Labor Movements, reformers and politicians (Eight-hour day movement). Fun Fact from the Wikipedia page:

    “A 12-hour day was reintroduced [in Germany] by a right-wing government during the occupation of the Ruhr and subsequent hyperinflation crisis in 1923″ (Link)

    The Computer Age

    The late 20th century brought the rise of computers, automation, and digital technology. The innovations transformed industries, from manufacturing to office work, making production faster and more efficient. – That sounds like GenAI-light, doesn’t it?

    But the whole efficiency gain did not materialize in a quick, massive drop in working time (Charts from ourworldindata.org). The increased productivity was great, no doupt! But the impact to working time, … Between 1970 and 2020, U.S. productivity rose quite a bit, but the average workweek barely changed, hovering around 40 hours (Our World in Data, OECD).

    Conclusion

    Working times HAVE reduced massively in the last 150 years (see here). There’s no doubt about that. But this was rarely down to the goodwill of the companies that have benefited from technological progress.

    This raises the question: Why is the narrative of the 2-3 day workweek still being promoted so repeatedly when it’s historically untenable? Is it naivety, tech optimism, or deliberate intent? Maybe all of them. – Undoubtedly, it fuels and legitimizes the agenda of the major tech companies (well, the investments have to pay off sooner or later!). And at the same time, it diminishes the discussion about government regulation of the impact of AI.

    The next time you hear someone claim that AI will soon reduce our workweeks to 2-3 days, ask yourself: Who benefits from this story? And more importantly: Who’s really fighting for our time?

    Fediverse Reactions
  • KI-Kataog.de An Independent Directory for AI Tools

    Finding the right AI tool can be overwhelming. With new solutions emerging constantly, it’s easy to get lost.

    KI-Katalog.de offers an alternative: an independent, German-focused directory that compares over 1,000 AI tools. Including pricing information and compatibility with the DSGVO / GDPR.

    https://ki-katalog.de

    Fediverse Reactions
  • BuzzFeed’s AI Gamble Backfired – The pivot to AI isn’t going so great

    I just came across the article BuzzKill – BuzzFeed Nearing Bankruptcy After Disastrous Turn Toward AI and thought it might be worth sharing. Not because of schadenfreude but as a reminder that going all-in on a technology that you haven’t fully mastered is a gamble that risks the company’s existence.

    The article starts with …

    In January 2023, BuzzFeed CEO Jonah Peretti announced in a memo to staff […] a hard pivot to AI […]. two months after OpenAI unveiled […] ChatGPT

    “What could possibly go wrong” is literally the only thing that comes to my mind.

    It’s so insane because they didn’t just bet on AI. They bet against their own strengths: human creativity, editorial judgment, and the hard-won trust of an audience.

    They had a Pulitzer-winning investigative unit (!) and content machine that understood what people wanted. The issue might have been that Facebook changed the rules and BuzzFeed’s response wasn’t adaptation — it was surrender. Instead of doubling down on what made them unique (award winning journalism), they doubled down on what made them cheap. A desparate race to the bottom that you simply can’t win against a behemoth like Facebook.

    BuzzFeed’s story isn’t about AI failure. To me, it’s a testament about

    • mistaking hype for strategy
    • automation for innovation, and
    • desperation for disruption.

    The next time someone declares a ‘hard pivot’ to the latest flavor-of-the-month tech (keep in mind WHEN this pivot was decided!), let’s remember BuzzKill: Are they innovating — or just paying Silicon Valley to automate themselves into obsolescence.

    Read the article on futurism.com: https://futurism.com/artificial-intelligence/buzzfeed-disastrous-earnings-ai

    Fediverse Reactions
  • One of the most potentially dangerous failure modes of LLM-based coding assistants …

    I really like having Jason Gorman’s blog posts in my RSS reader. Especially when he’s highlighting some critical issues with AI assisted coding.

    This paragraph for example really made me smile:

    For example, a common strategy they use when they’re not able to fix a problem they created is to delete failing tests, or remove testing from the build completely,

    What Makes AI Agents Particularly Dangerous Is “Silent Failure”

    I just had to smile because I probably would have been quite surprised to see that happening.

    But okay. It’s another thing I put onto my mental list to care about when doing AI assisted coding.

    Check out his post: https://codemanship.wordpress.com/2026/02/27/what-makes-ai-agents-particularly-dangerous-is-silent-failure/

    Fediverse Reactions
  • Agent finops

    The start of this article made me laugh:

    The first time my team shipped an agent into a real SaaS workflow, the product demo looked perfect. The production bill did not.

    FinOps for agents: Loop limits, tool-call caps and the new unit economics of agentic SaaS

    I wasn’t laughing out of malicious joy, but as it’s something that quite a lot of people don’t think about when they start AI / Agentic coding: Whenver you give the program flow the opportunity / ability to make queries on it’s own judgement, think about the case that the thing (I don’t want to call it AI) could run into an infinite loop. And every query to the LLM generates real costs.

    And with “costs” I don’t just mean “a busy CPU” like in traditional infinite loops. More like “costs” in terms of Lambda Horror Stories: Suddenly, every loop querying your LLM provider hit’s your budget.

    And that might get even more interesting in case of vibe coding, where such an infinte loop is burried in thousands of lines of auto-generated code. Oh we have interesting times ahead!

    Check out the article: https://www.infoworld.com/article/4138748/finops-for-agents-loop-limits-tool-call-caps-and-the-new-unit-economics-of-agentic-saas.html

  • AI amplifies DevOps

    DevOps is the backbone of modern software delivery. The latest insights from Developer Tech on Perforce’s AI-driven tools highlight why — again.

    70 percent of the organisations report their DevOps maturity materially affects their success with AI. Rather than replacing established delivery practices, proper foundational workflows serve as the prerequisite for scaling these capabilities.

    Perforce Software: How AI is amplifying DevOps | developer-tech.com

    What’s remarkable out isn’t just the AI integration. It’s how it amplifies DevOps’ core strengths: bridging team gaps, automating repetitive tasks, and ensuring reliability at scale.

    Collaboration, Speed, and Resilience

    DevOps thrives on collaboration, speed, and resilience. AI doesn’t replace these principles — it supercharges them. Perforce’s tools streamline code reviews, predict deployment risks, and optimize workflows. They’re not just upgrades. They’re force multipliers for teams drowning in complexity.

    It’s not an “either or”

    The article also points out that DevOps without AI risks obsolescence. Manual processes become bottlenecks – but AI-driven insights — whether in testing, monitoring, or incident response —turn the huge amount of data into actionable insights.

    That’s not hype. It’s a competitive edge. The future isn’t about choosing between DevOps and AI. It’s about how well you integrate them.

    Check out the article: https://www.developer-tech.com/news/perforce-software-how-ai-is-amplifying-devops/

    Fediverse Reactions
  • Rules don’t always work on AI agents

    A recent Mastodon post from @solomonneas highlights an annoying issue: an AI agent pushed to the main branch 12x, despite clear instructions not to.

    […] My agent pushed to main 12 times despite explicit instructions.

    Fix: git pre-push hooks on 39 repos. Agent can’t push code to main because git rejects it. No willpower needed. […]

    Mechanical enforcement > written instructions.

    @solomonneas@infosec.exchange

    The post really speaks for itself:

    • Agent rules are not 100% reliable
    • KISS: Keep it Simple, Stupid. Don’t make it more complex than necessary. (= don’t start fiddling around with additional AI)