By Mark The rapid collapse of job boundaries is easily one of the most frustrating shifts happening across engineering teams today. As automation pipelines and modern tools become standard, organizations are pushing past initial adoption issues and running straight into role confusion. Management claims that “anyone can code now,” using that line to demand unrealistic, bloated skill sets while ignoring the depth required for specialized engineering work. The result is obvious: team members lose their technical identity, and systems suffer from constant operational fatigue.
A few days ago, I looked at a job posting from our neighboring Database Administrator (DBA) team and couldn’t help but laugh. Right at the top of the requirements list, it stated:
Required: Hands-on backend application development experience in Python or Go, ability to build CI/CD pipelines, and experience with IaC tools.
They were asking a DBA—someone whose core job is tuning transaction isolation levels, preventing table lock contention, and planning disaster recovery scenarios—to code like a full-stack backend engineer. As it turns out, that team has failed to hire a single person for the past six months. The remaining staff are burnt out just trying to keep up with night on-call shifts.
How did we get here? Driven by delivery speed and the assumption that tooling solves everything, leadership and product teams started demanding that operational engineers write software. Because of this, experienced operational specialists are quitting, and underlying system stability is taking a direct hit.
This isn’t just happening to DBAs. As a security engineer, my own weekly tasks regularly cross over into data engineering, data science, and AI infrastructure. While broadening personal skills can be useful for an individual, forcing it across an entire organization inflates job descriptions and erases domain expertise. Here is a practical look at why this happens and what it costs an engineering team.
A Series on Interesting Phenomena Emerging in the AI Era
Stage 1. Early Adoption (Ignorance, Blind Faith & Misuse)
- Ep. 1 | Leaks & Costs: AI Turned into a PII Classifier — Reckless data ingestion and the reality of runaway token bills
- Ep. 2 | Distrust: When “AI Says So” Trumps Decades of Senior Expertise — Hallucinated answers replacing seasoned engineering judgment
Stage 2. Diffusion (Role Collapse & Contribution Conflicts)
- Ep. 3 | Delusion: The Manager’s Vibe-Coding Fantasy — Underestimating engineering complexity by thinking anyone can build production software
- Ep. 4 | Chaos: Why Coding Requirements Infiltrated DBA Job Postings — The role-inflation trap driven by the “everyone must code” hype
- Ep. 5 | Dismissal: “AI Wrote It, So What Did You Actually Do?” — Distorted performance reviews that erase architecture and debugging efforts
Stage 3. Endgame (Debt Explosion & Loss of Control)
- Ep. 6 | Technical Debt: Product Managers Writing Code and the Compounding Interest — Prototype-level spaghetti code boomeranging into unmaintainable systems
- Ep. 7 | Complacency: “Vulnerabilities? We’ll Just Have AI Swap the Library” — Ignoring dependency graphs and architectural blast radiuses until a security breach hits
- Ep. 8 | Betrayal: This Isn’t the Deterministic System You Thought It Was — Non-deterministic behavior, context drift, and total systemic collapse
Table of Contents
The Push for Automation: When Job Boundaries Start to Blur
As teams moved toward cloud-native setups and GitOps-style deployment, development teams gained significant leverage over operations. The growing narrative that new tools remove the difficulty of writing code only made things worse.
The Problem with “Database Changes as Code”
It started with a push to modernize database change management. From a software engineer’s point of view, pushing application code triggers a pipeline, builds a container, and deploys it to a cluster without manual intervention. Database schema updates (DDL) and data patches (DML), on the other hand, still felt slow and manual.
- What developers asked for: “Integrate tools like Liquibase or Flyway into our delivery pipeline, and have the DBAs build an internal orchestration service so schema changes run automatically through CI/CD.”
- What management thought: “With all these modern tools available, our DBAs should just build an internal self-service portal in Python or Go to improve deployment velocity.”
The goal sounds fine on the surface. Automating database deployments seems like good engineering. But underneath that request was a complete lack of understanding regarding the operational risks of stateful systems.
Architectural Conflict: Zero-Downtime Pipelines vs. Database Locks
Stateless application containers are simple: if one crashes, you spin up another; if a rollout fails, you roll it back. Databases do not work that way. They hold state, and managing state carries real physical constraints.
1. The Risk of Metadata Locks (MDL)
When an experienced DBA reviews a schema migration, they look well beyond SQL syntax:
- They calculate the disk I/O impact of building an index on a partitioned table with hundreds of millions of rows.
- They check connection pool health to ensure an
ALTER TABLEoperation’s metadata lock won’t conflict with long-running transactions and pile up incoming queries in an execution queue. - When necessary, they run online migration tools like
pt-online-schema-changeorgh-ost, monitoring replication lag manually during off-peak hours.
2. When Automated Pipelines Trigger Production Outages
The automated workflow pushed by management replaced this calculated verification with simple script execution.
[ What Teams Expected from an Automated Pipeline ]
Create PR (DDL Script)
→ Pass CI Linting
→ Click Approve
→ Pipeline Runs Script Directly Against Production DB
The outcome was predictable. Automated checks verify whether SQL syntax is correct, but they have no awareness of buffer pool hit ratios or replication lag on read replicas.
A pull request merged right before peak traffic triggered an exclusive table lock. Database connections filled up almost immediately, taking down customer-facing services. During the post-mortem, developers pointed to the pipeline, saying the script passed without errors. All the blame landed directly on the DBA team.
Development Pressure and Team Turnover
Management’s response after the outage missed the point. Instead of fixing the operational process, they told the DBAs: “The pipeline failed because it lacked error handling. Your team needs to build a custom backend service that runs pre-flight health checks and handles automated rollbacks.”
Losing Technical Focus
On top of monitoring query performance, tuning storage engines, and verifying backup integrity, DBAs were suddenly expected to act like full-stack developers:
- Build internal approval workflows using frameworks like Spring Boot or FastAPI.
- Write Slack bots driven by webhooks.
- Implement custom UI dashboards for self-service requests.
The DBAs burned out quickly. Years of deep knowledge about database internals were dismissed as outdated because they didn’t write web services. Instead of monitoring production databases, they spent their days debugging Docker build errors and Python syntax issues.
The senior DBAs left the company one after another. With them went the regular operational maintenance that keeps databases running: managing index fragmentation, tuning slow queries, and validating point-in-time recovery plans.
Six Months with an Open Role: The Cost of Inflated Job Descriptions
With key personnel gone, the company posted a job listing. But the requirements only repeated the same mistake.
[ The Unrealistic DBA Job Spec ]
* Responsibilities:
- Design and optimize production RDBMS/NoSQL databases at scale.
- Build and maintain automated database deployment pipelines.
- Develop backend APIs for internal self-service portals (Python/Go).
* Requirements:
- 5+ years of DBA experience in high-traffic production environments.
- Hands-on experience with backend web development and microservices.
- Direct experience building CI/CD pipelines (GitLab, ArgoCD, etc.).
Looking for Skills That Rarely Overlap
This role has sat empty for six months for practical reasons:
- Conflicting Specializations: An engineer who spent a decade mastering storage engines, memory pools, and lock behavior rarely spends their time building web applications. Conversely, backend engineers who write Go or Python services daily rarely want to spend their time debugging database storage engines.
- Unrealistic Pay Bands: An engineer who truly excels at both database internals and full-stack software development is exceptionally rare and demands compensation far beyond standard senior DBA rates. The company wanted two distinct engineering roles for the price of one.
- The Trap of Expecting Everything: Believing that modern tooling allows everyone to write software has inflated hiring profiles. Candidates simply skip the posting because the requirements make no sense, leaving existing systems unmanaged.
When Everyone Is Expected to Code: A Security Engineer’s Reality
This loss of boundary lines is something I deal with directly.
My official title is security engineer, but looking at my daily tasks, the work stretches across multiple fields:
- I build data pipelines using Kafka and Spark to process system logs for anomaly detection—work typically done by a data engineer.
- I clean datasets, engineer features, and run machine learning scripts using Pandas—work typically done by a data scientist.
- I evaluate and deploy vector databases and embedding models to test internal retrieval systems for vulnerabilities—work typically done by an AI engineer.
Practical Utility vs. Shallow Knowledge
Being able to work across domains has its advantages. Modern tools make it much faster to draft boilerplate code or set up infrastructure configurations outside your main discipline. I use these tools regularly to speed up my work.
However, when an organization assumes this broad surface coverage should be the standard expectation for every role, major issues follow:
- Loss of Depth: Doing a bit of everything leaves no time to understand what happens at the kernel or storage layer when systems hit critical scale.
- Burnout: Trying to handle core security, regulatory compliance, data pipeline throughput, and model serving limits all at once simply wears engineers out.
- Zero Accountability: When everyone writes a bit of the pipeline, no one actually owns the outcome when data corrupts or an outage occurs.
Fixing the Problem: Returning to Clear Responsibilities
Engineering teams need to stop chasing the idea that every single employee must be a software developer. To maintain stable systems, companies have to reset realistic role boundaries.
[ A Practical Team Structure ]
+-------------------------------------------------------------+
| Platform Engineering |
| Builds CI/CD setups, common tools, and deployment systems |
+-------------------------------------------------------------+
│ Provides tooling
┌───────────────────────┴───────────────────────┐
▼ ▼
+-------------------------------+ +-------------------------------+
| Domain: DBA | | Domain: Security |
| - Transaction integrity | | - Threat modeling |
| - Engine performance & tuning | | - Audits & access control |
| - Backup and disaster recovery| | - Vulnerability handling |
+-------------------------------+ +-------------------------------+
1. Separate Domain Knowledge from Tool Development
Instead of asking DBAs to build internal web services, platform teams should build the deployment scaffolding while allowing DBAs to supply the verification rules. DBAs should focus on data integrity and recovery plans, working with developers rather than replacing them.
2. Clean Up Job Postings
Companies need to drop the laundry list of trendy tools from job descriptions. Decide what the role actually needs: do you need someone to keep a production database alive, or do you need someone to build developer tools? Trying to hire a single person to cover both usually means hiring no one.
3. A Realistic View of Generalists
A practical engineer is not someone who can build any system from scratch. They have deep expertise in one specific area and enough broad knowledge to coordinate with adjacent teams. Tooling should make cross-team coordination easier, not serve as an excuse to eliminate dedicated operational roles.
The evolution of software engineering has always been about making complex systems easier to run. But right now, teams are using modern tools as an excuse to dump unrelated responsibilities onto individual engineers.
Demanding full-scale programming skills in a DBA job posting and leaving that position empty for six months isn’t innovation—it’s an operational failure. If organizations keep pretending that deep specialization no longer matters, they will end up with fragile systems that no one on the team truly knows how to fix.