📰 English IT Daily · 2026-07-16

A recent blog post looked at a question many publishers, marketers, and tech workers are asking: how does ChatGPT decide which sources to use? Instead of judging the final answer on the screen, the writer examined the network traffic sent to the browser. In simple terms, network traffic is the hidden exchange of information between a service and a user’s device. By reading the JSON, or structured text, inside that traffic, the writer tried to see the system’s internal labels rather than guess them from the output alone.

This approach stands in contrast to large visibility studies. Those studies often send thousands of prompts, then measure which brands or websites appear in answers. That method can show broad patterns, but it is still a black box because researchers cannot directly see the system underneath. The network-traffic method is narrower, since it came from one user account over a short period, but it can lift the lid on the names of fields and categories that the system uses internally. In other words, it says less about scale but more about structure.

According to the source context, the captured traffic showed several internal fields, including labels for where a result came from and what type of task a query belonged to. The writer reported values such as result_source and turn_use_case, as well as vendor names and search queries created by the system itself. The post also suggested that some text queries may skip the web entirely, while more complex “Thinking” mode can trigger many extra searches, including site-specific checks and price-verification queries. These findings matter because they move the discussion away from pure speculation.

At the same time, the writer was careful not to overstate the evidence. The post clearly separates structural facts from frequency observations. If a field appears in the traffic, that is strong evidence that the field exists. But if one source appears more often than another in a small batch of prompts, that does not prove a general rule. The sample focused mainly on SaaS and tech topics, so it may naturally favor places like review sites, forums, or community discussions. A different set of prompts, such as health or fashion, could easily shift the balance.

For people who create content, the practical lesson is not a silver bullet. The study does not offer a simple trick for forcing a site into ChatGPT’s answers. Instead, it suggests that source selection may depend on several layers: the kind of query, whether the model decides to search the web, what vendor tools are involved, and what sub-queries are generated behind the scenes. That is a double-edged sword. On one hand, it means there may be several paths to visibility. On the other hand, it means advice based on one output snapshot can be misleading.

For engineers and technical decision-makers, the bigger value may be methodological. Reading network traffic is not the same as reverse-engineering the full system, but it can provide direct clues about behavior that output-only studies cannot confirm. It also reminds us to keep confidence levels separate: what is read straight off the wire deserves more trust than broad claims drawn from a small sample. As AI assistants gain traction in search and information access, this kind of careful analysis could shape how teams think about observability, testing, content strategy, and user trust.

PrismML has announced Bonsai 27B, a new multimodal AI model based on Qwen3.6 27B. The company says it is the first model in this capability class that can run on a phone. That claim matters because 27B-class models are usually far too large for mobile hardware. A normal 16-bit version can take around 54 GB of memory, and even a 4-bit version is still too heavy for most phones. By cutting the model size much further, PrismML is trying to bring advanced AI from the data center closer to everyday devices.

Bonsai 27B comes in two variants. The ternary version uses weights with three possible values, while the 1-bit version uses only two. In simple terms, the model stores its parameters in a much more compact form than standard versions. PrismML says the ternary model is about 5.9 GB and is aimed at users who want better quality on a laptop. The 1-bit model is about 3.9 GB and is designed for a tighter memory budget, including a recent high-end smartphone. The company also says there are no higher-precision escape hatches, meaning the low-bit format runs through the whole language model rather than only in a few parts.

The headline feature is not just that the model is small. PrismML says it still handles multi-step reasoning, structured tool calls, vision tasks, and computer-use agentic loops that stay coherent over many steps. Both variants are multimodal, so they can work with images as well as text. The vision tower is shipped in a compact 4-bit form, which means on-device workflows can analyze screenshots, documents, and camera input. The model also supports a 262K-token context window and speculative decoding, a method that can speed up generation by letting a smaller draft process run ahead and then verify the result without changing the final output.

According to PrismML, the model retains much of the intelligence of the full-precision baseline. Across 15 benchmarks, the ternary version keeps about 95% of the baseline score, while the 1-bit version keeps about 90%. The company highlights a sharper point behind those averages: math and coding remain relatively strong, and tool calling also holds up well. Those areas are especially relevant for agentic systems that need to reason, call functions, and complete tasks step by step. PrismML also argues that aggressive conventional low-bit builds can lag behind Bonsai 27B while still using much more memory.

If these results hold up in wider testing, the implications could be significant. On-device AI can offer lower latency, better privacy, and offline use because requests do not always need to travel to a remote server. That could open the door to new mobile assistants, document tools, accessibility features, and local coding helpers. For enterprise users, it may also widen deployment choices. Some workloads could stay on the device, while others still move to larger systems when higher throughput or broader knowledge is needed. In that sense, smaller local models are not replacing cloud AI overnight, but they are shifting the balance.

Still, there are trade-offs, and this is where the story gets more nuanced. Benchmark retention is impressive, but real-world performance depends on battery life, thermal limits, response speed, app integration, and safety controls. A model that fits in memory is only one piece of the puzzle. Developers will also want independent evaluation, especially for long agentic tasks where errors can snowball. Even so, Bonsai 27B shows that model compression is moving fast. It raises an important question for the industry: if a phone can now run a 27B-class model, what kinds of AI experiences will users soon take for granted?

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. In simple terms, Hexana is designed to let developers open, inspect, run, and sometimes debug WebAssembly modules and other binary files without leaving their editor. That may sound narrow at first glance, but the timing is notable. WebAssembly is gaining traction beyond the browser, and teams increasingly need better ways to understand what is inside compiled files, not just the source code that produced them.

The JetBrains plugin is the deeper option. According to the documentation, it includes a multi-tab editor for .wasm files, an editable WAT view, and support for WAT and WIT, which are text formats related to WebAssembly. It also offers features aimed at developers working in Java, JavaScript, and TypeScript, such as completion for some Java-side WebAssembly libraries and type inference for WebAssembly.instantiate. The plugin can run and debug code on several runtimes, including Wasmtime, WAMR, GraalVM, and wazero. Beyond WebAssembly, it can inspect formats such as Parquet, Arrow IPC, and Protocol Buffers, and it includes experimental support for ELF, Mach-O, and PE binaries.

The VS Code version is lighter, but it still covers a lot of ground. It has a custom editor, a virtual-scrolling hex viewer, several structural-analysis tabs, and support for custom scriptable tabs. It can also resolve dependencies in the WebAssembly Component Model and offers experimental debugging. Users can run modules on common runtimes and, in some cases, in Node.js or a browser. The same layout used for WebAssembly modules can also be applied to native binaries. That shared experience matters because many developers work across tools and want a smoother handoff between environments instead of learning a completely different interface each time.

Under the hood, both products share one Kotlin Multiplatform analysis core. JetBrains says this core supports many parts of modern WebAssembly, including GC, SIMD, Threads, Tail Call, Reference Types, Bulk Memory, Multi-Value, and older exception handling. It can parse modules, list imports and exports, build function and type catalogs, and do size profiling. It also looks for dead code, which means compiled code that is present but never used, and it can inspect custom sections. In the JetBrains plugin, that includes DWARF information, which is often used for debugging and source mapping. For engineers who usually stay at the source level, these features can pull back the curtain on what a compiled artifact is really doing.

This matters because binary inspection is often scattered across niche tools, command-line utilities, and handwritten scripts. Hexana tries to bring that work into the daily development flow. That convenience could lower the barrier for application teams that want to adopt WebAssembly but do not want to get stuck in the weeds of unfamiliar tooling. At the same time, there is a trade-off. Putting many features into the editor can be a double-edged sword: it saves context switching, but it may also add complexity, especially for people who only need a quick file viewer. The product choice reflects that tension. The JetBrains plugin aims for depth, while the VS Code extension focuses more on reach and portability.

Looking ahead, Hexana is interesting not because it promises to replace every specialist tool, but because it shows where developer tooling may be heading. As compiled components, portable runtimes, and AI-assisted workflows move into the mainstream, teams need tools that can connect source code, intermediate text formats, and raw binaries in one place. Hexana also includes an MCP server for AI assistants, which suggests JetBrains sees analysis features as part of a broader automation story. If WebAssembly continues to spread into backend services, plugins, and cross-platform applications, tools like this may become less of a niche extra and more of a standard part of the toolbox.

Noisia is an open-source tool on GitHub that creates harmful workloads for PostgreSQL. In simple terms, it is designed to make a healthy system behave badly on purpose. That may sound strange at first, but the idea is practical. Many teams only discover serious database problems after users complain or an outage has already begun. A tool like noisia lets engineers reproduce those situations in a controlled way, so they can study warning signs, test alerts, and practice recovery steps before real damage happens.

The project focuses on several kinds of stressful behavior that are common in production systems. According to its repository, noisia can simulate idle transactions, deadlocks, rollbacks, failed connections, and waiting transactions blocked by locks. It can also generate temporary files by forcing queries to spill work from memory to disk. Other workloads are even more disruptive, such as terminating backends, creating excessive connection churn, or flooding write-ahead logging, often called WAL. Some modules are built to show how disk space can fill up even when normal business data is not growing quickly.

One reason the tool stands out is that its scenarios reflect real operational pain points rather than artificial benchmarks. For example, one workload keeps many sessions waiting on an ACCESS EXCLUSIVE lock, which can create a flickering staircase of blocked activity. If left unbounded, this can eat up available connections until new clients are refused. Another scenario pins WAL through an unused replication slot, so log files keep growing and may eventually fill the disk. There is also a visible counterpart that drives heavy update traffic and can increase replication lag when archiving or recycling cannot keep up.

For database administrators and platform engineers, this kind of tool is a double-edged sword. In the right hands, it is valuable for resilience testing. Teams can see whether monitoring catches rising rollback counters, too many blocked sessions, or unusual temporary file growth. They can also check whether settings such as work memory, connection limits, or lock management are fit for purpose. Just as important, noisia can support incident drills. A team can run a harmful pattern in a test environment and then walk through the exact steps needed to diagnose and contain it.

At the same time, the project should be handled with care. A tool that can trigger connection exhaustion, disk pressure, or even instance restarts is not something to run casually. The README makes it clear that these workloads are harmful by design. That means the main value is educational and operational, not performance bragging. Used carelessly, it could derail a shared environment or confuse less experienced engineers who do not yet know how PostgreSQL behaves under stress. In that sense, noisia raises a broader question about security and responsibility around openly available testing tools.

Even so, the larger lesson is easy to understand: modern systems do not fail in neat, predictable ways. They fail through lock contention, resource leaks, replication backlog, and many small issues that pile up at the worst possible time. Tools like noisia give engineers a chance to get ahead of those problems. Instead of waiting for a midnight emergency, teams can test assumptions, sharpen their runbooks, and build confidence in their monitoring. As databases support more critical services, practical failure testing is likely to gain traction as a normal part of operations.

For many people, machine learning can feel like a field with a high barrier to entry. There are many tools, many math topics, and many new words to learn. That is why beginner-friendly study repositories on GitHub are gaining traction. One example is a public repository created to support people who are interested in machine learning study, especially beginners or people preparing a study group. Instead of presenting machine learning as one huge subject, the repository breaks it down into practical areas such as Python, Kaggle, PyTorch, TensorFlow, Pandas, visualization, and Scikit-Learn.

This kind of structure matters because self-study often falls apart when learners do not know where to start. A long list of online tutorials can leave people in the weeds, moving from one video or notebook to another without a clear path. A well-organized repository can act as a roadmap. It gives learners a sequence of topics and a place to revisit materials later. In that sense, GitHub is not only a place to store code; it can also serve as a public classroom, where people learn by reading, running, and modifying examples at their own pace.

The repository’s topic list also reflects a common learning journey in machine learning. Python usually comes first because it is the language many learners use to write scripts and test ideas. Then tools like Pandas and visualization libraries help learners inspect tables, clean information, and understand patterns before building models. After that, learners can branch out into Scikit-Learn for classic machine learning methods and into PyTorch or TensorFlow for deep learning. Kaggle, meanwhile, gives students a more hands-on way to practice on real problems and compare approaches with other learners.

Studying alone has clear advantages. It is flexible, low-cost, and easy to tailor to your own goals. A software engineer, for example, may focus on notebooks, model evaluation, and practical experiments rather than going deep into theory at first. Yet self-study is also a double-edged sword. Without feedback, learners can pick up bad habits or misunderstand core ideas. They may also spend too much time tuning code before they fully grasp what a model is doing. That is why many people use repositories like this as a springboard, then combine them with books, courses, or peer discussion.

Another reason such repositories matter is that they lower the friction of getting started. Installing tools, preparing examples, and finding trustworthy materials can slow beginners down. A curated collection reduces some of that effort. It also gives learners a way to benchmark their progress: Can they follow a notebook, explain the result, and adapt it to a new task? For engineers already working in tech, that practical loop can be very valuable. It connects theory with daily problem-solving and makes the learning process feel less abstract.

Looking ahead, resources like this are likely to remain useful even as machine learning changes quickly. New libraries and model types will continue to emerge, but the core study habits still hold up: learn the basics, practice regularly, compare tools, and build small projects. For independent learners, the challenge is not only finding information but also staying consistent and avoiding overload. A strong repository cannot do all the work, but it can point learners in the right direction. For anyone trying to study machine learning alone, that kind of guidance can make the first steps much easier.

SQLite is one of the most widely used database engines in computing, especially for local storage inside apps and devices. Unlike many traditional relational database systems, it does not run as a separate server process. Instead, it is linked directly into an application as a library. That design makes it simple to deploy, easy to embed, and attractive for mobile apps, desktop tools, and embedded systems. Some larger services have even started to rely on it in production. Because of this broad reach, even small design choices in SQLite can have an outsized effect on software quality.

A recent blog post argues that SQLite should adopt something like Rust-style “editions.” In the Rust programming language, editions let the language improve defaults and remove long-standing problems without breaking older code overnight. The basic idea is to preserve compatibility for existing projects while allowing new projects to start with safer and more modern behavior. The writer says SQLite has a similar problem: its long history and strong focus on backward compatibility make it hard to fix defaults that many developers now see as risky or outdated.

The main example is foreign key constraints. In most relational systems, foreign keys are enforced by default. They protect consistency by making sure one table cannot refer to a row that does not exist in another table. In SQLite, however, foreign key checks are ignored unless the application explicitly turns them on with a pragma setting. That can catch developers off guard, especially if they assume SQLite behaves like other SQL systems. A team may write a schema that looks correct on paper, but the protection is not really there unless the setting is enabled.

The blog post highlights why this is more than a minor footgun. SQLite can reuse ROWID values in some cases, and an INTEGER PRIMARY KEY can act as an alias for that internal row identifier. If foreign key checks are off, a deleted row can leave behind a reference that no longer points to a real parent record. Later, if a new row receives the same ID, the old reference may silently point to the wrong record instead. That is worse than a simple error because the system may appear to work while returning incorrect results. In other words, the bug can slip through the cracks and stay hidden for a long time.

The proposed answer is not a sudden breaking change for everyone. Instead, an edition system could let SQLite keep old behavior for legacy applications while rolling out safer defaults for new ones. For example, a newer edition might enforce foreign keys by default and possibly revisit other historical choices that no longer age well in modern development. This approach would try to strike a balance between stability and progress. It would also acknowledge a practical reality: many engineers want SQLite’s simplicity, but they do not want to memorize every exception to the rules they know from other relational systems.

There are, of course, trade-offs. SQLite’s conservative approach is part of why it has become so dependable. Any new compatibility model would need careful design, strong documentation, and clear tooling so developers understand which rules apply to a given project. Still, the discussion has gained traction because it speaks to a wider issue in software engineering: defaults matter. Developers often trust sensible defaults, especially in tools that are famous for reliability. Whether SQLite ever adopts editions or not, the debate is a useful reminder to scrutinize assumptions, review configuration choices early, and treat backward compatibility as a double-edged sword.

Many developers work on several changes at the same time, and that can make Git feel stressful. A small fix in an old commit may force you to stop, open an interactive rebase, and carefully move through a long list of commits. If anything goes wrong, your working tree can end up in an awkward state. Because of this pain point, some programmers have started to look at alternatives such as jj, which is often presented as a fresh way to manage stacked changes. Still, not everyone wants to switch tools or rebuild an entire workflow just to solve one problem.

That is why the experimental git history command is getting attention. It arrived recently in core Git, with features appearing across two releases. The idea is simple: let developers repair or improve earlier commits without all the usual manual steps. Instead of relying on a long rebase process, git history offers three subcommands: fixup, reword, and split. These are designed to rewrite older commits and then rebuild later commits on top automatically. Since the command is part of standard Git, people can try it without installing another version control system.

The first subcommand, fixup, is for correcting an old commit. A developer stages the correction in the normal way and then runs git history fixup on the target commit. Git folds the staged change into that earlier commit, creates a new version of it, and then rewrites the later commits that descended from it. Branch tips can move along as well, so related local branches stay aligned. This goes beyond a typical autosquash workflow because the command is meant to update every relevant local branch, not just the branch currently being rebased. For teams that juggle parallel work, that could streamline a task that is often tedious and error-prone.

The second subcommand, reword, focuses on commit messages. During development, the meaning of a change can shift as the design evolves, so an old message may no longer describe the code well. With git history reword, a developer edits the message of an earlier commit, saves it, and Git rebuilds the later stack automatically. That sounds small, but clear commit messages matter when people review changes, debug problems, or study the background of a feature months later. In that sense, reword supports cleaner project history without forcing users to dive into complex rebase steps.

The most notable design choice is that these operations are atomic. In other words, Git tries to avoid leaving the repository in a half-broken state. It does this by refusing operations that would create a conflict. That makes the feature safer and easier to trust, especially for people who dislike history editing because it can go off the rails. However, this safety-first approach is also a trade-off. The command is less powerful than jj in one major area: it does not yet treat conflicts as a first-class part of the workflow. Also, according to the source discussion, it does not work when merge commits are involved, which may be a dealbreaker for some teams.

Even with those limits, git history could gain traction because it offers practical benefits inside a tool many developers already use every day. It may appeal to engineers who like Git but want a smoother way to clean up stacked commits and branch structures. At the same time, it shows that Git itself is still evolving in response to pressure from newer ideas. The next thing to watch is whether the command matures, expands beyond its current limits, and wins broader community discussion. If that happens, more developers may find that they can improve their workflow without taking the plunge into a completely different system.

As AI coding agents become part of daily development work, a new problem is coming into view: people use many agents, but they often cannot see the full picture of what those tools are doing. AgentsView is an open-source project on GitHub that aims to solve that problem. Its main idea is simple: let users browse, search, and analyze sessions from AI coding agents in one place, while also tracking token use and related costs. According to the project description, it supports Claude Code, Codex, and more than 20 other agents.

One part that stands out is its local-first approach. In plain terms, that means the tool is designed to keep everything on the user’s own machine instead of sending session records to a hosted service by default. The project also says it works with one binary and no accounts. For many developers, that lowers the barrier to entry. They can install the tool and inspect their own work without signing up, creating a team workspace, or moving sensitive coding history into another company’s system.

This kind of visibility matters because coding agents are no longer a side experiment. In many teams, they are starting to gain traction as everyday assistants for writing code, fixing bugs, and exploring unfamiliar codebases. But once several tools enter the workflow, it becomes harder to compare them. A developer may remember that one agent gave a smart answer last week, but not which prompt led to it, how long the session took, or how many tokens were consumed. AgentsView tries to bring those details together so users are not flying blind.

The idea also reflects a broader shift in AI tooling. Companies first rushed to adopt powerful models, but now many are getting into the weeds of operations. They want better records, clearer analytics, and a way to see whether usage patterns are sustainable at scale. Cost tracking is especially relevant because token spending can rise quietly in the background. A tool that surfaces session history and token statistics may help engineers and managers spot trends, justify expenses, or decide when one agent is more efficient than another.

Still, there are trade-offs. A local-first design can strengthen privacy and user control, but it may also limit some features that are easier in centralized products, such as shared dashboards across a large organization. In the same way, broad support for many agents sounds appealing, yet maintaining compatibility can be a moving target if those agents change quickly. Open-source tools also depend on community interest, and users may wonder how fast new integrations or fixes will roll out. In other words, the project’s strengths could also be a double-edged sword.

Even so, AgentsView points to an emerging need in the AI development ecosystem. As coding agents multiply, developers will likely ask for more than raw model power. They will want traceability, cost awareness, and practical insight into how these systems fit into real engineering work. Whether AgentsView becomes a standard tool or remains a niche option, it highlights a useful question for the industry: if AI agents are becoming part of the toolchain, how should teams monitor them in a simple, trustworthy way?

For many years, software companies followed a familiar path. First, they built one strong feature and sold it as a better alternative to older tools. Then they added more products and tried to become a full suite. Finally, the biggest firms aimed to become a platform that others depended on. This model worked because building good software was slow, expensive, and difficult to copy. Time itself acted as a moat, or a form of protection. But the rise of AI agents and AI-assisted coding is now putting that logic under pressure.

A recent discussion in the tech world argues that software is no longer the main prize. Instead, software may become the packaging around something more valuable. The source points to a sharp market reaction earlier this year, when investors seemed to realize that the old rules might no longer apply. Even companies that launched fast-growing AI products did not always receive a positive market response. That suggests a deeper concern: if competitors can reproduce a useful feature very quickly, then the feature alone may not defend a business for long.

One reason is that the barriers to building digital products are falling fast. AI tools can now help users write code, design workflows, and connect services with much less effort than before. As a result, more non-technical founders can launch products and even earn revenue. This is a major shift. In the past, technical skill was a gatekeeper. Today, more of the value may come from understanding customer problems, owning unique distribution, or controlling a trusted relationship with users. In other words, competition is rotating away from what you build and toward what you own.

This idea changes how people think about SaaS, or software sold as a service over the internet. If basic product surfaces become easier to copy, then companies may need to focus on assets that are harder to replicate. These could include proprietary workflows, brand trust, access to customers, compliance know-how, or deep integration into a company’s daily operations. Outcome pricing is also gaining traction in these conversations. Instead of charging simply for seats or usage, a vendor may charge for a business result. That can be powerful, but it is also a double-edged sword because the provider may take on more risk.

Distribution is another part of the new playbook. In the past, product-led growth worked well when users could discover a tool, try it alone, and gradually expand adoption inside a company. But if many AI tools can be built in a weekend, then having a nice interface is not enough to stand out. Companies may need stronger channels, partnerships, communities, or embedded positions inside existing workflows. At the same time, customers will have more choice, which is good for innovation but may also create noise. Buyers could find it harder to separate durable products from short-lived experiments.

The bigger picture is not that SaaS disappears overnight. Businesses still need secure, reliable systems and clear ownership when work happens at scale. However, the center of value may be shifting. AI agents can automate tasks, but they also turn some parts of software into a commodity more quickly than before. For founders, engineers, and enterprise buyers, the key question is no longer only, “What can we build?” It is also, “What can we defend, distribute, and tie to real outcomes?” The companies that figure that out may write the next playbook for the industry.

vocabulary