Striving Through the AI Revolution: Notes From an Engineer Who Is Still Catching Up

I have been writing software for long enough to remember when a new framework could reshape my week and then quietly fade. What's different now is the pace. Tools that felt cutting-edge last spring feel dated by autumn, and the expectations placed on engineers change faster than we can absorb them. So when people ask how to keep up with AI, I don't think the honest answer is a single plan. It's a habit of continuous effort, which is what I mean by striving.

Striving Is a Practice, Not a Moment

Many of us imagined the AI shift as a single event: a day when everything changes and we either adapt or fall behind. That framing is comforting because it suggests there's a finish line. It's also wrong. What I've seen on my own teams is a steady stream of small changes. A new model improves code completion. A new agent framework changes how we structure internal tools. A new policy from legal changes what data we can send to an external API.

Striving, in this context, means treating adaptation as a standing part of the job. I set aside a couple of hours every other week to try one new tool on a real problem, not a toy example. I keep a short running document of what worked, what failed, and what I'd do differently. That document has become more useful to me than any single tutorial.

Augmentation Beats Replacement

The clearest lesson I've taken from my own work is that AI helps most when it sits alongside expertise rather than replacing it. A 2022 controlled study by GitHub found that developers using GitHub Copilot completed a coding task about 55% faster than those without it. That number is striking, but I'd read it carefully. The gain came from people who already knew what they were building. They could tell a good suggestion from a plausible-looking bad one, and they could steer the tool toward the structure they wanted.

In practice, my best results come from a simple loop: I define the problem, sketch the approach, let the assistant fill in the boilerplate, and then review every line as if a junior colleague wrote it. The people I see struggling tend to do the reverse. They accept whatever appears and hope the tests catch the rest.

Skills Are Moving Under Our Feet

The World Economic Forum's Future of Jobs 2023 report estimated that around 44% of workers' core skills would be disrupted by 2027. Reading that line made me pause, because it describes more than tool churn. It describes the underlying competencies that make a job feel like yours.

For engineers, I think the durable skills are shifting toward problem framing, system design, reviewing code critically, and communicating tradeoffs to people outside engineering. Syntax memorization matters less than it used to. Judgment matters more. Reskilling, then, isn't about chasing every new library. It's about deliberately practicing the parts of the craft that the tools can't yet supply on their own: deciding what should be built, and knowing when a result is wrong.

Patience: What Electricity Can Teach Us

Economic historians often point to electricity as an example of a general-purpose technology. Factories did not become dramatically more productive the moment electric motors arrived. For decades, many simply swapped a steam engine for an electric motor while keeping the same layout. The big gains came later, when managers redesigned workflows around what electricity made possible: distributed machines, flexible floor plans, new processes.

I find this reassuring and a little humbling. It suggests that the largest returns from AI may depend less on the models themselves and more on how we reorganize work around them. That kind of change requires experimentation, and experimentation requires patience. Early hype promises instant transformation. History suggests that the people who benefit most are those who run small, honest trials and learn from them.

Klarna and the Operational Reality

In 2024, Klarna reported that its AI assistant handled roughly two-thirds of customer service chats in its first month. The efficiency story is obvious. The less visible part is what it implies for the organization. Support workflows had to be redesigned, escalation paths had to be defined, and the people who remained had to take on different kinds of work.

Whenever I see an impressive deployment number, I now ask a second question: what changed around it? Who owns the handoff when the bot gets stuck? How are customers told they're talking to an automated system? What happens to the staff whose daily work shifted? Striving responsibly means treating these operational questions as part of the engineering problem, not an afterthought for another department.

Verify Everything: The Air Canada and Amazon Lessons

Two cautionary examples have shaped how I work more than any productivity study. In 2024, Air Canada was held liable after its chatbot gave a customer incorrect information about bereavement fares. The company had argued, in effect, that the bot was a separate entity responsible for its own answers. The tribunal disagreed. If your system speaks for your business, its mistakes are your mistakes.

Then there is Amazon, which in 2018 scrapped an experimental résumé-screening tool after discovering that it had learned to penalize résumés associated with women. The model had been trained on historical hiring data that reflected past biases, and it reproduced them.

Both stories point to the same discipline: verify outputs and monitor for bias. In my own projects, I've started wrapping AI-assisted logic in checks that would have caught these failures early. Here's a simplified example of a guardrail I use when an assistant generates decision logic that affects people:

from collections import defaultdict

def selection_rates_by_group(records, group_key, outcome_key):
    """Compute the positive-outcome rate for each group."""
    totals = defaultdict(int)
    positives = defaultdict(int)
    for record in records:
        group = record[group_key]
        totals[group] += 1
        if record[outcome_key]:
            positives[group] += 1
    return {g: positives[g] / totals[g] for g in totals}

def check_disparity(rates, threshold=0.8):
    """Flag if the lowest selection rate is below 80% of the highest."""
    if not rates:
        return True
    highest = max(rates.values())
    lowest = min(rates.values())
    return highest == 0 or (lowest / highest) >= threshold

# Example usage
decisions = [
    {"group": "A", "advanced": True},
    {"group": "A", "advanced": True},
    {"group": "B", "advanced": True},
    {"group": "B", "advanced": False},
]
rates = selection_rates_by_group(decisions, "group", "advanced")
if not check_disparity(rates):
    raise RuntimeError(f"Disparity detected: {rates}")

This isn't a complete fairness audit, and a single ratio never tells the whole story. But it forces a conversation that would otherwise be skipped. The same principle applies to verifying factual outputs: write tests against known correct answers, especially for policies and numbers that customers rely on.

A Working Routine

If I had to summarize how I'm trying to strive through this period, it would look something like this:

• Experiment on real work, briefly. Try one tool or technique every couple of weeks and record the outcome.
• Keep the judgment human. Review generated code and content as if you're accountable for it, because you are.
• Build checks into the system. Tests, monitoring, and bias audits belong in the pipeline from the start.
• Think about the organization. Ask who inherits the changes and how they'll be supported.
• Be patient with the big payoff. Meaningful productivity gains tend to come after workflows are redesigned, not before.

The AI revolution isn't a wave that washes over us and leaves us either drowned or dry. It's closer to a long tide, one that keeps rising and asks us to keep adjusting our footing. Striving is simply the willingness to keep learning, verify what we build, and stay accountable for what it does. I'm still working at it, and I suspect most of us will be for a long time.