After 20 Years in Technology, AI Changed How I Work - Part 2

Three weeks of AI-integrated work taught me more about the future of technology work than 20 years of experience. This isn’t about tools—it’s about a fundamental shift in how ALL work gets done.

---

A few weeks ago, I wrote about AI being genuinely different after 20 years in technology—the organizational challenges, the security implications, the honest uncertainties.

I was writing from experimentation and curiosity. I’d seen enough to know AI wasn’t hype, but I was still testing, still exploring, still skeptical about the real-world impact.

Three weeks later, something fundamental shifted.

Now I’m writing from the other side of something I can only describe as a fundamental shift in how I work.

In the last few weeks, I’ve built more than I built in the previous six months. Not because I’m working longer hours or cutting corners. Because I’m working differently.

Projects that sat on my “someday” list for years are done. Automation I thought would take weeks took hours. Tools I’d mentally shelved as “not worth the time investment” exist now and are running in production.

This isn’t about specific tools. Tools will change. New ones will emerge. Better ones will replace what I’m using today.

This is about the workflow pattern I discovered that I believe represents the future of technical work.

Let me show you what changed.

---

The Three-Week Transformation

Week 1: Integration

I spent the first week building what I now think of as an “AI-integrated work environment”—not just for coding, but for everything. Strategic thinking. Technical execution. Content creation. Problem exploration. Planning. Analysis.

The setup was tedious. Lots of experimentation. Lots of “does this actually work?” testing across different domains.

I wasn’t sure it would be worth it. Spoiler: it was.

Week 2: The Breakthrough

Somewhere in week two, something clicked.

The breakthrough wasn’t about one type of work. It was about how AI integrated into my entire workflow—not just writing code, but thinking through problems, exploring solutions, creating content, planning architecture, analyzing tradeoffs.

I started completing work that had been shelved for months or years. Technical projects. Strategic analysis. Documentation. Content. Things that would have taken weeks happened in hours.

That’s when I realized: This isn’t about AI making me faster at specific tasks. This is about AI as an integrated assistant across everything I do.

Week 3: The New Normal

By week three, I’d shifted into what I now think of as the new way of working.

My backlog started shrinking across all categories. Technical work. Strategic planning. Content creation. Analysis. Documentation. The “nice to have” items that never quite justified the time investment.

They were all suddenly worth doing. Not because I lowered my standards—because the time-to-value ratio changed fundamentally.

---

The Four Workflow Shifts

Let me be specific about what actually changed. These aren’t incremental improvements. These are fundamental shifts in how technical work gets done.

Shift 1: From Sequential to Parallel

The old workflow:

Think → Research → Build → Test → Document → Review → Deploy

Everything sequential. One step at a time. Each step blocking the next. My time was the bottleneck for everything.

The new workflow:

Think → [Multiple parallel streams] → Orchestrate → Integrate → Review

Now multiple things happen simultaneously. While AI is generating one component, it’s also writing tests for another, documenting a third, and researching implementation patterns for a fourth.

My role shifted from executor to orchestrator.

It’s not about any one task moving faster. My job now is to orchestrate parallel streams of work and integrate the results into something coherent.

That’s a fundamentally different job.

Shift 2: From Context-Free to Context-Aware

This is the breakthrough most people miss.

Before: Every interaction with AI started from scratch. “Here’s my generic problem, give me a generic solution.”

After: AI has context about my actual systems. My infrastructure. My data sources. My patterns. My constraints.

When I ask it to connect the dots across systems—operational metrics, upcoming releases, policy constraints—it doesn’t respond with a generic tutorial. It understands the landscape I’m working in, pulls the signals that matter, and surfaces insights that would have taken days of manual context gathering.

The difference isn’t speed. It’s relevance and depth.

Instead of spending hours adapting generic examples to my specific environment, AI generates solutions that fit my environment from the start.

Context-aware AI doesn’t just help me code. It helps me think through problems in the context of my actual systems.

This isn’t prompt engineering—it’s context engineering. It’s the deliberate work of designing the systems, guardrails, and data pathways that give AI relevant situational awareness across every part of my job, not just in an IDE.

That’s the shift that makes everything else possible.

But context-awareness introduces security risk.

This is where most organizations make their biggest mistakes.

When AI has access to your systems—through APIs, monitoring data, infrastructure context—you’re exposing potentially sensitive information. System architectures. Data patterns. Security configurations.

The security model shifts from “AI doesn’t know anything” to “AI knows what I explicitly allow it to know.”

What this means in practice:

• API access requires authentication controls - Not all AI services should access all systems
• Context data needs filtering - Don’t feed AI sensitive credentials, customer data, or proprietary algorithms
• Audit logs matter - Track what context AI accesses and when
• Organizational policies are essential - Clear rules about what context AI can access

The more context-aware your AI workflow becomes, the more critical your security boundaries are.

I manage this tension daily as Security Officer: context-awareness is transformative, but it’s not a free pass to bypass security controls.

Shift 3: From Building to Reviewing

Twenty years in technology, my primary role has been builder.

In the last three weeks, my primary role became architect and reviewer.

The old workflow:

• Me: Build the thing (80% of time)
• Me: Review the thing (20% of time)

The new workflow:

• Me: Design and architect (30% of time)
• AI: Build the mechanical parts (happens in parallel)
• Me: Review, integrate, refine (70% of time)

This isn’t about AI “taking my job.” It’s about AI handling the parts I’m overqualified for anyway.

I don’t need 20 years of experience to write boilerplate error handling. I do need 20 years of experience to know what error conditions matter, how they should be handled in the broader system, and what the architectural implications are.

AI is really good at the first part. I’m still essential for the second part.

The shift is: I now spend most of my time on the parts that actually require experience and judgment.

That’s appropriate. That’s where my value is.

Shift 4: From “Worth It” to “Done”

This is the shift that’s changing my backlog math.

The old calculation:

• Project value: Medium
• Time required: 40 hours
• Decision: Not worth it right now, backlog it
• Result: Never gets built

The new calculation:

• Project value: Medium (same value)
• Time required: 4 hours (AI-assisted)
• Decision: Worth doing this week
• Result: Built, tested, deployed

The threshold for “worth doing” dropped dramatically. When context engineering cuts the time-to-value across everything, the backlog math flips—“maybe someday” becomes “worth doing now.”

Projects that would never have justified three weeks of my time suddenly justify four hours. That’s not a 10x productivity increase. That’s a fundamental change in what problems are worth solving.

My backlog isn’t getting reprioritized. It’s getting completed.

---

The Uncomfortable Productivity Math

I know how this sounds. “Weeks to hours” is the kind of claim that makes people roll their eyes.

But here’s why it’s real:

A typical project breaks down roughly like this:

• 40% Strategic work (architecture, design, integration, judgment)
• 60% Mechanical work (boilerplate, standard patterns, documentation)

Before AI: I did all 100% myself. Time: 40 hours.

With AI: I do the 40% strategic. AI does the 60% mechanical in parallel.

My time: ~16 hours. Total elapsed: ~8-10 hours (with iteration).

That’s 4-5x faster. Sometimes 10x on boilerplate-heavy work.

But here’s what matters: I don’t need 20 years of experience to write standard patterns. I need it to know which patterns to use, how they integrate, and what the trade-offs are.

That’s where AI can’t help. That’s where experience matters.

---

The Leadership Implications

For Knowledge Workers

Your role is shifting from executor to strategist/orchestrator.

If your value is “I execute tasks,” you’re replaceable. If it’s “I think strategically, make judgment calls, and integrate complex work,” you’re more valuable than ever.

For Technology Leaders

Traditional productivity metrics are breaking. Output volume? Task completion? Velocity? All measuring the wrong thing.

The better question: “What problems did we solve that weren’t worth solving before?”

When your team can produce 5-10x more with the same headcount, the hard part isn’t execution—it’s knowing what’s worth doing.

For Organizations

The bottleneck shifts from execution capacity to strategic direction.

When you can do 10x more, strategy matters more than ever.

---

What’s Not Solved (The Honest Limitations)

Let me be clear about what AI-integrated workflows do NOT solve:

What’s Working

• Mechanical execution (research, drafting, standard patterns)
• Exploration and iteration
• Documentation and synthesis
• Analysis of known patterns
• Parallel workstreams

What’s NOT Working Yet

Strategic decisions: AI can’t tell you what to do. It can help you execute faster once you know what you want.

Complex integration: AI struggles with integration across multiple complex domains with implicit dependencies and organizational context.

Trade-off judgment: AI can present options, but you still need experience to evaluate trade-offs in the context of your specific constraints.

Organizational context: AI doesn’t understand your team dynamics, your company’s risk tolerance, your customers’ unspoken needs, your political landscape.

What’s Still Hard

• Knowing what problems are worth solving
• Understanding system-wide and organizational implications
• Making decisions with long-term consequences
• Integrating across organizational boundaries
• Managing technical and organizational complexity simultaneously
• True strategic thinking and vision

The point: AI augments judgment, it doesn’t replace it.

The workflow shift makes experienced professionals MORE valuable, not less—because the parts that require experience are now the majority of the work.

---

What’s Next

Three weeks ago, I thought I understood AI’s impact. I was wrong.

This isn’t about tools getting incrementally better. It’s about a fundamentally different way of working.

Am I 10x more productive? Wrong metric. The right questions:

• What’s now worth doing that wasn’t before?
• What quality improvements can I now afford?
• What problems can I solve that I was ignoring?

For me: Almost everything on my backlog. More thorough work. All the strategic projects I’d been deferring.

That’s not a productivity increase. That’s a fundamental shift in what’s possible.

Is this the workflow of the future? Maybe. Or maybe in another three weeks I’ll discover something even better.

But right now, after 20 years in technology, this is the biggest shift in how I work that I’ve ever experienced.

The backlog is shrinking. Excellence is scaling. The “not worth the time” work is getting done.

And the best part? I’m spending more time on strategy, judgment, and integration—the parts that actually require 20 years of experience.

That’s the workflow of the future: AI handling mechanical parts so humans can focus on expertise.

We’re still early. But the direction is clear.

And if you’re an experienced professional, this shift makes you more valuable—not less.

Call it context engineering if you want. The industry is starting to formalize it with standards like MCP, but the pattern is the same: treat context like infrastructure, keep the guardrails tight, and the tools can change without breaking the workflow.

---

Connect

I’m documenting this journey in real-time. If you’re exploring similar patterns or have discovered different approaches, I’d love to hear about it.

All code from my experiments is publicly available. Use it, adapt it, improve it.

---

Mike Falkenberg is a technology leader with 20+ years of experience building scalable systems and leading engineering teams. He shares practical insights on infrastructure, security, and organizational transformation.