📰 English IT Daily · 2026-07-22

For many developers, old web work felt simple. You wrote HTML, added CSS, uploaded files, and the site was live. There was no build step, no huge list of dependencies, and usually no long setup guide. Over time, that world changed. Modern frontend development now includes package managers, build tools, testing systems, and several layers of code before a page reaches the browser. To people who stepped away for a few years, this can feel like the ground shifted under their feet. The key point, however, is that this complexity did not appear out of nowhere.

A useful way to understand the change is to look at the problems that teams were trying to solve. In the late 2000s, developers wanted pages to update without a full reload. That demand gave rise to AJAX and tools such as jQuery, which smoothed over browser differences and made interactive pages far easier to build. For a while, this approach hit the sweet spot. But as websites turned into web applications, a deeper issue came to the surface: developers had to keep the screen and the underlying state in sync by hand. If one value changed, several parts of the page might need updates, and missing one could mislead users.

That pain set the stage for frameworks built around declarative UI. Instead of writing every step needed to update the page, developers described what the interface should look like for a given state, and the framework handled the rest. This was a major shift in thinking. It reduced a lot of manual work, especially in larger applications, and it made interactive interfaces more predictable. As these frameworks gained traction, teams also adopted component-based design. A button, form, or menu could be built as a reusable unit, which helped organize growing codebases and made collaboration easier.

Still, each solution brought fresh trade-offs. Once teams relied on components, they also needed ways to bundle files, transform newer JavaScript into code that older browsers could run, and manage many third-party packages. Tooling began to pile up because browsers, language features, and project needs did not move at the same pace. In other words, many tools were scar tissue over real wounds. They existed because teams had already run into performance problems, browser inconsistencies, maintenance headaches, or release risks at scale. The result was not random chaos but a long chain of practical responses.

Critics say the modern stack can be a double-edged sword. It enables powerful applications, but it can also bury beginners in setup work before they build anything useful. A simple contact form may now require many moving parts. Some developers feel the industry got carried away and optimized too early. Supporters answer that these practices grew out of real production demands, especially for teams maintaining large products over time. Both views can be true. The strongest lesson is that complexity often reflects accumulated history rather than pure fashion.

Interestingly, the story may now be coming full circle. Newer tools often aim to strip away unnecessary steps, improve performance, and make development feel closer to the older model of writing files and shipping them quickly. The difference is that today’s teams still want modern features, good user experience, and maintainable code. So the future may not reject the past; it may reconcile simplicity with lessons learned the hard way. For engineers, this matters because choosing frontend tools is not only about trends. It is about understanding which wound a tool is meant to heal, and whether that wound actually exists in your project.

A new debate is growing in the AI industry: should powerful models stay closed and controlled, or should their weights be released so others can run them more freely? Recent discussion around Chinese AI companies suggests that open-weight models may be giving China an advantage. The basic idea is simple. If developers and businesses can download a model, host it where they want, and adapt it to local needs, adoption can spread quickly. In contrast, a closed model usually stays behind a company’s own service, with tighter rules, limited access, and stronger vendor control.

This matters because AI models may not have a deep moat by themselves. In business, a moat means a lasting advantage that competitors cannot easily copy. For many users, switching from one model to another is not very difficult, especially in engineering work where models are called through standard interfaces. A team might use one assistant today and another tomorrow with only small workflow changes. That means the real business value may sit less in the model alone and more in the surrounding enterprise services: contracts, security reviews, system integration, support, and tools that fit daily work.

At the same time, the United States has placed export controls on advanced GPUs, and many countries and companies are careful about sending sensitive information to Chinese services. These limits create a difficult situation for Chinese AI firms. They may have enough computing power to train strong models, but offering global, centralized services at the same scale as major American firms is harder. In that context, releasing open-weight models is a practical move. It turns a weakness in centralized distribution into a strength in broad adoption, because others can run the model on their own infrastructure.

Supporters of this approach argue that open technologies often gain traction faster in infrastructure markets. The reason is permissionless use: companies, researchers, and startups do not need to wait for approval from a central provider. They can experiment, fine-tune systems for their own use cases, and deploy them in places where compliance rules are strict. Open-weight models are not the same as fully open-source software, but they are still more portable than closed services. That portability can create a wider ecosystem, because each organization can plug the model into manufacturing, research, education, or internal business tools.

Another reason this strategy is getting attention is that the performance gap seems to be narrowing. For a while, the strongest American frontier models clearly outperformed most open alternatives. That lead gave US companies time to build premium services around them. But recent Chinese model releases from companies such as Moonshot and Alibaba have been presented as much cheaper systems that can compete more closely with top American models. Even if the exact rankings change from month to month, the broader trend is clear: lower-cost models with strong enough quality can be disruptive, especially when organizations care about flexibility and local control.

Still, this story is not one-sided. Open-weight AI is a double-edged sword. It can lower costs, widen access, and reduce lock-in, but it can also raise concerns about safety, misuse, and political bias. Some critics worry that models built in China may reflect government positions on sensitive topics. Others point out an irony: China is often seen as tightly controlled, yet some American AI companies are the ones keeping their technology under close control. For engineers and business leaders, the key question is not only which model is best today. It is also which strategy will hold up over time: closed services with strong support, or portable models that can spread across the world more easily.

A new report from Supabase offers a broad snapshot of startup life in 2026. The company says it surveyed 2,000 startup builders about what they adopted and what they left behind between 2025 and 2026. The picture is clear: AI is no longer a side tool. For many teams, it now sits at the center of coding, product work, and daily decisions. The report also suggests that startups are becoming more global. Strong companies are being built from many regions, not only from famous tech hubs. That shift matters because young companies often act as a leading indicator for the rest of the industry.

One of the strongest themes in the report is the rise of what Supabase calls the “Anthropic generation.” In simple terms, this means many founders are building with tools and models connected to Anthropic’s Claude. The survey shows high usage of Claude-related coding tools, and Anthropic appears near the top among model providers as well. This does not mean the market is settled. OpenAI, Gemini, and other model options still have a large presence. But the tooling layer seems to be undergoing a clear shift. Startups are showing which products are gaining traction first, and larger companies may follow later.

Another striking result is how much code is now written by AI. According to the survey, AI-written code has become the median experience for startup teams. Many respondents said that a large share of menial coding tasks is handed off entirely to AI systems. That can speed up development, especially for small teams trying to move fast. It can also free engineers from repetitive work and let them focus on product decisions or system design. At the same time, this trend is a double-edged sword. Faster output is useful, but teams still need strong review habits, testing, and security checks if they want to avoid technical debt and hidden mistakes.

The report also points to a deepening product stack around Supabase itself. In the survey, many startups said they use Supabase for backend services, authentication, and hosting-related choices. React and Next.js remain popular on the application side, while mobile and other web options are still part of the mix. This tells us something practical about startup behavior. Founders often prefer tools that reduce setup work and let small teams ship quickly. When resources are tight, convenience can outweigh the flexibility of building every part from scratch. For engineers, that trade-off is familiar: speed today may limit choices tomorrow, but early-stage teams often accept that bargain.

AI agents are another area to watch. More than half of respondents said agents are useful, and many teams are already using them in production or planning to do so. The most common uses include workflow automation, data analysis, personalization, support, and research assistance. In many cases, the goal is not a fully autonomous system but a practical assistant that can take routine work off a person’s plate. Even so, many startups are still feeling their way. The report says almost half have no formal system for managing prompts, while others rely on hardcoded prompts or version-controlled files. That suggests the field is moving fast, but standards are still catching up.

Taken together, the survey describes a startup world that is moving quickly but not blindly. Founders appear willing to bet on AI-native tools, integrated platforms, and new ways to reach customers, yet they are also testing what truly works. For engineers and product teams, the message is straightforward. Keep an eye on how startups build, because their habits often spread outward. The next few years may bring even more AI-generated code, more agent-based features, and more competition between all-in-one platforms and specialized tools. The companies that come out ahead will probably be the ones that balance speed with discipline, and experimentation with sound engineering judgment.

A cyberattack on Romania’s land registry agency has shown how deeply digital systems are tied to daily life. According to reports, a hacker broke into the National Agency for Cadastre and Real Estate Advertising, known as ANCPI, and deleted the country’s land registry records after an extortion attempt failed. The attack reportedly used valid login details, which suggests the intruder did not need to force a way in from the outside. Instead, the person may have entered by abusing access that already looked legitimate. After moving through internal systems, the attacker is said to have wiped systems and backups and also disrupted email services.

The damage quickly brought the real-estate market to a standstill. For about a week, official apps and websites were offline, which meant notaries could not register new property deals. Citizens also could not get proof of ownership or detailed land records. A land registry is not just an archive sitting in the background. It supports legal transactions, mortgages, inheritance, planning, and disputes over who owns what. When that foundation is missing, many ordinary processes grind to a halt. This is why an attack on a government records system can affect far more people than a typical company breach.

Reports say the incident became public as the attacker started deleting information. Soon after, some stolen material was reportedly offered for sale on a hacking forum. That material included employee credentials, internal documents, and details about the agency’s IT network. If that reporting is accurate, the attack was not only destructive but also intelligence-driven. In other words, the hacker seems to have mapped the environment before carrying out the final step. That kind of careful preparation matters because it can help an attacker find the most damaging targets, avoid detection, and increase pressure during an extortion attempt.

Romanian officials later restored the agency’s website and said they were rebuilding the network from scratch. That phrase often means an organization no longer fully trusts its environment and wants to reset core systems, accounts, and connections in a controlled way. Even so, one key question hangs over the case: backup strategy. The source report suggested the attacker claimed to have deleted backups, but it also indicated the agency may have had an offline copy. If that is true, it could be the difference between a serious crisis and a disaster that drags on for months. Offline backups remain one of the strongest last lines of defense because they are harder for intruders to reach during an active breach.

The case also fits a broader pattern. Romania is not the only country whose land records systems have been targeted in recent years. Similar agencies in other countries have also faced attacks. That trend is worrying because land registries are high-value public systems. They hold sensitive legal records, and they support transactions that cannot easily be delayed without economic cost. At the same time, many public-sector organizations must manage old technology, limited budgets, and a large attack surface. These conditions can leave them on the back foot against attackers who are patient, financially motivated, and willing to mix theft, extortion, and destruction.

For security teams everywhere, the lesson is not limited to one agency or one country. An incident like this raises basic but difficult questions: how credentials are protected, how unusual internal behavior is detected, how quickly backups can be verified, and how essential services continue during recovery. It also shows that cyber resilience is about more than preventing entry. Organizations need ways to contain damage, keep critical operations running, and recover with confidence. When public records are involved, trust is just as important as uptime. People must believe that the system is accurate, available, and legally reliable, even after a breach puts all of that at risk.

For years, many people feared that artificial intelligence would remove large numbers of jobs and leave workers with less to do. New research suggests a different pattern, at least for now. Instead of creating free time, AI often seems to increase the amount of work people try to fit into a day. Studies mentioned by The Atlantic found that workers who adopted AI spent much more time on email, messaging, chat, and business tools. In other words, AI is not simply a machine that gives people rest. It can also become a machine that raises the pace of work.

One reason is that AI lowers the barrier to starting tasks that once felt too difficult, too technical, or too time-consuming. Research from UC Berkeley’s Haas School of Business suggests that when AI makes activities such as coding or engineering easier, workers may stop outsourcing those tasks and do them themselves. That sounds efficient, but it also means people may take on more responsibility than before. They may work in short bursts at night, on weekends, or whenever they have a spare moment. AI can turn many small gaps in the day into extra work time.

This shift has a psychological cost. If AI lets people complete a task faster, managers may begin to expect more output in the same number of hours. Workers may also expect more from themselves. The result is a more crowded workday, with constant switching between tasks and less time for deep concentration. Some researchers have used the phrase “AI brain fry” to describe this frazzled mental state. Focused, uninterrupted work may fall even as total activity rises. So the central question is not only whether AI saves time, but also what people do with the time it saves.

This pattern is not completely new. History shows that labor-saving tools do not always lead to a calmer life. Faster travel, for example, does not simply reduce travel time; it often encourages people to travel more often. In a similar way, AI can expand what workers believe is possible in a single day. When intelligence becomes more available through machines, human value may shift toward something else: the willingness to direct effort, make choices, and stay engaged. In simple terms, if smart assistance is plentiful, then personal drive may matter more.

That idea connects to a concept from psychology called need for cognition. Some people naturally enjoy hard thinking. They like solving difficult problems, reading dense material, and wrestling with complex ideas. Others are more likely to avoid mental effort whenever they can. Many people sit somewhere in the middle. The article argues that AI may widen the gap between these groups. People who actively grapple with AI, question its answers, and use it to sharpen their own thinking may gain more from it. People who use it only as a shortcut may become more passive over time.

This does not mean that only extreme work habits will succeed, or that every worker should always do more. AI is a double-edged sword. It can remove boring tasks, but it can also invite overload and unrealistic expectations. For professionals in technology and beyond, the challenge is to use AI with intention. The workers most likely to thrive may be those who protect time for real thinking, choose carefully when to rely on automation, and keep building their own judgment. As AI spreads, success may depend less on raw intelligence alone and more on discipline, curiosity, and the ability to manage mental effort.

Google has introduced three new Gemini models: 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber. The company says these models are designed for developers who are building AI agents in real production systems. In simple terms, Google is trying to improve three things that matter a lot in business use: speed, cost, and reliability. This is especially important as more companies move from demos to large-scale services that must answer quickly and work consistently.

The main release is Gemini 3.6 Flash, which Google describes as its workhorse model. It builds on earlier feedback from users of 3.5 Flash and aims to offer better coding, stronger knowledge work, and improved multimodal performance. Multimodal means the model can work with more than one type of input, such as text, images, charts, or documents. Google also says 3.6 Flash is more efficient because it uses fewer output tokens, takes fewer reasoning steps, and needs fewer tool calls to complete multi-step tasks. That can lower the total cost of running an agent, not just the model price itself.

Another model, 3.5 Flash-Lite, focuses on raw speed and cost-effectiveness. According to Google, it is the fastest and cheapest model in the 3.5-class family and can generate output very quickly. This matters in applications where response time is a deal breaker, such as customer support, security triage, or systems that need to process a high volume of requests. A model like this may not be the strongest in every benchmark, but it can hit the sweet spot for teams that need acceptable quality at scale without spending too much.

The most specialized launch is 3.5 Flash Cyber, which is paired with Google’s CodeMender code security agent. Google presents this as a cyber-focused system rather than just a general model. That distinction matters because security work often depends on careful orchestration between a model and the tools around it. In practice, a security agent may need to inspect code, identify risky patterns, suggest fixes, and avoid unnecessary changes. In that setting, speed alone is not enough. Teams also need precision, predictable behavior, and workflows that can stand up to real operational pressure.

These releases reflect a broader shift in the AI market. For a while, many companies competed mainly on benchmark scores, but now buyers are looking more closely at efficiency and practical value. A model that is slightly smarter on paper may still lag behind in business adoption if it is too slow, too expensive, or too verbose. Token efficiency has become a key metric because it affects both cost and usability. If a model gives shorter, clearer answers and reaches the goal with fewer steps, the whole system can become easier to manage.

At the same time, there are trade-offs to watch. Specialized and faster models can be a double-edged sword: they may reduce cost and latency, but teams must still test whether the quality is good enough for their use case. Security is an even higher bar, since errors can create serious risk. For engineers, the bigger lesson is that model choice is becoming more nuanced. It is no longer only about choosing the most powerful model. It is about matching the right model to the right task, measuring real workflow performance, and keeping an eye on how quickly this field is moving.

A new design debate is gaining traction in the age of AI. As image generators and interface tools become faster and cheaper, many companies can produce endless options in minutes. This has changed the role of designers. In the past, value often came from the ability to create polished outputs. Now that execution is easier to automate, the harder question is not how to produce more ideas, but how to choose the right one. The central claim in this debate is simple: taste cannot be delegated. Someone still needs to decide what good looks like and what deserves to be built.

The article from UX Collective connects two related problems. First, AI can generate many designs, but it does not truly own the judgment behind them. Second, organizations often weaken judgment through design by committee. In that model, many people review a product, each person gives feedback, and the final result becomes a compromise. On paper, that sounds safe and collaborative. In practice, it can water down strong ideas. A product may avoid obvious mistakes, but it may also lose clarity, character, and direction. When too many people shape every small decision, quality can become harder to protect.

This matters because taste is not the same as popularity. A system can learn patterns in what users tend to prefer, and a large group can agree on a direction. But neither of those things automatically produces good design. According to the source, taste starts with deep exposure to excellent work and with an internal reference library built over time. It includes knowledge of proportion, typography, composition, and interaction. Just as important, it includes the courage to act on that judgment. Recognizing quality is only half the job; deciding what should exist is the harder part.

AI tools are becoming remarkably good at prediction. They can compare options, rank outputs, and generate versions that feel familiar or appealing. That is useful, especially in early exploration. Teams can test many concepts, move faster, and lower the cost of trying new ideas. In that sense, AI is a double-edged sword. It democratizes execution, which is exciting, but it can also flood teams with average choices. If everything looks acceptable, people may settle for work that is merely safe. The risk is not that AI will create ugly products. The risk is that it will normalize polished but forgettable ones.

This is why the debate is also about leadership, not only about tools. In many companies, approval processes are meant to reduce risk. However, when every choice must pass through several layers, responsibility becomes diluted. People may recognize a stronger option, but no one has the authority to back it decisively. The result is often a product shaped by alignment rather than conviction. That can be sensible in regulated or high-stakes environments, yet it can also leave teams stuck in the middle. They spend too much time in the weeds and lose sight of the larger vision.

For product teams, the lesson is not to reject AI or collaboration. It is to be clearer about where each one fits. AI can support execution, research, and rapid exploration at scale. Cross-functional feedback can catch blind spots and improve usability. But final judgment still needs ownership. As AI keeps improving, the competitive advantage may shift away from producing assets and toward making better decisions. Companies that stand out may be the ones that use AI widely while still protecting a clear point of view. In other words, tools can assist taste, but they cannot replace accountability for it.

vocabulary

vocabulary1