AI Changed the Equation

AI is changing that dynamic.

The latest GitHub Octoverse report highlights an emerging pattern: AI accelerates languages that offer structure, strong ecosystems, and predictable abstractions. TypeScript continues to rise because AI agents can reason about typed code. Python remains dominant because it owns the tooling ecosystem for data, research, and AI. The patterns are driven not by sentiment, but by leverage loops.

What sits underneath this trend is simple: AI models are better at languages they’ve seen vastly more examples of, and languages whose structure reduces ambiguity. If a model has seen a trillion examples of TypeScript and only thousands of Haskell, it will inevitably be better at generating and refactoring TypeScript.

Typed languages also help AI reason about intent — structure acts as a guide rail. A related analysis, “TypeScript, Python, and the AI feedback loop changing software development”, frames this trend clearly: typed and well-structured languages benefit most in the era of AI assistance and generation.

This shift surfaces an important mindset:

In the AI era, languages should be chosen for leverage — not loyalty.

Yet many engineering cultures still operate from loyalty-based reasoning:

• "Everything should be TypeScript because we’re a JS company."

• "Everything should be Go because it’s production-ready."

• "Everything should be Python because AI happens there."

Uniformity feels elegant. But uniformity does not automatically scale.

If we instead ask:

“Where does each language provide the most leverage for its layer of the system?”

a more realistic and future-proof architecture emerges. Because once the frame shifts from preference to leverage, the criteria for choosing a language changes too.

A Leverage-Aligned Stack

Frontend

TypeScript is the default. Its ecosystem, tooling, and AI support make it the natural place for user-facing development.

Backend Application Logic

TypeScript performs well here, especially when paired with contract-first API design. AI support accelerates iteration, prototyping, and refactoring — and most business logic benefits more from speed and clarity than from micro-optimized runtime characteristics.

High-Performance or Long-Lived Services

Some workloads such as schedulers, workers, streaming processors, and high-throughput edge compute, require predictable memory characteristics and runtime stability. Here, Go becomes a natural choice. Not because TypeScript is incapable, but because operational predictability becomes the dominant force.

Infrastructure and Platform Software

Infrastructure tooling lives in a different ecosystem. Terraform uses HCL — not because it's expressive, but because it enforces consistency. And when things need to be extended or written as providers, the ecosystem gravitates toward Go, because the tooling around Kubernetes, operators, Envoy, and most modern cloud-native foundations are written in Go.

This layer is optimized not for flexibility, but for durability and predictability.

AI / ML / Data Systems

Python remains uniquely positioned. Its ecosystem, libraries, research velocity, and AI-native frameworks give it continued leverage in domains where experimentation and iteration matter. It isn’t the fastest language, but speed of idea flow outweighs execution cost in this domain, and that reality won’t change soon.

The New Decision Model

AI lowers the friction of learning a new language. The hard part is no longer syntax; it’s architecture. If boundaries are explicit with schemas, contracts, protocols, queues, and messaging patterns, different languages can coexist cleanly.

So the question is no longer:

“Which language should we standardize everything on?”

but rather:

“Where does this language give us the highest return on effort — for humans, for systems, and for AI?”

Once framed that way, the emerging pattern — at least for now — becomes clearer:

• TypeScript where iteration speed and architecture flexibility matter.

• Go where operational stability and runtime behaviour matter.

• Python where AI, ML, and analytical workflows live.

Not everything needs Go.
Not everything needs TypeScript.
Not everything needs Python.

But everything SHOULD have a reason.

The takeaway isn’t about switching stacks. It’s about optimizing for leverage, not loyalty.

The languages and tools that survive the next decade won’t be the ones developers love most—they’ll be the ones that give developers and machines the most shared advantage.

“TypeScript, Python, and the AI feedback loop changing software development”

Seeing Structure Enables Generalisation

Originally, the model handled only the seller’s side.
Then I noticed that “available delivery dates” were nothing more than an intersection of date sets.
From this point of view, a seller, a customer, and delivery timing all share the same structure: each provides a set of dates, and their intersection defines what is possible.

earliest_delivery_date = (
  customer.preferred_delivery_dates &
  product.available_delivery_dates &
  shipping_schedule.available_delivery_dates
).min

Generalisation happened not because of creative imagination, but because I recognised the underlying structure — a set.

Knowing common data structures such as sets, ranges, trees, and graphs gives us a language to describe problems more precisely.
Once we have that vocabulary, we can see through the surface of business rules and find simpler, reusable forms beneath them.

Standard Libraries as Dictionaries of Structures

Language standard libraries are, in a sense, museums of reusable structures.
In Ruby, for instance, Enumerable abstracts the pattern of iteration; Range represents an interval that can apply to numbers or dates; and Set formalises an unordered collection of unique elements.
Each of these abstractions was born from many developers solving similar problems and then recognising a pattern that could be generalised.

Reading a standard library is like reading a dictionary of abstract data structures.
You can find how earlier engineers captured everyday patterns—iteration, ordering, containment—and turned them into composable building blocks.
Those structures often provide the missing words we need to express our own domain models more clearly.

Knowing Structures Lets You Delay Design Decisions

When I introduced AvailableDateSet, I didn’t need to handle every type of restriction at once.
Because I knew the concept of a set, I understood that other constraints—customer or delivery-related—could later be merged through intersection.
Knowing these underlying forms lets you delay generalisation until the right moment.
You can start simple, stay consistent, and expand when reality demands it.

Conclusion

Abstraction in software design is not a leap of imagination but a process of discovering existing structures.
Those structures—sets, ranges, trees, graphs—are already part of the common language of computation.
They live quietly inside every standard library, waiting to be noticed and reused.

When you struggle with a complex domain, try looking for a familiar shape within it.
The right abstract structure may already exist, and once you see it, your design will naturally become lighter and more flexible.

1. Known knowns: issues we are aware of and understand.

2. Known unknowns: issues we know exist but lack full understanding.

3. Unknown unknowns: issues we neither know exist nor understand.

This article explores testing techniques for known knowns and known unknowns, and shows how logging and observability help us convert unknown unknowns into known risks. We’ll also see how Site Reliability Engineering (SRE) practices fit into this picture.

1. Understanding Known Knowns and Known Unknowns

• Known knowns are clear requirements or behaviors already captured by tests.

• Known unknowns are areas we suspect might fail, but we don’t know the exact nature of the failure.

For example, we may know that a user-input parser must handle Unicode strings (known unknown), but we lack precise examples of problematic inputs.

2. Testing Techniques for Known Knowns and Known Unknowns

2.1 Unit and Integration Tests

• Unit tests verify specific functions or methods with fixed inputs and outputs.

• Integration tests check the interaction between multiple components.

These approaches are excellent for covering known knowns, because they focus on explicit, pre-defined cases.

2.2 Property-Based Testing

Property-based testing flips the script: instead of writing individual test cases, we define properties that should always hold. For instance:

• A sorting function should always return a list of the same length, with elements in non-decreasing order.

• A JSON serializer followed by a deserializer should yield the original object.

By generating thousands of random inputs, property-based testing helps uncover edge cases, turning some known unknowns into known knowns.

3. From Unknown Unknowns to Known Knowns: Logging and Observability

While testing covers many issues, some problems only appear in production under real-world conditions. These are the unknown unknowns. To discover them, we rely on:

3.1 Structured Logging

• Contextual logs record key variables and execution paths.

• Log levels (INFO, WARN, ERROR) help prioritise messages.

Good logging makes unexpected behaviour visible, turning unknown unknowns into known unknowns that we can investigate.

3.2 Metrics and Monitoring

• Counters track event occurrences (e.g., request rates, error counts).

• Gauges measure values over time (e.g., memory usage).

• Alerts notify teams when metrics cross thresholds.

By observing metric spikes or trends, we identify anomalies that testing missed, shifting issues from unknown to known.

3.3 Tracing and Distributed Context

• Distributed tracing maps request flows across services, showing latency and errors per segment.

• Trace IDs link logs and metrics to individual user requests.

Tracing reveals complex failure modes in microservice architectures, converting unknowns into testable scenarios.

3.4 Cultivating an Observability Culture

• Post-mortems document incidents, root causes, and preventive actions.

• Blameless analysis encourages team collaboration and continuous improvement.

Observability is not just tools—it’s a mindset that embraces uncertainty and learns from real-world failures.

4. SRE and the Convergence of Practices

Site Reliability Engineering combines testing, logging, and observability:

• SRE teams define service level objectives (SLOs) to guide alerts and dashboards.

• Error budgets balance innovation against reliability, using real-time data.

• Collaboration between dev and ops ensures that unknown unknowns are surfaced early and learned from.

Conclusion

By applying:

• Unit/integration tests for known knowns,

• Property-based testing for known unknowns, and

• Logging + observability for unknown unknowns,

We build resilient systems that adapt and improve. Embracing these practices bridges the gap between what we expect and what happens, turning every unknown into an opportunity for learning.

“There are unknown unknowns; the ones we don’t know we don’t know.”
– Donald Rumsfeld, Wikipedia: Unknown unknowns

Pros and Cons of Using UUID v4 as a Primary Key

UUID v4 gives global uniqueness and improves security because its random nature makes it hard to predict record order. Clients can even generate IDs without extra database calls. However, this randomness harms performance. The non-sequential order leads to poor index locality, increased disk I/O, and frequent page splits, especially during writes. In addition, the 128-bit size uses more storage than regular integers.

Why MySQL Suffers More: Index and Data Structure Differences

MySQL’s InnoDB engine uses a clustered B+Tree where table data is stored along with the primary key. With sequential keys, new records are added to the end of the tree, keeping data on the same pages and improving cache hit rates. UUID v4, being random, scatters inserts over many pages. This causes frequent page splits and increases disk I/O, which degrades performance. PostgreSQL, by contrast, stores data separately from the index, so it suffers less from this issue.

A Better Alternative: Binary Storage and Ordered ID Schemes

One solution is to store IDs in binary form (BINARY(16)) rather than as strings, which improves storage efficiency and reduces comparison overhead. Even better, using an ordered ID—such as a time-ordered UUID (v6 or v7) or alternatives like Snowflake IDs or ULIDs—can improve performance. Both Snowflake IDs and ULIDs include a timestamp that makes new records nearly sequential. Note that NanoIDs, by default, are generated randomly and do not embed a time component (see Why we chose NanoIDs for PlanetScale’s API for more details).

4. Conclusion

While UUID v4 offers many advantages in security and distributed systems, its randomness can degrade performance, especially in MySQL’s clustered index environment. Storing IDs in binary and adopting an ordered ID scheme—whether a time-ordered UUID (v6/v7) or an alternative like Snowflake IDs or ULIDs—can achieve near-sequential order, improving index efficiency and overall database performance in both MySQL and PostgreSQL.

How AI Influences Technology Choices

Many AI tools are built with system prompts that encourage the use of popular technologies such as React or Tailwind. Because these tools appear frequently in the training data, they are often suggested even when newer technologies might be better. This bias is explained in the essay AI is Stifling Tech Adoption.

Given this bias, it is important to explore solutions that address these limitations.

A Possible Solution: LLM Instructions in Web Frameworks

One way to solve this problem is to update the AI tools with new guidelines. By "LLM instructions" we mean a set of updated guidelines that tell the Large Language Model (LLM) how to behave using the most up-to-date information available. Encore.ts is a framework that includes these guidelines as part of its system^1. The content can be updated as the framework evolves, so that the LLM is always working with the latest data. This approach can help encourage the use of new and promising technologies that might otherwise be ignored.

Conclusion

AI models help many developers, but they can also slow down the adoption of new technologies because they rely on old training data and fixed system prompts. Using updated LLM instructions provided by web frameworks—such as the approach taken by Encore.ts—offers a possible solution. With up-to-date guidelines, developers can receive more accurate support from LLMs, which can lead to increased adoption of new technologies.

Compatibility and Performance

Deno v2 was a significant milestone that resolved many Node.js compatibility issues. While some minor challenges remain, the runtime has proven surprisingly robust. The application using NestJS runs smoothly, and I've particularly appreciated the ability to compile binaries that dramatically reduce our Docker container sizes.

Development Experience and Tooling

The developer experience with Deno has been mostly positive. Instead of relying on traditional tools like ESLint or Prettier, I've found Deno's built-in linter and formatter more than adequate. However, I encountered a notable challenge with dependency management: Renovate, a popular automated dependency update tool, doesn't seem to support Deno's deno.lock file fully. As a workaround, I've been using pnpm to manage our dependencies effectively.

Testing and Monitoring Limitations

Testing has been an area with room for improvement. While Vitest works, the lack of VS Code plugin support and incomplete V8 coverage implementation^1 can be frustrating. I've transitioned to using @std/testing, an official testing tool provided by the Deno team. Similarly, OpenTelemetry support remains partial, though official improvements are in progress^2.

A Pragmatic Approach

My strategy involves maintaining flexibility. By avoiding Deno-specific APIs and keeping a package.json, I ensure I can seamlessly transition back to Node.js if needed. This risk mitigation approach has been crucial.

Looking Forward

Despite some limitations, the Deno team's rapid improvements and community engagement are impressive. While I'm currently limited to reporting issues^3, I hope to contribute more directly to the runtime's evolution through code in the future.

For developers considering Deno in production, my advice is to approach it with cautious optimism. The runtime shows immense promise, and its evolving trajectory offers an exciting alternative for modern JavaScript development.