DR. ATABAK KH
Cloud Platform Modernization Architect specializing in transforming legacy systems into reliable, observable, and cost-efficient Cloud platforms.
Certified: Google Professional Cloud Architect, AWS Solutions Architect, MapR Cluster Administrator
Everyone is talking about AI. The real question is whether your team builds systems that last - or relies on a few heroes, knowledge nobody wrote down, and demos that fall apart in production.
Context: By spring 2026, boards were asking engineering leaders about headcount, coding assistants, and whether they were “AI-native”. Engineers worried about staying relevant. Both miss the real point: AI makes strong engineering stronger, and weak engineering easier to see.
Boilerplate and scaffolding. Explaining unfamiliar code. Drafting tests, docs, SQL, Terraform. Faster exploration and PoCs. Summarizing incidents and logs.
That compresses local task time - especially for people who already know what “good” looks like.
Accountability for production outcomes. Trade-off judgment under business constraints. Cross-team negotiation - contracts, priorities, decommissioning. Trust repair after an incident. Knowing what not to build. Operating messy legacy while migrating safely.
Orgs pay for judgment under uncertainty, not token output.
| Weakness | How it showed up |
|---|---|
| No data contracts | Every copilot rebuilds joins; answers disagree |
| No ownership | Agents query tables nobody maintains |
| No SLOs | “AI was wrong” with no freshness evidence |
| Hero culture | Copilot helps juniors; seniors still bottleneck |
| Demo-driven delivery | Impressive prototype, no production gate |
| Governance in slides | Agents with excessive access |
AI did not create these problems. It raised the price of ignoring them.
Quick “is this platform ready for a pilot?” score I used in conversations. Tick the row if it is true today:
| Gate | Ready? |
|---|---|
| Written data contracts on the tables the copilot will read | |
| Freshness SLAs, not only “the job is green” | |
| Named business and technical owners | |
| Kill switch / deterministic fallback | |
| Cost ceiling per task or per day | |
| Eval set with a baseline (time, errors, overrides) |
Score under 4 -> lab only. 4–5 -> bounded pilot. 6 -> discuss a production gate. Do not skip the empty rows because a demo looked good.
Serving layers and contracts - retrieval and features cheaper to consume. Runbooks and tests. Platform standards so suggestions match house patterns. Measurement culture - eval harnesses and cost per task. Distributed ownership - fewer “only Maria knows” bottlenecks.
Mature platforms turn AI into leverage. Immature ones turn it into noise at scale.
Stop asking only: how many engineers can we cut with AI?
Start asking: where does tacit knowledge block delivery? Which platform gaps make every AI project bespoke? What production gates do pilots skip? How do we measure value (time saved, errors, cost) - not demo applause? Which workflows should not be automated yet?
Headcount planning without platform maturity is guesswork.
I would not compete with the model on typing speed. What mattered more: system design and failure modes, data and domain understanding, production operation, clear writing and decision records, mentoring and review quality.
The engineer who only typed fast was already replaceable - by offshore, contractors, or templates. AI changes the margin, not the fundamentals.
| Invest | Why |
|---|---|
| Platform and data quality | Makes AI outputs trustworthy |
| Guardrails and governance | Makes automation survivable |
| Product thinking in platform teams | Connects tech to outcomes |
| Leadership paths for senior ICs | Keeps judgment without forcing management |
| Honest kill criteria for pilots | Stops zombie demos |
Cutting platform investment while buying AI tools is the expensive path.
AI will not replace engineers who build accountable, operable systems. It will expose teams that relied on heroics, ambiguous data, and demo culture. Treat it as a stress test of engineering maturity - and fix the platform and ownership problems it reveals.
This is a personal blog. The views, thoughts, and opinions expressed here are my own and do not represent, reflect, or constitute the views, policies, or positions of any employer, university, client, or organization I am associated with or have been associated with.