📰 English IT Daily · 2026-07-15

Many AI products look different on the surface, but inside they do a very similar job: they generate tokens, or small pieces of text, one after another. A chatbot answer, a coding suggestion, and a search summary all depend on this same basic process. In recent years, inference, the stage where a trained model answers real user requests, has moved center stage. Training still matters, but for many companies the bigger ongoing cost now comes from serving huge numbers of prompts every day. That is why people are paying closer attention to what happens after a user presses Enter.

A single prompt does not go straight to one GPU and come back with an answer. It usually travels through many logical and physical steps inside a data center. First, a gateway receives the request, checks permissions, and routes traffic. Then a scheduler decides where the work should run based on capacity, latency targets, and model availability. This can sound like plumbing, but it has real business value. If the system sends work to the wrong place, response times rise and hardware sits idle in the worst case. In other words, the path of one token can affect both user experience and cost.

After routing, the model begins two main phases: prefill and decode. Prefill is when the model reads the prompt and builds the internal state it needs to answer. This phase is usually limited by raw compute power, so it strongly affects time to first token, the delay before a user sees the first word appear. Decode comes next. Here, the model produces tokens one by one, reusing earlier context as it goes. This phase is often limited less by pure computation and more by memory bandwidth, because the system must move model weights and cached information quickly and repeatedly.

One key part of that cached information is the KV cache, which stores attention keys and values from earlier tokens so the model does not need to recalculate everything from scratch. This is a crucial shortcut, but it also creates pressure on memory capacity and bandwidth. GPUs may do the main math, yet the surrounding network also matters a great deal. Data must move between machines, accelerators, and storage layers with low delay and high reliability. At scale, even small inefficiencies can snowball. A few extra milliseconds, repeated across millions or billions of requests, can become a major operational issue.

This is why AI infrastructure is no longer just about buying more chips. Power, cooling, interconnects, and optics are gaining traction because they shape what performance is actually possible in production. There is also a trade-off between cost, speed, and reliability. A system optimized for the cheapest token may not deliver the best user experience. A system optimized for the fastest response may be expensive to run. Companies therefore need to weigh blended cost, output speed, security, deployment needs, and model coverage. For engineers, this means inference is not a black box anymore; it is an end-to-end system with measurable bottlenecks.

The broader economic point is simple: inference is recurring work, not a one-time event. Every new query adds cost, and demand keeps rising as AI features spread into more products. At the same time, the cost per token has been falling quickly, which encourages even more usage. That combination can reshape the market. Some observers focus on model quality, while others argue that durable value may sit in physical constraints such as memory bandwidth, networking, and power delivery. Either way, understanding how a token travels through a data center helps engineers reason more clearly about latency budgets, architecture choices, and what to watch as AI systems scale up.

For many years, the tech industry believed that most value would move upward from hardware to software. In the age of SaaS, or software sold as a service, this idea made sense. Once a company built the product, it could add more users at very low cost. That created high margins and rewarded the businesses that owned the user interface and daily workflow. This is why people often repeated the famous idea that “software ate the world.” But the rise of AI is pushing this story in a new direction.

A growing number of investors and founders now argue that AI is changing where profits and power sit in the tech stack. Instead of moving upward, value may be drifting downward toward the layers that are harder to build and harder to replace. These include semiconductors, computing infrastructure, model training, inference systems, and the platforms that store and manage the information used by AI. In simple terms, inference means running a trained model to produce an answer. Unlike old software, AI applications often have a real cost every time a user sends a request, because each request uses expensive compute.

This shift matters because the economics are different from traditional software. In SaaS, serving one more customer usually cost very little. In AI, serving one more customer can require more chips, more electricity, more memory, and more networking. That can squeeze margins at the application layer. An AI app may look polished, but if many competitors can build a similar wrapper around the same open model, it becomes easier to substitute. By contrast, companies that control scarce chips, packaging capacity, power, or high-quality platforms may hold stronger control points. In that sense, hardware is starting to eat software.

One reason is capital intensity. The lower layers of the AI stack are extremely expensive to build and maintain. Advanced chips, packaging, and large-scale computing facilities require huge investment, and not every company can keep up. Another reason is physical bottlenecks. Some limits cannot be solved quickly just by spending more money. If there is a shortage in advanced packaging, memory, or power, the whole market feels it. Scarcity can give leverage to the companies that control these resources. In addition, data and infrastructure often create inertia: once systems are deeply connected to one platform, switching away becomes costly and slow.

Still, this does not mean the application layer will disappear. Many businesses will continue to win by solving real industry problems, designing strong user experiences, and combining models with domain knowledge. In healthcare, finance, manufacturing, and security, customers do not buy technology only because it is clever. They buy tools that fit existing processes, meet legal requirements, and deliver reliable results. So the debate is not hardware versus software in a simple sense. Rather, it is about which layer can defend its position when AI becomes widespread and cheaper models become common.

For engineers, managers, and investors, the key lesson is that AI is not only a story about smarter applications. It is also a story about supply chains, energy, cost structure, and technical constraints. Teams that once focused mainly on features may now need to think more seriously about model efficiency, deployment cost, latency, and vendor dependence. The center of gravity in tech may be moving down the stack, even if the user still sees only an app on a screen. The companies to watch are not just the ones with eye-catching products, but also the ones that quietly control the foundations underneath them.

PrismML has announced Bonsai 27B, a new multimodal AI model that can run locally on a phone. According to the company, this is the first model in the 27B class to fit on a smartphone while still keeping much of the ability of a much larger full-precision version. The model is based on Qwen3.6 27B and is presented as the flagship of the Bonsai family. In simple terms, Bonsai 27B aims to bring advanced AI features such as multi-step reasoning, structured tool calls, vision tasks, and computer-use agent loops to devices that people already carry every day.

The technical hurdle has always been memory size. A normal 27B model takes about 54 GB in 16-bit precision, and even a heavily compressed 4-bit version is around 18 GB. That is still far too large for a phone and too much for many laptops. PrismML says Bonsai 27B gets around this limit with very low-bit weights. The ternary version uses values of -1, 0, and +1, while the 1-bit version uses only -1 and +1. These designs sharply reduce the memory footprint without throwing away the whole point of a large model.

The company is releasing two variants. Ternary Bonsai 27B is the quality-oriented option. It has an effective size of 1.71 bits per weight and fits in 5.9 GB. PrismML says this version can run on an everyday laptop while preserving full reasoning, tool-calling, and agent-style behavior. The smaller version, 1-bit Bonsai 27B, is built for the tight memory budget of a phone. At 3.9 GB, PrismML says it can fit on an iPhone 17 Pro. Both versions are multimodal, and their vision component comes in a compact 4-bit form so the model can process screenshots, documents, and camera input as well as text.

PrismML also says the low-bit design runs end to end across the model, including embeddings, attention layers, MLPs, and the language-model head. In other words, there are no hidden higher-precision parts acting as escape hatches. That matters because some compressed models look efficient on paper but quietly depend on larger components behind the scenes. Bonsai 27B also supports a 262K-token context window and speculative decoding, a method that can speed up generation by drafting and then verifying text without changing the final output.

On benchmark tests, PrismML reports that the ternary model retains about 95% of the full-precision baseline, while the 1-bit model retains about 90%. The headline numbers suggest a clear trade-off, but the details are just as interesting. PrismML says math and coding are nearly untouched, while tool calling also remains relatively strong. Those are exactly the areas that matter for agentic workloads, where a model must reason through several steps, call tools in the right order, and stay coherent over time. Vision scores are lower than the original baseline, but the company still presents on-device image understanding as a practical feature rather than just a box-ticking demo.

If these claims hold up in wider testing, the implications could be far-reaching. Running a capable model locally can improve privacy, reduce dependence on a constant network connection, and lower serving costs. It could also open the door to new mobile apps that combine reasoning, tool use, and visual understanding in real time. At the same time, there are trade-offs to watch. Smaller footprints can come with weaker performance in some tasks, and real-world battery life, thermal limits, and responsiveness will matter as much as benchmark charts. For engineers, the bigger story may be that the edge is no longer lagging far behind the data center. The next question is not only whether large models can run on phones, but which workloads actually make sense there.

JetBrains has introduced Hexana, a toolkit for WebAssembly and binary analysis. It comes in two versions: a full plugin for JetBrains IDEs and an extension for Visual Studio Code-based editors. The idea is simple but timely. WebAssembly is gaining traction beyond the browser, and developers now use it for command-line tools, plugins, edge workloads, and language runtimes. As this ecosystem grows, developers need better ways to inspect, understand, run, and debug low-level files without leaving their editor.

Hexana tries to close that gap by putting analysis tools directly into familiar development environments. In JetBrains IDEs, it offers a multi-tab .wasm editor, an editable WAT view, and support for WAT and WIT, which are text formats related to WebAssembly. It can also run and debug modules on several runtimes, including Wasmtime, WAMR, GraalVM, and wazero. The VS Code version focuses on a lightweight but capable inspection experience, with a custom editor, a hex viewer, structural-analysis tabs, and experimental debugging. In both products, the goal is to spare developers from switching between many separate tools.

A key point is that both versions share the same Kotlin Multiplatform analysis core. That shared foundation supports core WebAssembly features as well as newer proposals such as SIMD, threads, tail calls, reference types, bulk memory, and the component model. For users, this means the two products are not completely different tools moving in opposite directions. Instead, they are two front ends built on the same engine. That should make behavior more consistent and may lower the risk of one version lagging behind the other on major parsing and inspection features.

Hexana is not limited to basic file viewing. According to the documentation, it can inspect imports and exports, list functions and types, profile size, detect dead code, and examine custom sections. It also shows awareness of the WebAssembly component model, including nested modules and dependency resolution. On top of that, the toolkit has experimental support for native binaries such as ELF, Mach-O, and PE files. That broader scope matters because many developers work across boundaries: they may start with WebAssembly, then need to look under the hood of related native artifacts during debugging or performance work.

Another notable feature is its connection to modern developer workflows. The JetBrains plugin includes an MCP server with Hexana tools, and the VS Code extension can download one on demand. In practical terms, this means AI assistants may be able to query the toolkit instead of guessing about a binary file. The JetBrains version also adds language-aware features for Java, JavaScript, and TypeScript in specific WebAssembly-related cases. This kind of editor integration could be a double-edged sword. It can speed up analysis and reduce context switching, but it may also tempt users to rely too heavily on convenience features instead of understanding the format itself.

Hexana arrives at a moment when WebAssembly tooling is still maturing. Many developers like WebAssembly because it is portable and efficient, but the surrounding tools can feel fragmented. By offering inspection, execution, and debugging in editors that teams already use every day, Hexana could lower the barrier to entry for more engineers. Still, success will depend on reliability, performance, and how well the experimental features hold up in real projects. If JetBrains keeps refining both versions, Hexana may become a useful bridge between high-level application work and the low-level details that are often hard to see.

Working with Git can become messy when many changes are moving at the same time. Developers often juggle branches, fix old commits, and rewrite history before sharing code with others. In that situation, even skilled engineers may feel uneasy about using interactive rebase, because one small mistake can leave the working tree in a confusing state. Recently, another tool called jj has gained traction because it tries to make this kind of work easier. However, not every developer wants to switch to a different version-control workflow just to solve a few painful problems.

That is why some people are paying attention to git history, an experimental Git command that arrived in recent releases. It is part of core Git, so users do not need to install a separate tool to try it. The command includes three subcommands: fixup, reword, and split. Together, they focus on a common problem in software development: changing older commits without manually rebuilding everything on top. According to the source article, git history received a burst of attention when the releases came out, but then the wider discussion seemed to die down. The writer argues that this is unfortunate because the feature may already offer some of the practical benefits that people praise in jj.

The fixup subcommand is meant for a situation where an older commit contains a mistake. A developer stages the correction and then runs git history fixup with the target commit. Git folds the staged change into that old commit and then rewrites later commits so the branch stays consistent. More importantly, it can also update other local branches that descend from that commit, not just the branch the developer is currently on. In plain terms, if several lines of work are built on the same earlier commit, Git can carry the repair through the whole stack automatically. That can remove a lot of repetitive work and lower the risk of human error.

The reword subcommand handles a different but common need: editing an old commit message after the design or purpose of the code has shifted. Instead of running a longer history-editing process by hand, the user can open the message, revise it, and let Git rebuild the later commits on top. The source context also mentions split as a third subcommand, showing that the broader goal is to make history editing more direct and less intimidating. For developers who often work in stacked branches, where one branch depends on another, this kind of workflow can be very appealing. It keeps the process closer to everyday Git while smoothing out some rough edges.

One standout feature is that these operations are designed to be atomic. In other words, git history tries to avoid leaving the repository half-finished in the middle of a rewrite. It does this by refusing to perform actions that would create a conflict. That safety-first approach could be reassuring for developers who have had bad experiences with complex rebases. At the same time, it is also a trade-off. The article points out that this makes git history less powerful than jj in one key way: jj can treat conflicts as a first-class part of the process and let users resolve them later, while git history currently refuses such cases.

There are other limits as well. The source says git history does not work when merge commits are involved, and for some teams that may be a dealbreaker. Still, the feature raises an interesting question about the future of Git. Many developers want simpler tools for rewriting history, but they may not want to abandon established habits or retrain entire teams. If git history continues to mature, it could offer a middle ground: safer history editing inside the tool developers already use every day. For now, it is worth keeping an eye on, especially for engineers who manage several related branches and want cleaner workflows without too much disruption.

GitFut is a small but eye-catching project that turns GitHub activity into a football-style player card. Instead of showing plain charts or a long list of numbers, it presents a developer like an athlete with ratings out of 99. The idea is simple and playful, but it taps into a real trend in tech: people want better ways to show their work online. On GitHub, profiles often act as public resumes, portfolios, and social signals all at once. A tool like GitFut stands out because it gives that information a fresh visual form.

According to the project page, GitFut creates a live card that can be embedded in a GitHub profile README, a personal site, or other online spaces. The card lives at a URL, so it updates itself as a user's GitHub statistics change. The project says it reads six signals from a live GitHub profile through GitHub's GraphQL API. These signals are mapped to football categories such as pace, shooting, passing, dribbling, defending, and physical strength. For example, commits in the last year influence pace, while stars, pull requests, followers, reviews, issues, and lifetime contributions shape other parts of the card.

One interesting design choice is that the overall score does not rise in a simple straight line. The README explains that raw stats are capped at 88, while scores in the 90s are treated as something earned through years of influence and steady contribution. In other words, one strong year is not enough to crown someone an icon. The system also tries to infer a position or archetype from a user's stat pattern. A developer with strong 'shooting' may look like an attacking player, while someone with stronger defending and passing may come across as a deep playmaker.

This kind of project gains traction because it turns dry metrics into a story. Numbers alone can be hard to read at a glance, especially for recruiters, collaborators, or curious visitors. A sports card format gives people an instant hook. It also adds a layer of fun to the serious business of professional identity. In a crowded online world, playful presentation can set a profile apart. For open-source contributors, that can be useful, because visibility often affects networking, job opportunities, and community recognition.

Still, GitFut also shows the limits of metric-based identity. Any scoring system is a double-edged sword. It can motivate people and highlight effort, but it can also flatten complex work into a few public numbers. GitHub activity does not capture everything that matters in software engineering. It may miss mentoring, architecture decisions, private company work, or careful maintenance that produces fewer visible signals. It can also nudge people toward optimizing what is measured rather than what is truly valuable. That does not mean the card is misleading, but it should be read as a playful snapshot, not a full scouting report on a person's ability.

Even with those trade-offs, GitFut points to a broader shift in developer tools. More projects are trying to package technical history in ways that are visual, shareable, and easy to understand outside engineering circles. The repository itself appears to be built with modern web tools, and its popularity on GitHub suggests that the idea has struck a chord. The bigger lesson is not just about football graphics. It is about how developers present themselves online, how platforms shape reputation, and how design can reframe familiar information. As coding communities keep growing, tools that blend utility with personality will likely keep showing up.

The software industry is going through a major reset. For many years, SaaS companies followed a familiar path: build one strong product, expand into a wider suite, and then become a platform that other businesses depend on. That model worked because building serious business software took a long time, a large team, and a lot of money. Today, AI coding tools and agent-based products are lowering that barrier very quickly. As a result, investors and founders are starting to question an old assumption: if a product can be rebuilt in days or weeks, can it still protect a business for long?

This shift became easier to see in 2026. Some software companies launched fast-growing AI products, yet the market did not reward them in the usual way. The message from investors seemed clear: shipping a popular new feature is no longer enough on its own. The concern is that many AI features can be copied quickly, especially when new tools let small teams, or even non-technical users, create products that once required experienced engineers. In that world, the moat is no longer the interface or the feature list. The ground has moved beneath the traditional SaaS model.

A key idea in this new playbook is a ninety-degree rotation in competition. In the past, companies competed mainly on what they built. Now the focus is shifting toward what they own and control but others cannot easily copy. That may include proprietary workflows, trusted customer relationships, deep industry expertise, access to unique distribution channels, or the right to act inside a customer’s daily operations. If AI agents can perform tasks across many tools, then the visible product layer may become less valuable than the assets behind it. In simple terms, software may become the packaging, while the real value sits somewhere else.

This does not mean products no longer matter. It means the source of advantage may be changing. In the old model, time itself acted as a moat because competitors needed years to catch up. When production costs fall sharply, that protection starts to weaken. Product-led growth, or PLG, may also face pressure if users can generate lightweight alternatives on their own. At the same time, the pie may get bigger. Lower barriers can bring many more builders into the market, including people from non-technical backgrounds. That could create new demand, new categories, and more specialized tools for smaller business problems.

Another debate is about pricing. In a world of AI agents, some companies may move away from charging mainly for seats or subscriptions and toward outcome-based pricing. In plain language, customers may pay more for results than for access. But this model is not simple. If a vendor promises an outcome, it may also take on more risk, almost like underwriting performance rather than just billing for usage. That can be attractive to customers, but difficult for providers. They need strong measurement, clear service boundaries, and enough trust to prove that their system truly created the result.

For engineers, founders, and enterprise buyers, the practical lesson is not to panic but to look beneath the surface. It is still possible to build successful SaaS products, but the playbook is changing fast. Teams may need to think less about adding one more feature and more about embedding their product into real business processes, gaining durable access, and owning the hard-to-copy parts of the workflow. The winners in the AI agent era may not be the companies with the flashiest demo. They may be the ones that tie software to trust, distribution, and measurable business outcomes.

A new open-source tool called AgentsView is trying to solve a growing problem in AI-assisted coding: people now use many different coding agents, but their work is often scattered across separate tools and windows. According to its GitHub page, AgentsView offers local-first session search, analytics, insights, and token-use statistics for coding agents. It supports Claude Code, Codex, and more than 20 other agents. The project describes itself in simple terms: one binary, no accounts, and everything local. That message is likely to strike a chord with developers who want a clearer view of how AI tools are being used during daily work.

The basic idea is straightforward. As engineers switch between coding agents, they can lose track of past prompts, generated code, and token consumption. That makes it hard to compare tools, review earlier decisions, or understand the real cost of AI support over time. AgentsView tries to bring those separate sessions under one roof. Instead of forcing users to log into a central service, it focuses on local storage and analysis. For many developers, that approach is appealing because coding sessions may contain sensitive business logic, internal discussions, or security-related details that they would rather keep on their own machines.

This local-first model reflects a broader trend in developer tools. Many teams like the speed and convenience of cloud dashboards, but they are also wary of sending every activity log to an outside provider. In that sense, AgentsView positions privacy as a key feature rather than an afterthought. Search is another major part of the value. If developers can quickly find old sessions across different agents, they do not need to start from scratch every time they revisit a problem. Analytics and insights also matter because AI coding is no longer just an experiment on the sidelines; in many teams, it is becoming part of the standard workflow.

Cost tracking is especially relevant. AI coding agents often charge based on token usage, and costs can quietly add up when teams run many sessions every day. A tool that shows token statistics in one place can help users spot patterns, compare habits, and decide which workflows are worth the expense. That does not automatically mean one agent is better than another, because quality, speed, and reliability also count. Still, clearer visibility can improve decision-making. In practical terms, an engineer or team lead may be able to see whether certain tasks consume far more tokens than expected, or whether one style of prompting leads to more efficient results.

At the same time, there are trade-offs. A local-only approach can be a double-edged sword. It may offer better privacy and control, but it can also create extra work for setup, storage, backup, and sharing. Some teams want a polished hosted service with built-in collaboration, while others prefer tools they can run themselves. Another issue is coverage: the AI agent market moves fast, and support for many tools is useful only if it keeps pace with constant product changes. Open-source projects can gain traction quickly, but they also depend on active maintenance and a community that reports bugs and contributes improvements.

Even with those questions, AgentsView points to a useful shift in the AI coding ecosystem. As more agents enter the market, developers will likely need better ways to search across sessions, measure usage, and understand cost at scale. Tools that bring order to that complexity may become as valuable as the agents themselves. For software engineers, the bigger lesson is clear: adopting AI is not only about generation quality. It is also about observability, governance, privacy, and workflow discipline. If AI coding tools are here to stay, then session history and usage analytics may soon become part of normal engineering practice, not just a nice-to-have extra.

As AI agents write more code, a new problem is coming into focus: understanding. In a July 2026 talk, writer and developer Geoffrey Litt argued that the main bottleneck may no longer be code production itself. Instead, it may be the human ability to follow what these systems are building. This idea pushes back against a common belief that better agents will remove people from the loop. Litt’s point is not that AI coding tools are failing. In fact, they are improving quickly. The issue is that faster output can still create a gap between what gets built and what a person truly understands.

The usual reason for understanding code is verification. A developer reads the result and asks a simple question: is this correct? That can mean many things. Does the code match the request? Is the design sensible? Will it create problems later? But Litt suggests that this answer is incomplete. AI systems are getting better at checking their own work, running tests, and catching obvious errors. If verification becomes more automated, then human understanding still matters for another reason. People need to understand enough to participate in the next round of decisions, not just give a thumbs-up or thumbs-down at the end.

That idea matters because real projects do not move in a single straight line. They unfold through many loops of prompting, building, reviewing, and revising. In that process, a developer needs a mental model of the system. Without that model, it is hard to steer the project, spot hidden risks, or come up with better ideas. A person may accept working code in the short term, but the bill can come due later. This connects to the idea of cognitive debt, which is similar to technical debt. You can move fast while understanding very little, but that shortcut may box you in when the system becomes larger or more critical.

So how can developers keep up without reading every diff line by line? Litt points to education for inspiration. If teachers have spent centuries thinking about how people learn, then software teams can borrow some of those methods. One technique is to ask for explanations, not just raw output. Instead of only showing a patch or a diff, an AI agent could produce a short explainer document. It might describe the goal, the key design choices, trade-offs, and how different parts of the system fit together. A good explanation can surface the main ideas much faster than low-level inspection alone.

A second technique is to use quizzes to check understanding. This may sound unusual in engineering, but it follows a basic lesson from education: people often think they understand more than they really do. A short quiz can expose weak points in a mental model. For example, a developer could answer questions about which component handles a certain task, why one design was chosen over another, or what would break if a feature changed. This kind of active recall can be more effective than passive reading. It also turns understanding into something observable, rather than a vague feeling.

The third idea is to create micro-worlds, or small spaces where a person can play with a system and see how it behaves. That could mean a tiny demo, a simplified environment, or a visual tool that makes a complex workflow easier to explore. Together, explanations, quizzes, and micro-worlds suggest a broader shift in software work. As AI coding tools gain traction, the scarce resource may be fluent human judgment, not typing speed. Some people may argue that deep understanding will matter less as agents improve. But others see that view as a double-edged sword. If teams rely too heavily on outputs they cannot explain, they may move faster at first but lose control when it matters most.