📰 English IT Daily · 2026-07-20

Many people now ask a new kind of SEO question: how can a website appear inside ChatGPT answers? A recent blog post looked at that question in an unusual way. Instead of judging only the final text that users see, the writer examined the network traffic sent to the browser while ChatGPT was working. In other words, he looked under the hood. This matters because many popular claims about AI visibility are based on guesswork. People often repeat advice such as “write better content” or “post on Reddit,” but they do not always know what the system is actually doing behind the scenes.

The main idea of the study was simple. Large visibility reports usually send many prompts, collect the answers, and then infer patterns from those outputs. That method gives a big sample, but it is still a black box. By contrast, reading network traffic can reveal the internal labels and fields that the product itself uses. According to the source, the captured JSON showed items such as result_source, vendor names, search queries written by the system, the model used, and a field called turn_use_case. This kind of evidence does not prove how often each pattern happens across all users, but it does show that these internal structures exist.

That distinction is the heart of the article. Structural facts and frequency claims are not the same. If a field appears clearly in the traffic, we can be fairly confident that it is real. However, if one person sees a certain source type often in a small set of searches, that does not automatically mean the same pattern holds at scale. The writer was careful to stress this point. He used one logged-in Pro account over only a few days, and many of the prompts were about SaaS and other tech topics. So the findings offer direction, not a final measurement of the whole system.

Even with those limits, the results are still revealing. The traffic suggested that not every ChatGPT response uses the web in the same way. Some text queries may skip the web entirely, while more complex “Thinking” tasks can trigger many extra searches, including narrow site-specific checks and price-verification queries. That paints a more nuanced picture than the common belief that the model simply grabs a few pages and summarizes them. It suggests a layered process in which the system may decide first whether outside information is needed, and then run additional checks depending on the task.

For publishers, marketers, and engineers, this is a double-edged sword. On one hand, it is useful to know that source selection may depend on query type, internal use case, and vendor pipelines rather than on one simple ranking rule. On the other hand, this makes optimization harder. There may never be a single playbook for “ranking in ChatGPT.” A site could be visible for one kind of question and almost invisible for another. This also raises questions about transparency. If AI tools influence what users read and trust, people will want clearer explanations of why certain sources surface and others do not.

The broader lesson is not that one small traffic study has settled the debate. It has not. But it does move the conversation away from pure speculation and toward direct observation. For technical readers, that is the key takeaway. When a system is a black box, outputs alone can be misleading. Looking at logs, request flows, and internal labels can reveal how the machinery works, or at least how it describes its own process. As AI search tools gain traction, more careful reverse engineering will likely shape the next wave of research, product strategy, and content decisions.

A recent report says some LG monitors can trigger app installation on Windows PCs without a clear consent step from the user. According to tests described by VideoCardz and based on reporting from Gamers Nexus, Windows Update installed LG-related packages when certain monitors were connected. Soon after that, a program called LG Monitor App Installer appeared on the system. In many cases, users did not see a prompt asking whether they wanted this to happen. That is why the story has struck a nerve with many PC users, especially people who care about privacy, system control, and unwanted apps.

The issue became more controversial because the installed app was said to show promotions, often for a McAfee subscription. In testing across many system boots, the popup appeared almost every time. One message offered a free trial that would later become a paid plan. On one boot, the app promoted an LG utility instead. For users, this changes the situation from a simple driver or support tool into something more sensitive. Many people accept that hardware may need drivers or control panels, but they draw the line at marketing messages arriving through an automatic system process.

What makes this case notable is the path the installation appears to take. The report says Windows Update first delivered an LG extension package and a software component package linked to the monitor. Then the installer showed up shortly after. In other words, the monitor was not just acting as a passive display. It seems to have been associated with device metadata, which is information Windows uses to identify hardware and fetch related items. This kind of mechanism can be convenient because it reduces setup friction, but it can also feel opaque when users are not clearly told what will be installed and why.

The story also suggests that the behavior is not limited to brand-new products. A monitor that had been bought several years earlier reportedly showed the same popup after being connected to a Windows PC. Complaints about the LG Monitor App Installer appear to go back at least to 2024, although recent reports suggest the behavior may now be affecting more models. That broader pattern matters. If this is not a one-off glitch but something that can surface across different devices and over time, then it raises larger questions about how hardware vendors roll out companion apps and promotions at scale.

LG is not the only company using this route. The source notes that Dell has also used Windows Update to install software associated with certain Alienware devices when compatible hardware is detected. This shows the issue is bigger than one brand. From a vendor’s point of view, automatic installation can smooth the onboarding process and ensure that customers get features, settings tools, or firmware support without searching manually. But that convenience is a double-edged sword. If users feel that vendors are overstepping, trust can erode quickly, even when the technical method itself is allowed by the operating system.

For users and IT teams, the practical question is what to do next. One reported workaround is a Windows Group Policy setting that prevents the automatic download of apps associated with device metadata. That can stop surprise installations, but it may also block useful utilities that some devices need. In managed environments, this trade-off is familiar: tighter control often means more manual work later. The bigger lesson is that consent, transparency, and least surprise still matter. As connected devices become smarter and more integrated with operating systems, companies will face more scrutiny over where setup automation ends and unwanted behavior begins.

A new blog post by Chip Weinberger challenges a famous idea in tech: “hardware is hard.” Weinberger wrote about building and selling Jamcorder, a device that automatically records MIDI piano performances without any action from the player. He says more than 2,500 units have already been sold, and the product can now stand on its own as a business. For him, the surprise was not that hardware was difficult. The real surprise was that, compared with the software work, the hardware side felt relatively smooth.

That view may sound unusual, especially to engineers who have heard endless warnings about manufacturing, shipping, and component shortages. Weinberger came from a software background, so he expected electronics design, plastics, and fulfilment to be the hardest part. Instead, he says the software took far more effort. According to his post, Jamcorder required around 200,000 lines of code across firmware, an app, and manufacturing tools. He spent more than three years on that work, often putting in long nights. In that context, the hardware work did not become the nightmare he had feared.

Part of the reason was careful product design. Weinberger intentionally kept the device simple. The printed circuit board, or PCB, used only 25 unique components. The MIDI connectors were custom-made, but everything else was off the shelf, meaning standard parts that could be purchased easily. Assembly was also straightforward: one PCB and one screw. He says the case design was also kept simple for injection molding. To avoid getting bogged down in extra complexity, he removed features such as low-battery detection, ambient light detection, a power button, and even USB-C.

He also gives a striking example from early production. To refine the process, he hand-assembled the first 500 units himself, and he says it took four days. More importantly, he reports that the work went smoothly and required no design changes. That does not mean hardware has no risks. He mentions that tariffs were a close call, and he clearly admits that things would look very different at much greater scale or with a much more complex product. Still, his main point is that the difficulty of hardware depends heavily on the choices a team makes at the start.

This argument matters because many software engineers treat hardware as a field that is out of reach. Weinberger’s experience suggests a more nuanced picture. Hardware can be hard in crowded markets, in industries with thin margins, or when products need complex assembly, calibration, or regulation. But a focused device with clear limits may be another story. In other words, hardware is not easy by default, but it is not automatically impossible either. If founders protect their margins and keep their company lean, physical products may be more realistic than they first appear.

The post ends with practical advice for anyone who wants to ship hardware at medium scale. Weinberger recommends keeping the bill of materials, or BOM, simple, avoiding parts from only one manufacturer, and steering clear of difficult assembly or calibration steps. He also suggests working closely with Chinese suppliers and assembly partners, noting that Alibaba can be useful. Finally, he says founders should aim for at least 70% gross margin. For engineers in any field, the broader takeaway is clear: complexity is often a choice, and disciplined scope can turn a risky idea into a viable product.

Linus Torvalds, the longtime leader of Linux kernel development, recently shared a skeptical view about using large language models, or LLMs, in low-level system work. The Linux kernel is the core part of the operating system, so even small mistakes can cause serious problems. In that context, Torvalds argued that code quality, careful review, and deep human understanding matter far more than fast text generation. His comments fit a wider debate in the tech world: where can AI tools genuinely add value, and where do they create new risks?

Kernel development is not like writing a simple web app or a short script. It often involves hardware behavior, memory management, timing issues, and security concerns that are difficult to reason about. Developers must understand how one change can affect many other parts of the system. Because of that, maintainers do not only check whether code seems to work. They also look at why it works, whether it follows project standards, and whether it might break under unusual conditions. In such an environment, anything that sounds convincing but lacks real understanding can become a liability.

That is one of the main concerns around LLMs. These models can produce fluent explanations and plausible code, but they are also known to invent facts, misunderstand context, or hide uncertainty behind confident language. For casual tasks, that may be manageable. In kernel work, however, a subtle mistake can be very expensive to track down later. Torvalds's view appears to be that maintainers should not get swept up in AI hype when the job demands precision and accountability. If a patch is submitted, reviewers need to trust not only the output but also the reasoning behind it.

This does not mean AI has no place in serious engineering. Many developers already use AI assistants to summarize documentation, explain unfamiliar code, suggest test cases, or clean up routine text. In that sense, LLMs may still serve as a productivity aid around the edges of development. The key question is where to draw the line. Using a model to brainstorm is very different from relying on it to write critical kernel code that interacts directly with hardware or security boundaries. The distinction matters because the cost of being wrong is not the same in every layer of computing.

There is also a cultural side to this discussion. Open-source projects like Linux depend on trust, reputation, and careful peer review. Contributors are expected to stand behind their patches and explain their design choices. If AI-generated submissions become common, reviewers may face more noise and more polished-looking patches that are harder to evaluate. That could bog down maintainers rather than save them time. In other words, a tool that promises efficiency can become a double-edged sword if it increases review burden instead of reducing it.

For engineers across the industry, Torvalds's comments are a useful reality check. AI coding tools are gaining traction, and many teams are under pressure to adopt them quickly. Still, not every part of engineering should be automated in the same way. High-stakes, low-level work demands rigor, traceability, and judgment that current models may not provide consistently. The broader lesson is not simply to reject AI, but to use it with clear limits and strong review practices. As companies experiment further, the most sensible approach may be to keep humans firmly in the loop, especially where reliability is non-negotiable.

A humorous article from design site VelvetShark has revived an odd question in tech branding: why do so many AI company logos look strangely alike, and why do people keep making the same anatomical joke about them? The writer points to a repeated visual formula: a circular shape, a central opening, soft curves, and sometimes a glowing gradient. Once you notice the pattern, it is hard to unsee. The joke is crude, but the design trend behind it is real, and it says something interesting about how AI companies want to present themselves in 2025.

This discussion did not appear out of nowhere. Commentators had already noticed the trend earlier, including coverage in 2023 that described the rise of swirling, circular AI symbols. VelvetShark simply pushed the joke further and named what many people were already thinking. The article highlights examples from major AI firms and argues that their logos often rely on the same basic ingredients: symmetry, softness, motion, and a focal point in the middle. OpenAI’s newer branding is mentioned as one case where the company offered a polished explanation about the meeting point between humanity and technology, while critics saw a familiar visual cliché instead.

There are practical reasons this style may have gained traction. First, AI products are abstract. Unlike a camera, car, or shoe, a language model or assistant has no obvious physical form. Designers therefore reach for symbols that suggest intelligence, flow, connection, and emergence. A circle can imply completeness and harmony. A central void can suggest depth, focus, or a system generating something from within. Soft gradients and organic curves also make advanced technology feel less cold and less threatening. In other words, the visual language is doing a lot of branding work before a user reads a single word.

At the same time, the trend may be self-reinforcing. Once a few high-profile companies choose a certain look, others follow suit because it signals that they belong to the same category. This is common in tech. Cybersecurity firms often use shields, and productivity tools often use check marks or bright geometric icons. In AI, circular emblems may have become shorthand for intelligence in motion. But that shorthand is a double-edged sword. It can make a new product feel familiar, yet it can also blur differences between competitors. If every brand reaches for the same visual metaphor, distinctiveness starts to fade.

That is why the joke matters beyond simple internet sarcasm. Branding is not just decoration; it shapes first impressions, trust, and memorability. If a logo unintentionally distracts users or becomes the butt of online discussion, it can overshadow the message a company wants to send. On the other hand, viral mockery can increase attention, and attention is valuable in a crowded market. Some people may even argue that the whole debate is overblown. After all, many logos across industries are circular because circles are flexible, balanced, and easy to use across apps, websites, and small mobile screens.

Still, this small controversy offers a useful snapshot of today’s AI industry. Many companies are racing to look advanced, human-centered, and approachable at the same time, so they end up drawing from the same visual playbook. For product teams, marketers, and engineers, the lesson is fairly straightforward: design choices carry meaning, even when they seem minor. A logo must work at scale, fit many interfaces, and support a clear identity. But it also needs enough originality to stand out from the pack. As AI branding keeps evolving, it will be worth watching whether companies stick with the circular trend or break away from it.

For many developers, frontend work used to feel direct and simple. You could write HTML, add some CSS, upload the files, and your website was live. Over time, that experience changed dramatically. Modern tutorials often begin with package managers, build tools, bundlers, linters, and several layers of configuration before a page even appears on the screen. To people who stepped away from frontend for a few years, this shift can seem absurd. However, the main argument in recent discussions is that this complexity did not appear out of nowhere. It grew step by step as developers tried to solve real problems in browsers and in larger web applications.

One early problem was the need to update part of a page without reloading the whole site. As users expected smoother interactions, developers turned to JavaScript techniques such as AJAX, which allowed browsers to fetch information in the background. In those years, jQuery gained traction because it made painful browser differences easier to handle. It offered a practical way to open menus, validate forms, and load content dynamically. For a while, that was enough. But as web apps became more ambitious, developers found themselves constantly editing the page by hand. If one number changed, they had to update several parts of the screen manually, and it was easy for the interface to drift out of sync with the actual state.

That synchronization problem opened the door to modern UI frameworks. Their core idea was declarative design: instead of writing every step needed to change the page, developers describe what the page should look like for a given state, and the tool handles the updates. This was a major turning point. It reduced a lot of repetitive work and made large applications easier to reason about. Yet every solution introduced fresh trade-offs. Once apps relied heavily on JavaScript, teams also had to think about component structure, state management, code reuse, performance, and the growing amount of code shipped to the browser.

As projects scaled up, new tooling emerged as scar tissue over earlier pain points. Build systems helped combine files, transform newer syntax, and optimize assets for production. Package managers made it easier to share code, but they also pulled in huge dependency trees. The result was a paradox: tools meant to simplify development could also bury teams in setup and maintenance. Beginners often feel overwhelmed because they meet the entire stack at once, without seeing the historical reasons behind it. In that sense, the modern frontend world can look like a cathedral of solutions built on top of one another, each one justified by a problem that came before.

Not everyone agrees on how much complexity is necessary. Supporters of modern tooling argue that today’s web applications are much closer to desktop software than to the simple websites of the past. They need routing, accessibility, testing, internationalization, offline behavior, and fast updates across many devices. Critics reply that the industry sometimes reaches for heavy tools too quickly, even for small sites that do not need them. They warn that convenience can become a double-edged sword: abstraction saves time, but it can also hide what the browser is actually doing and make systems harder to debug.

An interesting part of the current debate is that the frontier may be moving back toward simplicity. Newer approaches often try to keep the useful lessons of the past two decades while reducing the amount of JavaScript sent to users. In other words, after years of piling on layers, some developers want a calmer model that feels closer to the old days of shipping a file and letting the browser do more of the work. For engineers outside the frontend world, the lesson is clear. Today’s complexity is easier to understand when you follow the wounds that created it. Each tool is part of a long chain of practical decisions, not just a fashion trend.