How LLMs Brought Back the Feature Google Maps Took Away

How LLMs Brought Back the Feature Google Maps Took Away

At some point, every heavy Google Maps user has a moment of grief: the team at Google removes a subtle but beloved feature. The official changelog says 'simplified UX', and the community threads fill with users describing their old workflow.

The developer who posted on Habr decided not to wait. According to the article, they used an LLM — Claude — to build a functional replacement for a Google Maps feature that no longer exists in the product. Even better, the solution was packaged as a reusable skill for Claude and shared with the community.

This is a story about a small usability idea, but it is also a lens through which to look at the future of using closed SaaS platforms.

The Problem: When a Platform Removes Part of Its UI

The removal, as described in the Habr post, did not happen with a graceful migration path. One day the option was there; after an update it was gone. The author explains why this feature mattered to them: it was not a gimmick but part of a routine workflow. Without it, they had to switch between multiple web services and manually compare data. To reproduce the previous functionality, they would have to open the Google Maps API, write scripts, handle authentication, and build a new frontend. That is a lot of effort for one person.

The post is not an exception. Google Maps has retired many capabilities over the years. Sometimes the product team resurrects them in a different form; often they do not. The workaround most users rely on is giving up on the feature. The developer instead chose to rebuild it with a Claude skill.

Why a Claude Skill Is a Good Fit

Claude Skills, available in the Anthropic Claude ecosystem, let users extend the assistant with a set of instructions and files. A skill usually consists of a SKILL.md markdown file, optional metadata, and helper scripts. When you tag the skill in a conversation, Claude follows the procedure defined there: calling APIs, formatting data, and producing output.

In this case, the skill instructs Claude how to emulate the removed Maps functionality. The developer's skill turns a natural language request such as 'show me the same data I used to get from Maps' into a sequence of structured calls. Instead of clicking through a GUI, the user simply asks Claude.

This is the key shift: from a fixed interface to an agentic workflow. The LLM is not just predicting text; it is acting as a small application.

The Architecture of a Skill

The technical side is straightforward. The skill directory contains a SKILL.md file with YAML front-matter. The front-matter typically has three fields:

• name — the skill identifier used in prompts;
• description — a natural language description that tells Claude when to activate the skill;
• allowed-tools — a list of tools the skill can invoke, such as HTTP requests or file operations.

The body of SKILL.md is written in Markdown. In this body, the author describes the workflow in detail. For instance, the instructions may look like this:

1. Read the user's input and determine what kind of data they need.
2. Call the relevant Google Maps API endpoint (for example, Places API, Directions API, or Geocoding API).
3. Handle API authentication with an API key stored in environment variables.
4. Transform the JSON response into a readable summary.
5. Output tables or lists similar to the old interface.

Because Claude executes these instructions, the skill is essentially a living documentation file. The user does not need to write code for every step; the LLM interprets the instruction and uses the available tools.

From Closed UI to Open API

The key enabler is that Google still provides the underlying data through APIs. Removing a UI toggle does not remove the underlying data. The Maps interface is only one way to access geospatial data. If you combine the official API with an LLM workflow, you effectively get a customizable copy of the old feature.

Interestingly, the article reminds readers that Google Maps has an official API with many endpoints. Even if the UI removes a button, the API still supports the operation. This creates a strange asymmetry: a feature can disappear from the interface but remain fully available in the backend. Traditionally, exploiting that asymmetry required a custom app. With Claude skills, the gap is closed on the same day.

Of course, this approach has limitations. The Google Maps API is not free. The developer had to manage billing, quotas, and rate limits. They also had to be careful with API keys, since exposing a key in client-side code is risky. In the skill implementation, keys are stored locally or in environment variables, and all API calls are executed through Claude's server-side environment or locally with Claude Code.

One more limitation: API response schemas change. The LLM may fail to handle API changes if the skill is not updated. That is why the skill includes clear instructions on how to detect error codes and adapt. The developer reports that Claude handles most edge cases well.

What the LLM Brings to the Table

The obvious part is parsing natural language. But there are two less obvious benefits:

1. Resilience to change: when Google changes the API schema, a traditional script breaks. With an LLM skill, you can update the instructions and Claude adapts to the new response format automatically.
2. Formatting and explanation: the old feature showed raw numbers. The skill can explain them, highlight anomalies, and recommend routes, because it combines API data with reasoning.

The result is a personal assistant that becomes a bridge between a proprietary service and the user's own information needs.

Practical Example: Restoring a Map Overlay

The Habr article focuses on a single feature, but the same pattern is easy to apply in other cases. Imagine Google Maps removed a custom map layer that showed traffic incidents. You could instruct Claude to periodically call the Directions API, parse the JSON response, and render it as a list of incidents with severity and description.

The skill might use the following endpoint:

https://maps.googleapis.com/maps/api/directions/json?origin=...&destination=...&departure_time=now

Then the skill converts the responses into a human-readable table:

This example is illustrative, but it follows directly from the architecture described in the post.

Comparing the Old Workflow and the New One

The table shows a trade-off. The user loses the free and stable UI but gains the ability to shape the feature exactly as they need.

Privacy and Security Considerations

Because the skill works with a real API key, security is important. The author of the article recommends never embedding the key directly in a prompt. Instead, the key should be stored in a local .env file or in the environment of Claude Code. This way, the skill can read the key without exposing it to the chat log.

Another point is data ownership. The skill may send user queries and API responses to Anthropic's servers. For personal use, this is generally acceptable. For companies, it means checking compliance and data retention policies before connecting a corporate Google Maps project.

Was It Worth It?

The author's conclusion is yes. The skill is not a perfect replacement: it requires an API key, consumes quotas, and depends on the availability of the underlying endpoints. Yet the developer no longer needs to wait for Google to restore the UI. Moreover, the skill can be extended: add more APIs, integrate with other services, or run on schedule.

One of the most interesting parts of the article is the idea that LLM skills make product teardowns reversible. When a SaaS company removes a feature, the data often remains accessible via backend APIs. Consumers used to have no way to access that data without writing code. Now an LLM can act as a compiler, translating natural-language commands into API calls.

A Decision for Developers

This case study is a useful template for anyone working with popular web services. If you are building an integration layer for AI agents, consider these lessons:

• Keep a canonical API description in the skill instructions.
• Make the skill fail gracefully when the API returns an unexpected shape.
• Keep secrets out of the repository and use environment variables.
• Test the skill after every upstream service update.

For teams that want to build similar connectors, the same pattern is used in the ASI Biont integration layer. ASI Biont поддерживает подключение к Google Maps API через API — подробнее на asibiont.com/courses.

Conclusions

The Habr article shows a small but meaningful example of what happens when an LLM meets a closed platform: the user gets control back. The specific feature may be niche, but the method is universal. Google Maps removed something; the author recreated it with Claude and a skill; the skill is shared with the community.

From a technical viewpoint, this is a standard API wrapper. From a product viewpoint, it is a unique piece of UX: the user's own assistant, their own preferences, and their own data flow. It turns the question 'why did they remove this?' into 'what do I want to see instead?'.

Perhaps the most valuable takeaway is this: in 2026, a single developer can build a better UI for a big platform's data in a few hours, using an LLM skill. That is a lesson for both users and product managers.

Source