6 ways AI can quietly sabotage your SDLC

Introduction

At first, everything seems simply amazing – your team delivers faster than ever, developers can take a nap while an agent implements features and product owners (POs) turn their ideas straight into code (mildly exaggerated). But soon, issues start to crop up, and you realize that you're pushing more code to prod than ever, but you're not delivering more value.

We've seen this first-hand in some of our clients’ projects. AI makes coding cheap, but it does not replace engineering judgement.

In this article, we want to highlight six ways AI can quietly sabotage your software development life cycle (SDLC) and what you can do about them.

Golden Hammer

An agent can take a prompt written in plain language and turn it into code that compiles and runs. This makes it tempting for non-technical people to go straight to the agent instead of describing the requirements to a software engineer.

This can work out wonderfully when the goal is to create a throwaway proof-of-concept – something the user can click through, check what it feels like and figure out what works and what should be implemented differently.

But expecting the agent to deliver working changes straight to prod is misguided. Even a simple request, such as changing the maximum length of an input field on a website, can fail because the person prompting lacks the technical context. It's not even really the agent’s fault – given such a prompt, it will change the validation on the frontend. But it won't push back and ask: what about the backend? Don't we have this field on the mobile app as well?

AI is not a magic bullet that lets us skip the software development process. Even if an agent ultimately writes the code, a product owner should still consult an engineer on the requirements – at the very least, this will result in a more precise and more thorough prompt.

Premature Specification

Another way non-technical team members may use AI is to help them understand the codebase. LLMs are very convincing and a brainstorming session with AI may give false confidence about a chosen solution. This may result in tickets that describe a solution (one of many possible) instead of the problem.

POs are not the only people susceptible to this. Developers can also use AI to write requirements, which has its own pitfalls. Even when the intention is to describe the problem, solutions tend to sneak into AI-drafted tickets – specific implementation details that nobody has actually thought through. When another developer starts working on such a ticket, it's hard to say which parts of the description are deliberate decisions and which parts are just an assumption, suggestion or even an outright hallucination. Whatever time the ticket’s author saved thanks to AI is now spent by the person working on it, who has to verify and recheck everything stated in the description, almost writing it from scratch.

The worst case is when AI generates artifacts like product requirements documents (PRDs) or functional specification documents (FSDs). These documents exist to present ideas in a clear, specific way, but it's easy to think of them as elaborate ceremony – and if they were mere ceremony, why not outsource them to AI? That’s exactly the wrong conclusion! Yes, they are time-consuming to create, but the process of writing down your thoughts, exploring different ideas and shaping them into a concrete solution is where much of their value lies.

When reading such AI-generated documents, which tend to feature walls of text, it's hard to see past the noise to the decisions that were made deliberately and the parts that actually need a closer review. We end up with a team that nominally has an FSD they can follow, but the decisions in it were never properly discussed and are likely suboptimal.

Invisible Decisions

Using AI requires discipline. We all know that keeping good, up-to-date documentation is important and that we should be writing architectural decision records (ADRs). Previously, gaps in documentation were not the end of the world because there was often someone who kept the information in their head – and there was ample opportunity to share the knowledge during video calls or in Slack threads.

Our AI agents know none of this. They do not listen to our calls and they don't read chat messages (even if you connect a Slack MCP, the agent is not going to rifle through channels each time you ask it to write some code).

Just as we try to move conversations from private messages to public channels and save meeting minutes after calls, we should think about how we can make the knowledge available to our agents. The first obvious (and very valuable) step is being diligent about writing ADRs and documenting our software well.

We once had a task that involved migrating an enum with a limited set of values to a free-form string. A developer prepared a prompt that would carry out the migration, tested it on one or two microservices, then ran it on all of them. It mostly worked.

That left us with a lot of pull requests to review. For most services, the generated PR was correct, but a couple of projects used an external service (which we didn't own) that happened to expose an enum with the same name. That didn't stop the agent from changing it, breaking the contract. In the olden days, with a human creating each PR, this would not have happened. Here, we ended up with several PRs that weren't even worth fixing and had to be redone from scratch.

The agent had no idea that the external contract had not changed. Providing it with that service’s OpenAPI spec would have prevented that. So would pointing it at other relevant repositories (if you are not using a monorepo), so that it could see how the projects relate to each other and how the APIs are actually used. A software engineer wouldn't be confused like this, thanks to the extra context that exists only in their head.

There is also another kind of knowledge that never leaves our heads… or the terminal window. A developer may spend an hour guiding the agent: rejecting one approach because it would break compatibility, discarding another because it doesn’t fit the architecture, correcting an assumption about the data, and so on; in the end, they open a clean, well-structured PR. The reviewers and the subsequent agents touching the code will see the result, but not the reasoning behind it. Once the terminal is closed, all of that context is lost.

Important conversations about design happen between the developer and a short-lived agent, then have to be repeated when working on the next task. From the outside, your agentic workflow appears to work wonderfully, while in reality the output is good only thanks to constant manual supervision by the developer.

The fixes are simple, but they require being mindful. Firstly, before closing a session, ask the agent to summarize the decisions made along the way and put that summary in the PR – and if they have far-reaching implications, create an ADR. Secondly, if you notice yourself correcting the agent the same way twice, update your agent’s guidelines (e.g. AGENTS.md), so that future sessions can be more hands-off.

Some teams go a step further and record agent sessions automatically, tied to the commits they produced. Then “why does this code look like this?” can be answered from the session itself rather than from someone’s memory.

Deteriorating Source of Truth

When documentation is sparse, the agent is missing the why and makes decisions largely based on the code itself. As a result, some incidental changes – some introduced by AI in the first place – get elevated to become the new ground truth. Worse, every sloppy change made by AI becomes permission for the agent to continue the pattern.

It is often repeated that AI is great at generating test cases. But if the generated code is not vetted properly, the tests written by the agent effectively become the specification that all future code adheres to.

Sometimes, those tests don’t even check what they were intended to, or an assertion may be loosened, because the agent could not make the test pass. For that reason, you must pay very close attention to generated test cases. Their quality is important not only for the task at hand, but also for the future direction of the codebase. (We would like to see mutation testing employed more widely to keep AI-written tests honest and more reliable!)

Rubber Stamping

Everything mentioned so far comes to a dangerous conclusion: agents are great at writing lots of code quickly, so we open more PRs than before (and unfortunately, they are often longer than before). While AI is helpful at reviewing, ultimately a human has to approve each PR. It's easy to assume that the person opening the PR reviewed the agent's code thoroughly, that it meets all requirements and works exactly as described in the comments, and... LGTM.

But the issue is that even though the code looks very convincing, the agent frequently lacks the context necessary to implement a complete solution.

One failure mode to look for is that we might read a PR, think "ok, this does not implement the whole feature, but it's good progress that future PRs can build on" and give it our approval. But someone relying on AI, possibly using an integration that turns a ticket into a PR with a single click, may never follow it up…

Small PRs are considered good practice, because they are easier to review than AI-generated walls of text, so this happens more often than you might think. It's worth leaving a comment reminding the author that additional changes will be needed elsewhere – and better yet, the author themselves should clearly state what falls outside the scope of this PR and will be implemented in another. 

Broken Chain of Trust

Usually in a software development life cycle, when we face a problem we need to solve, we start by gathering requirements, so that we can explore multiple possible solutions and choose the best one. The product owner discusses the functional requirements with a software engineer, who can examine the trade-offs and propose a solution that meets the requirements and fits within the larger system. Then, when a developer grabs the ticket and begins implementing it, there is another chance to reconcile the proposed technical solution with the actual state of the code. In mature teams, there is also a QA engineer who independently comes up with exhaustive test scenarios.

At every stage, someone had the opportunity to contribute their perspective and fill in the gaps in the requirements. There was a chain of trust: decisions made earlier in the process could be trusted to have been meticulously thought through, so each stage could build on the previous one. Every handoff carried an implicit verification.

AI agents make it easy to skip this entire chain. Given even vague requirements, an agent will start writing code. As we’ve seen, it won’t push back when something is unclear, and it won’t know all the pieces that have to fit together for the solution to be complete.

When we rely too heavily on AI, we preserve every artifact – FSDs, tickets, PRs, approvals – but we hollow out the verification behind them.

We have tremendously increased the amount of code we can produce, but we haven't made that code any more trustworthy.

Closing Remarks

To make the most of AI, we have to incorporate it into the whole software development life cycle, from start to finish, instead of using it ad hoc at different steps or trying to skip parts of the process.

We can delegate the implementation of code to AI, but we still have to gather the requirements by examining the problem at hand and carefully checking how the solution fits into the larger picture. We have to record all important decisions and make sure that our agents can refer to them to guide their work.

Here’s a summary of what you can start doing at work to increase the quality of your code:

• use agents freely for throwaway PoCs and internal tools, but for everything else, follow the full SDLC and let AI accelerate each step, rather than skipping any of them
• write tickets that clearly state the problem and not only describe some solution
• when you draft a spec using AI, highlight what you have verified and what is just an educated guess that may change
• write down ADRs whenever you and your team make decisions, and save them somewhere agents can access
• before closing an agent session, have it summarize the decisions you made to arrive at the solution and the approaches you rejected – then consider updating your agent guidelines or even creating an ADR
• point the agent to contracts it can't infer like OpenAPI docs or the components that consume your API
• pay extra attention to generated tests, because they become the new spec
• self-review your PRs before handing them off to other people and always make the goal and scope of the PR clear

Most of this is discipline rather than tooling, but tooling can make the discipline stick. That's why we built Visdom: it records agent sessions alongside the commits they produced and gives agents the context they can't infer from a single repository, such as other services and their API contracts. If you want to see where your team stands, our AI-Native SDLC Maturity Matrix maps these practices across five levels.

Special thanks to Magda Stożek, Marcin Kubala and Artur Skowroński for helping me improve this article