📰 English IT Daily · 2026-07-14

Most AI products may look different, but under the hood they do a very similar job: they generate tokens, or small pieces of text, one after another. A chatbot reply, a coding suggestion, and a search summary all depend on this same basic process. In recent years, the industry has started to focus less on training models and more on inference, which is the act of running a trained model to answer a real request. That shift matters because inference is no longer a side issue. It is becoming the main cost of serving AI at scale.

To understand why, it helps to follow one prompt through a data center. The request usually enters through a gateway, which checks access, routes traffic, and sends the prompt to the right service. From there, a scheduler decides where the work should go based on available hardware and current demand. This may sound routine, but these early steps can shape latency, reliability, and cost. If traffic spikes, the system has to keep its footing and continue to deliver answers without major delays.

Next comes the model’s internal work, which is often split into two phases: prefill and decode. In prefill, the model reads the full prompt and builds the first internal state it needs to answer. This phase is mostly limited by raw compute power, so it strongly affects time to first token, or how quickly the user sees the first word. Decode is different. After the first token appears, the model generates the next token, then the next, step by step. This stage is often held back not by pure calculation but by memory bandwidth, because the system must repeatedly fetch model information fast enough to keep output flowing.

A key part of this process is the KV cache, which stores useful context from earlier tokens so the model does not have to recalculate everything from scratch. That saves time, but it also creates new trade-offs. The cache uses memory, and memory is expensive and limited. In large systems, moving data between chips can become a bottleneck. This is why the physical side of AI infrastructure matters so much. High-speed interconnects, networking, optics, power delivery, and cooling are not just background details; they can decide whether a service runs smoothly or hits a wall.

The economic picture is just as important as the technical one. Training a model is a major capital event, but inference is a recurring operating cost because it happens on every user query. As token volumes rise, even tiny improvements in cost per token can move the needle. At the same time, buying inference is rarely a simple race to the bottom on price. Companies also weigh latency, reliability, security, deployment choices, and model coverage. A cheaper service may look attractive on paper, but it can be a double-edged sword if performance is unstable or if it is hard to move workloads later.

This is why many people now argue that the token, not the model, is the real unit of economic output in AI. Following one token through a data center opens the black box and shows where time and money are actually spent. It also helps engineers ask better questions: Which step is compute-bound? Which step is memory-bound? Where do network delays pile up? As AI adoption gathers pace, these details will not stay in the weeds for long. They will shape product design, infrastructure spending, and the competitive edge of companies building AI services.

Data centers in Ireland now use 23 percent of the country’s metered electricity, according to new figures from the Central Statistics Office. That share rose in 2025 after already passing 20 percent in 2023. The increase is striking because Ireland is a small country with a population of just over five million, yet it hosts a large number of facilities that run digital services for businesses and consumers. In simple terms, these sites are buildings full of computing equipment that need constant power, cooling, and network connections. As online services grow, their electricity demand keeps rising as well.

The latest data shows that electricity use by data centers increased by 10 percent in 2025. Over the same period, all other customers together used only 2 percent more power. Data centers also used more electricity than urban households, which accounted for 18 percent of metered use, and far more than rural households at 9 percent. This did not happen overnight. In 2015, data centers represented only 5 percent of electricity use. By 2021, the figure had climbed to 14 percent, and by 2025 it had reached almost a quarter. That steady rise suggests a long-term trend rather than a short-term spike.

What makes this story more notable is that most new grid connections for data centers around Dublin had been heavily restricted for much of 2025. Regulators had kept an effective moratorium in place because so much of the country’s data-center activity is concentrated near the capital. Even with those limits, electricity use still went up. That tells us two things. First, existing sites may be expanding their operations or running equipment more intensively. Second, restrictions on new connections do not immediately solve the broader issue if demand keeps climbing inside facilities that are already online.

Ireland has now started to tighten the rules. Under newer regulations, operators that want a grid connection above 10 megawatts must provide generators or battery systems that can match that level of power. They may also be required to feed electricity back into the national grid when needed. This approach tries to ease pressure on the system by making large users support grid stability instead of only drawing power from it. In practice, this means data-center projects may need to include more on-site energy infrastructure, which could raise costs but also improve resilience during periods of stress.

The debate is not only about engineering. It is also about trade-offs. Data centers can bring jobs, tax revenue, and strategic digital infrastructure. They support everything from business applications to streaming, communications, and AI systems. At the same time, local communities may worry that these facilities crowd out other electricity needs or put upward pressure on energy bills. In some places, people are also concerned about water use and the wider environmental footprint. As a result, public opposition has begun to gain traction in Ireland and in other countries facing similar growth.

For the tech industry, Ireland’s situation is a warning sign that digital growth is running into physical limits. Computing may feel invisible to end users, but at scale it depends on land, power lines, backup systems, and cooling equipment. Governments therefore have to strike a balance between attracting investment and protecting national infrastructure. Operators, meanwhile, face pressure to improve efficiency, shift workloads more intelligently, and show that they can be better grid citizens. The next few years will reveal whether stricter rules, backup power requirements, and smarter planning can curb demand growth without slowing the digital economy too sharply.

Postgres 19 is bringing a new feature called property graphs. The idea is not to replace the relational model, but to offer another way to look at the same schema. In a normal relational design, rows represent things or events, and foreign keys connect them. That already forms a graph in a practical sense. For example, a race result can point to a driver, a race, and a constructor. Property graphs give developers a direct way to describe those connections and ask graph-style questions without writing every join by hand.

This matters because many teams already store highly connected information in relational systems. They may have customers linked to orders, devices linked to events, or users linked to permissions. In the past, if they wanted graph analysis, they often had to export the tables into Python tools or move the data into a separate graph system. That extra step can be a stumbling block. It adds more moving parts, creates another copy of the information, and makes the workflow harder to keep in sync. Postgres 19 tries to close that gap by letting graph thinking happen closer to where the tables already live.

In Postgres, a property graph is a named object created over existing tables. It is best understood as an overlay, not a new physical store. Developers declare which tables should act as vertices, which means nodes, and which should act as edges, which means connections. They also choose keys, labels, and properties. Keys identify each row, labels describe what kind of node or edge it is, and properties are the columns that can be queried in graph patterns. The key point is that no data is moved. The rows stay where they are, and the graph definition sits on top of them.

The query side is also important. With SQL/PGQ, developers can use graph pattern matching through the MATCH predicate. In simple terms, that means they can describe a path through connected records instead of spelling out each join condition one by one. This does not mean SQL joins disappear overnight. Under the hood, the graph query still connects relational tables. But the graph syntax can be easier to read when the question is naturally about relationships, paths, or neighborhoods. It can also make an existing schema feel more intuitive for teams that already think in terms of entities and links.

One especially interesting detail from early exploration is that a single table can pull double duty. In other words, the same table can be treated as both a vertex and an edge at the same time. That may sound unusual at first, but it fits many real schemas. A fact table can represent an event as its own record, while also connecting other entities through foreign keys. In the Formula 1 example discussed in the source article, a results table can be a node with its own properties, but it can also define edges to driver and race records. That flexibility may prove handy for complex models.

Still, there are trade-offs to watch. Property graphs do not magically turn a relational system into a specialized graph engine, and teams will need to learn when the new syntax is worth using. For some tasks, classic joins may remain clearer or faster. There is also a broader question of adoption: whether developers will embrace graph queries inside a relational environment, or continue to rely on external tools for advanced graph workloads. Even so, the feature is noteworthy because it broadens what Postgres can express. For engineers, the big takeaway is that the line between relational and graph thinking is becoming less rigid.

Papermake is an open-source tool for teams that need to create PDFs from templates and structured input. It is built around Typst, a modern markup-based typesetting system for documents. The main idea is simple: instead of installing Typst on every machine, a team can publish a template once and render PDFs through HTTP requests. In that sense, Papermake treats document templates more like deployable assets than one-off files. For companies that produce invoices, reports, certificates, or internal forms, that approach could streamline a task that often becomes messy over time.

According to the project description, Papermake works as a content-addressable template registry with server-side rendering. In plain English, that means templates are stored and identified by a cryptographic hash, so the system can tell exactly which version was used. The project compares this model to a container registry, but for document templates. A template can be published with a fixed version that never changes, while a moving tag such as latest can point to the newest release. This gives teams a clearer paper trail when documents must be reproduced later for business or legal reasons.

The workflow is fairly straightforward. A user uploads a main Typst file, and can also attach other files such as images, fonts, or imported components. There is also support for an optional JSON schema, which can define the expected shape of the input. After a template is published, another request sends the input values needed for rendering. The service then returns a render ID, a hash for the resulting PDF, and timing information. The final PDF can be downloaded through another endpoint. For quick testing, the project also offers a simpler route where the template can be sent inline as JSON.

One reason the project may gain traction is operational simplicity. The quick-start setup uses a Rust-based application together with S3-compatible storage and ClickHouse for render history. The repository says it can be self-hosted with one Rust binary plus those supporting services. That could appeal to teams that want full control over their document pipeline, especially when PDFs contain sensitive customer or financial information. It also reduces local setup friction, because developers or other systems can call the service over HTTP instead of worrying about local rendering tools on every environment.

At the same time, this design comes with trade-offs. Centralized rendering can improve consistency, but it can also become a bottleneck if many systems depend on one service. Self-hosting gives control, yet it means the team must handle operations, storage, reliability, and security on its own. Auditability is another strong selling point, but it can be a double-edged sword if logs contain sensitive material and retention rules are unclear. In other words, the architecture is attractive, but teams still need governance around access control, secrets, and how long render records should be kept.

More broadly, Papermake reflects a wider shift in developer tooling: documents are increasingly treated as code and as part of a reproducible pipeline. That mindset fits well with modern engineering practices such as versioning, traceability, and automated delivery. The project is still a specialized tool, but it highlights a real need in many organizations. PDFs may sound old-fashioned, yet they remain deeply embedded in finance, compliance, and business workflows. If tools like Papermake mature, they could carve out a useful place between document design, backend automation, and infrastructure management.

Git has been the standard tool for version control for many years, but it mostly shows changes line by line. A newer open-source tool called sem is trying to add another layer on top of Git. Instead of focusing on line numbers, sem tracks changes at the level of code entities such as functions, methods, and classes. The project describes this idea as semantic version control. In simple terms, it tries to show what changed in the structure of a program, not only where text was added or removed.

According to its GitHub page, sem parses code with tree-sitter, a parser system used to understand source code structure. It can work across 28 languages, which is a notable point for teams with mixed codebases. The tool can run in any Git repository with no setup, and it supports common installation paths such as a shell script, Homebrew, winget, npm, Docker, and building from source with Rust. That broad availability may help it gain traction among developers who want to try it without changing their current workflow too much.

The main pitch is easy to understand. In normal Git output, a developer may see that lines 120 to 145 were edited, but that does not always explain the real impact. A line-based diff can leave people in the weeds, especially in large refactors or files with heavy formatting changes. Sem tries to cut through that noise by saying something clearer, such as a specific function was modified or a class method was removed. The repository also highlights features like entity-level diffs, blame, and impact analysis, which suggests that the tool aims to answer not just what changed, but what else may be affected.

This approach could be especially useful for coding agents and automated development tools, which the project openly targets. Machines often need structured information to reason about a codebase. If a tool can spell out which function changed and what depends on it, an agent may be better able to review updates, plan edits, or avoid touching unrelated parts of the system. Human developers may also benefit. During code review, semantic information could make discussions faster and reduce guesswork when a pull request includes many files or mechanically generated edits.

Still, semantic version control is not a silver bullet. Parsing source code across many languages is hard, and developers will want to know how reliable the results are in edge cases. Some teams may also wonder whether another layer of tooling is worth the extra complexity, especially if plain Git already fits their needs. The project says that cloud-backed queries are opt-in per repository and that logging in does not automatically upload a repository or send a query. That consent model will matter because privacy and code ownership are sensitive issues for many engineering teams.

Even so, sem points to a broader shift in developer tools. As codebases grow and AI coding systems become more common, line-based history may start to feel too narrow for some tasks. Tools that understand code as functions, classes, and relationships could become more valuable over time. Sem is part of a wider stack from Ataraxy Labs, and its progress will be worth watching. If it delivers useful semantic diffs without getting in the way, it could carve out a niche beside Git rather than trying to replace it.

A new benchmark suggests that Apple’s latest on-device speech system has moved ahead of both its older recognizer and several Whisper models for English transcription. In tests reported by Inscribe, Apple’s new SpeechAnalyzer produced the lowest word error rate, or WER, among the engines they measured. WER shows how many words a system gets wrong by replacing, missing, or inventing words. Lower scores are better. On both clean and noisy LibriSpeech test sets, SpeechAnalyzer performed better than Whisper Tiny, Base, and Small, and it also ran faster than Whisper Small on the same Apple hardware.

The comparison matters because Apple recently replaced the older SFSpeechRecognizer with SpeechAnalyzer and SpeechTranscriber in iOS 26 and macOS 26. Before this benchmark, developers had little hard evidence about accuracy, so many teams were still guessing when deciding whether to migrate. Inscribe had a useful setup for testing because it already ships Apple’s speech engines and multiple Whisper models in the same product. That allowed the company to run all of them through identical code paths, on the same machine, using the same audio. In benchmarking, that kind of apples-to-apples comparison is important because small differences in setup can skew the result.

The clearest result was how far the legacy Apple recognizer lagged behind. According to the benchmark, SFSpeechRecognizer came last on clean speech, even behind Whisper Tiny, which is a much smaller model. By contrast, SpeechAnalyzer cut the error rate by roughly three-and-a-half to four times compared with the old API on the same audio. The report also noted that the new engine returns punctuated, properly cased text, while the older output is rougher. For long recordings such as meetings, that gap can add up quickly. If a team still uses the legacy recognizer for anything beyond short voice commands, the case for migration now looks strong.

The more surprising finding was that Apple’s new engine also came out ahead of Whisper Small, the largest Whisper model Inscribe ships, while using about one-third of the compute time per second of audio. In practical terms, all of the tested engines were faster than real time on an Apple M2 Pro, but SpeechAnalyzer still stood out. This shifts the picture for developers who had treated Whisper as the automatic best choice for on-device English transcription. On current Apple devices, that assumption may no longer hold. If accuracy and speed are your main goals, the built-in engine now appears hard to beat for supported languages.

Still, the result comes with trade-offs. Whisper keeps two major advantages: it supports many more languages, and it is not tied to one platform. Apple’s SpeechTranscriber reportedly supports around 30 locales, which is useful but narrower than Whisper’s broader language coverage. Platform lock-in can also be a double-edged sword. A built-in engine may offer strong performance and tight integration, but teams that need one code base across mobile, desktop, and non-Apple systems may still prefer a portable option. In other words, the benchmark does not settle every debate; it mainly changes the default answer for English on recent Apple hardware.

For product teams, the lesson is straightforward: benchmark first, then decide your defaults based on evidence rather than reputation. Inscribe said it already changed its own product so that its automatic engine now prefers SpeechAnalyzer for languages Apple supports, and Whisper for everything else. That decision reflects a broader trend in engineering. As vendors roll out new local AI features, older assumptions can become outdated very quickly. Developers should keep an eye on accuracy, speed, language support, output quality, and operating system requirements. In speech technology, the ground is shifting fast, and the best choice may depend less on hype and more on the exact users and devices you need to serve.

A new argument is spreading through the tech industry: in the age of AI agents, traditional SaaS may no longer be the main source of value. For many years, the usual plan was clear. A company built one strong feature, turned it into a product, then expanded into a bigger suite and finally into a platform. That model worked because building reliable business tools took a long time, and time itself acted like protection from rivals. Now, with generative AI lowering the cost of building new products, that old logic is under pressure.

The source article describes this shift as a ninety-degree rotation in competition. In the past, companies competed mostly on what they could build. Today, the harder question is what they actually own that others cannot easily copy. If a small team can rebuild a headline feature in a weekend, the feature may no longer be a moat. It becomes closer to a commodity. In that world, value moves away from the visible interface and toward assets that are harder to reproduce, such as trusted customer relationships, unique workflows, proprietary feedback loops, strong distribution, or control of the business outcome itself.

This idea helps explain why fast product growth does not always calm investors. The article points to the strange market reaction around AI products: even when a company launches a rapidly growing AI offering, the market may still worry that the underlying business is becoming easier to copy. At the same time, new tools are letting more non-technical people build products and even earn revenue from them. That lowers the gatekeeping power of traditional builders. In simple terms, more people can ship something useful, so the number of competitors rises sharply and product-surface advantages may have a very short half-life.

If building becomes cheap, then the next battleground is not just the app but the outcome. That is why many people are now talking about outcome pricing. Instead of charging only for seats or subscriptions, vendors may charge based on the result an AI system delivers, such as qualified leads, resolved support cases, or completed tasks. This sounds attractive, but it is also risky. A vendor that promises outcomes is taking on a kind of underwriting role. It must understand the customer’s operations, predict performance, and absorb some uncertainty. In return, it may capture more value if the system works well at scale.

Another major issue is distribution, or how products reach users. Product-led growth, often called PLG, was powerful in the last SaaS era because users could try a tool cheaply and spread it inside a company. But AI agents may invert that pattern. If agents complete work across many systems, users may care less about which interface they open and more about which service reliably gets the job done. That could strengthen companies with direct access to workflows, channels, or decision-makers. It could also favor firms that are deeply embedded in customer operations, even if their product looks less polished on the surface.

Still, this new playbook is not settled. AI lowers barriers, but it also creates noise, weak products, and copycat features. Some buyers will continue to prefer stable vendors, clear security controls, and predictable pricing. Others will experiment with smaller tools that move faster. The key question is where durable advantage will come from when coding is no longer the main bottleneck. For business and engineering teams, the message is clear: do not focus only on shipping features. Watch the assets behind the product, the economics of outcome-based models, and the channels through which customers discover and trust AI systems.

A recent essay by software thinker Kent Beck argues that junior engineers should understand one key point early: they were not hired simply to complete a list of tasks. In many teams, a new hire may think success means closing as many tickets as possible. Beck says that view is too narrow. Senior engineers and managers are not only watching output today. They are also trying to judge what kind of engineer a new person may become in the future. From that perspective, speed matters, but it is not the whole story.

The essay describes the hiring of junior engineers as an investment in future capacity. A senior engineer could often finish small tasks faster and with less trouble than a beginner. If short-term productivity were the only goal, hiring less experienced people would not make much sense. Instead, companies accept slower progress now because they hope to build a stronger next generation later. In Beck’s framing, a salary is like an option premium paid on future potential. The real question is whether the new engineer is learning fast enough to justify that investment.

This idea leads to a more interesting way to evaluate performance. Imagine one new engineer finishes 40 tasks in a quarter, while another finishes 20. Which person is better? Beck’s answer is simple: there is not enough information. Even if the tasks look similar, raw numbers can be misleading. A newcomer can rush through work and still leave behind confusion, bugs, or extra effort for teammates. Another person may complete fewer tasks but communicate clearly, ask smart questions, and produce reliable code. For a team, those signals can matter more than a high task count.

According to the essay, the first sorting step is not whether someone is brilliant. It is whether they look like a solid performer or someone who may not last. Several behaviors stand out. The code should work. The engineer should keep others in the loop about what they are doing. The work should finish in a reasonable time, even if the first estimate is not perfect. Just as important, the engineer should not create a ripple effect of extra work for reviewers, on-call staff, or operations teams. A task is not really done if other people must clean up the mess afterward.

One of the strongest points in the essay is about trust. Trying to game the system by claiming progress that is not real is presented as an immediate warning sign. In technical work, trust is hard-won and easy to lose. New engineers will make mistakes, and senior engineers expect that. Beck’s advice is not to avoid every weak signal, because that is impossible. Instead, the goal is to learn quickly and never repeat the same bad pattern. In other words, a mistake can be a setback, but repeated carelessness can become a verdict on someone’s judgment.

The message matters beyond junior staff. It raises a broader question about engineering culture: what do teams truly reward? If organizations focus only on visible output, they may encourage shortcuts and shallow learning. If they also reward communication, sound judgment, and reduced burden on others, they are more likely to develop strong engineers over time. For people entering tech, the lesson is clear. Do the task, but also show how you think, how you collaborate, and how you improve. Those qualities are often the real signals that separate a temporary contributor from a future leader.

As AI agents write more code, some engineers are asking a basic question: do humans still need to understand the systems those agents build? A recent talk by product engineer and writer Geoffrey Litt argues that the answer is yes. His main point is simple but provocative: understanding is becoming the new bottleneck. In other words, the problem is no longer only how fast code can be produced. The harder part may be how quickly a person can build a clear mental model of what the system does, why it works, and how to improve it.

This idea matters because modern AI tools can already complete many coding tasks with little supervision. They can generate features, run tests, and sometimes even check whether the output matches a specification, which is a detailed description of what a system should do. That progress leads some people to think humans can step out of the loop. But Litt pushes back on that view. He says understanding is not just for verification, meaning checking whether the answer is right or wrong. It is also needed so people can participate in the next round of decisions and design choices.

That distinction is at the heart of the argument. If a project were just one cycle, then verification might be enough. But real engineering work is rarely a one-off task. It is an ongoing process with many loops: new ideas, bug fixes, changing goals, and trade-offs between speed and quality. To steer that process well, a developer needs fluency with the system. Without that fluency, it is hard to ask better questions, suggest a new direction, or notice hidden risks. This is where the idea lines up with “cognitive debt,” a term used to describe the future cost of not really understanding a system today.

So how can teams keep up when agents produce more code than people can read line by line? Litt suggests borrowing ideas from education. One technique is to ask for explanations, not just raw diffs. A diff shows exactly what changed, but it may leave readers in the weeds when they need a broader picture. A better explanation might describe the purpose of the change, the key concepts behind it, and the trade-offs that shaped it. In that sense, every completed task can become an artifact that teaches the human partner, not just a patch that gets merged.

He also points to quizzes and small “micro-worlds” as useful learning tools. A quiz can reveal whether you truly grasp the design or only think you do. A micro-world is a tiny, interactive version of a system that lets you play with its rules and behavior. This can lower the barrier to understanding because people learn faster when they can test ideas directly. Instead of passively reading long explanations, they can poke at the system, observe what happens, and build intuition. For fast-moving AI projects, that hands-on approach may be more realistic than trying to inspect every detail.

There are trade-offs, of course. Producing good explanations takes time, and some teams may feel pressure to move fast and ship first. Others may argue that as agents improve, human understanding will matter less. Still, Litt’s view is gaining traction because engineering is not only about producing correct code. It is also about shaping the next step. If engineers lose their grasp of the systems around them, they may become weaker collaborators even when the tools are strong. For teams using AI heavily, the key question may not be whether understanding still matters, but how to keep it from falling behind.