{"slug": "the-sdlc-was-designed-for-humans", "title": "The SDLC Was Designed for Humans", "summary": "Companies across different industries are converging on the same challenge: how to make large language models (LLMs) perform repeatable, trustworthy work in software development, according to Yusuf Aytaş. As agentic workflows push software production beyond human speed, existing systems designed for human developers—such as pull requests, CI capacity, and permissions—are breaking down. Organizations are responding by converting tacit knowledge into machine-readable formats, including reusable patterns, service metadata, and explicit context delivery, to enable LLMs to consume and act on it.", "body_md": "I was doing research on what to build next in the AI world. I’ve done a few hobby projects that have gone nowhere. I was fishing for the next. I was looking for an interesting idea to implement. So, I decided to take a look at recent job descriptions to see what companies want and where they want to go.\n\nTo my surprise, companies in very different domains look like they are asking for similar capabilities. Initially, most of the conversation around AI driven development was about producing and understanding code. Now, the problems are gradually moving to agentic development. Job descriptions talk about skills and MCP, standardized environments, reusable patterns, service metadata and permissions. Then there is evaluation, traceability, audit and the cost of work done by LLMs. These are different industries, different names, but they appear to be converging on the same question. How do we get LLMs to do repeatable, trustworthy and usable work?\n\nWe’re well past the stage where LLMs were autocomplete. We’ve been putting them deeper and deeper into the SDLC. The bizarre thing is that producing software is starting to move beyond human speed, while the rest of the system still assumes a human is on the other side.\n\nWe Put AI Into the Old Machine\n\nWhen we first interacted with LLMs, we put them into our existing human workflows. That was rather a practical approach. Now, with the advent of agentic workflows, they are expected to be side by side with humans. The trouble is that almost everything around software development was designed around humans. Our throughput, permissions, development environments, review systems and ownership models all fundamentally assume that the actor doing the work is a person.\n\nOur existing system looked roughly as follows.\n\nAgents are different, for one, there can be many, and they do not necessarily operate at human speed. One engineer can have several agents making changes at once. That changes the assumptions underneath our entire development pipeline.\n\nA pull request assumes changes arrive slowly enough for [another human to inspect them](https://yusufaytas.com/a-guide-for-code-reviews). CI capacity roughly follows the pace at which humans produce code. Service ownership assumes teams create software slowly enough to absorb it. Permissions assume the actor exercising them is a person who can be held accountable later. All of that starts to break when the worker is an agent, because our system was never designed for something that can [produce this much shit this quickly](https://yusufaytas.com/does-code-quality-still-matter).\n\nHumans Have Been Filling the Gaps\n\nToday, [humans are filling the gaps](https://yusufaytas.com/the-engineer-in-the-half-space). For instance, we have been writing our documentation in markdown files, even more, we have been even writing ticket description, designs in such a way. That helps give context for AI because it can then pattern search what happened.\n\nWe have also been building paved paths for years to [repeat quality across repositories](https://yusufaytas.com/what-good-looks-like). The difference is that another consumer has arrived. Now, we need to do the same for LLMs but the trick is to get them to consume it. Companies are investing in reusable patterns, reference architectures, service metadata, machine-readable instructions, skills, templates, development environments and explicit context delivery. Hence, standardization and paved paths appear again and again.\n\nA surprising amount of what we will call LLM-ready platform engineering is really the work of converting [organizational knowledge](https://yusufaytas.com/the-work-runs-on-different-maps) into something a machine can consume. Things engineers used to learn from another engineer, infer from a repository, or discover by asking around now [have to become explicit](https://yusufaytas.com/trial-by-fire). We have wanted better documentation for years and there is never enough of it. Apparently agents are finally going to make us write the damn thing, pro bono.\n\nThe Developer Platform Gets a New Persona\n\nIf you think about modern platform engineering, we standardized a few good things. With the new persona coming in, we need to think a bunch of these capabilities in terms of agents. Standard questions like how do I deploy, how do I create a ticket, [where are my logs](https://yusufaytas.com/the-mirror-is-part-of-the-machine), how do I get credentials, who owns this service and so forth need to be calibrated against both humans and agents.\n\nDeveloper experience, AI platform, security and developer productivity are already bleeding into each other. I don’t think the names will matter for long. Call it whatever you want. We are going to end up with a platform that has to work for both humans and agents.\n\nOnce an agent needs to discover a service, figure out who owns it, get credentials, make a change and prove what it did, our concerns start collapsing into each other. Humans have been filling the gaps with judgment, memory, reputation and the ability to ask someone what the hell is going on. Agents need those things represented in the system.\n\nLimits will be Part of Control Plane\n\nNow, we are solving the problem of what LLMs are allowed to do and what they aren’t. If you wrote something as follows.\n\n```\nUse Java 24.  \nFollow our repository pattern.  \nDo not access production.  \nRun integration tests.  \nAsk before changing schemas.\n```\n\nWe are using prose as permission and LLMs occasionally don't give a shit. If we are going to give an agent consequential work, that’s not gonna fly. These are also represented in every repo, so they will drift. I think these will converge into controlled permissions, policy, traceability, auditability, validation and reproducible environments alongside ordinary agent instructions. And again there seems to be startups around that. Missed the train!\n\nOne thing that I have never thought of is that instructions become executable constraints. That’s essentially what we wanted in platforms but we also valued engineering freedom to an extent. We are now treating this as non-negotiable given that agents can mess things up big time.\n\nRules like [“Do not access production”](https://yusufaytas.com/update-statements-on-production) or “Ask before changing schemas” can’t be soft prompts. The platform has to say no. Maybe that’s policy-as-code at the API layer, maybe something else, but the agent shouldn’t get to negotiate. The same goes for [execution](https://yusufaytas.com/what-good-execution-looks-like). If an agent gets a working tree, give it a [reproducible, isolated environment](https://yusufaytas.com/local-vs-production-debugging) too. A short-lived container, for example. Let it loop there instead of running its nonsense on shared infrastructure. And keep a record of what it did and why, because “it ran” isn’t much help when something goes wrong.\n\nOn the flip side, not every instruction needs enforcement. “Prefer this repository pattern” can remain guidance. Instructions can express taste. Anything that defines what an agent is allowed to do has to live in the platform constraints.\n\nThe Unit of Work Introduces New Metrics\n\nDeveloper productivity was about enabling engineers to get their best work with the least amount of friction. We tracked a few good metrics such as lead time for changes, deployment frequency, change failure rate and so on. They became part of the DORA metrics. Yet [metrics are indicators, not guarantees](https://yusufaytas.com/beyond-numbers-quality-in-software-engineering). With LLMs, I think something closer to [time to safe merge](https://yusufaytas.com/vibe-coder-vs-software-engineer) starts becoming interesting because the developer is no longer necessarily the unit producing the work.\n\nSuppose five agents are working for an engineer, assuming the token cost will go lower. Each agent gets a sandbox, a working tree. That means [pressure on compiling, testing, and other resources](https://yusufaytas.com/old-software-was-fast-because-it-had-no-choice) because these agents can spend a lot of time doing the work, e.g. loop engineering. In the end, someone takes a look at the work and says this is ready.\n\nThe imbalance is interesting. Five agents can generate fifty candidate changes while the engineer is still [one person](https://yusufaytas.com/when-too-many-maps-overlap-on-one-person) who has to establish whether any of them are safe. We can increase production upstream without [increasing safe throughput downstream](https://yusufaytas.com/why-headcount-math-lies). That means the metric cannot simply be how much code the agent produced or how many tasks it completed. The useful boundary is how much of the path to a safe merge the system can complete without creating more work for the human at the end.\n\nWhat the Next SDLC Looks Like\n\nThis research made me ask the same question again and again. How does SDLC look like in the future? I think it has drastically changed for some companies already, not so much for others. Some companies are already defining an agentic SDLC while others are still putting agents into the existing one.\n\nI think we are going to go to something like standardized environments, skills, permissions, evaluation and lifecycle controls rather than something the sources describe as one finished system. When you have a task like [moving the payments service to the new authentication mechanism](https://yusufaytas.com/risk-comes-first). It would look quite different. It’s more like as follows.\n\nIn this world, agents become replaceable. It’s like switching from one electricity provider to another. The important point is that the surrounding engineering platform knows enough to let either of them work safely. In a few years, we came to a quite different place from where we started with coding assistants.\n\nAnd once the platform knows enough to let an agent do the work, the interesting problems start moving outside the agent. Who can do what, what happens when [work collides](https://yusufaytas.com/working-with-dependencies), [who owns the result](https://yusufaytas.com/code-author), and eventually, how the agents deal with each other.\n\nWhat’s the Bottleneck?\n\nOur development environments are assumed and designed for humans. If code takes thirty seconds and CI takes twenty minutes, [CI becomes the problem](https://yusufaytas.com/cracking-coding-bottlenecks). If five agents can work in parallel but their changes collide, integration becomes the problem. If agents can create services faster than teams can operate them, ownership becomes the problem. If agents can execute production actions, authorization becomes the problem. If agents can create hundreds of internal skills and workflows, lifecycle and reuse become the problem. More ifs to come. However, that’s not where this ends.\n\nThe bottleneck keeps moving because the constraint we removed was human production speed. We did not remove everything that surrounded it.\n\nIt comes back to a question I asked earlier: [where does the automation have to stop?](https://yusufaytas.com/where-the-automation-has-to-stop) I thought the answer was humans, one way or another. Perhaps. The strange part is that the further we automate the SDLC, the more it starts to resemble the thing we were supposedly automating away. Good old engineering organization.\n\nParallel agents need to divide work without making the same bet. They need to distrust bad information, resolve conflicts, establish hierarchy and remember what happened. They also have to deal with actors whose goals do not quite line up. Humans have norms, reputation, [incentives](https://yusufaytas.com/incentives-drive-everything) and recourse because intelligence is never enough to make coordination work.\n\nIt looks like agents are going to discover the same problem very quickly. So perhaps the final bottleneck is not only humans but also [coordination of agents](https://yusufaytas.com/the-invariant-is-hiding). We can replace more of the people doing the work, but then we have to rebuild, in software, many of the systems humans invented to make [groups of people work together](https://yusufaytas.com/the-real-work-is-social).", "url": "https://wpnews.pro/news/the-sdlc-was-designed-for-humans", "canonical_source": "https://yusufaytas.com/the-sdlc-was-designed-for-humans", "published_at": "2026-08-16 11:27:44+00:00", "updated_at": "2026-08-16 11:41:43.414363+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Yusuf Aytaş", "LLM", "MCP"], "alternates": {"html": "https://wpnews.pro/news/the-sdlc-was-designed-for-humans", "markdown": "https://wpnews.pro/news/the-sdlc-was-designed-for-humans.md", "text": "https://wpnews.pro/news/the-sdlc-was-designed-for-humans.txt", "jsonld": "https://wpnews.pro/news/the-sdlc-was-designed-for-humans.jsonld"}}