📰 English IT Daily · 2026-07-29

A GitHub project called esp32-ai is getting attention for an unusual result: running a 28.9 million parameter language model on an ESP32-S3 microcontroller that costs about $8. The model runs directly on the device, with no network connection and no requests sent to a remote computer. It can generate text at around 9 tokens per second and show the output on a small screen connected to the chip. On paper, that sounds almost impossible, because microcontrollers are designed for very limited tasks and have far less fast memory than phones, laptops, or graphics processors.

The hardware limits are what make this project stand out. According to the repository, the ESP32-S3 has 512KB of SRAM, 8MB of PSRAM, and 16MB of flash storage. In ordinary situations, those numbers would force engineers to use a very small model. The previous language model reported on a similar class of chip had only about 260,000 parameters. By comparison, 28.9 million parameters is roughly one hundred times larger. The project therefore does not break through because the chip suddenly became powerful. Instead, it finds a clever way to work around the memory bottleneck.

The key idea is that most of the model does not stay in fast memory. A large share of the parameters sits in an embedding table, which the model reads from instead of actively computing all the time. The project stores about 25 million of those parameters in flash, which is much larger but also slower than SRAM. Then, for each token, the system pulls in only the few rows it needs. The repository says this is based on Per-Layer Embeddings, an approach used in Google's Gemma models. In simple terms, the design keeps the small 'thinking' core in fast memory, puts working memory and the output head in PSRAM, and leaves the huge lookup table in flash.

This setup is a trade-off, not magic. The model fits on the device because it avoids loading most of the parameters at once. That means the large table in flash can sit quietly in the background and be sampled a little at a time. The model is also quantized to 4-bit, which shrinks the size to about 14.9MB. However, no one should mistake this for a powerful general assistant. The repository is clear that the model was trained on TinyStories, so it mainly writes short and simple stories. It does not answer questions well, follow instructions, write code, or provide reliable factual knowledge. The memory trick changes where the model lives, but it does not remove the limits of a small reasoning core.

Even with those limits, the project could have a ripple effect across edge AI. Many discussions about local AI focus on phones, laptops, or specialized chips, but microcontrollers are everywhere: sensors, household devices, wearables, and industrial equipment. A design like this raises the possibility of privacy-friendly text generation on devices that are cheap, small, and often offline. It also shifts the conversation from raw model size to system architecture. In other words, the headline is not only that a tiny chip can run a larger model than expected, but also that careful memory design can punch above its weight.

There are still reasons to keep expectations in check. Speed, quality, and flexibility remain limited compared with even modest models on stronger hardware. Engineers would also need to think hard about debugging, updates, and how far such methods can scale before latency or complexity becomes a serious problem. Still, projects like this are useful because they test assumptions. They show that edge devices may not need to follow the same path as cloud systems or GPUs. For developers, the real lesson may be simple: when memory is the main constraint, smart placement of components can matter just as much as model size.

PGSimCity is an unusual educational project that turns the inner workings of PostgreSQL into an explorable 3D city. Instead of reading only diagrams or technical documents, visitors can move through a visual world that represents parts of the database engine. The project describes itself as independent and non-commercial, and it is careful to say that it is not connected to the makers of the SimCity game. Its goal is simple: to give learners a more concrete way to understand how a complex system behaves under the hood.

For many engineers, PostgreSQL is a familiar tool, but its internals can be hard to grasp. People may know how to write queries, create indexes, or tune performance, yet still feel lost when the conversation shifts to storage, memory, or execution details. PGSimCity tries to bridge that gap. By mapping technical components to places and activity in a city, it offers a mental model that may be easier to remember than a static chart. This approach can lower the barrier to entry for learners who want to go beyond day-to-day operations.

The project is still an early prototype, and that point is front and center in its own description. The creator warns that the model and explanations are unreviewed and may contain inaccuracies. In other words, users should treat it as a learning aid, not as the final word on PostgreSQL behavior. That honesty matters. Visualizations can spark curiosity, but they can also oversimplify. In technical education, that is a double-edged sword: a clear picture can open the door, yet it may also leave out messy but important details.

Even so, the idea has clear appeal. Complex systems often remain abstract until people can attach them to something familiar. A city is a useful metaphor because it suggests movement, traffic, coordination, and bottlenecks. Those ideas fit many computing problems. If a learner can see processes as neighborhoods or operations as roads and flows, it may become easier to connect cause and effect. That can be especially valuable when someone is troubleshooting performance issues and needs to reason step by step rather than get stuck in the weeds.

Projects like this also reflect a wider trend in tech education. Engineers increasingly look for interactive tools that let them explore systems instead of only reading about them. Textbooks and official documentation are still essential, but visual and hands-on resources are gaining traction because they support different learning styles. For teams, that can pay off when junior engineers need to ramp up quickly or when cross-functional staff need a shared picture of how a system behaves. A strong mental model often leads to better questions, clearer communication, and more careful debugging.

At the same time, users should keep their expectations grounded. PGSimCity needs JavaScript and WebGL2 to run, so it depends on modern browser graphics features. More importantly, its educational value will depend on how accurately it evolves and whether the community weighs in with feedback, issues, or pull requests. If the project matures, it could become a handy entry point for people who want to understand PostgreSQL more deeply. Even in its current form, it highlights an idea worth watching: technical learning does not always have to come from dense manuals. Sometimes, seeing a system come alive can make a difficult subject click.

Most companies use large language models through hosted services from outside providers. Netflix has taken a different path. According to its engineering blog, the company runs the full serving stack itself inside its normal production environment. In other words, LLMs are not treated as a separate machine learning island. They are part of the same system that already supports many member-facing experiences. This matters because a serving platform is not only about raw model speed. It must also fit real business traffic, testing, logging, reliability needs, and the many small decisions that appear only when a system is under pressure.

Netflix says its member-scale machine learning setup already has a unified serving system based on the JVM. That system manages the full flow for downstream teams, including routing requests, running A/B tests, fetching features, doing inference, post-processing outputs, and logging what happens at each step. It supports both real-time requests and cached batch paths. Today, callers can reach LLM inference in two ways: through a gRPC path inside the existing serving layer, or through a direct HTTP path that newer LLM applications use. This design shows a practical goal: keep one broad platform for many workloads, while still leaving room for newer product teams that need a simpler entry point.

Where inference runs depends on model size. Smaller CPU models can run in-process, which cuts out the overhead of a remote call. Larger models need GPUs, so the main serving system keeps pre-processing and post-processing nearby but hands off the actual inference work to a remote backend called the Model Scoring Service. This shared backend already supports several model types through one interface, while NVIDIA Triton handles loading models, batching requests, and scheduling GPU work. On top of that sits a Java control plane that manages deployment, versioning, health checks, autoscaling, and multi-region rollout. The result is a layered system designed to work at scale without forcing every model team to rebuild the same operational pieces.

A key design choice was the inference engine. Netflix says it first built the platform on TensorRT-LLM, which was a strong option and already connected to Triton. Later, the team revisited the decision because the landscape had shifted. Open-source engines had narrowed the performance gap, and the workload mix had become more varied. The company was no longer focused only on one style of text generation. It also needed embedding generation, prefill-only inference for ranking and retrieval, autoregressive decoding, and support for custom models with special step-by-step rules. After benchmarking this broader mix, Netflix chose vLLM as its paved-path engine, mainly because it fit operations better and allowed faster iteration without a complicated compilation pipeline.

That decision highlights a trade-off that many engineering teams face. The fastest tool in a narrow benchmark is not always the best tool in production. A more flexible engine can be a better fit when teams need to roll out model changes quickly, support custom architectures, and avoid operational friction. Netflix also points to other important design areas, such as model packaging, API surface design, deployment strategy, and output constraints enforcement. Those choices may sound less exciting than model quality, but they often determine whether a platform is dependable in day-to-day use. Production traffic has a way of exposing weak points that are easy to miss during the design phase.

The broader lesson is that in-house LLM serving is not simply a technical flex. It is a decision about control, consistency, and long-term platform strategy. Running the full stack can reduce dependence on outside vendors and make it easier to align LLMs with existing observability, rollout, and reliability practices. At the same time, it raises the bar for internal platform teams, because they must manage GPUs, engine updates, safety constraints, and zero-downtime upgrades. For other companies, Netflix’s approach may not be a one-size-fits-all answer. But its experience is useful because it shows how real production needs can reshape architecture decisions, especially when LLMs move from experiments to core services.

A new report argues that a fine-tuned 9B open-source model can outperform frontier models on a real business task while costing far less. The task was catalog review, which means checking product listings for quality and correctness. In the reported workflow, the open model used the same tools, images, and scoring method as the frontier systems. Even so, it achieved better results at about $0.50 per 1,000 listings. According to the report, that made it many times cheaper than the frontier options they tested.

The claim matters because many companies still struggle to turn AI excitement into clear business value. Since the public launch of modern chatbots, firms have tested AI for low-risk work such as summaries, emails, and first drafts. Later, many moved toward higher-value tasks like coding, content production, and systems linked to internal knowledge. But strong results have not always appeared at scale. Some companies have gained traction and seen large productivity or revenue gains, while others still lag behind despite heavy spending.

One reason is that strong AI results often depend on redesigning the workflow, not just dropping a model into an old process. If a company keeps the same approval steps, the same handoffs, and the same bottlenecks, the speed gains may never reach the bottom line. The source context points to research suggesting that workflow redesign has a strong link to business impact, yet only a minority of organizations have done it. In other words, the model matters, but the process around the model can matter just as much.

The report also supports a broader idea: intelligence ownership. This means a company may get more value from a model that it trains for its own task than from renting a general-purpose frontier model for every request. In this case, the team used GRPO fine-tuning, a training method that teaches the model to perform better on a target workflow. The lesson is not that frontier models are weak. Rather, it is that a smaller open model can punch above its weight when the task is narrow, the tools are fixed, and the scoring system is clear.

Still, this approach is not a silver bullet. Task-trained models can be excellent in a defined setting, but they may be less flexible when the task changes. They also require careful evaluation, secure access controls, and engineering work to connect the model to the right business context. Prompting and retrieval can add context at call time, but building those systems is not trivial. Teams also need incentives to experiment, because models, tools, and best practices shift quickly and last quarter's setup may soon be outdated.

For business and engineering leaders, the main takeaway is practical. Instead of assuming the newest and largest model is always the best choice, they should compare quality, cost, and fit for a specific workflow. A cheaper open model may win if it is trained well and measured fairly. Frontier models may still be the safer choice for broad reasoning or rapidly changing tasks. The next stage of AI adoption will likely depend less on headline model size and more on disciplined testing, workflow redesign, and knowing where a custom system can deliver an edge.

For many years, user experience design mostly meant designing screens. Teams focused on buttons, menus, forms, and page flows. That approach still matters, but it no longer explains everything users do with digital products. A recent UX article argues that the interface is “leaving the building.” In other words, people now interact with products through chat, voice, and AI agents that can act in the background. The screen has not disappeared, but it is no longer the only or even the main place where the experience happens.

One big shift is the rise of chat-based interfaces. Since generative AI became mainstream, many products have added a text box where users can type requests in natural language. This feels simple, but good chat design is not as easy as it looks. A conversation works best when user intent is unclear or still taking shape. If someone is exploring options, comparing ideas, or asking for guidance, chat can meet them halfway. But when a task is direct and predictable, such as filtering results or confirming a purchase, a structured interface is often faster and less tiring.

This is why many experts now support hybrid design. Instead of going all in on chat, products can combine conversation with visual controls. A user might begin by asking an open question, then narrow the result with buttons, cards, or filters. This kind of design reduces friction because it uses each interaction style for what it does best. Chat can handle ambiguity, while traditional interface elements can speed up routine actions. In practice, the best systems often switch between these modes rather than treating one as the answer to everything.

Voice is another interaction model that is gaining traction, especially as speech recognition becomes more accurate. Voice can feel natural when people are driving, cooking, walking, or doing other hands-free activities. It can also improve accessibility for users who cannot easily use a keyboard or screen. At the same time, voice comes with trade-offs. Spoken commands disappear quickly, so users may forget options or miss details. Privacy is also a concern, since speaking to a device in public or at work is not always comfortable. Designers therefore need clear feedback, confirmation steps, and ways to recover from mistakes.

The biggest change may come from agentic AI, which means systems that do more than answer questions. These tools can interpret goals, carry out steps, and sometimes complete tasks with limited user input. That sounds powerful, but it is a double-edged sword. When an AI agent acts on behalf of a person, the design challenge shifts from simple control to trust, oversight, and accountability. Users need to know what the system is doing, why it is doing it, and how to step in if something goes wrong. Without that clarity, convenience can quickly turn into confusion.

All of this suggests that UX is being rewritten at a deeper level. Designers are no longer only arranging pixels on a page; they are shaping conversations, decision paths, and systems that may act before a user even opens an app. For product teams, the key question is not whether screens are dead. They are not. The real question is which interface fits which moment. The next generation of products will likely stand or fall on how well they balance speed, clarity, trust, and user control across chat, voice, and AI-driven actions.

A new guide from workflow startup Hatchet looks at a problem many young tech companies face: how to stop Postgres from falling over as traffic grows. The article is based on hard lessons from running Postgres in production over the past two years. Its author says the official manual is excellent, but it can be difficult to use when a team is under pressure and needs practical advice fast. The guide is written for engineers who already know basic SQL, tables, rows, and indexes, but who want a clearer survival guide for real-world operations.

One major theme is schema design. The guide argues that schemas are among the hardest parts of a system to change after launch, so teams should think carefully before they lock in their choices. At the same time, the advice is not overly academic. Traditional database normalization can improve structure, but the guide notes that it may sometimes clash with query efficiency and speed of development. For startups moving quickly, this can become a trade-off. In some cases, a flexible jsonb column may be more practical than a perfect model, although that choice can also create problems later if it is overused.

The guide also focuses on read performance. Many engineers learn a simple rule early on: if a query is slow, add an index. But the article shows that real systems are more nuanced than that. Teams need to understand which filters are common, how joins behave, and how compound indexes work. It also highlights the importance of aligning ORDER BY clauses with indexes so the database can avoid extra work. These details may sound small, but at scale they can decide whether a system feels fast and reliable or begins to struggle under load.

Write performance gets equal attention. Startups often worry first about reads because slow pages are easy to notice, but writes can quietly become a bottleneck. Frequent updates, bulk inserts, and schema migrations all put pressure on Postgres in different ways. The guide suggests that engineers should think ahead about which columns will be updated most often and how those patterns affect storage and maintenance. It also points out that migration work is not just a development task. In production, even a routine change can ripple through the system if it locks tables, increases load, or runs longer than expected.

Beyond the basics, the guide dives into internals that many application developers only encounter when things go wrong. A key example is the query planner, which decides how Postgres will execute a query. This layer can feel like a leaky abstraction because a query that looks reasonable in SQL may perform very differently in practice. The guide also discusses autovacuum, a background cleanup process that removes old row versions. Its warning is clear: default settings can be a double-edged sword. They are convenient at first, but on busy systems they may lag behind and allow bloat to build up, which can hurt performance.

The final sections touch on more advanced techniques such as FOR UPDATE SKIP LOCKED, partitioning, and strategies for large-table migrations. These are not everyday tools for every startup, but they become relevant once a team is in the weeds with growth, queue processing, or very large tables. Another useful point is about ORMs. The guide does not reject them, but it says some optimizations are hard to reach unless engineers break past the abstraction layer and write SQL directly. Overall, the message is simple: Postgres is powerful, but it will not take care of itself. Startups need habits, monitoring, and a deeper understanding of trade-offs if they want their systems to stay healthy as they grow.

A recent design article argues that small user interface, or UI, choices can have a surprisingly large effect on how people feel when they use an app. The main idea is simple: good UI design is not only about artistic talent or personal taste. It is often based on clear rules that guide decisions about layout, spacing, typography, and color. This matters because many digital products still frustrate users, not because the features are weak, but because the screens feel messy, confusing, or tiring to read. In other words, small visual problems can quietly chip away at usability.

The article presents a case study of a property details page in a short-term rental app. One version looks cluttered and harder to use, while another version improves the same content with a series of practical fixes. The advice does not depend on fancy effects. Instead, it focuses on logic-driven choices, such as grouping related elements with space, keeping styles consistent, and making sure similar-looking elements behave in similar ways. These principles sound basic, but they often separate a polished product from one that feels rough around the edges.

One major lesson is that space is not empty; it is a tool. When related items sit close together, users can scan them faster and understand their relationship more easily. Designers can also use containers, alignment, and visual similarity to create groups, but too many boxes or decorative lines may add clutter. The article also stresses visual hierarchy, which means showing users what to notice first, second, and third. Clear headings, restrained font choices, and simpler styling can prevent people from getting lost in the weeds when they are trying to complete a task quickly.

Accessibility is another key theme. The article highlights contrast ratios for interface elements and text, noting that buttons, labels, and body text must remain easy to see. It also warns designers not to rely on color alone as a signal, because some users may not notice the difference. Typography choices matter as well. A single sans serif typeface, limited uppercase text, regular and bold weights, left-aligned copy, and enough line height can all improve readability. These suggestions may sound modest, but together they can move the needle in a meaningful way.

For product teams, this kind of guidance is valuable because it turns design from a vague art into a repeatable system. Engineers, designers, and product managers often work under time pressure, and a logical set of UI rules can speed up reviews and reduce unnecessary debate. It can also support design systems, where shared components and patterns make products more coherent across screens. That said, rules are not a silver bullet. If teams follow them too rigidly, they may overlook context, brand personality, or the specific needs of their users.

The broader message is that great interfaces are usually the result of many careful choices rather than one dramatic redesign. Small improvements in spacing, consistency, contrast, and typography can add up over time and improve trust, comfort, and task completion. For tech teams, that is especially relevant because UI quality shapes how users judge the entire product. A feature can be powerful under the hood, but if the interface feels inconsistent or difficult, people may never see its value. That is why these seemingly minor tips continue to gain traction across modern product design.

Topcoat is a new open-source web framework from the Tokio ecosystem for building full-stack apps in Rust. Its project page describes it as modular and batteries-included, which means it tries to give developers many common tools in one package instead of asking them to assemble everything themselves. The project also puts simplicity and productivity front and center. At the same time, the maintainers are clear that it is still early-stage and experimental, so developers should expect breaking changes as the design evolves.

The main idea behind Topcoat is to reduce the usual split between backend and frontend work. In many web projects, teams build HTML on the client side, talk to a separate API, and manage state in JavaScript. Topcoat takes a different path. It renders markup on the server, and its components can be async, which means they can run code that waits for other work, such as reading from a service or fetching application state. This setup aims to cut out a lot of repetitive wiring and boilerplate that often slows teams down.

One feature that stands out is its approach to client reactivity without a heavy client bundle. According to the project description, a special expression syntax can be written in ordinary, type-checked Rust. Topcoat evaluates that code on the server for the first render and also translates it to JavaScript so it can run instantly in the browser. In practical terms, this means a simple interactive action, such as opening and closing a section of a page, can happen without a round-trip to the server. The pitch is clear: developers keep working in Rust while users still get fast interactions.

Topcoat also has a way to handle cases where the browser really does need fresh server output. The project calls this kind of unit a shard. When one of a shard's inputs changes, Topcoat can re-render that component on the server and swap the new HTML into the page. A search box is an easy example. As a user types, the results can be updated by running server-side code again and sending back fresh markup. This model could be appealing for teams that want dynamic behavior but do not want to juggle a large amount of frontend code and a separate application layer.

That promise, however, is a double-edged sword. A more unified model can improve developer experience, but it can also hide complexity under the hood. Translating Rust-based expressions into JavaScript is an ambitious idea, and the long-term trade-offs will matter. Developers will want to know how easy it is to debug, how flexible it is for complex user interfaces, and how well it performs at scale. They will also watch whether the framework can keep its simple mental model as more features roll out. For Rust teams, strong type checking and one-language development are attractive, but early adopters usually pay for that convenience with rough edges.

In the bigger picture, Topcoat reflects a wider trend in web development. Many teams are rethinking the old boundary between server and browser and looking for ways to streamline full-stack work. Rust already has a strong reputation for safety and performance, but web development in Rust can still feel fragmented. Topcoat is trying to bridge that gap with a more integrated approach. Whether it gains traction will depend on documentation, stability, and how quickly developers can get real apps off the ground. For now, it is a project worth watching, especially for engineers who want Rust to cover more of the web stack without getting lost in the weeds.