DEV Community: Jérôme Van Der Linden

AI‑Assisted Software Development — 6 Pitfalls to Avoid

Jérôme Van Der Linden — Mon, 05 Jan 2026 13:26:54 +0000

Generative AI isn't just another tool, it's rewriting how we build software. Tools like Cursor and Claude Code, endless LinkedIn hype threads, and YouTube '10x productivity' demos have flooded the space. But most teams chasing the hype are about to learn a hard lesson: speed without discipline creates chaos faster than it creates value.

Most people see the vibe-coding demos and think "let me trade my VS Code for an AI version of it (Kiro, Cursor, etc…) and I'll be the king". They'll produce code faster, sure. But without good practices, proper specifications and design, test harness and review process, they'll write 10x faster code that's 10x messier.

This blog post details 6 concrete pitfalls I've seen - and sometimes fallen into myself - and recommendations to avoid them.

Disclaimer: this blog post represents my personal thoughts and is not endorsed by AWS.

1. Vibe-coding without a plan

I wanted to title this blog post "AI-Driven Development - 10 pitfalls to avoid" but that's wrong: developers drive the AI, not the other way around!

Vibe-coding is a bit like enabling the auto-pilot mode in your car: you might arrive at destination but not sure it will be the safest and shortest trip.

With a powerful assistant in your editor, it's tempting to jump straight into prompting and code generation: "Generate a service that does X, Y, Z." Ten minutes later, you have a shiny pull request with ten new files that introduce a new logging library, violate your coding standards, don't respect the project structure, and so on.
Then you end up in a long conversation where requirements (if we can call them that), design (eventually) and implementation details are all mixed together. It results in an infinite back-and-forth between the developers and the AI.

Of course, you can also ship the code directly without any code review, it will come back sooner than expected, like a boomerang, in the form of a production bug. In the end, it's a complete waste of time and what was supposed to make you x times faster finally slows you down (bug fix, rewrite, etc.).

Recommendations:

You will see everywhere "Spec-driven development" as if it were the new "agile", but let's face it, it's not new! Go back 20+ years in the past with the "V model" and you'll see nothing was invented: you start by defining the requirements and design before starting any implementation. With AI-assisted development, it's the same: If you want the AI to understand what you want and respect several rules, you need to specify things upfront.
You also need to make sure to properly design what you want: how it integrates in the project architecture, what the inputs and outputs are, the business rules, etc.
And last step before actually implementing anything, you need to plan the work for the AI not to diverge. Having a detailed list of tasks will avoid the back-and-forth we mentioned before and will permit the AI to stay focused.

If you don't know it yet, I encourage you to have a look at Kiro, a VS Code-based IDE with built-in "spec-driven development". Kiro will help you define your requirements, produce detailed specifications, design documents and task lists.

2. Providing insufficient context

You can see this pitfall as an extension of the previous one. Most often, specifications and design aren't enough. Without well-defined rules, the AI assistant will produce code that doesn't respect your standards, system architecture, or constraints.

You will have to repeat things you've already said (when I started, I had to repeat each time to put imports on top of Python files). You will have to ask for changes in the code again and again to generate the desired code. At that point, it would have been faster to write it yourself.

Recommendations:

Not only do you need to define your requirements, but also the constraints to work with: architecture, compliance, coding standards, non-functional requirements, etc.
Create steering documents to specify your constraints. Invest in them early. Treat them as code, share them in the repo. You can eventually share them more broadly at the enterprise level. Make them live, update them when the AI makes mistakes (just like you'd update unit tests to ensure non-regression after a bug fix).
In addition to steering docs, you can give the assistant access to broader information (enterprise policies, security guidelines, compliance rules, etc…) from a Knowledge base through MCP tools or structured docs.
Make your code "discoverable". Models perform better when projects have a clear structure, consistent naming, great conventions. Note this isn't just for AI, it's just a general good practice, even for humans to maintain a project.

In Kiro, you can use steering documents to provide rules and constraints. You can also plug MCP servers, for the assistant to retrieve additional information, either third-party ones (AWS for example) or your own.

3. Amassing too much context

On the contrary, sometimes, you provide the assistant too much context: a very big codebase, lots of MCP servers, and an endless conversation about many different topics. The session accumulates many partially related requirements, refactors, bug fixes, and side explorations. Over time, the AI starts mixing up domains and quality gradually degrades.

Some tools provide auto-summarization/compaction of the context, which can help, but it doesn't reliably reconstruct a clean, task-oriented context.

Recommendations:

Have one major task per session: treat each significant feature, bug, or refactor independently as a separate AI session. For each session, provide only the required assets (code, specs, steering docs, MCP servers) - no more. Clear or restart the session when moving to the next task or if you start to say "ignore this" to the assistant.
Reduce the scope of the requirement, don't ask the AI to build a complete application. Instead, focus on a specific feature or even smaller: a specific service. This will avoid the AI going into many directions, generating tons of poor and useless code.
Capture decisions in documentation or steering documents, not endless conversation. These assets will be saved in the repo while conversation will be lost at some point. As the context grows, the LLM will have issues "remembering" and applying everything discussed. Instead, you (and your colleagues) will be able to leverage steering docs in future sessions. It's also a great way to document the project.

Kiro recently introduced the notion of "powers". Powers permit to load MCP servers dynamically, based on user query, rather than preloading all of them and filling the context with hundreds of tool definitions.

For steering documents, Kiro permits to specify an "inclusion mode" to define when to load them, and thus avoid adding all steerings to the context:

always (for common best practices and rules)

based on the presence of certain files (for example "components/**/*.tsx" for React components)

manual (using the #steering-file-name)

4. Treating AI as a developers-only tool

Unfortunately, today, these tools generally land only in the hands of developers. Product owners still write fuzzy user stories, architects produce PowerPoint and wiki pages, security arrives at the end with a PDF of "blocking issues", and QA becomes the new bottleneck, flooded by tens of new features released by the developers.

It's not new, organization has always been a factor of failure or success. Agile tried to gather people and competencies to build multi-skilled autonomous teams. DevOps tried to reduce the distance between developers and ops. But with the developers' (expected) increased velocity, it will become even more critical. AI becomes central here - not leading, but supporting the process.

Recommendations:

As discussed above, the context provided to the AI is key, to get the right product and the good code. And most of the actors listed above must participate in generating this context: specifications and validation (PO, business, QA), design (architects), security and compliance (security and architects).
But it's not just about giving markdown files to the developer instead of PowerPoints or Word documents to be more AI-readable. It's about using AI themselves, in close collaboration with developers and other actors to provide the best possible input:
1. Product owners, business, QA should now participate in the requirements generation with the developers. Keep an iterative approach and continuously refine them during sprints. Notice that sprints might be shorter than before, one week or even less.
2. During the specification phase, prepare the validation by creating BDD scenarios ("Given / When / Then") that everyone signs off before any code is generated. Leveraging these scenarios and BDD frameworks like Cucumber will drastically help QA validation. I will cover the "test" topic in the next part.
3. During the design phase, developers can certainly design their software, with the help of well-crafted steering documents, but when integrating with other system parts, or handling non-functional requirements, architects and security should join developers to ensure alignment.
During all these steps, AI generates content, but it's the teams' responsibility to review, enrich, correct it, to produce the most accurate context, free of ambiguity, for the development phase.
With this "tool" comes a new organization. Don't throw away what you built with agile, reinforce it: build a strong product-oriented, multi-skilled team, co-build and share the same AI context (specs, design, steering docs, tests) and co-own the result. AI becomes an assistant of the team, not just of the developers.

5. Testing after

We briefly touched on tests in the previous part. AI is quite good at generating tests… that pass its own generated code. You will tell me it's still better than what most teams do: no test at all. The problem is if we forgot a business rule in the code, it will be also absent from tests. Tests confirm potential biases in the code, they don't challenge them.

Recommendations:

Write tests before writing code, between the specification/design and development phases. It's not new, this is called Test-Driven Development (TDD). This practice, as good as it is, was rarely adopted except by a few purists and craftsmen. The mental model is very different, writing tests without code feels counterintuitive. But now with AI, you can generate them easily. This ensures all the requirements are backed by one or more tests, before starting the development. Later, it validates the AI-generated code against those tests.
Write tests even earlier, during specification. These tests, written with a specific language (Gherkin) can then be "implemented" (with Cucumber for example) to test the application. These "executable specifications", can be used by QA to validate the behavior of the application, it is called Behavior Driven Development (BDD). Gherkin/BDD exist for a very long time, but like TDD, the practice did not spread as it should have. POs/QA often struggle to write good Gherkin and developers struggle with the glue code. But AI can solve both:
1. Generate Gherkin specifications with the help/review of POs and QA during specification.
2. Write the glue code (with Cucumber or the framework of your choice) during development. POs and QA get instant validation and avoid post-development bottlenecks.

6. Over-trusting AI-generated code

As we saw, providing good context and writing tests first to get better AI-generated code is primordial. But that's still not enough! What? You thought that leveraging AI, you'd have almost nothing to do?! You thought "developer" was a prehistoric job already?! Not at all!

Even with solid specs, steering docs, and TDD/BDD in place, AI can still hallucinate, miss requirements, forget some edge cases or introduce unexpected changes in your codebase. Your job now is to control what gets in (context and tests) and what gets out (review and guardrails).

Recommendations:

Humans always review AI-generated code.
Not just review, but understand the generated code. If you can't explain a function to your colleagues during PR review, don't commit it.
Human review alone is not enough. Enforce automated guardrails:
- CI/CD quality gates: minimum test coverage, linter, security scans, dependency checks, performance tests, documentation, no hardcoded secrets, etc.
- Staged rollout (e.g. 10% every 10 minutes) and automatic rollback.
- Manual gates for critical paths (auth, payment, external integrations), keep human in the loop, AI cannot decide these alone.

Don't forget: you're the owner of the code, even if your IDE generated it.

Anonymize your data using Amazon S3 Object Lambda

Jérôme Van Der Linden — Fri, 09 Jul 2021 14:59:12 +0000

Introduction

Personal Data in Europe, Personal Identifiable Information (PII) in the US, Client Identifying Data (CID) here in Switzerland, … Whatever the name you give it, the definition is slightly the same: it defines a category of information about an individual that can be used to unambiguously distinguish or trace his/her identity.
For example, passport numbers, social security numbers, IBAN or biometric records, known as direct identifying data, clearly identify an individual. Full names, addresses, phone numbers, dates of birth or emails can also be used to identify someone. However, as they can be shared by several people, you need to combine them to explicitly identify an individual - we say they are indirect identifying data.
This data, when maintained by a company, especially highly regulated one (Financial Services, Healthcare, …) or governing agency must comply with security standard and compliance certifications (GDPR, HIPAA, FINMA circulars, …). These certifications require this kind of data to be highly protected, from public leakage of course, but also internally from your own employees.
In this article, I will mainly focus on this second point. Today more than ever, data is key is to take appropriate decisions, create new services or improve existing ones. And if you want to share data internally, in order to build clever solutions, leveraging analytics and machine learning for example, you need to keep control on that data and ensure it remains compliant with aforementioned certifications.

Anonymization / pseudonymization

Anonymization or pseudonymization are some of the technics commonly adopted to do protect some data. In both case, you want to remove the ability to identify someone and more important the link to his personal information (financial, health, preferences…), while keeping the data practically useful. Anonymization consists in removing any direct (and part of indirect) identifying data. Pseudonymization does not remove these information but modify them so that we cannot make a link with the original individual.

Multiple papers, algorithms (k-anonymity) and technics exist to perform anonymization and pseudonymization. AWS also provides 2 functions — available in the Serverless Application Repository (SAR) — that use Amazon Comprehend and its ability to detect PII:

On my side, as the input file is pretty straightforward, I don’t need Comprehend to detect sensible information.

Here is my (naive) approach:

Remove any (identifying) field that is not useful to the downstream process. In my example, the SSN (social security number) is clearly useless for a data analytics application or to perform machine learning. Same thing for the phone number, address and name.
Remove some precision, by extracting only the meaningful part. For example, we don’t need the exact date of birth, an age may be enough.
If for any reason, we need to keep some identifying fields, then we must pseudonymize them. For example, we can replace the name with another, randomly generated.

After this process, we should end up with the following information, clear from any identifying information (names have been replaced):

Now that we know what we want to do, let’s see it in the context of our workload.

Architecture

We have 3 main components in our workload:

A confidential application, that deal with these data, used by doctors and other medical staff. In that case, the data is not anonymized.
A storage area (Amazon S3), where the data is kept as CSV files for further analytics. Raw data (with identifying information) is kept and protected with appropriate policies.
Another application, used to perform some analytics on this data (without identifying information). Actually, there could be many more applications like this with each their specific requirements and compliance rules.

To provide anonymized data to these applications, we have several options:

Create and maintain as many copies as there are applications with different requirements so that each one has its own version of the data.
Build and manage a proxy layer with additional infrastructure, so that you can manage this anonymization process between S3 and the target application.

Both options add complexity and costs. So this is were I introduce S3 Object Lambda, a capability recently announced by AWS and that will actually act as this proxy. Except that you don’t have to manage any infrastructure, just your Lambda function(s).

Implementation

Let’s implement this solution. First thing to do is to create a Lambda function. To do so, use your preferred framework (SAM, Serverless, CDK, …). I use SAM and my function is in Python 3.8.

The function must have permission to WriteGetObjectResponse, in order to provide the response to downstream application(s). Note this is not in the s3 namespace but s3-object-lambda:

{
    "Action":  "s3-object-lambda:WriteGetObjectResponse",
    "Resource": "*",
    "Effect": "Allow",
    "Sid": "WriteS3GetObjectResponse"
}

And here is the code of my function (commented to understand the details):

My Lambda function is really simple and if you would like to get something more production-ready, I encourage you to have a look at the AWS samples, mentioned above.

Once the function is created and deployed, we need to create an Access Point. Amazon S3 Access Points simplify managing data access for applications using shared data sets on S3, exactly what we want to do here. Using the AWS CLI:

aws s3control create-access-point --account-id 012345678912 --name anonymized-access --bucket my-bucket-with-cid

Then we create the Object Lambda Access Point. It will make the Lambda function act as a proxy to your access point. To do so with the AWS CLI, we need a JSON file. Be sure to replace with your account id, region, access point name (previously created) and function ARN:

Finally, we create the Object Lambda Access Point using the following command:

aws s3control create-access-point-for-object-lambda --account-id 012345678912 --name anonymize-lambda-accesspoint --configuration file://anonymize-lambda-accesspoint.json

And that’s it! You can now test your access point and the anonymization process with a simple get. Note that you don’t perform a get directly on the S3 bucket, but on the access point previously created, using its ARN, just like that:

aws s3api get-object --bucket arn:aws:s3-object-lambda:eu-central-1:012345678912:accesspoint/anonymize-lambda-accesspoint --key patients.csv ./anonymized.csv

You can now provide this access point ARN to the analytics application so it can retrieve anonymized data and perform whatever it needs to.

Conclusion

In this article, I’ve shared how to leverage S3 Object Lambda in order to anonymize your data. In just a few commands and a bit of code, we can safely share data containing identifying information with other applications without duplicating it or building a complex infrastructure.

Note that you can use the same technology to enrich some data (retrieving information in a database), or modify it on the fly (eg. image resizing), or modifying the format (eg. xml to json, csv to parquet, …), and I guess you will find some usage too.

The code of this article is available in github, together with a full sam template to create everything (bucket, access points and Lambda function).

Photos by Jason Dent and Tarik Haiga on Unsplash