There’s a situation I keep encountering.
Back to a time when I just joined a feature team, brought in to help move things forward after they hit a wall. We sat down to discuss the system. I asked: “What does the system do?” I got the answer with how it was implemented, the classes, the services, the data flow through the code. I asked again, same answer, different details. Again, still implementation.
We were both frustrated. They had deep knowledge of the system and couldn’t understand why I wasn’t getting it. I needed to understand the behavior before I could reason about the code, and I couldn’t make them see why that distinction mattered. The discussion went in circles. Nothing moved.
As a new member of the team, I felt like I had walked up to an ATM and asked “What can I do here?” and someone had opened the backend instead.
When we walk up to an ATM, we see a screen. It tells us what we can do: check our balance, withdraw cash, transfer funds. We don’t see the authentication services, the ledger updates, the fraud detection algorithms running behind it. We don’t need to. The screen is the contract between us and the system: what goes in, what comes out.
The contract has a name in software: the interface. And behind every interface is an implementation: the backend, the wiring, the mechanics that make the contract work.
Both layers are real. Both matter. But they answer different questions:
In that meeting room, my teammates were fluent in the backend. They knew every service, every API call, every edge case in the data flow. But when I asked “what does the system do?”, I was asking for the ATM screen, and they kept showing me the backend.
Neither of us was wrong. We were just answering at different layers. And until we found a shared layer to stand on, the conversation couldn’t move.
It’s not a flaw. It’s a reflex.
Engineers spend most of their time in the backend: reading code, debugging services, tracing data flows. That’s where the work lives. That’s where the precision matters. When someone asks “how does this work?”, the backend is the honest answer. It’s the most complete, most accurate description of the system we have.
So when someone asks “what does the system do?”, we answer the same way. Not because we’re being difficult. Because the backend is the layer we trust. The interface feels like a simplification: a lossy summary of something we know in full detail.
But that instinct, however natural, has a cost. The ATM screen isn’t a dumbed-down version of the backend. It’s a different kind of knowledge entirely. It describes intent, not mechanism. It answers the question a new team member, a stakeholder, or a product owner actually needs to move forward.
When we skip the ATM screen and go straight to the backend, we’re not being more rigorous. We’re just answering a different question than the one that was asked.
After the discussion went in circles long enough, I suggested we draw a sequence diagram: the user roles, the system components, the core use cases walked through step by step.
Something shifted. Instead of explaining how services called each other, we started describing what a user could do, and what the system would do in response. The backend knowledge was still there, informing every step. But it was now expressed at the interface layer: behavior, not mechanism.
The diagram became our ATM screen. A shared surface that both of us could read, regardless of how deeply we each knew the backend behind it.
The discussion unblocked. Not because we had learned something new about the system, but because we had found the right layer to talk about it.
Back to that meeting room.
The feature team wasn’t wrong to know the backend deeply. That knowledge is what makes a system run. But deep backend knowledge, expressed only in backend language, doesn’t travel, not to a new team member, not to a stakeholder, not to anyone who needs to understand what the system does before they can reason about how to change it.
This is the mindset shift I’m still learning. Before we explain how a system works, we should be able to explain what it does. Not as a simplification. Not as a dumbed-down summary. But as a different, equally valid layer of knowledge, the one that makes everything else legible.
In system design, we’ve always known this. Requirements before architecture. Interface before implementation. The ATM screen before the backend.
The sequence diagram wasn’t a workaround. It was the right starting point, the one we should have found at the beginning of the conversation.
Start with the ATM screen. The backend will still be there when we need it.
]]>Today I read Boris Tane’s post, half-expecting another breathless “AI will replace engineers” take. What I found was different. He wasn’t predicting the end of engineers, he was describing the end of the workflow I had quietly built my identity around.
He was right. And that’s what scared me.
I’ve spent years getting good at the whole craft, breaking down requirements, thinking through architecture, reviewing pull requests with care. I was proud of that. It felt like engineering.
Tane’s argument is that most of that craft is now a relic. That AI agents haven’t just accelerated the SDLC, they’ve collapsed it. Requirements, design, implementation, testing, review: all merging into a single tight loop driven by intent and iteration, not process and ceremony.
I didn’t want to dismiss him. But I also didn’t want to just nod along. Because if he’s right, and I think he largely is, the question hea leaves unanswered is the one that keeps me up at night: what does it mean to be a software engineer in the age of AI?
That’s what this post is about. Not a eulogy for the SDLC. A genuine attempt to figure out what comes next.
It’s tempting to read Tane’s post as provocation. The SDLC is dead. PRs are a relic. Jira is a terrible context store. These are fighting words in most engineering teams.
But strip a way the sharpness, and the argument is surprisingly rigorous. His point isn’t that process is bad. It’s that process was always a response to contraints, and those constraints have changed.
The SDLC was sequential because building was expensive. When a feature took weeks, we had to specify everything upfront. We froze requirements because reopening them mid-sprint cost real money. We had separate QA phase because catching bugs late was painful. We had release trains because deploying was risky and slow. The ceremony wasn’t arbitrary, it was load-bearing.
What AI agents change is the underlying cost structure. When a working draft of a feature takes minutes, not weeks, the logic that justified the ceremony collapses with it. We don’t need to specify everything upfront when we can generate 10 versions and pick the best one. We don’t need separate QA phase when tests are generated alongside code. We don’t need a release train when deployment is continuous and automated.
Then SDLC didn’t die because it was wrong. It died because the problem it was solving got solved in a different way.
Thant’s what makes Tane’s argument hard to dismiss. And it’s what makes the follow-up question so urgent.
Tane is convincing on the diagnosis. The SDLC is collapsing, stage by stage, and most of use are still operating as if it isn’t. But his post ends where the hard question begins.
He tells us the map is wrong. He sketches the outline of a new one: context engineering, observability as the connective tissue, but leaves is at that. The diagnosis is sharp. The prescription is thin.
And that absence is uncomfortable in a specific way. Because if we’re honest, most of us have been using the SDLC as more than a workflow. We’ve been using it as a definition of what is means to be a software engineer.
That definition is dissolving. And the industry, for all its excitement about AI agents, hasn’t seriously reckoned with what replaces it.
So that’s the question I want to sit with here. Not whether the SDLC is dying, I think it is. But what we’re supposed to become on the other side of that.
For most of our careers, being a good engineer meant being good at execution. Writing clean code. Knowing our patterns. Debugging with precision. Shipping without breaking things. The craft was in the doing, and we got better at it by doing more of it.
That’s not worthless. But it’s no longer the ceiling.
When an agent can generate a complete feature in minute, with tests, error handling, edge cases, the value of execution compresses. Not to zero, but dramatically. What doesn’t compress is judgement. Knowing whether the feature should be built at all. Recognizing when the agent’s architecture is clever but wrong for the context. Feeling when something technically works but misses the point entirely.
This is the shift: from craftsman to architect. From being the person who builds to being the person who designs, evaluates, and takes responsibility for the outcome.
It sounds like a promotion. In some ways it is. But it’s also genuinely harder. Execution is legible, we either shipped it or we didn’t. Judgement is murky. It requires taste, context, experience, and the confidence to say “this isn’t right” without always being able to fully articulate why.
And here’s what make it uncomfortable: judgement can’t be faked. We could fake parts of the old craft, copy Stack Overflow answer, follow a tutorial, lean on a framework. Judgement requires that we actually understand the system, the users, the trade-offs. The agent raises the floor for everyone. It also raises the bar for what it means to be genuinely valuable.
The engineers who thrive won’t be the ones who use agents to do less thinking. They’ll be the ones who use agents to think about harder things.
So if execution compresses, what expands? I’ve been thinking about this a lot, and here’s where I land.
Context engineering. Tane names it and points at what matters - the quality of context we give an agent is directly proportional to the quality of what it builds. What that means practically? It’s not about writing clever prompts. It’s about understanding a problem deeply enough to frame it well, scoping it, constraining it, anticipating where an agent will go wrong. We can’t give good context about something we don’t understand. This skill rewards depth, not shortcuts.
System thinking. When agents handle implementation, our leverage moves up the abstraction ladder. Understanding how distributed systems fail, where bottlenecks emerge, what architectural trade-offs actually cost, this becomes more valuable, not less. The engineer who understand why a design is good is the one who catches when an agent over-engineers or misses a constraint.
Product taste. Agents optimise for what we specify. They have no sense of what the user actually needs, no instinct for elegant simplicity. The engineer who can say “this technically works but it’s wrong” is irreplaceable. The requires genuine product sense: understanding users, business context, and what “good” looks like beyond the spec.
Knowing when not to trust the agent. This might be the most underrated skill of all. Agents are confidently wrong in non-obvious ways. Reading generated code critically, not line by line but architecturally, and spotting when something looks right but isn’t, requires maintaining genuine technical depth. The agent raises the floor. It doesn’t replace the judgement that comes from real understanding.
None of these are new skills exactly. But they were previously optional layers on top of execution. Now they’re the job.
There’s a word Tane uses almost in passing that stuck with me. Describing engineers who cling to PR reviews in an agent-driven world, he calls it luddism.
It’s a provocative word. But I think it’s th right one, if we understand what the Luddites were actually about.
The Luddites weren’t anti-technology. They were skilled craftsmen who had built their identity around a specific form of work, and who fought to protect that form when the underlying economics shifted beneath them.
They weren’t irrational. They were human. And they lost, not because machines were evil, but because they tried to protect the specific shape of their work rather than the underlying value they brought.
That’s the mirror I find uncomfortable to look into. Because I recognize the impulse.
I’ve caught myself defending the PR review not because I genuinely believe it’s the best way to ensure quality in an agent-driven world, but because reviewing code is something I’m good at. It’s legible. It feels like engineering. Letting fo of it means stepping into something less defined, less certain, less easy to measure.
That’s not rigor. That’s identity preservation dressed up as professional standards.
The real question isn’t whether we use AI tools. Most of us do. The question is whether we’re willing to let go of the ceremonies that no longer serve the outcomes they were designed to produce, even when those ceremonies are deeply tied to how we see ourselves as engineers.
That’s harder than adopting a new tool. It requires honesty about what we’re actually protecting.
I don’t have a tidy conclusion. That would be dishonest.
What I have is a direction. And a few things I’m actively trying to do differently.
We’re investing more in understanding the why before touching an agent. Not writing a PRD, not estimating story points, just sitting with a problem long enough to understand it’s shape, its constraints, its failure modes. That’s what good context engineering actually requires. And it turns out that slowing down at the start makes everything that follows faster and better.
We’re talking observability more seriously, not as a monitoring layer bolted on at the end, but as a design concern from the beginning. If the feedback loop between production and the agent is the connective tissue of the new lifecycle, then designing that loop well is ont of the highest leverage things we can do.
And we’re trying to stay honest about the difference between defending quality and defending comfort. Every time we feel the urge to insist on a process, it’s worth asking: is this serving the outcome, or is this serving our sense of what engineering is supposed to look like?
The Luddites lost not because they were wrong to care about their craft. They lost because they confused the form of their work with its value. We’re at a similar inflection point. The engineers who navigate it well won’t be the ones who resist the shift or the ones who abandon all judgement to the agent. They’ll be the ones who carry their values (quality, responsibility, depth) into a new shape of work.
That shape is still being defined. I find that unsettling. I also find it, quietly, exciting.
]]>Then we also discussed on how to strategically survive, as an engineer, in such a neo-feudal system while looking for breakthrough without being cynical.
The modern tech landscape can be considered as a map of feudal territories, each controlled by a dominant lord.
Walled gardens as territories. Apple controls iOS; Google controls Android and search; Amazon controls e-commerce and cloud (AWS); Microsoft controls enterprise software and cloud (Azure); Meta controls social identity. Each has built an ecosystem that’s deliberately difficult to leave. Just as medieval peasants couldn’t easily cross from on lord’s domain to another, users and developers face enormous switching costs moving between platforms. Our Apple purchases, Google account history and Amazon seller reputation are ties that bind us to the land.
Vassal ecosystems. Smaller companies and developers operate like vassal lords within these territories. An app developer on the App Store must follow Apple’s rules, pay Apple’s 30% tax (the “Apple tax” is quite literally a feudal tithe), and can be expelled at Apple’s discretion without meaningful appeal. AWS customers build their entire infrastructure on Amazon’s land, migration is technically possible but so costly that it functions as a form of bondage.
Inter-platform warfare. The major platforms compete for territory much like feudal lords engaged in wars and alliances. Google and Apple battle over mobile dominance. Microsoft and Amazon fight over cloud. Meta and Google compete for advertising revenue. These aren’t free market competitions so much as territorial disputes between entrenched powers, complete with strategic alliances (Microsoft investing in OpenAI to challenge Google) ans sieges (Epic Games vs. Apple over App Store control).
Standards as borders. Each platform promotes proprietary standards, APIs, and data formats that lock users in. This is the digital equivalent of feudal lords controlling roads, bridges, and trade routes through their territory. Interoperability, the idea that systems should work together freely, is resisted because it would weaken territorial control.
Data as land. In feudalism, land was the fundamental source of wealth. In neo-feudalism, data plays that role. Platforms harvest user data as their primary resources, and users who generate that data have little ownership or control over it. We work the digital land, the platform lord reaps the harvest.
Now let’s dive into these tech fiefdoms at how labor is structured.
The new aristocracy. At the top sit founders, C-suite executives, and major shareholders are the lords who own the means of production. Below them, a layer of senior VPs and directors function as high nobles, granted significant equity (their fiefs) in exchange for loyalty and service. Their wealth is tied directly to the platform’s success, aligning their interests with the lords rather than with workers below.
The knight class: senior and staff engineers. These are highly skilled specialists who receive meaningful equity compensation, enjoy relative autonomy, and are courted between fiefdoms. Like medieval knights, they have real value and some bargaining power, but ultimately serve at the pleasure of the lords above. Their golden handcuffs (non-vested stock options, deferred compensation, etc.) function exactly like a fief: valuable, but contingent on continued service and loyalty.
The yeoman class: mid-level engineers. These workers are competent and necessary but increasingly replaceable. They receive som equity but not enough to fundamentally change their economic position. They have moderate autonomy within defined boundaries. Their situation mirrors the free peasant of feudalism: better oof than serfs, but still dependent on the system and vulnerable to its shifts.
The digital serfs: junior engineers and contractors. At the bottom, junior developers, contract workers, outsourced teams, and gig workers in tech bear the closest resemblance to serfs. They do essential work bu receive fewer benefits, no equity, limited career mobility, and can be dismissed easily, echoing how feudal surplus was exploited from those with the least power.
The loyalty economy. Tech companies cultivate loyalty through mechanisms that mirror feudal bonds. Equity vesting schedules keep people tied to the company for years. Internal leveling systems create a hierarchy that determines our worth. Performance reviewers by the direct manager give individual lords enormous power over our career. Company culture and perks (free food, campus life, team events, etc.) create a self-contained world where leaving feels like exile.
The illusion of meritocracy. Feudalism justified itself through divine right and tradition. Tech neo-feudalism itself through meritocracy, the idea that the hierarchy reflects talent and effort. But in practice, advancement depends heavily on which team we join (which lord we serve), who sponsors us politically, and whether we’re visible to the right people. The “leveling” system at big tech companies, supposedly objective, is deeply influenced by these feudal dynamics.
AI as the new enclosure. The rise of AI tools threatens to be a modern equivalent the enclosure movement, where feudal lords fenced off common land for private use. Ai is automating tasks that gave mid-level engineers their value, potentially pushing more workers down the hierarchy while concentrating even more power and wealth at the top. The engineers who build and control AI systems become the new landed gentry; those displaced by them join the growing class of digital serfs.
The horizontal and vertical dimensions reinforce each other. Platform monopolies give tech lords the power to dictate terms to their workforce. An engineer at Google has limited alternatives precisely because so few companies operate at that scale. The concentration of the industry into a handful of dominant platforms means the “lords” compete for talent among themselves while collectively maintaining a system that benefits their class.
Meanwhile, engineers who move between companies aren’t really escaping the system, they’re transferring allegiance from one lord to another within the same feudal order. The fundamental power dynamics remain unchanged.
The question this topic raises, especially for someone navigating this landscape as we are, is whether genuine alternatives can emerge through open source movements (digital commons), regulation (a kind of modern Magna Carta?), worker cooperatives, or decentralized technologies, or whether the feudal consolidation will only deepen?
However, the question that matters most practically, is how to strategically survive, as an engineer, in such a neo-feudal system while looking for breakthrough.
The first step is shedding the meritocracy illusion without becoming cynical. The system rewards certain behaviors and positions, we should understand which ones gives us agency.
We’re not passive serfs; we’re closer to a skilled craftsman in a feudal economy, which historically was one of the few classes that could accumulate independent power.
As for me, a senior engineer, I should believe that I already have a craftsman’s toolkit. The question is how to convert that into leverage that isn’t entirely dependent on any single “lord”.
Choose our “lord” wisely. Not all fiefdoms are equal. Some companies offer more autonomy, better equity structures, and genuine learning opportunities. When evaluating roles, assess not just compensation but how much ownership and visibility we’ll have. A smaller fiefdom where we’re a key vassal often beats being an anonymous serf in a massive one.
Build cross-platform skills. Feudal lords want us specialized in their stack so we can’t leave. Resist this strategically. We can move toward other skills alongside our expertise, which makes us valuable across fiefdoms rather than locked into on. Skills that transfer across platforms are our equivalent of portable wealth in a feudal economy.
Accumulate political capital. This is often uncomfortable but necessary. Inside any organization, advancement depends on relationships, visibility, and sponsorship as much as technical skill. Being able to articulate our value in terms leadership understands is how a craftsman becomes a guild master rather than remaining a hired hand.
[!NOTE] For me: The Pyramid Principle work I’ve done and my focus on structured communication serve this directly.
Negotiate from knowledge, not need. Understand our market value precisely. Know what lord across the border is paying. Use this position: we’re not begging for shelter.
This is where we move from surviving to positioning for breakthrough.
Own something. In feudalism, the path out of serfdom was ownership of land, of a trade, of a shop. In tech, the equivalents are intellectuel property you control, a product you’ve built, a reputation that belongs to you rather than your employer, or deep expertise in a scarce domain.
[!NOTE] For me: My interest in AI engineering is strategic here: the field is young enough that genuine expertise creates independent value that no so many fully capture.
Contribute to commons. Open source is the most powerful anti-feudal force in tech. Contributing meaningfully to open source projects does several things simultaneously:
[!NOTE] For me: If I can build something useful in the AI or .NET open source space, it belongs to myself in a way that no corporate project ever will.
Develop a public voice. Writing, speaking, or teaching creates leverage that is independent of any employer. A blog, technical articles, conference talks, or even a well-maintained GitHub presence transforms us from an anonymous worker into a recognized craftsman. In feudal terms, this is the difference between an unknown peasant and a master artisan whose reputation precedes them.
Build a network of peers, not just superiors. Feudalism isolates people vertically, our relationship is with our lord, not with other serfs. The most subversive thing we can do is build strong horizontal connections with other skilled engineers across companies. These relationships will become our guild, a mutual support structure that gives us information, opportunities, and collective bargaining power that no individual has alone.
Move towards ownership, no just employment. The ultimate escape from neo-feudalism is the same as it was from feudalism: stop being a worker on someone else’s land. This could mean a startup, a consultancy, a product, or freelance expertise in a scarce enough domain that we set the terms.
[!NOTE] For me: My combination of .NET architecture skills and growing AI expertise can position me for consulting or product development where I’m the lord of a small domain rather than a vassal in a large one.
Bet on disruption. Feudal systems are most vulnerable during periods of upheaval, when new technologies or economic shifts redraw the map. AI is exactly such a disruption right now. The engineers who deeply understand both traditional software architecture and AI systems will be the ones who build the next generation of platforms, not just work on existing ones.
Think in terms of optionality, not optimization. A feudal mindset optimizes within the existing hierarchy:
How do I reach the next level?
A free mindset creates options:
How do I ensure I have multiple paths forward regardless of what any single lord decides?
Every skill we learn, relationship we build, and asset we create outside our employer’s control adds optionality.
Here’s the most encouraging thing: history shows that skilled craftsman were among the first to break free from feudalism. They formed guilds, moved to free cities, accumulated independent wealth, and eventually became the merchant class that replaced the feudal order entirely. The same pattern is available to software engineers today, but only to those who think strategically about it rather than simply climbing the ladder inside a single fiefdom.
The key shift is applying the same rigor not only to technical skills but also to building independent leverage: portable expertise, public reputation, owned assets, and strong horizontal networks.
The engineers who will thrive aren’t necessarily the most technically brilliant. They’re the ones who understand the system they’re operating in and build deliberately toward independence within it.
]]>