AI Is Your Infinite Expert: You Just Need to Know How to Build

I’ve never built anything that talks to a GPS receiver. I’ve never parsed NMEA sentences. I’ve never dealt with coordinate reference systems, geofencing math, or satellite signal quality metrics. A month ago, if you’d asked me to build an app with GPS integration, I’d have budgeted a week just to learn the domain.

It took an afternoon.

Not because GPS is simple. It’s not. There are protocol details, platform-specific permission models, accuracy thresholds, battery optimization tradeoffs, and edge cases around tunnel loss and cold starts. But Claude knows all of it. Every protocol. Every platform API. Every edge case that’s been documented in a Stack Overflow answer or a developer guide.

I didn’t need to become a GPS expert. I needed to describe what I wanted, review what it produced, and know enough about software design to spot when the architecture was wrong. The API knowledge was free.

The encyclopedia vs. the architect

This is the shift that most people miss when they talk about AI-assisted development.

The value of a senior developer used to be split across two areas: knowing how to design software well, and knowing the specific technologies to implement that design. You needed both. An architect who couldn’t write a SQL query was useless. A developer who knew every framework but couldn’t structure a system was dangerous.

AI collapses the second category. Not partially. Almost entirely.

Claude doesn’t care if the task involves C#, Java, Python, Rust, or TypeScript. It doesn’t care if you’re calling a REST API, a GraphQL endpoint, a gRPC service, or a raw TCP socket. It has read the documentation for all of them. It knows the method signatures, the configuration options, the common pitfalls, and the idiomatic patterns. It knows them better than you do, because it has read every version of every framework’s docs, and it doesn’t forget.

What it doesn’t know is what you’re trying to build. It doesn’t know your domain. It doesn’t know your architectural constraints. It doesn’t know that your team prefers composition over inheritance, or that your deployment target can’t run containers, or that your users are on spotty cellular connections and every API call needs to be idempotent.

That’s your job. And it turns out that job is the hard part. It always was.

A Java codebase walks into a .NET shop

Here’s another example. I needed to analyze a Java application. Understand its structure, identify its domain concepts, map its bounded contexts, assess its test coverage patterns.

I don’t write Java. I haven’t written Java in years. I find it verbose, and its ecosystem choices frustrate me. On a normal day, I’d push this task to someone else or spend a few hours remembering where things live in a Maven project.

Instead, I pointed Claude at the codebase.

Within minutes, I had a structural analysis. Package organization, dependency patterns, where the domain logic lived versus where it was tangled into infrastructure. Claude read Java as fluently as it reads C#. It identified the same architectural patterns and anti-patterns I’d look for in any language: anemic domain models, service classes doing too much, repositories with business logic leaking in.

The language was irrelevant. The design principles are universal. I brought the architectural lens. Claude brought the ability to read Java without complaining about it.

The spec bridges the gap

This connects directly to the spec-driven methodology from Post 1 in this series.

When you’re working in unfamiliar territory, the spec becomes even more important. Without a spec, asking an AI to “add GPS tracking” produces generic code. It’ll give you a working implementation, but it won’t be your implementation. It won’t account for your offline-first architecture, your battery budget, or your domain model’s relationship between a round and its location data.

With a spec, the conversation changes. You describe the feature in terms of your domain, your architecture, and your acceptance criteria. The AI fills in the technology-specific details. You write:

## Spec: GPS Shot Tracking

**As a** player, **I want** my shot locations recorded automatically
**so that** I can review my round on a course map.

### Acceptance Criteria

- Location captured at each shot event with accuracy metadata
- Graceful degradation when GPS signal is weak or unavailable
- No location tracking between shots (battery preservation)
- Coordinates stored as domain value objects, not raw doubles

### Technical Details

- **Domain**: `ShotLocation` (value object), `Accuracy` (value object),
  `LocationUnavailable` as explicit domain concept
- **Platform**: Use device GPS APIs with configurable accuracy threshold
- **Persistence**: Coordinates stored with shot aggregate

You don’t need to know which GPS API to call. You don’t need to know the permission model. You don’t need to know the battery optimization strategy. You specified what you want and why you want it. The AI knows how.

And because the spec is explicit about your domain model (value objects, not raw doubles; location unavailability as a first-class concept), the AI produces code that fits your architecture. Not generic GPS code. Your GPS code.

What this means for your career

If you’ve spent years accumulating expertise in a specific technology stack, this might feel threatening. If your value proposition is “I know React” or “I know Kubernetes” or “I know the AWS SDK inside and out,” then yes, that specific value is diminishing.

But if your value proposition is “I know how to design systems that work,” you just got a massive multiplier.

Think about what becomes possible. A .NET architect can now evaluate a Java codebase, prototype a mobile feature, write a Python data pipeline, and set up a Rust service. Not because they learned four new languages. Because the architectural thinking transfers, and the AI handles the syntax.

The developers who thrive in this environment are the ones who understand domain modeling, system boundaries, failure modes, and testing strategies. The ones who can look at AI-generated code and say “this is wrong” not because the syntax is bad, but because the design is bad. The ones who write specs that produce correct implementations because they know what correct looks like.

The fundamentals won. They always do. But now they win faster.

The boundaries still matter

This isn’t a “learn nothing, let AI do everything” argument. You still need to understand what you’re building. You still need to review generated code with a critical eye. You still need to know when the AI is confidently producing something that will fail in production.

GPS is a good example. Claude knows the API calls. It does not know that your specific Android device has a GPS chipset that takes 30 seconds to get a first fix in dense tree cover. It does not know that your users play golf at 6 AM when satellite geometry is suboptimal. It does not know that the course you’re testing on has a cell tower that interferes with GPS accuracy near the 7th hole.

Operational knowledge, domain expertise, and user empathy don’t come from documentation. They come from experience. The AI can’t replace those. But it can free you from spending your time on the parts that are documented, so you can focus on the parts that aren’t.

What this means for your organization

If you lead a technology team, the implications go beyond individual productivity.

Hiring changes. The old model was to hire for specific technology stacks. You needed a Java team for the Java services, a .NET team for the .NET services, a Python specialist for the data pipeline. AI-equipped developers with strong design fundamentals can work across all of them. Fewer, better engineers cover more ground. Hire for architectural thinking and domain expertise, not language keywords on a resume.

Technology choices become less permanent. Choosing a framework used to mean committing your team’s learning budget for years. If your only Python developer leaves, that service becomes a liability. When any developer on the team can work in any language with AI assistance, technology decisions get evaluated on technical merit instead of team familiarity. The bus factor drops.

Legacy systems become approachable. Every organization has that COBOL service, that aging VB.NET monolith, that Perl script nobody wants to touch. AI reads legacy code as fluently as modern code. Your team can analyze, document, and incrementally modernize systems written in languages nobody on staff has used in a decade. The barrier to legacy modernization drops from “hire a specialist” to “point your existing team at it.”

Ramp-up time compresses. New team members with strong fundamentals become productive faster when AI handles the technology-specific learning curve. Onboarding shifts from “spend two weeks learning our stack” to “spend two days learning our domain and architecture.” The spec and rules file give new developers the context they need. The AI gives them the technology knowledge.

Your competitive advantage is your domain expertise. Every company has access to the same AI tools. The differentiator is how well your team understands your business domain, your users, and your architectural constraints. Those are the inputs AI can’t generate. Organizations that invest in domain knowledge and design capability will outpace those still hiring for syntax.

The practical takeaway

Next time you face a task that involves a technology you don’t know, don’t start with a tutorial. Don’t spend a day reading documentation. Don’t budget a week for “learning the platform.”

Start with your spec. Describe the feature in your domain language, at your architectural level. Let the AI fill in the technology-specific implementation. Review it. Ask it to explain the parts you don’t understand. Push back on the parts that don’t fit your design.

You’ll learn the technology faster this way than you would reading docs, because you’re learning it in the context of a real problem you actually care about. And you’ll ship the feature in hours instead of days.

The API knowledge is free now. Invest in the things that aren’t.