📰 English IT Daily · 2026-07-13

Many AI products look very different on the surface, but underneath they do a similar job: they generate tokens, or small units of text, one after another. A user sends a prompt, the model predicts the next token, and then repeats that process until it finishes the answer. This step is called inference. In recent years, inference has moved to center stage because companies now spend huge amounts of money not only to train models, but also to answer requests every second of the day. That is why experts are looking more closely at what happens inside a data center when just one prompt arrives.

The journey usually begins at a gateway. This is the entry point that receives the user request, checks identity and safety rules, and sends the prompt to the right service. After that, a scheduler decides where the work should go. In simple terms, the scheduler is the traffic controller. It tries to match each request with available computing resources while keeping delays low and hardware use efficient. This may sound routine, but at scale it becomes a delicate balancing act. A small delay at the start can ripple through the whole system and hurt the user experience.

Next comes an important split in the process: prefill and decode. During prefill, the model reads the full prompt and builds the internal state it will need for generation. This phase is mostly limited by raw computation, so it strongly affects time to first token, the delay before the first word appears on screen. Decode is different. Once generation begins, the model produces tokens one by one, and this stage often depends more on memory bandwidth than on pure compute power. That means the system may have very fast chips, but still run into a bottleneck if it cannot move model state quickly enough.

One key tool in this flow is the KV cache, which stores attention information from earlier tokens so the model does not need to recalculate everything from scratch each time. That saves work, but it also creates pressure on memory and interconnects. The request then reaches GPUs or other accelerators that run the model itself. In large deployments, several devices may need to work together, so the network inside the data center matters a great deal. Fast links, good scheduling, and careful placement can all move the needle on both speed and cost. If any part lags behind, the whole pipeline suffers.

This is why AI infrastructure is no longer a black box for engineers or investors. The economics depend on each step of the round trip. A model may be impressive in a benchmark, but real services are judged by latency, reliability, and cost per token. Companies also have to think about power, cooling, and physical space, not just chips. In other words, the hard part is not only the model; it is the full system around it. For buyers of inference services, this becomes a weighted trade-off among response speed, consistency at busy times, security, portability, and model coverage.

There are also different views on where long-term value will settle. Some people believe the main winners will be software layers that manage routing, batching, and optimization. Others argue that durable value sits closer to physical constraints such as memory bandwidth, networking, optics, and power delivery. Both sides agree on one thing: token prices are falling fast, while demand keeps climbing. That combination can unlock more usage instead of shrinking the market. For engineers, the lesson is clear. To understand modern AI, it is not enough to know the model architecture. You also need to follow the token, end to end, through the machinery that delivers every answer.

Postgres 19 introduces a new property graph feature that lets developers describe graph relationships on top of ordinary relational tables. The idea is simple but powerful. In many systems, the schema already looks like a graph: rows can act like nodes, and foreign keys can act like edges. For example, a race result can point to a driver, a race, and a constructor. In standard SQL, developers follow those links with joins. With property graphs, Postgres adds another way to ask the same kind of question, using graph patterns instead of writing every join by hand.

This matters because graph-shaped problems appear in many domains. Recommendation systems, fraud analysis, social networks, logistics, and scientific research often depend on connections between records, not just single rows. Researchers working on relational deep learning have also argued that a normalized schema already contains useful graph structure. In many current workflows, however, that structure gets pulled out of the database and rebuilt in Python or another tool. That can become a bottleneck, especially when teams want one system of record instead of moving large amounts of information into memory.

The new feature in Postgres 19 is not a separate graph database hidden inside Postgres. Instead, it is an overlay on existing tables. Developers create a named property graph and declare which tables should be treated as vertices and which should be treated as edges. They also define keys, labels, and the properties that can be queried. In plain terms, this means teams can map their current schema into a graph model without copying the rows anywhere else. The underlying tables stay where they are, and the graph view sits on top of them.

A key point from early hands-on exploration is that a table can pull double duty. In the Formula 1 example discussed in the source article, a results table can be treated as a vertex with its own properties, but rows from related edge definitions can also connect those results to drivers or races. That idea may feel unusual at first if you think in strict categories, where one table must be either an entity table or a relationship table. In practice, many business events carry both meanings. An event can be a thing you want to analyze on its own, and it can also serve as a link between other things.

The practical benefit is readability and flexibility. A graph pattern can express traversal more directly than a long chain of joins, especially when the question is about paths or repeated relationships. At the same time, there are trade-offs. SQL joins are familiar, mature, and often easier for teams to debug because everyone knows what they compile down to. A graph layer could streamline some queries, but it may also introduce a learning curve. If developers are not careful, they could get lost in the weeds trying to decide whether a graph pattern is truly clearer than a conventional SQL statement.

For engineers, the larger takeaway is that relational and graph thinking are starting to converge. Postgres 19 does not replace relational design; rather, it broadens the toolkit. Teams that already store highly connected information in Postgres may gain traction from using graph patterns without adopting a separate platform. The feature is still new, so it will be worth watching how well it fits real production workloads, how query performance behaves, and how smoothly it works with analytics and AI pipelines. Even so, it signals a shift: graph-style questions no longer have to live only outside the relational world.

Mitchell Hashimoto is one of the best-known names in developer tools and open-source infrastructure. He helped create products such as Vagrant, Packer, Consul, Terraform, Vault, Nomad, and Waypoint. In a recent interview with Alex Alejandre, he spoke about a very different project: Ghostty, a terminal emulator. He also discussed the Zig programming language and the realities of open-source maintenance. The interview matters because it shows how an experienced founder and engineer thinks when he returns to low-level technical work after years of leading products and companies.

Hashimoto said Ghostty began as a personal technical challenge rather than a business plan. After leaving HashiCorp, he wanted to sharpen skills that had grown dull over time. In particular, he wanted to work on GPU programming, desktop or single-node systems, and Zig. He had spent many years building command-line tools, but he realized he did not fully understand how a terminal emulator worked. His original aim was simple: build something good enough to run Vim and a compiler, let it build itself, and then throw it away. But as he dug into the terminal world, he found that nothing really fit the niche he wanted: something fast, feature-rich, and natively cross-platform.

That gap in the market gave Ghostty room to gain traction. Hashimoto shared early versions with friends, and those users started relying on it every day. The project’s Discord community reportedly began as a private group chat among friends and then took on a larger role. He also said he avoided a public launch for some time because his reputation could bring undue attention before the product was ready. This is a familiar open-source problem: a well-known developer can attract users quickly, but that attention can be a double-edged sword. It can create excitement, but it can also raise expectations, increase support requests, and put extra pressure on maintainers.

In the interview, Hashimoto also pushed back against the idea that terminals should become all-purpose platforms like web browsers. In theory, terminal applications could add more and more features, including richer media or more advanced interface behavior. However, he argued that terminals are at their best when they focus on what makes them unique: text-based interaction, speed, scriptability, and a clear security model. In his view, terminal tools are especially strong when they can be composed easily, following the long-standing Unix idea that programs should do one thing well and work together. Better terminal applications, he suggested, could also lead to better automation.

At the same time, he pointed to a deeper technical obstacle. Traditional terminals and pseudo-terminals, often shortened to PTYs, still depend heavily on in-band signaling. In simple terms, that means information is sent through one unstructured byte stream mixed with escape sequences. This system has worked for decades, but it can be messy and limiting. Hashimoto suggested that the ecosystem needs more fundamental improvement rather than endless small patches on top. That view is notable because many developers treat terminal behavior as old but settled technology. His comments suggest there is still a lot of low-level design work left to do.

The interview also highlights a broader issue in open source: maintenance is rarely glamorous, but it shapes the tools millions of people use. Building a popular project is one challenge; sustaining it is another. Ghostty, Zig, and terminal protocols may sound like topics in the weeds, yet they affect developer productivity, portability, and reliability in everyday work. For engineers, the big takeaway is that mature tools still have room for reinvention. For maintainers, the message is just as clear: success is not only about shipping code, but also about choosing a scope, setting expectations, and protecting the long-term health of a project.

A small web project is showing a surprising idea: a real TrueType and OpenType font can turn text inside square brackets into QR codes. Instead of creating an image file, the user simply types something like [hello], applies the font, and the letters are shaped into a QR pattern. Text outside the brackets stays normal and readable. At first glance, this may sound like a neat trick, but it also highlights how far modern font technology can go beyond ordinary typography.

The project works through text shaping, which is the process that a system uses to decide how characters should be displayed. In this case, the font includes built-in OpenType rules that replace bracketed text with a QR code during rendering. That means there is no separate image generation step and no preprocessing pipeline. The content is still stored as ordinary text characters, so users can copy and paste it, keep it in plain text files, or place it inline with regular Latin text. In other words, the font blurs the line between text and graphic output.

The idea is clever because it challenges a basic assumption: people usually think of fonts as visual style, not as logic. Yet advanced fonts can contain substitution rules that react to the text they receive. This project pushes that capability in an unusual direction. It is not trying to replace standard QR tools across the board, but it opens a new path for lightweight experiments, artistic layouts, and compact workflows. For developers, it is also a reminder that some problems can be solved lower in the stack than expected.

There are limits, of course. The project offers several font versions with different character capacities, so the amount of text that can fit in one QR block is restricted. The source context says users should use printable ASCII inside square brackets, and each font supports only up to a certain number of characters. There is also a browser-specific wrinkle. Layout engines usually decide line breaks before text shaping happens, so a QR block may be split across lines if the original text includes spaces, dots, or slashes near the edge of a container. To sidestep that problem in HTML, the bracketed text should be wrapped in an element styled with white-space: nowrap or display: inline-block.

That trade-off makes the font both practical and experimental. On one hand, keeping the QR content as text is elegant. It can travel through copy-and-paste workflows, remain readable outside the brackets, and fit into plain text systems where images would be awkward. On the other hand, reliability depends on the rendering environment, and that can be a double-edged sword. If a design relies heavily on layout behavior in browsers or other apps, small differences in text handling could trip people up. As a result, this approach is probably best suited to controlled contexts rather than every production scenario.

Even so, projects like this often gain traction because they make engineers look at old tools with fresh eyes. A font that generates QR codes will not overturn the wider ecosystem, but it does show that typography, encoding, and interface design can overlap in unexpected ways. It may inspire more experiments in which text remains the source of truth while presentation becomes smarter at render time. For programmers, the larger lesson is simple: sometimes the most interesting ideas come from bending familiar standards, not from building a whole new system from scratch.

A new experiment called Ghost Font asks a simple but timely question: can people share written messages in a way that humans can read, but AI systems cannot? The project presents itself as an anti-AI font, although it is not a normal font file. Instead, it turns text into moving video. The idea is that the human eye is very good at noticing motion and patterns over time, while many AI tools still depend on clear static images or standard text. In a period when AI can scan screenshots, documents, and photos with growing accuracy, this idea has struck a nerve.

Ghost Font works by showing letters through motion rather than through fixed shapes. Dots move in a way that lets a human viewer recognize a word almost immediately, even though a single paused frame looks like meaningless visual noise. The project also uses decoys, or false visual clues, to throw AI models off the scent. According to the project description, when recent AI models were given videos created with Ghost Font, they often read the decoy message instead of the real moving one. In other cases, they struggled unless they were told exactly what method to look for.

That design matters because modern AI has already caught up with older anti-reading techniques. The source page points to ZXX, a typeface released in 2013 and described at the time as readable by humans but difficult for optical character recognition, or OCR, software. Its letters were hidden with noise and misleading marks. But what once looked surveillance-proof no longer seems so strong. Today, advanced AI systems can often read text in ZXX with little trouble. Ghost Font is trying to move the goalposts by using time and motion, not only shape, as part of written communication.

The project is still a prototype, and its creator does not claim that it is a silver bullet. In fact, the source explicitly notes an important trade-off: simply hiding a message in video is not a perfect defense. A model working in a limited online environment may fail to decode the message frame by frame, but a more determined attacker could still analyze the video in detail, write custom code, or use computer vision techniques designed for motion. As with many privacy tools, the real question is not whether a system is impossible to break, but whether it raises the cost and effort of breaking it.

This makes Ghost Font interesting beyond its novelty. It highlights a growing tug-of-war between human communication and automated reading. Many people now assume that anything visible on a screen can be captured, indexed, summarized, and reused by AI. For artists, journalists, private communities, or anyone who wants a message to stay among real viewers, that shift creates unease. A tool like Ghost Font pushes back against the idea that all digital text must be machine-friendly. At the same time, it is a double-edged sword: a format that blocks AI assistants could also reduce accessibility, searchability, translation, and archiving.

For people in tech, the bigger lesson may be conceptual rather than practical. Ghost Font shows that human perception and machine perception do not always overlap, even when AI seems highly capable. It also reminds us that benchmarks can be misleading if they focus only on standard inputs. Systems that perform well on screenshots or documents may still fall short when information is spread across motion, distraction, and ambiguity. Whether Ghost Font gains traction or remains a clever side experiment, it points to a future in which interface design, security, and AI resistance become more tightly connected.

A recent blog post by developer Dan Q argues that some mobile apps do not need to be apps at all. He wrote about a travel app called Travelbound, which families were asked to install to see a trip itinerary, accommodation details, and related documents. After trying it, he felt the app was doing a job that a normal webpage could handle more simply. In his view, the content was mostly text, images, and links to PDF files. That raised a basic question: why ask users to download and keep a separate app for information that could live on the web?

His complaint was not only about convenience. He said a webpage would be easier to copy, print, save, bookmark, and search. It would also work on almost any device and could be more accessible for users with different needs. By contrast, he believed the app added extra baggage. According to his description, it also included tracking linked to a Google account and showed promotional content for other trips. From his point of view, those features were not benefits but drawbacks. This is a familiar debate in tech: companies often package simple information inside an app, even when the browser might be enough.

To test his idea, Dan Q decided to inspect how the Android app worked. He set up a virtual Android device, rooted it, and used a traffic interception tool to watch the app's network requests. In simple terms, he placed the app under a microscope and looked at what it asked for when it loaded information. He then installed the app and configured the proxy so it would focus only on that one app's traffic. This cut through the noise and made it easier to understand the app's behavior.

After a short period of experimentation, he found that the app was requesting trip information from a web address built from the user's login details. That request returned JSON, a structured text format often used to move information between systems. The response appeared to contain the full itinerary, references to files such as images, and a separate section for promotional items. In other words, the app was not doing heavy local processing. It was mainly fetching content from the web and presenting it in a mobile wrapper. He also noticed that some image links expired after a while, which meant the content needed to be fetched again from time to time.

With that discovery in hand, he built an alternative. He wrote a Ruby script that runs on a schedule, pulls the latest JSON, and turns it into an HTML page. He chose to leave out the promotional section and focus on the practical information: the itinerary and the attached files. This workaround shows how thin some apps really are. If the core content already comes from web requests and can be rendered as HTML, the line between an app and a webpage starts to look blurry. For users, that can be a double-edged sword: apps may feel polished, but they can also create friction when they are unnecessary.

The bigger issue goes beyond one travel app. Many organizations still prefer apps because they offer branding, notifications, analytics, and a more controlled user experience. In some cases, that trade-off makes sense, especially when offline features, device integration, or secure local storage are important. But when an app is little more than a container for web content, people may push back. For engineers and product teams, this story is a useful reminder to question assumptions. Before rolling out another app, it is worth asking whether the browser already solves the real problem in a simpler, more open way.

vocabulary_en,

A recent essay by Ian Reppel uses an unusual animal to explain a common business problem. The Mexican cavefish lives in two nearby environments. In rivers, it has eyes and behaves like a normal fish. In dark caves, members of the same species are blind. Their genes are still almost the same, but the environment changes which traits are expressed. In the cave, energy no longer goes into sight. Instead, it is redirected to abilities that help the fish survive there, such as better smell and stronger fat reserves. Reppel argues that something similar can happen inside successful companies.

His main idea is not the usual story about large firms missing a market shift because they protect old products or profits. Instead, he describes what he calls “competence blindness.” This happens when a company grows fast and gradually stops recognizing good engineering practice. At first, speed may be necessary. Teams hire quickly, and the hiring bar can slip in order to fill roles. New engineers learn the company’s habits from people who also grew up inside the same system. After several rounds, many employees have no outside frame of reference. They may be skilled and hard-working, but they cannot easily see that some of the company’s ways are weak.

From the outside, such a company can still look healthy. Revenue may be solid, the brand may be strong, and headcount may keep rising. But inside, there can be serious operational problems. Reppel points to examples that many engineers will recognize: build pipelines that only one original author can run, deployments so fragile that a senior engineer must always stay close, and internal documentation so old that it is almost useless. When business results still look fine, leaders may assume the foundations are sound. As a result, careful engineering can become a vestigial trait: the ability still exists in theory, but the environment does not reward it in practice.

This creates a difficult situation for people who join from outside. They arrive with fresh eyes and quickly spot risks that others no longer notice. They may suggest standard practices that the wider industry adopted years ago, such as clearer ownership, safer release processes, or more reliable maintenance work. Yet these ideas can be brushed aside as over-engineered, too academic, or out of step with current priorities. In some cases, even well-meant criticism is taken personally because it seems to challenge the identity of the engineers who held the system together during the company’s rapid growth. That social reaction can be just as powerful as any technical constraint.

One common response is to set up a “center of excellence.” On paper, this sounds sensible. A focused group can create standards, review designs, and spread knowledge across teams. However, Reppel warns that this can become a double-edged sword. If too much control is concentrated in one group, the rest of the organization may stop taking responsibility for quality. Engineers begin to feel that excellence belongs somewhere else. Their intrinsic motivation can fade because the important decisions are no longer theirs. In healthy companies, good practice is ambient and distributed across teams. In weaker environments, it gets extracted into a process-heavy function that tries to enforce quality from above.

The broader lesson is that success itself can hide decay. A company does not need to be failing in public to be going blind internally. Good numbers can mask fragile systems, weak hiring signals, and habits that no longer serve the business. For technology leaders, the challenge is to keep a clear view while growth is still strong. That means checking whether teams can explain why they work a certain way, whether new hires bring useful outside perspectives, and whether engineering quality is truly valued rather than praised only in presentations. The risk is not just slower innovation. Over time, competence blindness can make a company less resilient when conditions suddenly change.

Git is one of the most widely used tools in programming, but it still describes change mainly by lines of text. For many developers, that can be hard to follow in large projects. A new open-source tool called sem tries to solve that problem by adding semantic version control on top of Git. In simple terms, it focuses on code entities such as functions, methods, and classes instead of only showing which lines moved or changed. The project comes from Ataraxy Labs and is presented as part of a broader set of tools for coding agents.

The basic idea is easy to understand. When a developer runs a normal Git diff, the output usually shows added and deleted lines. That is useful, but it can also leave people in the weeds when a refactor moves code around without changing the real behavior. sem parses source code with tree-sitter, a parsing system that can understand programming language structure, and then extracts named entities from the code. According to the project page, it supports 28 languages through tree-sitter. As a result, the tool can say that a specific function was modified or that a class was added, which is often more meaningful than a raw line-by-line view.

This shift could gain traction because modern development is becoming more complex. Teams now work across many repositories, languages, and services, and they often depend on automation. In that setting, understanding the impact of a code change quickly is valuable. sem does not try to replace Git. Instead, it sits on top of it and adds another layer of analysis. The repository also describes features such as entity-level diffs, blame, and impact analysis. That could be useful for engineers who want to know not only what changed, but also which parts of a system may be affected by a particular edit.

The project says it is built for coding agents, and that point stands out. As AI tools become more common in programming, they need cleaner ways to read and reason about code history. A line-based diff can be noisy, especially after formatting changes or large refactors. Entity-level information may give agents and human developers a more precise view of what happened. Still, this is not a silver bullet. Parsing code across many languages and edge cases is difficult, and any semantic tool depends on how well it recognizes structure in real-world repositories. If the parser misses something, the semantic view may also be incomplete.

There are also practical questions about workflow. sem is designed to work in existing Git repositories with no setup, which lowers the barrier to trying it. The project offers several installation options, including a shell script, package managers, an npm wrapper, building from source with Rust, and Docker. At the same time, developers will want to know how smoothly it fits into daily review habits, team policies, and existing automation. The project mentions cloud-backed queries as opt-in for each repository and says logging in does not automatically upload a repository or send a query. That consent model may reassure users who are cautious about privacy.

More broadly, sem reflects a larger trend in developer tools: moving from text-level operations toward structure-aware ones. For years, programmers have accepted line diffs because they are simple and universal. But as codebases grow and AI enters the picture, that old model may start to show its limits. A tool like sem could carve out a niche among developers who want better insight into changes without abandoning Git. Whether it becomes a staple will depend on accuracy, language coverage, and how much value teams see in semantic history compared with the familiar line-based approach.

Many engineers are told that they should fully understand their codebase before making serious changes. That idea sounds reasonable, especially in a small product with a stable team. In that kind of environment, a deep shared understanding can lead to careful design and fewer surprises. But a recent essay argues that this view does not fit every workplace. In large organizations, engineers often work inside huge systems built over many years by many different teams. In those cases, complete understanding is not a realistic goal, and partial understanding may be the normal way to do good work.

The essay pushes back against an older and influential idea from computer scientist Peter Naur. In his paper “Programming as Theory Building,” Naur said that the real product of programming is not just the code itself. It is also the team’s mental model: their intuitive sense of how the program works and why it was built that way. Code and documentation capture only part of that knowledge. If the team disappears, the remaining code can be hard to interpret. This is a powerful point, and many engineers still feel that strong ownership depends on this kind of shared theory.

However, the essay says this argument goes too far when it suggests that lost understanding cannot be rebuilt from the code. In very large systems, starting over is often a non-starter. Old products usually contain countless edge cases, special rules, and historical quirks that were added for real users over time. Even a highly skilled team would struggle to rebuild all of that behavior from scratch. That is why successful rewrites usually do not wipe the slate clean. Instead, teams carve out smaller parts, isolate them, and replace them step by step while the rest of the system keeps running.

The author also notes that abandoned codebases are often brought back to life. In a big company, team turnover can leave a service with nobody who truly knows it well. A few people leave, maintenance slows down, and suddenly the remaining engineers have to pick up the pieces. According to the essay, this happens more often than many developers admit. Yet engineers still manage to take ownership of neglected systems, read the code, run tests, inspect behavior, and gradually form a workable understanding. It may be incomplete, but it is often enough to fix bugs, improve reliability, and safely add features.

This view has practical consequences for engineering culture. If full understanding is impossible in some environments, then teams should not pretend otherwise. Instead, they should create conditions that support partial understanding. That can include clear interfaces between components, better logs, stronger tests, readable change histories, and documents that explain why a system exists. It also means accepting that many engineers will go deep only in their local area and stay out of the weeds elsewhere. This approach can feel less elegant than total mastery, but it matches the reality of large, fast-moving organizations.

The debate matters because it shapes how teams hire, document, review code, and plan rewrites. If leaders expect every engineer to understand everything, they may set impossible standards and slow work down. On the other hand, accepting partial understanding should not become an excuse for sloppy thinking. Engineers still need discipline, curiosity, and safe ways to learn unfamiliar systems. The essay’s main point is not that understanding does not matter. It is that, in big codebases, useful understanding often comes in layers. You do not need to know every line to make sound decisions, as long as you know enough about the part you are changing and the risks around it.

vocabulary list deliberately stretches the learner with richer, less common words, idioms and natural collocations (C1-C2). This learner already knows everyday English and common tech jargon. Topics span all of tech — AI, security, cloud, hardware, programming, science and more — not limited to any single vendor. You write in the style of Engoo Daily News but with a deeper, feature-length article, a vocabulary list, and discussion questions. You always return STRICT JSON only.