Month: April 2026

GitHub is moving its Copilot coding assistant to a usage-based billing model, replacing fixed subscription pricing with consumption-based charges as demand for AI-driven development workloads increases. The change, announced in a company blog, will take effect on June 1 and will apply to Copilot Pro, Pro+, Business, and Enterprise plans. Under the new model, usage will be measured through “AI credits,” reflecting the compute resources consumed during interactions with the service. “Today, we are announcing that all GitHub Copilot plans will transition to usage-based billing on June 1, 2026,” Mario Rodriguez, GitHub’s Chief Product Officer, wrote in the blog post. “Instead of counting premium requests, every Copilot plan will include a monthly allotment of GitHub AI Credits, with the option for paid plans to purchase additional usage.” There will be no change to base subscription prices, and every plan will include a monthly allotment of credits matched to its price, and once that allotment is exhausted, customers can either buy more or stop, the blog post added. Token consumption will be charged at the published API rate of the underlying model. The change marks the second pricing recalibration for Copilot in less than a year. GitHub introduced premium request limits in June 2025, capping Pro users at 300 monthly premium requests and Enterprise users at 1,000, with overages billed at $0.04 each. It also follows a week of tactical changes. The company tightened limits on Copilot Free, Pro, Pro+, and Student plans last week and paused self-serve purchases of Copilot Business, framing both as short-term reliability measures while it stood up the new metering infrastructure. Rodriguez said those limits would be loosened once usage-based billing is in effect. Why GitHub is changing the model Rodriguez framed the move as a response to how Copilot is being used today, rather than a price increase. “Copilot is not the same product it was a year ago,” he wrote in the blog. “It has evolved from an in-editor assistant into an agentic platform capable of running long, multi-step coding sessions, using the latest models, and iterating across entire repositories. Agentic usage is becoming the default, and it brings significantly higher compute and inference demands.” Under the existing premium request unit (PRU) model, a quick chat question and a multi-hour autonomous coding run can cost the user the same amount, the post said. “GitHub has absorbed much of the escalating inference cost behind that usage, but the current premium request model is no longer sustainable,” Rodriguez wrote. “Usage-based billing fixes that. It better aligns pricing with actual usage, helps us maintain long-term service reliability, and reduces the need to gate heavy users.” Sanchit Vir Gogia, chief analyst at Greyhound Research, said the sustainability framing was accurate but incomplete. GitHub was managing its own inference cost exposure, he said, and the per-seat model was breaking under agentic workloads at the same time. “The first is the proximate cause. The second is the structural cause of the proximate cause,” Gogia said. A single developer seat, he added, now contained two very different economic profiles. “A quiet user nudging completions across a normal working day. A power user orchestrating hour-long edits on a frontier model with heavy context. The first costs almost nothing to serve. The second can cost an order of magnitude more, sometimes considerably more than that.” A market moving to consumption pricing GitHub is not the first AI coding vendor to pivot to consumption-based pricing. Cursor moved from fixed fast-request allotments to credit pools in June 2025, prompting a public apology and refunds after some users incurred large overages. Anthropic took a similar path with Claude Code, charging on a token basis through its API with capped subscription tiers layered on top. OpenAI followed, moving Codex pricing onto token-based credits. The shift comes as enterprise AI cost overruns are emerging as a recurring CIO concern. IDC has forecast that the Global 1,000 companies will underestimate their AI infrastructure costs by 30% through 2027, a gap that token-metered tooling will widen rather than narrow. Gogia said the pricing convergence across vendors was a workload event being expressed through pricing, not a pricing fashion. He warned that better telemetry from vendors would not, on its own, contain the spend. “The dashboards do not lower the bill. The architecture lowers the bill. The dashboards merely describe the bill while it arrives,” he said. GitHub is keeping its plan prices unchanged across Copilot Pro at $10 a month, Pro+ at $39, Business at $19 per user per month, and Enterprise at $39, with each plan now carrying a monthly pool of AI Credits worth the same amount as the subscription, the post added. GitHub will preview the new bills on customer billing pages from early May, ahead of the June 1 transition.

Xiaomi has released and open-sourced MiMo-V2.5 and MiMo-V2.5-Pro under the MIT License, giving developers another potentially lower-cost option for building AI agents that can run longer tasks such as coding and workflow automation. Both models support a 1-million-token context window, the company said. MiMo-V2.5-Pro is designed for complex agent and coding tasks, while MiMo-V2.5 is a native omnimodal model that can work with text, images, video, and audio. The release comes as agentic AI workloads are putting new pressure on enterprise AI budgets. These systems can burn through large numbers of tokens as they plan, call tools, write code, and recover from errors, making cost and deployment control increasingly important for developers. By using the MIT License, Xiaomi said it is allowing commercial deployment, continued training, and fine-tuning without additional authorization. Tulika Sheel, senior vice president at Kadence International, said the MIT License can make it attractive. “It allows enterprises to freely modify, deploy, and commercialize the model without restrictions, which is rare in today’s AI landscape,” Sheel said. “On ClawEval, V2.5-Pro lands at 64% Pass^3 using only ~70K tokens per trajectory — roughly 40–60% fewer tokens than Claude Opus 4.6, Gemini 3.1 Pro, and GPT-5.4 at comparable capability levels,” Xiaomi said in a blog post. The models use a sparse mixture-of-experts (MoE) design to manage compute costs. The 310-billion-parameter MiMo-V2.5 activates only 15 billion parameters per request, while the 1.02-trillion-parameter Pro version activates 42 billion. Xiaomi said the Pro model’s hybrid attention design can reduce KV-cache storage by nearly seven times during long-context tasks. Xiaomi cited several long-horizon tests, including a SysY compiler in Rust that MiMo-V2.5-Pro completed in 4.3 hours across 672 tool calls, passing 233 of 233 hidden tests. It also said the model produced an 8,192-line desktop video editor over 1,868 tool calls across 11.5 hours of autonomous work. Will enterprises adopt MiMo? Whether Xiaomi’s MiMo-V2.5 models can gain adoption among enterprise developers over closed frontier models for agentic coding and automation workloads will depend on how enterprises evaluate performance, cost, and risk. “When assessing Xiaomi’s MiMo-V2.5 and its variants, enterprise developers should look at the total cost of ownership,” said Lian Jye Su, chief analyst at Omdia. “The TCO consists of token efficiency, cost per successful task, and the absence of licensing costs associated with proprietary models. Closed frontier models may still win on generic tasks, and the hardest edge cases, but open-weight models excel in agentic work that is high-volume in nature.” Pareekh Jain, CEO of Pareekh Consulting, said enterprises should assess MiMo-V2.5 less as a replacement for Claude or GPT and more as a cost-efficient agent model for high-token workloads. “The key benchmark signal is not just accuracy, but tokens per successful task,” Jain said. “Frontier models often reach higher success rates on complex coding benchmarks, but do so with massive reasoning overhead. MiMo-V2.5 is designed for Token Efficiency, meaning it achieves comparable results with significantly fewer input and output tokens.” Jain said that could make MiMo-like models useful as “economic workhorses” for repetitive coding, QA, migration, documentation, testing, and automation workloads, while closed frontier models remain the quality ceiling for the hardest tasks. Ashish Banerjee, senior principal analyst at Gartner, said models like MiMo could materially shift enterprise AI economics for long-horizon agents. “When tasks stretch into millions of tokens, metered proprietary APIs stop looking like a convenience and start looking like a tax on iteration,” Banerjee said. “By contrast, MiMo’s MIT license, open weights, 1M-token context window, and relatively low pricing make private-cloud or self-hosted deployment strategically credible.” However, Banerjee said this does not mean enterprises will abandon proprietary APIs. “Enterprises will continue to use proprietary APIs for frontier accuracy and low-operations consumption, while shifting scaled, repeatable agent workflows toward open models where cost predictability, data control, and customization matter more,” Banerjee said. “In short, long-horizon, high-volume agentic AI will evolve into a hybrid market, with open models like MiMo breaking pure API dependence.” Su added that adoption may face challenges because Chinese-origin models can trigger concerns in regulated Western organizations.

OpenAI has released Symphony, an open-source specification for turning issue trackers such as Linear into control planes for Codex coding agents. Instead of asking an AI tool for help with one coding problem at a time, Symphony is designed to let agents pick up work from an issue tracker, run in separate workspaces, monitor CI, and prepare changes for human review. In a blog post, OpenAI said the system grew out of a bottleneck it encountered as engineers began running multiple Codex sessions. Engineers could manage only three to five sessions before context switching became painful, the company said, limiting the productivity gains from faster coding agents. OpenAI said the impact was visible quickly, with some internal teams seeing landed pull requests rising 500% in the first three weeks. The orchestration layer can monitor issue states, restart agents that crash or stall, manage per-issue workspaces, watch CI, rebase changes, resolve conflicts, and shepherd pull requests toward review, the company said. “The deeper shift is how teams think about work,” OpenAI said. “When our engineers no longer spend time supervising Codex sessions, the economics of code changes completely. The perceived cost of each change drops because we’re no longer investing human effort in driving the implementation itself.” The approach, however, does introduce new problems, according to OpenAI. Agents can miss the mark when given ticket-level work, and not every task is suitable for orchestration. The company said ambiguous problems or work requiring strong judgment may still require engineers to work directly with interactive Codex sessions. Sanchit Vir Gogia, chief analyst and CEO at Greyhound Research, said Symphony should be viewed less as another AI coding assistant and more as an emerging operational layer for software delivery. “It schedules, tracks, retries, reconciles, persists state, and governs flow. In other words, it begins to resemble a lightweight operating system for software delivery, and that resemblance is the story,” Gogia said. Implications for enterprises Symphony is transforming AI from being a developer productivity aid to an execution model for software work, said Biswajeet Mahapatra, principal analyst at Forrester. “Forrester’s research on agent control planes and adaptive process orchestration shows that value increases when agents are embedded into workflows and governed at scale rather than invoked interactively by individuals,” Mahapatra said. Always-on orchestration, Mahapatra added, shifts AI from a personal coding aid to shared engineering infrastructure, helping teams organize work around issues and tasks while reducing developer cognitive load. However, enterprises will need to look beyond output metrics such as lines of code or pull request counts and focus instead on quality, delivery speed, developer experience, and business impact. “Relevant measures include lead time to usable functionality, defect escape rates, rework and code churn, production stability, and perceived developer flow and cognitive load as part of DevEx,” Mahapatra said. “Forrester’s application development research consistently highlights that productivity improvement must show higher quality, faster feedback loops, and clearer business impact, not simply more generated code.” Gogia also warned against treating higher pull request volumes as proof of productivity gains, saying the 500% figure cited by OpenAI should prompt caution rather than comfort. “Generation scales effortlessly, validation does not,” Gogia said. “As output volume rises, the burden of review, testing, and governance rises with it.” Enterprises should also track peer-review friction, downstream rework, escaped defects, post-deployment incidents, recovery time, and the impact on junior engineers, he said. Challenges to overcome According to Neil Shah, vice president of research at Counterpoint Research, one of the biggest challenges for enterprises will be keeping orchestration platforms secure while deciding how much autonomy to give coding agents. Orchestrators will need to handle diverse task types, support handoffs between agents, and provide “total transparency through comprehensive audit trails,” Shah noted. That will become more important as agents begin creating and managing tasks within automated orchestration systems, reducing the amount of direct human oversight. “Enterprises struggle with enforcing consistent security policies, auditability, and risk controls across distributed agents, especially when orchestration is decoupled from existing SDLC and identity systems,” Mahapatra said. Mahapatra added that enterprises will also need to resolve questions around legacy toolchain integration, ownership of agent decisions, traceability of changes, and separation of duties before adopting open agent-orchestration specifications at scale.

While the software development industry has been gorging on large language models (LLMs), the front-end ecosystem has quietly fractured into three competing but interrelated architectural paradigms. Between the dominance of reactive frameworks, the hypermedia-driven simplicity of true REST, and the decentralized resilience of SQL everywhere, developers are no longer just choosing a library, they are choosing where the data lives: at the server, at the client, or both. Three competing architectures, more or less Web developers are long familiar with React and the galaxy of similar reactive frameworks like Angular, Vue, and Svelte. For nearly a decade, these have dominated the narrative with their competition and co-inspiration. HTMX and hypermedia-driven applications have championed a return to the true RESTful thin client, alongside alternatives like Hotwire and Unpoly. We could in a sense see reactivity and hypermedia as two opposing camps. Somewhere in between is the local-first SQL movement, which proposes putting SQL directly in the browser. The waters are a bit muddy because local SQL can and does work right alongside React. It’s still safe to say that a reactive framework paired with a JSON API back end that talks to a datastore (SQL or otherwise) is still the de facto standard. But that monolithic story is starting to fracture in some very interesting ways. Where the weight of the data lies Data of course is the central mass of web applications. Where it lives and how it moves produce the gravity around which everything else must revolve. Each of these architectures proposes to handle that gravity in its own way, with different benefits and tradeoffs. Hypermedia (e.g., HTMX): Keep the data largely off the client. The client is just a visual representation of the server data. The back-end “API” is responsible for producing the data-driven markup. Any kind of datastore can be used by the API server. React and friends: A sophisticated, stateful engine runs in the client, and the developer syncs that state with the back end via RESTful JSON API calls. The back-end server tends to be dumb, responsible largely for just invoking other services to provide business logic or data persistence. Local-first SQL: The data is distributed to the clients, like with React and friends, but in a much different way. Although the data is automatically synced directly to a datastore (like Postgres), the back-end API server is used only for specialized service calls—not for data persistence. To summarize: HTMX: Data gravity is at the server. React: Data gravity is split between the server and the client. Local-first: Data gravity is at the client. Comparing the approaches Besides the technical stats, the developer experience for each of these paradigms is quite different. However, while each paradigm feels different, they intersect in some interesting ways. Let’s take a closer look. React and friends Reactivity is the world we have been working in for 15 years. We’ve got a whole universe of frameworks: React, Angular, Vue, Svelte, Solid, and full-stack variants like Next.js, Nuxt, SvelteKit, Astro, etc. The beauty of these is in the core reactive idea. You have a state that consists of the variables and the UI is updated automatically. The UI is a pure function of state: $UI = f(state). The downside is the gradual, almost imperceptible layering of intense complexity over the top of it all. This complexity seems at first just incidental, but it is in fact a direct outcome of the basic premise: building a state engine on the browser. The result is you have two states: the browser and the database. The reactive engine becomes a negotiation layer. Add to that the various inherent complexities of managing the browser state, and the result is quite a lot for front-end developers to wrap their heads around. In the effort to manage such complexity, wring more performance, and improve developer experience, we have wound up with quite a sprawling empire of tools and techniques. Even just for React we have React Server Components, complex state-management libraries like Redux or Zustand, and orchestration layers like TanStack Query for manual cache invalidation. On the back end, we talk to JSON APIs (or GraphQL), which can become unwieldy as a kind of boilerplate layer, but has in its favor an almost universal understanding. HTMX and similar (Hotwired, Unpoly) HTMX is like using HTML that has superpowers. You can do a huge amount of what you use reactive frameworks for, including all the AJAX and a lot of the partial rendering and effects, with just a few extra attributes sprinkled judiciously. You spend a lot of time on the server, using a template engine like Pug, Thymeleaf, or Kotlin DSL. These are where you bring together the data from the persistence service and combine it with markup. The markup you generate includes the HTMX attributes. You tend to decompose the templates, i.e., break them up into dedicated chunks. The idea is you want to have a chunk that can be used within the larger UI to create the whole layout, along with the ability to use that chunk alone when (and if) it is called upon for an AJAX response. Hypermedia with HTMX is a very powerful model. You are actually using REST, meaning you are transmitting a representational state. Hotwire and Unpoly are similar libraries. In the case of Hotwire, you can achieve quite a bit of functionality and performance even without changing your HTML, just by using Turbo Frames to intercept link clicks and form submissions, automatically turning standard page navigation into partial DOM updates. The beauty of the hypermedia approaches is that you gain a lot with a little. You are staying as much as possible in HTML, the very poster child of simplicity. On the other hand, you are giving up some of the sheer sophisticated power of reactive frameworks. Local-first apps Local-first development is the new kid on the block. Like React and friends, local-first keeps the data in two places, but it does so in a radically different way. In its most essential form, it means running a database in the browser that is kept aligned with the remote datastore via a syncing engine. This kind of thing has been done before with NoSQL databases like CouchDB or with the IndexedDB API, but the modern browser takes it to another level with a Wasm-based database engine, like SQLite. The user gets a small view of the full data, called a partial replication or a bucket (also called a “shape”). The front-end app interacts directly with that data, and the infrastructure automatically does the work of keeping everything synced. A big benefit here is strong offline support (because the client device is carrying around an actual database). This is a massive departure from the request-response cycle. In local-first, you don’t fetch data; you subscribe to it. The network becomes a background daemon that reconciles local and remote state using CRDTs (conflict-free replicated data types). CRDTs ensure that if two users edit a task while offline, the merge is seamless rather than messy. There is also a degree of simplification in using SQL everywhere, though that is offset by a rather unfamiliar and involved architectural setup. A syncing engine like PowerSync or Electric SQL is required, and it has a set of rules that must be maintained. Plus the auth and interaction between the database and the syncing engine must be configured. Local-first eliminates both the API server and the HTML template server. It pushes the entire data negotiation layer into the automated syncing engine that runs off developer-defined rules. Interestingly, local-first SQL can be used as a data driver for React (and other reactive engines) or plain vanilla HTML + JS. As such, it is an interesting alternative take on the architecture of the web, which is agnostic about the front end. Perhaps the strangest arrangement to contemplate is using HTMX and local-first SQL together. This is like a mad scientist architecture, which of course means developers are doing it. In this setup, the back-end HTMX template engine is actually a service worker running the SQL engine. In theory, you get the simplicity of HTMX and the ultra-speed + offline functionality of local SQL. Reactivity, hypermedia, or local-first? How to choose We remain in the era of the default choice being React plus a JSON API. From there you might experiment with innovative frameworks like Svelte or Solid. If you are looking for an ingenious way to leverage RESTful simplicity, HTMX or Hotwired are must-tries. Local-first SQL is an exotic animal, fit for the likes of Linear or Notion right now, but somewhat daring for most of us doing standard production work. More broadly, the emergence of this trilemma signals the end of the “one true way” for web development. We are moving away from the library wars and into a world of architectural choice. The choice between reactivity, hypermedia, and local-first isn’t just about code. It’s about where you want to place the data. If you want the data to be a server-side document, choose hypermedia. If you want the data to be a shared memory state, choose reactivity. If you want the data to be a distributed database, choose local-first. And of course, it is possible to put the approaches together to strive for a blend of the right benefits for your project. As the JSON-over-the-wire monolith continues to fragment, the best architects won’t be the ones who know the most hooks or the most attributes. They will be the ones who understand the weight of their data and choose the architecture that lets the data move most freely. The framework wars are over, but the battle for the network has just begun.

One of the more dangerous assumptions in the current AI market is that broad adoption means meaningful adoption. It does not. Much of what enterprises call AI transformation is, in fact, AI experimentation focused at the edge of the business, in systems and workflows that support employees but are not central to how the enterprise actually operates. These include calendaring, scheduling, meeting summaries, employee communications, customer messaging, document generation, internal assistants, and similar productivity-oriented use cases. Those applications may be useful, but they are not core applications that directly run the business and determine whether the company performs well or poorly. Inventory management, sales order entry, logistics execution, supply chain planning, procurement, warehouse management, manufacturing operations, and financial transaction processing belong in this category. If these systems fail, the business feels it immediately through delayed orders, lost revenue, rising costs, poor customer outcomes, and weakened operational control. McKinsey reports that AI is most often used in IT, marketing and sales, and knowledge management, with common use cases including content support, conversational interfaces, and customer service automation. It also says most organizations are still in experimentation or pilot mode, and only 39% report any enterprise-level earnings impact. This supports the idea that adoption is broad, but deep, core-business transformation is still limited. That distinction is critical because it exposes that most enterprise AI efforts are not going into the systems that define operational performance. They are going into the systems that are easiest to automate, easiest to pilot, and easiest to talk about in a board presentation. The market is flooded with productivity enhancements that create movement around the business while leaving the business itself mostly untouched. The problem here is that it’s often much harder to prove the value of AI in meaningful business terms. When AI is directed toward applications that are less strategic and not central to the business, the benefits tend to be indirect, diffuse, and difficult to connect to outcomes that matter. Saving time in drafting emails, summarizing meetings, or streamlining internal collaboration may sound positive, but those gains often remain anecdotal. They rarely translate cleanly into measurable improvements in margin, cycle time, service levels, or revenue generation. In other words, the farther you move from the operational core, the fuzzier the business case tends to become. Why enterprises avoid the core If core applications are where the larger value sits, why are enterprises not making them the center of AI strategy? The answer is simple enough: More is at stake, the costs rise quickly, and confidence remains low. Applying AI to edge applications usually carries limited downside. If a meeting summary is incomplete or an internally generated document needs revision, the business survives. A person steps in, makes corrections, and moves on. The failures are manageable. That is one reason shadow AI has spread so quickly. Employees can experiment with relatively little organizational risk because the blast radius is usually small. Core systems are entirely different. If AI makes flawed decisions in inventory allocation, order processing, logistics routing, or supply chain forecasting, the impact is immediate and expensive. It can mean stockouts, excess inventory, missed shipments, poor customer service, broken supplier coordination, and measurable financial damage. These systems do not tolerate loosely governed experimentation. A bad result here is not a minor inconvenience. Enterprises know this. Many are not confident enough in their own ability to design, govern, and support AI systems that can operate safely within business-critical processes. Frankly, that caution is justified. Too many AI projects are still based on generic strategies, templated approaches, and weak data integration. They are rushed in order to demonstrate something flashy rather than something operationally useful. The result is a parade of pilots, proofs of concept, and isolated wins that never make it into the systems that matter most. The current AI platform market adds to the challenge. Enterprises are being handed powerful pieces of technology, but often without a coherent path to operational value. In many cases, they still need to assemble the models, workflows, governance, data layers, and integration points themselves. That engineering burden is already heavy at the edge. In the core, where systems are older, more customized, and more intertwined with business processes, it becomes even more difficult. It is no surprise that enterprises often choose the safer route and automate around the business before they attempt to automate within it. Edge use cases are also attractive because they are visible and politically easy to support. Executives can tout progress because employees are using AI tools. Vendors can point to adoption numbers and usage metrics. Consultants can highlight quick wins. But visibility is not the same as impact. In fact, the emphasis on visible but low-risk use cases may be delaying the harder work required to produce real enterprise value. Finding real AI value Enterprises are unlikely to find real transformation until AI improves the systems that determine how the enterprise performs. Better demand forecasting. Smarter inventory positioning. Faster and more accurate sales order processing. Improved logistics coordination. More adaptive supply chain decisions. Better procurement timing. Stronger resilience in fulfillment operations. These are not cosmetic improvements. They affect the outcomes that executives, boards, and investors actually care about. This is also where value becomes easier to measure. In edge applications, benefits are often framed in soft language around convenience, efficiency, or time savings. In core applications, the metrics are tangible. Did order accuracy improve? Did cycle time drop? Did stockouts decline? Did transportation costs fall? Did customer service levels rise? Because core applications sit closer to the economics of the business, AI deployed there has a much clearer chance of proving itself. None of this means enterprises should ignore edge applications altogether. There is still practical value in reducing low-level manual work and giving employees better tools. But those efforts should be viewed as supporting use cases, not the center of strategy. Enterprises need to stop confusing easy automation with strategic transformation. The priority should now be a smaller number of AI initiatives aimed directly at business-critical systems, supported by better data, stronger governance, internal expertise, and realistic operational design. Until that happens, much of enterprise AI will remain what it is today: interesting technology circling the edges of the business while the real opportunity sits untouched in the middle because success is harder and risk is greater.

JavaScript remains one of the most in-demand programming languages for web development—and that’s not likely to change anytime soon. While a JavaScript certification alone may not land anyone a development job, it definitely has its benefits. “JavaScript isn’t just holding steady, it is still the most in-demand language in the market,” says Dan Roque, recruitment manager at HRUCKUS, a provider of professional and career services. The Stack Overflow 2025 Developer Survey of more than 49,000 developers shows that JavaScript remains the most-used programming language, coming in ahead of HTML/CSS, SQL, and Python. “It has held the top spot for over a decade, every single year since the survey began in 2011,” Roque says. JavaScript’s core advantage is its ubiquity, he says. “A developer who knows it well can contribute to front-end interfaces, back-end APIs [application programming interfaces], serverless functions, and automation pipelines without switching languages,” he says. JavaScript remains foundational because the web still serves as the default app platform, and most JavaScript growth is really the ecosystem expanding, with frameworks, tooling, and TypeScript becoming the common enterprise path, says Josh George, founder of Josh George Consulting, an independent technology strategy consulting firm. “JavaScript is the universal runtime for user experiences and caters to browsers, Node-based back ends, edge/serverless functions, and cross-platform apps,” George says. “The greatest benefit is a single language family across client and server, plus the added bonus of an enormous package ecosystem and mature tooling.” The programming language has evolved from being just a browser scripting language into a full-stack development platform, says Lucas Botzen, CEO and human resources manager at careers site Rivermate. “From an HR and industry perspective, organizations increasingly prefer technologies that allow teams to build both front-end and back-end systems with the same language,” he says. “That consistency reduces hiring complexity and accelerates development cycles.” JavaScript and AI AI-powered coding tools such as Claude Code and GitHub Copilot can increase productivity related to JavaScript development, Rogue says, with studies showing they can help developers complete JavaScript tasks faster. As a result, many developers plan to use AI in their development process, he says. “Employers aren’t just looking for developers who know JavaScript. They’re increasingly looking for [developers] who can evaluate and orchestrate AI-generated code within a JavaScript workflow,” Rogue says. AI is reshaping what mid-level and senior JaveScript roles actually look like, he says. “However, more and more technical testing and final interviews, especially in government-related roles, prohibit the use of AI during the last legs of the process, to ensure the talent actually can code and understand code without AI, and to validate whether they can review and troubleshoot AI-generated code on their own,” Rogue says. AI helps most with the “surface area” work, “meaning scaffolding components, generating tests, suggesting refactors, and explaining unfamiliar code paths,” George says. “The bigger shift though is that teams expect developers to spend less time typing boilerplate and more time making judgment calls like with API design, performance budgets, security, and maintainable architectures.” JavaScript certs and the hiring process Okay, so JavaScript is still a highly important piece of the development ecosystem. But is having a JavaScript certification necessary today? “It depends on context, but the answer I’d give is ‘yesn’t,’” Rogue says. “It is increasingly important, especially in structured hiring environments, because it provides a credibility anchor that résumés alone often can’t. But it doesn’t replace actual demonstrated skill.” There isn’t really a widely accepted global authority or standard on issuing JaveScript certifications, Rogue says, “so it’s much lower on the totem pole of validity when it comes to skill-signaling. Still, for client-facing or compliance-driven roles, certifications provide third-party validation that reduces perceived risk when a client is approving a candidate.” For back-end and full-stack roles, performance-based credentials that require solving real coding problems in a timed, proctored environment remain the gold standard, Rogue says. “Employers have simply grown skeptical of multiple-choice tests.” In most hiring decisions, “a JavaScript certification is not the primary signal of competence,” says Jacob Strauss, CTO at ChaseLabs, a provider of AI-based sales development tools. “They tend to help more as evidence of structured study than as a decisive hiring credential.” In practice, the strongest way to stand out is to pair any certification with a small, real project. “JavaScript changes continuously, and what matters in production is the ability to build, debug, and operate real systems,” Strauss says. “That said, certifications can be useful in specific scenarios: early-career candidates, career switchers who need a credible baseline, or organizations trying to standardize Node.js skills across a team. In those cases, a cert can reduce uncertainty, but it works best as supporting evidence alongside shipped work.” A JavaScript certification can serve as a screening mechanism or tie-break factor. “In high-volume pipelines, a cert may help a résumé survive the first pass, especially when applicants have limited professional history,” Strauss says. “For roles that involve running Node services in production, a certification can signal familiarity with asynchronous patterns, HTTP fundamentals, debugging, and service reliability concerns.” Even then, however, strong portfolios tend to outweigh credentials, Strauss says. A clean repository with typed code, sensible architecture, tests, and clear commit history is a far more predictive indicator than a generic certificate,” he says. Certifications can be influential in high-volume hiring, where recruiters need fast signals, or in regulated and enterprise contexts that prefer standardized training, George says. “It can also help when teams need specific competency areas, such as modern framework fundamentals, testing practices, secure coding basics, etc., and want a consistent baseline,” he says. In-demand JavaScript certifications CIW JavaScript Specialist. This certification covers core JavaScript topics such as functions, variables, Document Object Model (DOM) manipulation, form validation, event handling, AJAX/JSON asynchronous communication, and object-oriented programming. Candidates learn how to tackle complex scripting scenarios and debug code, according to Certification Partners, which owns and manages CIW certifications. The CIW JavaScript Specialist certification equips candidates with practical skills to build dynamic, interactive, and user-friendly websites using JavaScript, says Certification Partners. JavaScript Algorithms and Data Structures. Administered by FreeCodeCamp, this is considered an ideal certification for JavaScript beginners. Candidates will learn the JavaScript fundamentals such as variables, arrays, objects, loops, functions, DOM, and more. They’ll also learn about object-oriented programming, functional programming, and algorithmic thinking. JavaScript Developer Certificate. This certification validates proficiency in JavaScript programming, HTML DOM manipulation, and web development fundamentals. Before applying for the exam, candidates need to have a fundamental knowledge of JavaScript and HTML DOM, according to W3Schools, which offers the certification. The certification tests ability to manipulate HTML DOM and validates proficiency in dynamic website development. JSA—Certified Associate JavaScript Programmer. This certification from the JS Institute, which is managed by OpenEDG, demonstrates a candidate’s proficiency in object-oriented analysis, design, and programming and the more advanced use of functions in the JavaScript language, according to the institute. Becoming JSA-certified ensures that individuals are acquainted with how JavaScript enables them to design, develop, deploy, refactor, and maintain JavaScript programs and applications. JSE—Certified Entry-Level JavaScript Programmer. Also available from the JS Institute, this certification demonstrates a candidate’s understanding of the JavaScript core syntax and semantics, as well as their proficiency in using the most essential elements of the language, tools, and resources to design, develop, and refactor simple JavaScript programs. Becoming JSE-certified ensures that individuals are acquainted with the most essential means provided by the core JavaScript language, so they can work toward the intermediate level, the institute says. Mimo JavaScript Certification. This certification verifies a candidate’s ability to build interactive features, manage data, and understand the logic that powers modern front-end and full-stack development, according to Mimo. It shows mastery of variables, functions, loops, conditionals, arrays, objects, and ES6 features, and provides hands-on experience solving coding challenges. Participants work through practical projects such as dynamic web pages, forms, and interactive user interface components. OpenJS Node.js Application Developer (JSNAD). Created by the OpenJS Foundation, but retired in September 2025, the JSNAD certification demonstrates the ability to manage Node.js core modules, implement technical asynchronous logic, handle technical streams and buffers, and configure technical security protocols. Candidates were tested on solving complex back-end development problems and implementing scalable server-side applications in real world scenarios, according to Udemy, which still offers classes and practice exams related to JSNAD certification. The program explores the technical aspects of buffers, streams, and file system operations within the Node.js runtime, Udemy says. Senior JavaScript Developer. Offered by Certificates.dev, the Senior JavaScript Developer certification validates mastery in JavaScript, including prototypes, inheritance, and performance optimization techniques, according to Certificates.dev. It demonstrates proficiency in advanced asynchronous programming, testing, and security vulnerability mitigation. It’s designed for experienced developers aiming for technical leadership roles.

The most important thing Google announced at Google Cloud Next 2026 wasn’t another model, another Tensor Processing Unit (TPU), or another way to sprinkle Gemini across the enterprise (though it did all these things). Rather, it was an admission, or possibly a warning. Agents need supervision. We already knew this, of course, but “to know and not yet to do is not yet to know” as my high school philosophy teacher used to say. We like to think of agents as digital employees frenetically doing our bidding, but they’re also brittle software systems with credentials, budgets, memory, access to sensitive data, and a weird talent for failing in ways that are both expensive and hard to reconstruct. That’s the real story of Google Cloud Next 2026. The consensus was that Google showed up to claim the agentic enterprise. I think the more interesting read is that Google showed up to contain it. Yes, Google talked up the “agentic cloud.” It’s impossible to attend a conference these days that doesn’t. And, yes, it announced Gemini Enterprise Agent Platform, eighth-generation TPUs, new Workspace Intelligence AI capabilities, and a long list of integrations meant to make AI feel native to every corner of the enterprise. If you wanted a victory lap for the agentic era, there was plenty of keynote material to choose from. But strip away the stage lighting, and the message was much more interesting: Enterprises have spent the past two years falling in love with AI agents. Now they need to keep them from embarrassing, bankrupting, or exposing the business. That’s not a knock on Google. Quite the opposite. It may be the most useful thing Google announced. Trust, but verify The minute AI moves from saying things to doing things, all the boring enterprise questions demand answers. Who authorized this? What data did it use? What system did it touch? Why did it take that action? How much did it cost? How do we stop it? Google’s announcements were, in large part, answers to those questions. Consider what Google actually emphasized. Knowledge Catalog is designed to ground agents in trusted business context across the data estate. Gemini Enterprise now includes an inbox to manage and monitor agents, including long-running agents. Workspace is getting new controls to monitor, control, and audit agent access to data to reduce prompt injection, oversharing, and data loss risks. Google Cloud’s security announcements included new agentic defense capabilities and Wiz-powered coverage to help secure agents across cloud and AI development environments. These are not the tools you build when everything is humming along nicely. These are what you build when customers are discovering the awkward middle ground between “the demo worked” and “we trust this thing with real work.” The agent control plane Analysts seem to have settled on “agent control plane” as the phrase for this emerging layer of enterprise AI. It’s a good phrase because it’s familiar. It suggests Kubernetes for cognition: a unified place to govern, observe, route, secure, and optimize fleets of AI agents. If only. We’re still far from that world. The reason agents need a control plane isn’t that they’re already replacing employees; rather, it’s that enterprises are giving probabilistic systems access to deterministic workflows and discovering (surprise!) that somebody needs to watch the handoff. Agent demos make autonomy look clean, but enterprise systems make autonomy weird. The customer record is in one system, the contract is in another, the exception handling lives in someone’s inbox, the policy is in a PDF last updated in 2021, and the person who understands why the workflow works that way left the company during the pandemic. Now we’re adding agents to the mess. This is why I’m sympathetic to Google’s control-plane push, even as I’m suspicious of any vendor story that sounds too tidy. Yes, it’s useful to have a unified agent platform, governance, agent monitoring, evaluation, observability, and simulation. All needed. The new Gemini Enterprise story matters precisely because Google is trying to centralize the messy operational pieces that enterprises otherwise stitch together badly. But let’s not mistake the control plane for the work itself. Pilots are easy; production is hard The data on agentic AI keeps saying the same thing: Enthusiasm is running far ahead of operational maturity. Camunda’s 2026 State of Agentic Orchestration and Automation report found that 71% of organizations say they use AI agents, but only 11% of agentic AI use cases reached production in the past year. Even more telling, 73% admitted a gap between their agentic AI vision and reality. Gartner has been similarly chilly, predicting that more than 40% of agentic AI projects will be canceled by the end of 2027. Why? Cost, unclear business value, and inadequate risk controls. Let’s be clear. Those aren’t model problems. They’re all-too-familiar enterprise software problems. The same pattern shows up in security and governance. Writer’s 2026 enterprise AI survey found that 67% of executives believe their company has suffered a data leak or security breach because of unapproved AI tools. Also, 36% lack a formal plan for supervising AI agents, and 35% admit they couldn’t immediately pull the plug on a rogue agent. Of the three, it’s that last number that is perhaps scariest. These are software agents with access to business systems, customer data, and organizational credentials, yet more than one-third of organizations aren’t confident they can stop one quickly when it misbehaves. What, me worry? The agent is the least interesting part The dirty secret of the agentic enterprise is that the agent is probably the least interesting part of the architecture. It gets all the hype, but the real work is identity, permissions, workflow boundaries, data quality, retrieval, memory, evaluation, audit trails, cost controls, and deciding which system is allowed to be the source of truth when the agent gets confused. The presentations at Google Cloud Next didn’t prove that the agentic enterprise had arrived. Instead they proved that the agentic enterprise, if or when it arrives, will look a lot like enterprise software has always looked when it starts to matter. Less magic; more governance. That’s progress, but it’s not sexy progress. If you’re trying to pick winners in agentic AI, don’t look for those with the cleverest agents. Instead, look to the companies with the cleanest data contracts, the best evaluation discipline, the most coherent identity model, and the least tolerance for shadow AI chaos. The industry doesn’t want to tell that story because it’s much more fun to talk about autonomous digital workers than data lineage and access control. But boring is where enterprise software becomes real. Here’s another reason to be cautious about declaring the agentic era won: Agents are only as useful as the data they can safely understand and act upon. Google clearly knows this. The Agentic Data Cloud framing, including Knowledge Catalog and cross-cloud Lakehouse work, is an admission that agents need trusted business context. Without that context, they’re not enterprise workers. They’re articulate tourists wandering through your systems. Hence, the most encouraging announcements at Google Cloud Next weren’t the ones that made agents sound more autonomous. They were the ones that made agents sound more manageable. Agentic AI promises to be big, but only when it demonstrates it can be boring.

Meta is continuing its compute grab as the agentic AI race accelerates to a sprint. Today, the company announced a partnership with Amazon Web Services (AWS) that will bring “tens of millions” of AWS Graviton5 cores (one chip contains 192 cores) into its compute portfolio, with the option to expand as its AI capabilities grow. This will make the Llama builder one of the largest Graviton customers in the world. The move builds on Meta’s expansive partnerships with nearly every chip and compute provider in the business. It’s working with Nvidia, Arm, and AMD, as well as building its own internal training and inference accelerator chip. “It feels very difficult to keep track of what Meta is doing, with all of these chip deals and announcements around in-house development,” said Matt Kimball, VP and principal analyst at Moor Insights & Strategy. This makes for “exciting times that tell us just how incredibly valuable silicon is right now.” Controlling the system, not just scale Graphics processing units (GPUs) are essential for large language model (LLM) training, but agentic AI requires a whole new workload capability. CPUs like Graviton5 are rising to this challenge, supporting intensive workloads like real-time reasoning, multi-step tasks, frontier model training, code generation, and deep research. AWS says Graviton5 has the ability to handle “billions of interactions” and to coordinate complex, multi-stage agentic tasks. It is built on the AWS Nitro System to support high performance, availability, and security. “This is really about control of the AI system, not just scale,” said Kimball. As AI evolves toward persistent, agentic workloads, the role of the CPU becomes “quite meaningful;” it serves as the control plane, handling orchestration, managing memory, scheduling, and other intensive tasks across accelerators. “This is especially true in agentic environments, where the workloads will be less linear and more stateful,” he pointed out. So, ensuring a supply of these resources just makes sense. Reflecting Meta’s diversified approach to hardware The agreement builds on Meta’s long-standing partnership with AWS, but also reflects what the company calls its “diversified approach” to infrastructure. “No single chip architecture can efficiently serve every workload,” the company emphasized. Proving the point, Meta recently announced four new generations of its MTIA training and inference accelerator chip and signed a massive deal with AMD to tap into 6GW worth of CPUs and AI accelerators. It also entered into a multi-year partnership with Nvidia to access millions of Blackwell and Rubin GPUs and to integrate Nvidia Spectrum-X Ethernet switches into its platform, and was also one of Arm’s first major CPU customers. In the wake of all this, Nabeel Sherif, a principal advisory director at Info-Tech Research Group, posed the burning question: “What are they going to do with all this capacity?” Primarily it will support Meta’s internal experimentation and innovation, he said, but it also lays the groundwork and provides the capacity for Meta to offer its own agentic AI services, for instance, its Llama AI model as an API, to the market. “What those [services] will look like and what platforms and tools they’ll use, as well as what guardrails they’ll provide to users, is still unclear, but it’s going to be interesting to see it develop,” said Sherif. The expanded capacity will enable a diversity of use cases and experimentation across various architectures and platforms, he said. Meta will have many options, and access to supply in an environment currently characterized not only by a wide variety of new CPU approaches, but by significant supply chain constraints. The AWS deal should be viewed as a complement to its partnerships and investments in other platforms like ARM, Nvidia, and AMD. Kimball agreed that the move is “most definitely additive,” not a replacement or substitution. Meta isn’t moving off GPUs or accelerators, it’s building around them. “This is about assembling a heterogeneous system, not picking a single winner,” he said. “In fact, I think for most, heterogeneity is critical to long term success.” Nvidia still dominates training and a lot of inference, while AMD is becoming “more and more relevant at scale,” Kimball noted. Arm, meanwhile, whether through CPU, custom silicon or other efforts, gives Meta architectural control, and Graviton5 fits into that mix as a “cost- and efficiency-optimized general-purpose compute layer.” A question of strategy The more interesting question is around strategy: Does this signal Meta is becoming a compute provider? Kimball doesn’t think so, noting that it’s likely the company isn’t looking to directly compete with hyperscalers as a general-purpose cloud. “This is more about vertical integration of their own AI stack,” he said. The move gives them the ability to support internal workloads more efficiently, as well as providing the infrastructure foundation to expose more of that capability externally, whether through APIs, partnerships, or other means, he said. And there’s a cost dynamic here, too, Kimball noted. As inference becomes persistent, especially with agentic systems, economics shift away from peak floating-point operations per second (FLOPS) (a measure of compute performance) and toward sustained efficiency and total cost of ownership (TCO). CPUs like Graviton5 are well positioned for the parts of that workload that don’t require accelerators, but still need to run continuously. “At Meta’s scale, even small efficiency gains per workload compound quickly,” Kimball pointed out. For developers and enterprise IT, the signal is pretty clear, he noted: The AI stack is getting more heterogeneous, not less so. Enterprises are going to see tighter coupling between CPUs, GPUs, and specialized accelerators, with workloads increasingly split across them based on behavior (prefill versus decode, stateless versus stateful, burst versus persistent). “The implication is that infrastructure decisions have to become more workload-aware,” said Kimball. “It’s less about ‘which cloud?’ and more about ‘where does this specific part of the application run most efficiently?’” This article originally appeared on NetworkWorld.

As Europe seeks to assert its technological independence from the US vendors Aleph Alpha, once seen as Germany’s sovereign AI hope, is the target of a transatlantic takeover. Aleph Alpha is set to merge with Canada’s Cohere in a deal that will bring together Cohere’s global AI clout and Aleph Alpha’s background in research. The two companies hope they will be able to develop an AI powerhouse, with backing from their Canadian and German ecosystems “Organizations globally are demanding uncompromising control over their AI stack. This transatlantic partnership unlocks the massive scale, robust infrastructure, and world-class R&D talent required to meet that demand,” said ” said Cohere CEO Aidan Gomez in a news release that artfully presents the deal as a merger of equals but that, according to a footnote, only requires the approval of the German company’s shareholders, a sure sign of a one-sided takeover. The combined companies will be looking to offer customized AI in highly-regulated sectors including finance, defense and healthcare. By pooling their talents and offerings, theu hope to offer AI solutions to organizations according to local laws, cultural contexts, and institutional requirements. The move comes at a time when businesses across the word are looking at non-US options as a reaction to the Trump administration’s policy on tariffs and the uncertainty caused by the war with Iran. There have been several initiatives within Europe to counteract the US dominance. The EU’s Eurostack plan looked to make sure that major projects had a European option. Aleph Alpha was one of the companies highlighted within the scheme. The EU also launched Open  Euro LLM, an attempt to slow down the US and China’s lead in AI. This article first appeared on CIO.

Tencent has updated its Hunyuan AI model, its first major release since it recruited Yao Shunyu, a leading AI scientist from OpenAI. Tencent’s Hy3 model, currently available in preview, offers improvements in areas from complex reasoning to coding. The Chinese technology conglomerate is playing catch-up with other Chinese AI developers including ByteDance, Alibaba and DeepSeek. China is betting big on open-source AI to offer alternatives to major US players. Back in 2023, Tencent claimed its then-new Hunyuan LLM was a more powerful and intelligent option than the versions of ChatGPT and Llama available at the time. Tencent has backed AI start-ups including Moonshot AI and StepFun, hoping that they will boost its cloud computing division. The company has also restructured its research team to improve the quality of training data. It aims to double its investment in AI to more than $5 billion this year. Not to be outdone, DeepSeek announced its V4 Flash and V4 Pro Series, the newest versions of its LLM model. DeepSeek became an overnight hit in January 2025 with the launch of its R1 AI model and has gone on to develop other models since. It said the V4 model upgrades will offer users advances in reasoning and agentic tasks, while a new feature called Hybrid Attention Architecture improves the ability of the AI platform to remember queries across long conversations.