the software development lifecycle (SDLC) used to look something like this:

although the names of the phases are enough to encite a yawn in even the most pertinent of programmers, this traditional structure had a lot going for it. there was consistency, there was determinism, there was intention. rigid processes like this in conjunction with a general appetite for experimentation and skunkworks meant that software used to have an unpredictable yet exciting feeling, wrapped in a general sense of safety and process based rigour. in 2025, it all feels quite different, and i'm not convinced anyone could say it's for the better.

writing software and other arcane cuneiform

i started my career in 2021, so i really only caught the tail end of this very mechanical, procedural approach to shipping software. i still remember people around me at the time speaking with genuine fervour about TDD and other silly approaches like that. at least back then, it did feel like large software companies held themselves at keyboard-point trying to adhere to these rules - bending some of them, or god forbid skipping them entirely, felt closer to civil rebellion than a genuine exploration of a more modern approach.

your team was big (perhaps there was 6 or so of you), and you always had a product manager dishing out requirements and fielding external requests, always interfacing with the external world so as to shield engineers from ever having to interact with someone non-technical. planning was always executed through strict "sprint planning" meetings, and a beautiful 10 page PRD would be written for you laying out the foundation for a multi-quarter, multi-million (probably) dollar project.

perhaps you need to build an entirely new customer onboarding system, or a new db synchronisation tool to replace an expensive vendor (yes these are real examples). these were considered mammoth tasks that required a dedicated team working many quarters to properly work through the entire SDLC. baked into the psychology of project completion was the notion of being sufficiently proud of the end result, but also building the right support structures around it so that maintenance was as automated as possible. the last thing you'd want back in those days was to ship a new product and then spend the next year manually fielding support requests for use cases not catered to, or bugs you simply don't have time to fix because everyone has, understandbly so, moved onto the next money making project.

player 2 has joined the game

fast forward to 2025. i have always been an AI skeptic. to be fair, maybe due to personality defect or occupational hazard, i am generally skeptical about most things - but AI as it is used today in the form of large language models has never truly captured my attention like other marvel tooling/products/software. using LLM's for things like writing blog posts or stories feels intellectually dishonest, using diffusion or transformer models to generate art feels incredibly dystopian, and more crucially using AI for writing code feels downright wrong.

the goal of the software engineering discipline, as i have always understood it, has been to leverage computers and code to solve business problems. your coffee shop needs to capture payments from customers? point of sale system. you need to get from home to work? google maps. so on and so forth. there are very clear reasons for this:

code is the ultimate tool for leverage

i can write one piece of software and use it or sell it a million times over. just because i sold one business a point of sale system, doesn't mean i can't sell the same software to another business. if i sold that business a pen and paper to record their transactions instead, i couldn't then go and sell the same pen and paper to another business.

code is deterministic

if i write a piece of software to add two numbers together, i expect that if i run it 1 million times with 6 and 7, and it will output 13 every single time.

with LLM's, leverage is not a very convincing horse due to how much they cost to train and run, and determinism is basically impossible. if i ask GPT5 to generate a function to add two numbers together, it's pretty much guaranteed to be virtually the same every time i ask. if i ask it to write a db synchronisation tool, it's pretty much guaranteed to be entirely different every time i ask.

salutations, frustrations

interest rates seem to have a big impact on technology industry and the software business:

you can play with this graph at the FRED website. you'll need to modify it to add a separate EFFR line and also adjust the units to percentage change to get the above result.

technology companies that debt finance hire less (or fire more) when the cost of debt increases, where the effective federal funds rate is a proxy (of a proxy of a proxy of a proxy of a...) for the cost of debt, and unemployment rate is.. well, the unemployment rate. the tldr of this graph is that as the cost of borrowing goes up, so does the cost of human capital (not labour, different thing).

why is this important? well in recent times (i.e. the last 2 or so years), technology unemployment is generally pretty high. high cost of debt financing, but also threat of AI replacement, means that employing technologists (not just software engineers, but product managers, technical sales people, so on and so forth) is risky and expensive.

expectations, valedictions

your big team no longer has a product manager. you now field all requests from external teams and all other stakeholders (technical and non-technical). you are now expected to drive big projects solo through the entire SDLC. oh and you know how you used to own 3 big services? you've now inherited 15 more. huh? what's that? documentation? no, the previous owners didn't bother. oh, by the way, the pagerduty alerts are constantly firing and you're on call this week. anyway, you have AI, i'm sure you'll figure it out.

theatrics aside, from the perspective of a technology business, performance shouldn't go down - even with less people. we already have terminology like agentic engineering and agentic versions of the SDLC like research, plan, implement (see this video). the scales need to balance somehow, so whoever is left just needs to output more: if you augment human capital with AI, you can achieve more with less

the industry is heavily polarised towards AI, combining this with a high interest rate environment, it only feels natural to say software engineers are supposed to do everything now - otherwise they risk doing nothing at all.