Let’s be honest: nobody gets into engineering and aspires to climb the career ladder - whether on the technical or managerial track—because they love meetings.
We get into software engineering because we enjoy solving problems. And we do that with code.
Of course, at some point - especially for EMs, Directors, and above - the problems become less technical and more strategic or people-oriented: how to lead the people who are solving technical problems.
Yet, as we progress in our careers, the time to do exactly that—solving problems through coding—seems to shrink year after year. Hard skills appear less required or less frequently applied (even though they remain the foundation of your work), while more and more soft skills are demanded. And we need those soft skills to navigate meetings.
Meetings for technical alignment, meetings for requirement specification, meetings for stakeholder management, meetings for architecture design and reviews, and so on.
Calendars fill up. Context switching becomes the norm. And quickly, you find yourself opening your IDE less and less—and when you do, it’s mostly to review other people’s code or to create documentation and diagrams.
At some point, you might start asking yourself:
when was the last time I actually built something end-to-end?
This is one of the hardest truths of stepping up: Code becomes less important.
The expectation changes. You’re no longer measured by how much code you write, but by:
- how you connect teams and domains
- how you communicate with stakeholders
- how you share knowledge
- how you set direction and standards
- how you amplify impact across the organization
And at that point, it becomes clear that it was never really about the code itself.
It was about the problems you solved with it.
Quote from this interesting episod of the Tech Lead Journal
At senior levels, you still solve highly technical problems - but differently:
You design systems, review architectures, reason about trade-offs, write RFCs and ADRs, guide others, and try to make decisions that will age well. For EMs especially, the focus shifts further toward delivery, team dynamics, and creating the conditions for teams to succeed.
Among all this "talking about work", the technical part often feels squeezed into the margins. So the question becomes: when do we actually “do the work”?
Why I Became Obsessed with Productivity and Simplicity
I have a confession to make: I am kind of lazy.
Not the type of laziness that makes me lie on the couch all day or shy away from responsibility and hard work. It’s a very specific kind of laziness. Especially when I don’t like doing something, I try to become so good and so fast at it that I can get it over with and move on as quickly as possible.
I never really loved coding for its own sake. I never found deep joy in typing brackets, semicolons, or chasing syntax errors. What I really hated were the headaches: trying to get a legacy project up and running, digging through outdated docs, obscure comments, convoluted logic, and unclear or inconsistent naming conventions.
I hate avoidable complexity and cognitive overload. I hate doing the same task over and over again.
Over time, that turned into an obsession with simplicity, quality, and productivity - not because I want to work less, but because I want to solve problems once and solve them well. And because I want to use my skills and brainpower for more important things.
That mindset is exactly why I’m very open — almost eager — to experiment with AI.
I didn’t jump blindly on the AI bandwagon. The hype does not carry me away, and I remain skeptical and cautious in many circumstances.
But the potential to reduce the tedious, boring, error-prone work that consumes so much of our time is undeniable. And that’s not all.
I genuinely believe AI can help all engineers:
- Juniors, by providing structure and feedback
- ICs, by accelerating implementation and iteration
- Staff+ engineers and EMs, by reducing coordination and documentation overhead
Different stages, different leverage points.
For me, the real promise of AI isn’t “write more code faster.”
It’s enabling an AI-native SDLC that helps us think better, decide faster, and capture knowledge more effectively.
AI as a Multiplier of the SDLC
The Software Development Life Cycle (SDLC) has 6 core stages.
1️⃣ Requirement Analysis
Goal: Understand what needs to be built and why.
Activities: Gather business and technical requirements, define user stories or use cases, identify constraints and success criteria.
Output: Approved requirement specification or backlog.
2️⃣ System Design
Goal: Define how the system will meet the requirements.
Activities: Architecture decisions (e.g., microservices, cloud topology), data modeling, API/interface definitions, security and scalability considerations.
Output: Design documents, architecture diagrams, and tech stack choices.
3️⃣ Implementation (Development)
Goal: Build the product according to the design.
Activities: Code development, unit testing, version control, continuous integration, peer review.
Output: Source code with passing unit tests; deployable build artifacts.
4️⃣ Testing
Goal: Validate that the system behaves as expected and meets acceptance criteria.
Activities: Integration, regression, performance, and user acceptance testing (automated and manual).
Output: Quality‑assured release candidate.
5️⃣ Deployment
Goal: Deliver the working system into its target environment (staging → production).
Activities: Infrastructure provisioning, configuration, CI/CD pipelines, rollback strategy, deployment validation.
Output: Production system live and monitored.
6️⃣ Maintenance & Operations
Goal: Keep the system stable, secure, and evolving.
Activities: Monitoring, incident response, patching, scaling, feature enhancements, collecting feedback for the next iteration.
Output: Updated, reliable system with continuous improvement loop.
Each stage has specific activities and produces concrete artifacts. While often presented as a linear sequence, in reality these stages overlap, interleave, and repeat across multiple iterations.
Recently, there’s been a lot of discussion about how AI can boost the SDLC — both by improving individual stages and by fundamentally reshaping the lifecycle itself. This is where the idea of an AI-Driven Development Life Cycle (AI-DLC) comes in.
The AI-DLC is often simplified into three macro phases:
- Inception: What are we building, and why?
- Construction: How are we building it?
- Operation: How do we ship and run it safely?
At each stage, the cycle repeats: plan, clarify, execute, approve.
The partnership between humans and AI is strong - and necessary -with humans remaining the input source and control gate.
Regardless of how your current development lifecycle looks, the key question isn’t the exact model. What really matters is how we leverage AI to do more, faster, and better - depending on seniority and on the level of zoom (a single feature, a bug fix, or a long-term product roadmap).
While ICs tend to focus heavily on implementation, testing, and maintenance, Staff+ engineers and EMs have much higher stakes in:
- understanding the problem correctly
- designing the right architecture
- making and documenting good decisions
- sharing knowledge clearly and consistently
And this is where AI can have a disproportionate impact.
AI can help:
- structure vague or incomplete problem statements
- explore architectural alternatives quickly
- surface trade-offs and challenge assumptions
- draft RFCs, ADRs, and best practices while context is still fresh
- keep documentation and diagrams up to date
- support learning when tackling unfamiliar (but not necessarily “new”) problems
Yes, AI can hallucinate. Yes, it needs steering. And yes, judgment still matters. But used critically, it dramatically speeds up learning, reduces friction, and lowers the cost of doing the right thing.
From "No time to Code" to "AI-DLC"
Although week after week I find myself further away from hands-on coding, I still love technical challenges. And it’s still my responsibility to steer my team toward building a high-quality platform for our engineering organization—meaning scalable and reliable cloud architectures, useful and easy-to-use modules, and clear documentation, best practices, and guidelines that empower engineers.
Between roadmap alignment meetings, 1:1s, hiring, agile rituals, and incident response, I’m left with very little time to support my team technically or review code and documentation.
So when an opportunity recently arose for my team to support our Data team in building and deploying a prototype MCP server integrating our API, I jumped on it. It was the perfect chance to start experimenting with an AI-native SDLC / AI-DLC while:
- staying technically sharp despite a packed calendar
- validating ideas through prototypes, not just discussions
- reducing overhead around documentation and alignment
This series documents that journey — not as a polished playbook, but as learning in public.
In the next posts, I will start showing you how I set up my AWS Kiro IDE, how a AI-native SDLC actually looks like day-to-day, and how I began applying it in a real proof of concept.
More to come.
Useful Resources:
- AI-Driven Development Life Cycle: Reimagining Software Engineering
- SDLC Who? Meet AI-DLC: The New Build Loop
- AI-DLC (AI-Driven Development Life Cycle)
- Transforming the Software Development Lifecycle (SDLC) with Generative AI
Other articles you might be interested in:
- Strive for simplicity
- The screw and the hammer: Love the problems, not your solutions
- Learn how to ask good questions. Be aware of the XY Problem.
Header Picture: Me at AWS Community Day Rome 2024
Top comments (0)