Category: Analyst Corner

  • Free Tiers and Open Source LLMs – Mana for Developers, Platform Engineers and QA

    Free Tiers and Open Source LLMs – Mana for Developers, Platform Engineers and QA

    Development rarely follows one straight path. You sketch ideas, prototype, test, swap tools, iterate, and repeat. The increasing availability of free, limited-use AI tiers and locally run open-source AI LLMs is accelerating that loop. These tiers are not marketing fluff. They are practical on-ramps for developers and engineers. They offer the freedom to test, compare, and refine without upfront cost.

    Free Tiers For The Taking

    GitHub provides a free Copilot tier: up to 2,000 code completions per month, plus 50 premium requests (chat / “agent mode”) interactions. Available in VS Code, Visual Studio, JetBrains IDEs, and more. It includes access to Claude 3.5 Sonnet and GPT-4o models. (https://github.com/features/copilot/plans, https://docs.github.com/copilot/concepts/copilot-billing/about-individual-copilot-plans-and-benefits)

    Anthropic’s Claude is free to use on the web, iOS, Android, and desktop with usage limits. Its API is not free. (https://www.anthropic.com/pricing, https://docs.anthropic.com)

    OpenAI’s GPT-5 is available to free ChatGPT users with strict usage caps. Its API requires prepaid credits, minimum $5. (https://www.wired.com/story/openais-gpt-5-is-here, https://help.openai.com/en/articles/8264644-how-can-i-set-up-prepaid-billing)

    New AWS accounts get up to $200 in credits valid for six months. Generative AI services like Bedrock move to pay-as-you-go after that. (https://aws.amazon.com/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan)

    Google Cloud AI Studio and Firebase are free to access. The Gemini API has a free tier with lower rate limits; paid tiers offer higher capacity. (https://ai.google.dev/gemini-api/docs/pricing)

    Cursor offers a free plan with usage limits. Windsurf provides monthly prompt credits across free and paid plans. (https://cursor.com/pricing, https://docs.windsurf.com/windsurf/accounts/usage)

    Why This Matters to Developers

    Flexible Model Switching: You can test multiple models (GPT-4o, Claude) without changing workflow or integration. That removes friction from choosing the best fit for your task.

    Rapid Prototyping: No billing setup. You can try ideas, logic paths, and prompt styles immediately.

    Cost-Effective Scaling: Validate with free tiers. When it works, choose paid tiers intentionally, not by guesswork.

    Hybrid Model Approaches: Use GPT-5 or o1 for reasoning tasks, then cheaper models like Llama for bulk processing. Free access to each lets you refine that pipeline.

    AI in Your DevOps Pipeline

    Free models pair neatly with toolchains:

    • GitHub Actions could use a free model to auto-generate release notes, analyze test failures, or lint code.

    • Microsoft Azure DevOps can use GitHub Copilot Chat and Azure OpenAI Service to assist in pipeline creation, YAML authoring, and automated documentation generation.

    • Google Cloud Build can use Gemini to generate deployment docs or config templates.

    • AWS CodePipeline could incorporate Bedrock calls for compliance checks or IaC validation.

    • CLI tools across platforms can invoke these models for tasks like refactoring YAML, generating manifests, or annotating dashboards.

    These are just a few examples of how these tools can be used with AI models. Running these in staging pipelines gives you low-risk experimentation before you roll out to production.

    Go Local

    Open-source and locally run LLMs such as OpenAI’s GPT-OSS, Meta’s Llama 3, and Mistral’s Mixtral are giving developers new options for building AI-driven applications without relying entirely on cloud APIs. These models can be downloaded, hosted on personal hardware, or deployed within private infrastructure, allowing full control over data, latency, and customization.

    Running models locally means teams can experiment with fine-tuning for domain-specific tasks, integrate AI into environments with limited internet connectivity, and meet strict compliance or privacy requirements.

    While local models may not match the scale or capability of their largest cloud-based counterparts, they offer a powerful balance of cost efficiency, adaptability, and independence that can be especially valuable for development, testing, and edge computing scenarios.

    Who Else Should Care

    It’s not just about developers: Test Engineers can generate synthetic test data, edge-case inputs, and test scripts. DevOps Engineers can automate pipeline scaffolding, log review, and incident summaries. Platform Engineers can prototype developer automation, self-service templates, and internal documentation.

    Getting early hands-on experience helps you understand where AI adds value and where it doesn’t.

    If you code, automate, build pipelines, test, or run platforms, start exploring these free AI tiers today. Plug models into your editor, Actions workflows, test frameworks, and CLI tools. Use them on real tasks, not just sample prompts. Track what works, what stumbles.

    Experimentation costs almost nothing. Delay could cost your team time and innovation.

    Recent articles by Mitch Ashley:
    Kubernetes, AI, APIs, and YAML – A Future 2.0?
    We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves
    AI and You: Don’t Wait… Or Be Weight

     

    Mitch Ashley is VP and Practice Lead of Software Lifecycle Engineering at The Futurum Group. The voice of “AI across the SDLC”, Mitch is a serial-CTO, speaker, advisor, entrepreneur, and product creator. He leads analyst coverage of the Software Development Cycle (SDLC), with emphasis on AI-native and agent development, cloud-native, DevOps, platform engineering, and software security.

    See Mitch’s analyst research on the Futurum website.

    Subscribers can access Mitch’s Software Engineering Lifecycle practice, decision-maker data, insight reports, and advisories through the Futurum Intelligence Platform.

  • We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves.

    We’re Not Being Replaced. We’re Inventing What Comes Next, Including Ourselves.

    After graduating with degrees in computer science and business in hand, I entered the software industry with the energy and optimism of someone ready to create great software. My first job wasn’t called “software developer”—I was hired as a systems engineer. And that title mattered, a lot more than I first realized.

    Right after being hired, I was sent through a formal systems engineering program and was immediately placed on a project that would become the foundation of a new division: Future Banking Systems. After two years of heads-down redesigning and building banking systems in Garden City, New York, I was shipped to Dallas, Texas, for an “exciting opportunity” in a new group just being formed.

    Turns out the new group began with me and one salesperson, starting from zero, to form the foundation for a group that would create banking systems for an industry experiencing massive disruption due to deregulation. Our current customers were disappearing because of acquisitions, which were rolled up to become financial institutions that were beyond the scale and capabilities of our current products and business model.

    Inventing Without A Net

    There was no approved business plan. No product definition documents. No product roadmap. No backlog. Just a vision document, leaders with foresight standing beside us, and the knowledge that the industry was headed somewhere new and our current path wouldn’t get us there. However much we thought it would cost, we instinctively knew it would probably cost 4x more. It was our responsibility to build systems for much larger financial institutions in an industry still very much in flux.

    We weren’t just creating next-gen banking applications. We were inventing systems for where the industry was going to be, not where it was. It was early, messy, and it was foundational. And it eventually led me into my first experiences with AI, developing in Lisp, Prolog, and expert systems while teaching database theory. Those formative experiences taught me something that’s stayed with me ever since: Creating software isn’t just about shipping code. It’s about inventing what comes next.

     

     

    That mindset—the instinct to look ahead, to build with intent—is what real engineering is about.

    Today’s AI Moment

    Fast forward several decades…We’re now in one of the most disruptive and transformative moments in software history. AI can write code, scaffold entire applications, generate test cases, and devise solutions to problems in seconds. Developers are using copilots, models, and mega-prompts to accelerate their work at a pace we’ve never seen. And agents are coming online, backed by models with reasoning capabilities, to automate development tasks and tackle harder problems.

    And with this combination of exuberant expectations and feverous innovation in AI, comes a familiar claim: “We won’t need developers anymore.”

    I couldn’t disagree more.

    Yes, AI can generate code. But just code isn’t the application, system, or product. Underlying every working application is a complex system. There are architectural decisions, engineering challenges, design trade-offs, failure modes, built-testing, security constraints, integration boundaries, long-term lifecycle concerns, and, oh yes, operability. Those don’t just come from better context and prompts.

    AI massively expands what’s possible. And software development is the landing zone for AI innovations. (See Tech Vendors See the Future – Software Development Is the Agentic AI-Proving Ground.) But someone still has to know what to build, why to make it, when to create what, and for whom, and how to keep it working when the world around it continuously changes. Today’s design decisions are tomorrow’s technical debt.

    What Software Engineering Really Means

    Leading software teams taught me that engineering is the art behind software. It’s where experience, discipline, creativity, and instinct converge.

    When a team is deep in shipping the release with heads down, checking in code, solving bugs, driving toward delivery, engineering leaders raise periscope. You have to scan for the problems that haven’t surfaced yet, the threats and opportunities forming at the edge of the horizon, and verify that our instrumentation matches course, depth, and speed. That’s engineering. It’s not just watching the project plan or tracking how many issues are in Jira. It’s reading the signals others might miss.

    I’ve learned to trust that instinct: the kind of bugs we’re finding, the questions we’re not asking, the problems we haven’t had to solve yet. These are clues. They tell me if we’re still on track, or if we are behind, even when the project status says otherwise. Engineers know to pay attention to how we’re progressing, not just what we’ve done and how fast.

    Engineering is more than shipping by a deadline. It’s knowing when the real blockers will hit and deciding when to face them. It’s applying instinct in tangible ways: adjusting the design, pulling forward a hard dependency, probing deeper when something hard is too easy. This isn’t about perfectionism. It’s about intent. It’s about leading a system into existence, not following a script or just building what’s asked.

    We Lead the Loop

    I’ll say it again: I take issue with the idea that AI will simply replace developers. We hear the phrase “human in the loop” tossed around like it’s some kind of failsafe. But that’s not what this is.

    Humans aren’t destined to just be in the loop, supervising AI. We lead the loop, and where the loop is going.

    We define the problem. We decide what great, good, and bad looks like. We understand when to trust, when to probe, when to double-check, and when to ask if we are asking the right questions. We raise the periscope. And that’s what this moment means more than ever.

    Skating to Where the Puck Will Be

    AI is where the puck is. But engineering? That’s how we skate to where the puck will be.

    And more than that, it’s how we set the puck on a new arc entirely. That’s what we’re here to do now: not just follow the capabilities of AI, but lead us into new innovations in how software is created, new architectures, new apps, and systems we wouldn’t have imagined. We are the force. AI is the force multiplier.

    That’s what excites me about this moment. We’re not automating ourselves out of relevance. We’re stepping into a higher role: engineers with expanded reach, clearer intent, and tools that extend our vision—not replace it. The AI IDE of the (near) future looks more like the game Starcraft, engaging through language, voice, and keyboard, versus today’s code editor and NLP interface hybrid.

    We’re Being Called Forward

    For those of us who’ve built real systems, who’ve led teams through impossible delivery schedules, who’ve watched the intangibles reveal deeper design flaws—we know what this era asks of us.

    It’s not about writing every line. It’s about knowing that what we are doing ultimately matters.

    It’s about being the one who sees the storm before it hits. The one who adjusts course, not because it’s easy, but because it’s necessary.

    AI will continue to evolve. And so will we. So will all the roles across the software development lifecycle. AI is raising the bar for engineering, but remember…

    We lead the loop.

     

    Mitch Ashley is VP and Practice Lead of Software Lifecycle Engineering at The Futurum Group. The voice of “AI across the SDLC”, Mitch is a serial-CTO, speaker, advisor, entrepreneur, and product creator. He leads analyst coverage of the Software Development Cycle (SDLC), with emphasis on AI-native and agent development, cloud-native, DevOps, platform engineering, and software security.

    See Mitch’s analyst research on the Futurum website.

    Subscribers can access Mitch’s Software Engineering Lifecycle practice
    decision-maker data, insight reports, and advisories through the Futurum Intelligence Platform.

  • DevOps Must Learn From CrowdStrike’s Outage

    DevOps Must Learn From CrowdStrike’s Outage

    The CrowdStrike outage on July 19, 2024, is a stark reminder of DevOps practices’ critical role in deploying updates to maintain the security and reliability of applications and systems. While the underlying software defect was the immediate cause, the broader issue lies in the deployment process that allowed a severe flaw to impact a global customer base.

    Key Takeaway: To maintain trust and reliability in today’s complex software, security, cloud and data center ecosystem, we must prioritize robust, measured deployment strategies.

    The ability to rapidly deploy software updates across large, diverse environments is necessary for many software offerings. Updates can have unintended and, rarely, catastrophic consequences if done improperly or without diligent governance. The CrowdStrike incident highlights the importance of adopting more sophisticated deployment strategies—such as staggered, A-B, canary and phased rollouts—to minimize the blast radius of any potential defects. By initially releasing updates to a smaller subset of systems, organizations can validate changes in real-world conditions, catching issues before they affect the entire user base. Then, the update can be released in stages to increase the number of customers. This approach significantly reduces the risk of widespread disruptions and ensures that problems are contained and addressed quickly.

    Additional Resources

    Let’s move beyond this single CrowdStrike incident and focus on the lessons we need to learn to avoid repeating them in the future. As software delivery becomes faster and more automated, the need for meticulous, well-orchestrated deployment processes has never been greater. It’s not just about preventing the next outage; it’s about building a culture of reliability and accountability in every step and layer of the software supply chain. The urgency of this need cannot be overstated.

    Customers of software vendors bear a crucial responsibility in ensuring their systems remain secure and reliable. They should not rely on automatic updates without oversight, as doing so can leave their environments vulnerable to unforeseen issues. Organizations need to implement their own vetting and validation processes, testing updates in controlled environments before widespread deployment. This added layer of scrutiny helps catch potential problems early and prevents disruptions from unquestioningly trusting every update. In this way, customers play an active role in maintaining the integrity of their systems and minimizing risks.

    This is our call to action: To maintain trust and reliability in today’s complex software, security, cloud and data center ecosystem, we must prioritize robust, measured deployment strategies.

     


    Mitch Ashley is Chief Technology Advisor with The Futurum Group and CTO of Techstrong Group’s tech media platforms covering DevOps, cybersecurity, AI, cloud native, cloud infrastructure, platforms and ITSM.

    Mitch’s analyst research is available on FuturumGroup.com and TechstrongResearch.com.