My first real deep learning was in biology. Long before I wrote production code, I was studying living systems — how organisms and ecosystems survive, adapt, and fail. Over time, I’ve found that biological systems are one of the most useful mental models I have for understanding software and software engineering.
When I was young, I was told that the early bird gets the worm. I’ve largely found that to be true — at least for some aspects of living. Early access to calories matters. Momentum matters. Survival often favors the thing that moves first, eats today, and lives long enough to try again tomorrow.
But it’s also worth saying out loud: that early bird is still eating worms.
In a world full of options, the early win often comes with an invisible cost — specialization. Making a choice early can look like an advantage, but it quietly narrows what you can consume later.
If you study biological systems, this pattern shows up everywhere. Traits that help a species thrive early in its evolution often constrain what it can become later. Diets narrow. Behaviors harden. What once improved survivability can, many cycles later, become a liability — not because the trait is “bad,” but because the environment has changed.
I see the same pattern play out in software, which is why biology has become such a useful lens for me.
The Greenfield Trap
Let’s say I’m starting a new, greenfield project. The environment I’m operating in — shaped by time, money, users, expectations, and investors — is always different, and it dictates what progress realistically looks like. Decisions get made so things can start moving. Along the way, I hear myself say familiar things:
I’ll refine this later. It’s good enough for now.
I just need it to work.
Don’t overthink it — I can change it later.
And in those moments, I have to make a choice. Often, it’s the right one. Shipping feeds the system. Flow matters. The thing I’m building survives long enough to eat another day.
But while those choices fade into the background of commits, tickets, and the general noise of life, they don’t disappear.
They compound.
They become the system’s metabolism — the hidden processes required just to keep the organism alive. The abstractions, dependencies, conventions, and assumptions that quietly determine how much energy it takes to grow, adapt, or even just exist.
Every dependency added for convenience carries a tradeoff forward. Every unfamiliar tool skipped because it felt risky — or because the team didn’t know it, or because the broader market hadn’t embraced it yet — narrows what the system can become later. Choices like React vs Web Components, frameworks vs standards, convenience APIs vs explicit contracts all shape the system’s long-term diet.
Undoing those choices usually isn’t evolution — it’s surgery.
Sometimes that surgery is worth it. Sometimes it’s cheaper to let the old organism die and start a new greenfield entirely. What interests me most is how to make early choices that support evolution, change, and longevity. I’m still learning, but I have a strong hunch that the path through the madness involves leaning into standards and evaluating tools through the lens of how well they preserve optionality over time.
The Environment Always Shifts
Another force that pushes systems to undo early choices — in both life and software — is the environment they live in.
Change is constant, but it’s rarely uniform. Sometimes environments shift slowly, in subtle ways that are hard to see day-to-day. Other times change arrives fast and violently, wiping out entire species (or products) that aren’t resilient or adaptable enough to absorb the shock and survive one more cycle.
This is where AI collaboration enters the picture and makes things going forward very interesting.
What AI-assisted development and AI collaboration really bring is speed — a faster ability to adapt — but only within the constraints we’ve already set. These systems don’t invent structure. They learn from the average of human decisions and apply that knowledge to your prompts, your constraints, and your existing system as it exists in a moment in time.
If the foundations are implicit or brittle, you don’t get leverage. You get amplification.
You get locked into a system whose behavior grows increasingly stochastic, while its ability to adapt quietly disappears — until it breaks.
AI can generate code quickly, but it can’t tell you whether your system’s diet makes sense.
The real risk — in software and in life — isn’t making imperfect choices. Nature and evolution are built on imperfection. The risk is mistaking early success for long-term fitness. In the natural world, this has been mediated by random, unpredictable events for billions of years. With AI, we’re approaching a point where we can actively evaluate decisions for long-term risk and fitness — if we’re willing to slow down just enough to ask better questions.
Evaluating the long-term impact of early decisions has always been a bit of a gamble. Without a crystal ball, some choices will increase a system’s ability to evolve, while others quietly lock it into eating worms forever — and that’s fine, until the worms disappear from the ecosystem.
So for me, this all collapses into a simple distinction:
- A convenient system optimizes for today.
- A durable system optimizes for adaptation.
The right early questions aren’t:
- Is this the fastest way to build it?
- Does this look like progress right now?
They’re closer to:
- What kind of system am I teaching this to become?
- What does this choice make harder to change later?
- If the environment shifts, does this help, hinder, or simply not matter for survival?
Because getting the right worm early in the day only matters if you’re still alive when the menu changes.
