Some Things Just Take Time

If someone planted woods or a palm trees on a piece of land fifty years ago, they created something that cannot be bought off the shelf today. Money cannot accelerate that result. Effort cannot compress the timeline. The only way to get mature trees is for time to pass.

That is true of palm tree-lined streets, old gardens, and homes protected by a canopy that took decades to form. Start with an empty plot, and you can recreate many things. You cannot recreate age.

Some outcomes are valuable precisely because they take time.

We already understand this in other parts of life. We pay more for Swiss watches, Hermès bags, and historic homes because time is embedded in them. Sometimes that value comes from the labor required to make them well. Sometimes it comes from the fact that they have endured. We also set minimum ages for driving, voting, and drinking because we accept that maturity comes from lived experience, not instant access.

And yet we are increasingly surrounded by a culture of immediacy. That mindset is shaping how software and companies are built. Code generation may become faster and faster, but the real differentiator for a company or an open-source project will still be persistence: the willingness to stay with a problem for years, build trust over time, and work through constraints that are fundamentally human.

Friction Has a Purpose

A lot of founders and engineers today are fixated on speed. Iterate quickly. Deploy quickly. Move quickly. In many cases, that is reasonable. You can move fast, accept some imperfections, and learn from the process.

But not every form of friction is waste.

Some friction exists because it serves a function. Compliance is a good example. There is enormous pressure to strip away everything involved in processes like SOC 2, and a whole category of companies now exists to make that easier. Delve is one example, but far from the only one.

The assumption behind this trend is that whatever slows you down must be eliminated. Human judgment should be replaced with automation. AI should remove the nuisance from the process. The friction is treated as the problem.

But often the friction is the point.

There is a reason some major decisions come with cooling-off periods. We know that people need time to reflect. We also know that doing something correctly once proves much less than doing it correctly over an extended period. Reliability is not a moment. It is a pattern sustained over time.

Shipping Faster, Trusting Less

It is no longer remarkable that AI can write code quickly. The more interesting development is what happens after that capability enters the rest of the workflow.

Once code becomes easier to produce, the pressure shifts downstream. Teams want to ship faster, run more experiments, and remove every remaining source of delay. Reviews, infrastructure design, configuration, approvals, and checklists begin to look like unnecessary obstacles. If machines can produce results instantly, why keep the rest of the process slow? Why preserve permissions, reviews, or careful validation? State the intent, get the output.

That mindset assumes acceleration is always progress.

But public attention does not need to be anchored to truth to become dominant. It only needs to occupy enough space in people’s minds. Once a topic is repeated often enough, it becomes the thing people feel they are supposed to care about.

You can see this clearly in how buzzers operate in Indonesia. When public criticism of the government begins to gain traction on social media and crosses a certain threshold, the response is often not to address the criticism directly, but to flood the space with other topics. The goal is not rebuttal so much as redirection. Attention gets swayed elsewhere, and after a while the manufactured conversation starts to feel like the real one, simply because it is now the thing everyone is seeing, reacting to, and repeating.

I think something similar is happening in the AI era. When people with large platforms boast about their productivity by claiming hundreds of thousands of lines of code in a single day, or hundreds of commits and pull requests, I find it hard to take seriously. It feels less like engineering and more like performance. If a real company measured an engineer’s success by lines of code produced in a day, the absurdity would be obvious. And yet a surprising amount of AI discourse seems to reward exactly that kind of thinking.

What gets lost is the question of whether any of this work is useful, reliable, maintainable, or even meaningful. The conversation gets steered toward whatever is biggest, fastest, and loudest. Quantity becomes spectacle. In that sense, it resembles a broader political instinct: success gets measured not by impact on people, but by metrics that are easy to display. Not whether citizens are better off, but whether enough visible activity has taken place to create the impression of success.

That is also part of why I appreciate the stance the OpenCode team seems to be taking.

Increasingly, it feels like much of the software being built today, software people and businesses may depend on, has a lifespan measured in months, not decades. The same is true of many of the relationships around it.

The same pattern is showing up in open source. Suddenly everything is an open-source project, but many of those projects receive a week of activity and then stop. The creator loses interest, and the project fades away. As experimentation, that is fine. But experimentation alone is not what makes software dependable.

A good open-source project inspires confidence that its creator will keep maintaining it for the long haul, or that there is a real succession plan, or that a durable community exists around it. Longevity is part of the product.

What Time Builds

I spent five years at the startup I worked on, and two years at a game company. That is not because I am unusually virtuous or disciplined. It is because someone planted something, and I kept returning to it. Over time, it developed roots deeper than whatever enthusiasm I happened to feel on a given day. That is what time does. It turns an idea into a commitment, and a commitment into something stable enough to support other people.

No one is going to mass-produce a fifty-year-old oak.

And no one is going to generate trust, quality, or community out of a weekend sprint.

The things I care about most, projects, relationships, communities, became valuable through years of attention. They needed duration. They needed repetition. They needed people to keep showing up. No tool, no matter how fast, could have produced those outcomes ahead of schedule.