AI Is an Amplifier, Not a Substitute for Engineering Judgment
Whenever AI comes up in leadership conversations, the same question arrives almost immediately: is this going to replace engineers? I understand why people ask it. It is the fastest path to anxiety and the easiest headline to repeat. But it is still the wrong frame for most engineering organizations today. The more useful question is where AI actually improves the operating model right now, and what kind of team behavior makes that improvement real.
That was the point I tried to make during the Evolution Exchange Australia panel. I do not see AI as a substitute for engineering judgment. I see it as an amplifier. It helps with the repetitive work engineers delay, the first drafts that usually take too long to start, and the supporting tasks that matter operationally but often lose to feature delivery. When teams use it well, AI lifts the floor on execution and gives experienced engineers more room to spend time where humans still matter most: judgment, tradeoffs, communication, and accountability.
Documentation, summaries, scaffolding, planning breakdowns, and repetitive support work.
Context, review quality, product judgment, technical tradeoffs, and ownership.
Capability uplift, throughput quality, reduced friction, and repeatable team usage.
Treating license counts as adoption, or treating every efficiency gain as a headcount story.
"I see AI as augmentation, not replacement." That was my position in the panel, and it is still the most practical way to think about adoption today.
1. The replacement debate skips the part leaders can actually control
Most leaders cannot control what the market will look like five years from now, but they can control how their teams adopt new capability today. That is why I think replacement debates are often distracting. They push the conversation into speculation instead of execution. By the time a team has spent thirty minutes debating whether AI will eventually automate an entire role, it still has not answered the immediate questions that actually matter: where do we want to use it, what standards apply, how do we review the output, and what outcomes are we trying to improve?
I prefer to pull the conversation back to operating reality. In most engineering environments, AI is not replacing the work that defines the role. It is changing the speed, quality, and cost of the work that surrounds the role. That includes implementation drafts, decision summaries, design alternatives, documentation, post-incident synthesis, testing scaffolds, and countless small tasks that consume attention but do not deserve to own it. Once you frame AI that way, the discussion becomes more useful. You are no longer asking whether engineers are still needed. You are asking how to reduce friction without lowering standards.
That distinction matters because fear changes behavior. If a team believes AI is mostly a threat narrative, people will either resist it openly or use it quietly without consistent review. Both outcomes are bad. Resistance blocks learning. Secret usage blocks guardrails. Leaders need a third path: normalize practical adoption, make review expectations explicit, and communicate that capability expansion is the main goal.
2. The first wins show up in work engineers already avoid
The easiest way to see where AI is useful is to look at work that engineers know is important but still postpone. I mentioned in the panel that I genuinely do not remember how I used to write long executive summaries or break down plans the same way two years ago. That was not an exaggeration. Those tasks still matter. They influence prioritization, stakeholder alignment, and decision quality. But they were also the kind of work people delayed because the cost of producing a clean first draft was high.
AI changes that cost structure. Instead of starting from a blank page, I can start from a rough but useful draft. Instead of spending the first thirty minutes structuring a summary, I can spend that time refining the parts that need judgment. The same pattern applies to engineering tasks. Runbooks, implementation checklists, architecture option comparisons, migration plans, release notes, onboarding guides, test outlines, and even customer-facing explanation drafts all benefit from this shift. AI does not remove the need for review. It removes the pain of initiation.
Where I see immediate value
- Drafting summaries from long technical or stakeholder conversations.
- Turning a rough idea into a structured implementation plan.
- Producing first-pass documentation that an engineer can then sharpen quickly.
- Generating comparison frameworks for design options before the team discusses tradeoffs.
- Reducing the overhead of repetitive writing that blocks higher-value technical work.
This is why I describe AI as a productivity lift that improves the overall working experience. It lets teams stop dodging the black-and-white work that makes engineering organizations legible and scalable. That matters more than people admit. A lot of engineering drag comes from knowing what should be documented, clarified, or summarized and still not getting around to it.
3. Adoption is a capability curve, not a procurement event
One of the clearest signals from our own experience was that adoption got more useful as people learned how to use the tools. During the panel I spoke about our early GitHub Copilot rollout at Pickles. In the first few months, accepted suggestions were around five to six percent. Later, that figure moved closer to forty percent. That number matters less as a vanity metric and more as a signal of behavior change. Engineers were not simply given a tool. They became more fluent in how to work with it.
That fluency is what many organizations miss. They buy licenses and assume value will emerge automatically. It does not. Teams need examples, patterns, prompt discipline, and shared language about where AI helps and where it does not. The same engineer can have two completely different outcomes from the same tool depending on how much context they provide, how clearly they define the task, and how rigorously they review what comes back. In other words, AI adoption behaves more like skill acquisition than software rollout.
| Signal | What it means | What I would do |
|---|---|---|
| High license count, low usage quality | Access exists, but capability does not. | Teach concrete use cases and create team examples. |
| High usage, weak review | Speed is rising faster than judgment. | Reinforce code review, documentation review, and validation rules. |
| Rising accepted output over time | The team is learning how to collaborate with the tool. | Capture working patterns and turn them into playbooks. |
That is the leadership job here. Do not just enable the tool. Teach the operating model around the tool.
4. Augmentation remains the right frame because roles are bigger than tasks
I do not deny that AI will automate more work over time. It already is. But there is a difference between automating tasks and replacing roles. Most real roles are bundles of responsibilities, not isolated functions. A software engineer is not just a code producer. A platform engineer is not just a configuration executor. A manager is not just a summary writer. The role includes context gathering, tradeoff analysis, communication, escalation judgment, prioritization, and accountability when something goes wrong.
That is why I still believe repetitive tasks will compress long before entire roles disappear. The work most exposed right now is manual, redundant, and straightforward. The work that remains stubbornly human is the work with ambiguity, messy context, political tradeoffs, or emotional consequence. Even when AI can generate impressive output, someone still has to decide whether the output is correct, appropriate, safe, and aligned with the actual goal.
| AI handles well first | People still need to own |
|---|---|
| Drafts, summaries, repetitive pattern generation | Judgment, approval, accountability, and risk decisions |
| Initial scaffolding and option framing | Tradeoffs across business, security, and architecture context |
| Administrative acceleration | Team leadership, empathy, coaching, and trust-building |
This is also why the headcount conversation becomes so dangerous so quickly. If leaders talk about AI only as labor substitution, they train people to protect information and avoid experimentation. If they talk about it as capability amplification, they make it safer to learn, safer to share working practices, and easier to improve the team rather than just the budget line.
5. AI readiness is broader than tooling
Another point I made in the panel was that organizations have to become AI ready whether they are enthusiastic about every internal use case or not. AI is here. It is already shaping the products teams buy, the vendors they integrate with, the interfaces customers expect, and the ways operational knowledge gets consumed. That means readiness is not only about whether your engineers use generative assistants. It is also about whether your systems, data boundaries, and workflows can safely interact with AI-enabled services.
At Pickles, AI was not a brand new idea in the broad sense. We had already been doing machine-assisted valuation work for years based on internal models, sales history, market history, and domain-specific data. What changed with the current wave was the reach of general models. Suddenly AI could support not only pricing and pattern recognition but also writing, planning, support, search, and interaction design. That is a different category of impact. It touches how teams think, not just what they calculate.
Readiness therefore means more than buying a tool. It means understanding data boundaries, review obligations, integration pathways, policy expectations, and where automation helps or hurts. It also means accepting that external ecosystems will become more AI native whether your internal roadmap moves fast or slow. Companies that delay all readiness work until the use cases are perfectly obvious are choosing to fall behind on purpose.
6. What I would ask engineering leaders to do now
If I had to reduce all of this to a practical leadership checklist, it would look like this:
- Start with high-friction workflows. Pick the work teams repeatedly postpone but still need to do well.
- Teach usage patterns, not just access. Share prompts, examples, review methods, and failure cases.
- Keep the review bar intact. AI output is still draft output until someone validates it.
- Measure behavior and outcomes. Look for better quality, faster turnaround, clearer documentation, and more consistent execution.
- Make the message capability-first. If the culture only hears replacement, the learning curve will stall.
I also think leaders should be explicit that not every use case deserves AI. Some work is faster without it. Some work is too sensitive. Some work still benefits more from direct human discussion. Maturity is not using AI everywhere. Maturity is knowing where it genuinely improves the system and where it does not.
Closing thought
The teams that get the most from AI will not be the ones chasing the loudest tools or making the biggest claims. They will be the ones that use AI to strengthen discipline, improve the quality of routine work, and give people more room to do the parts of engineering that still depend on judgment. That is why I still use the amplifier metaphor. It is grounded, operational, and honest about where the value is today.