EN
EN
Each problem is unique in its own way. Sometimes you get stuck with some bug without having an idea what to do next except to use joker “call other dev”. Sometimes you miss an estimate for the new feature by a lot just because you haven’t planned it properly or you have missed some obvious points because you haven’t asked the right questions at the right time.
As you gain experience, you probably start having your own way of approaching these problems, set of some unwritten. You formed these rules, by bleeding on some problems, basically from your mistakes and falls. Would it be better to gain advantage by developing/learning a strategy much earlier in a career, and avoid unnecessary bleeding.
Having an exact strategy on how to approach problems in development can make your life easier. Even though you don’t need to follow exact steps every time, you will by time incorporate these steps unconsciously in your routine. Start by forcing yourself to follow these steps, write them somewhere in a visible place in your (home)office. Let’s try to define strategy!
Even though your first tasks on your first real jobs will be to fix some minor bugs, soon after you will start working on some startup or get an opportunity to work on an important company project, there you will need to implement some features.
We have divided feature implementation in following steps:
- Analysis
- Estimation
- Coding
- Testing
Getting to know the feature you are developing is the most important thing, you need to know every corner of it and you need to know answers to all questions about it. Start by approaching the problem from a critical standpoint and label all those uncertainties you have and clear those things. Forget about all the technical details and just think of a functionality from a user perspective as if you are going to use it. Communicating properly with others in a team will be the only right way that will give results. So, communicating with a designer, PM , other devs, product and anyone else involved will save you a lot more time and meetings in a later phase.
This is the phase where most engineers spend less time than needed mostly because of:
- firm deadlines and they try to save time in analysis and estimation
- not willing to participate and communicate in meetings which are related to analysis
- because of mindset that these meetings are waste of time
- If you are less experienced engineer you might be having a fear of asking stuping questions
- jump on coding directly and try to figure out things during development
As a part of analysis you need to do following:
1. Read your ticket
Read your ticket carefully. Make sure all acceptance criterias are clear to you. If there are no AC’s, there must be some product or project manager who should explain the ticket to you.
After you have read your ticket, if you are working on client-side there should be some design that will show you what you need to code.
2. Design analysis
You need to analyze design, and communicate any potential discrepancies or unclarities with the designer.
- Check if designer is following design system and using standardized components
- Check if implementation complexity is on a much higher level then benefits we are getting?
3. Compare design and acceptance criteria (AC)
Compare ticket description (and AC’s) with implemented design. If they are not in sync, communicate those differences with products, PM and designer. You need to have a clear picture, and know everything about the feature you are going to implement.
4. Ask questions
- Don’t be afraid to ask questions about anything.
- Asking questions and proper communication is in general one of the most important things that will take you to successfully finalize your tasks on time.
5. Check the codebase and analyze technical implementation
After you are clear about what you need to implement, you should take a quick look at the current state of the app and check the codebase where you are adding this feature. Think from a logical standpoint, are there some things that are not possible to implement in a way that non-tech people have envisioned it. See if you have proper knowledge of the technology you are working on, try figuring out if you can implement requested or you need guidance from more senior dev.
Ask for opinions from people who have already touched that part of the app.
6. Client side - server side sync
Also, if you are interacting with the backend side (or vice-versa), you need to take into account if you have everything ready from the other side. Also, point out any additional work that should be done on the other side before you can complete your task.
7. Divide ticket into subtasks
After you have verified all the stuff mentioned, you need to create your own plan of the implementation. Divide ticket into minor subtasks, either creating those subtasks in reality or having it just on a piece of paper.
8. Create implementation plan
Write down your plan and keep notes of any future adjustments.
When approaching ticket estimation, the best case scenario is that you have done all the steps from analysis and you come prepared for the pointing session. Don’t be afraid to postpone estimations, or to reject estimating when things are not clear enough to you. Once you estimate the ticket, any broken deadline from the dev side is on you. Of course, some unexpected things will always happen, issues will occur, but you need to make sure that you did your best.
Why are most estimates inaccurate ?
- Not investing enough time in analysis phase - being unprepared
- Being too optimistic and not anticipating unexpected events
- Blind guessing
When estimating, you should keep in mind following things:
1. Estimate each subtask separately
Estimate each subtask separately and in the end just summarize the points.
2. Consider PR reviews
You should consider also adding some points for PR reviews - because those can take some time, especially when complex logic is implemented.
3. Meetings and communication in the team
Consider time you will need to invest into communication with the team if needed (ex integration)
4. Dev Testing
Dev testing is a really important part to minimize bugs produced, so that will take some time also. Also, if you are working in different environments, you need to test on all those also. If deploying is your responsibility, you should take into account that time also.
5. Unexpected things
And just when you thought you had your final estimate, pause for a second, and add some points for unexpected things. Always expect the unexpected.
Once the time has come for you to start coding your feature, just go over your plan and go task by task. Seek help on time once you are stuck, at least talk with someone or use the rubber duck method.
1. Split your code
It would be best to have one feature branch on which you will merge multiple minor subtasks - meaning split your code to get approvals faster. Dev test everything in detail.
2. Escalate the issues - push deadlines on time
If you encounter any issue, either something is much harder to implement or you notice something that you have missed, don’t be afraid to escalate the issue, to contact anyone involved in it. Be honest, don’t be optimistic in a way that the newly found issue won’t affect deadlines, sooner you accept it and push the deadline for a valid reason you will lower stress and pressure for everyone, most importantly for you.
3. Compare implementation with AC’s, design and description
When you finish coding and you are just about to create a PR, go over AC’s, ticket description and design and verify that your work is in sync with the requirements.
4. Self-review your code and seek improvements
Before creating a PR, you also need to do self-review of your code, and seek improvements. See if you can refactor something or do some other code improvements.
5. Think of edge cases and dev test everything once more
Dev test everything in detail - this will keep bugs away from you.
Try to find possible edge cases, be as destructive to your code as you can.
6. Create a PR
When creating a PR, add comments with explanations for problematic places where you feel that someone could add a comment. It is always better to comment first, to show that you are aware the code is not easy to understand.
7. Resolve comments, finalize discussions
To merge your code it is really important to resolve/reply to comments on your PR as soon as possible, so you don’t get conflicts and also to speed up merging PR. Don’t leave your PR in a vacuum for some time.
In the end, when your code is merged, test it on the environment once more to make sure that it really works.
Mistake that a lot of developers do is they skip environment specific testing and directly move ticket to QA and issues might arise:
- Code was not deployed because of build issues and QA returns ticket
- There are some environment specific bugs which you did not covered during dev testing
- Someone else changes uncovered one of the cases you haven’t handled properly
Handling bugs
While most of these rules and principles apply to bugs, there are some key differences in the approach that we will mention in this section.
Before we delve into the details on how to tackle bugs that have appeared in the feature development process, we should quickly mention the types of bugs that you might encounter.
Types of bugs
• Styling
◦ Description: Styling bugs refer to issues related to how elements are presented visually on the user interface.
◦ Examples: Incorrect colors, font sizes, margins, paddings, or issues with layout responsiveness.
• Logical mistakes
◦ Description: Logical mistakes are errors in the application's logic flow, where the program does not perform the intended actions due to flawed reasoning or oversight.
◦ Examples: Infinite loops, unreachable code, or unintended consequences of conditional statements
• Business logic
◦ Description: Business logic bugs are errors related to how the application handles specific rules and processes that are essential to the core functionality of the software.
◦ Examples: Incorrect calculations, flawed decision-making processes, or rules not applied correctly.
• Rendering
◦ Description: Rendering bugs occur when the content or elements on a webpage or application do not display correctly or as intended.
◦ Examples: Misaligned elements, overlapping content, or elements not appearing in the correct order.
• Cross browser compatibility
◦ Description: Cross browser compatibility bugs occur when a website or application behaves differently across various web browsers or versions.
◦ Examples: Features not working in certain browsers, layout issues specific to a browser's rendering engine, or performance variations.
• Data issues
◦ Description: Data issues involve problems with the integrity, accuracy, or consistency of data within the application.
◦ Examples: Incorrect data retrieval, data corruption, or mismatches between different data sources.
• State management
◦ Description: State management bugs involve problems with how data is stored and managed within an application, especially across different parts of the application.
◦ Examples: Inconsistent data updates, incorrect data being displayed, or data loss under certain conditions
These aforementioned bug types are most common bug types that you will encounter, some other notable mentions are:
• Compatibility issues
◦ Description: Compatibility bugs arise when the software does not work correctly with other software components or systems it needs to interact with.
◦ Examples: API changes not accounted for, incompatible library versions.
• Performance bugs
◦ Description: Performance bugs impact the speed or responsiveness of the software.
◦ Examples: Slow loading times, high memory usage, or inefficient algorithms causing delays.
• Security bugs
◦ Description: Security bugs involve vulnerabilities that could be exploited by malicious users or code.
◦ Examples: Incorrect authentication setup, missing authentication middleware.
• Localization issues
◦ Description: Localization bugs occur when the software does not behave correctly or display content properly in different languages or locales.
◦ Examples: Text truncation, incorrect date/time formatting, or issues with character encoding.
• Deployment bugs
◦ Description: Installation or deployment bugs prevent the software from being installed or deployed correctly.
◦ Examples: Configuration errors, incorrect environment variables
While all of these bug types could be a separate topic itself, we were thinking of a general way to handle all of these variations. It is not mandatory to take all these steps when fixing your bug, but it is a good idea to take all them into consideration when doing your development to minimize unexpected issues that might occur from your fix.
We have split this method into 4 parts: ticket analysis, problem analysis, coding, testing
Ticket analysis
1. Read the ticket carefully
a. Make sure you fully understand the problem at hand
b. Read the documentation related to the bug at hand to make sure you didn’t miss any hidden requirements or acceptance criteria
c. Ask questions to people who are reporters of the issue as well as your PM or team lead
d. Make sure everything is clarified2. Reproduce the bug
a. Sometimes a bug that is reported is not even a bug, a lot of the times the reporter of the issue did not go through previous point before the issue is raised
b. Make sure you understand under what circumstances this error is reproduced
c. If there are some more issues related than what is being reported, notify the PM/QA about it
3. Analyze
a. Confirm whether the issues is caused by client side or server side changes
b. Confirm whether the issues might be caused by another team
c. With proper analysis, there might be no need for development, problems are often solved by communication with the team
d. Make sure you document your analysis (post your findings in the comments of the ticket or similar)
e. Assume the feature is a black box and write all the IN-OUT cases for the feature and highlight those for which the problem presents itself
Problem analysis
1. Search where the issue happens on a higher level
a. Try to locate the screen/component where you think the problem resides
b. What is happening and how should it behave differently ?
c. When did the issue start to appear ? Get some insights from the Git Lens extension.
2. Debug the code to find the exact location of the culprit
a. In some cases, try not to look at the part where you think the bug is happening, sometimes you have to go a few steps back or a few steps further to locate the actual cause of the issue.
b. Read the lines of code line by line, understand what is happening under the hood
3. Think of the IN-OUT parameters that you wrote in the previous section, check if the line that you suspect produces unexpected results for the highlighted cases
Coding
1. By the time you come down to this part, you most likely know what change to make to fix the bug at hand
2. Visualize the problem, go over the exact steps that you have tried and didn’t work (Rubber duck)
3. If you don’t know how to do it (even after the analysis step), ask for help from a more senior developer
4. If you have a sense that you could write this code cleaner/better write it down
a. Always do some minor refactoring if you have the time to do so.
Testing
1. Developer testing
a. By doing proper developer testing, you will save valuable development/testing time further and lower the chances of encountering a “boomerang” effect with your bug ticket. Just think of the path the ticket has to go before it comes back to you.
b. Use the IN-OUT cases that you wrote in one of the previous steps to check if all works as expected
c. This includes testing your fix after your changes were deployed to the staging environment
One thing to note from all of this is that even the most senior don’t go through all of these exact steps, the point of this guide was that all of these points make a strategic way to tackle issues and to make sure they have tried with everything that is in their power. Usually, when this method doesn’t help, the developer mostly relies on the help of someone who had previous experience with a similar issue, someone more experienced or perhaps trying to fish for an answer on Stackoverflow which should always be the last resort.
Each problem is unique in its own way. Sometimes you get stuck with some bug without having an idea what to do next except to use joker “call other dev”. Sometimes you miss an estimate for the new feature by a lot just because you haven’t planned it properly or you have missed some obvious points because you haven’t asked the right questions at the right time.
As you gain experience, you probably start having your own way of approaching these problems, set of some unwritten. You formed these rules, by bleeding on some problems, basically from your mistakes and falls. Would it be better to gain advantage by developing/learning a strategy much earlier in a career, and avoid unnecessary bleeding.
Having an exact strategy on how to approach problems in development can make your life easier. Even though you don’t need to follow exact steps every time, you will by time incorporate these steps unconsciously in your routine. Start by forcing yourself to follow these steps, write them somewhere in a visible place in your (home)office. Let’s try to define strategy!
Even though your first tasks on your first real jobs will be to fix some minor bugs, soon after you will start working on some startup or get an opportunity to work on an important company project, there you will need to implement some features.
We have divided feature implementation in following steps:
Block quote
Unordered list
Bold text
Emphasis
Superscript
Subscript
Each problem is unique in its own way. Sometimes you get stuck with some bug without having an idea what to do next except to use joker “call other dev”. Sometimes you miss an estimate for the new feature by a lot just because you haven’t planned it properly or you have missed some obvious points because you haven’t asked the right questions at the right time.
As you gain experience, you probably start having your own way of approaching these problems, set of some unwritten. You formed these rules, by bleeding on some problems, basically from your mistakes and falls. Would it be better to gain advantage by developing/learning a strategy much earlier in a career, and avoid unnecessary bleeding.
Having an exact strategy on how to approach problems in development can make your life easier. Even though you don’t need to follow exact steps every time, you will by time incorporate these steps unconsciously in your routine. Start by forcing yourself to follow these steps, write them somewhere in a visible place in your (home)office. Let’s try to define strategy!
Even though your first tasks on your first real jobs will be to fix some minor bugs, soon after you will start working on some startup or get an opportunity to work on an important company project, there you will need to implement some features.
We have divided feature implementation in following steps:
Block quote
Unordered list
Bold text
Emphasis
Superscript
Subscript
Each problem is unique in its own way. Sometimes you get stuck with some bug without having an idea what to do next except to use joker “call other dev”. Sometimes you miss an estimate for the new feature by a lot just because you haven’t planned it properly or you have missed some obvious points because you haven’t asked the right questions at the right time.
As you gain experience, you probably start having your own way of approaching these problems, set of some unwritten. You formed these rules, by bleeding on some problems, basically from your mistakes and falls. Would it be better to gain advantage by developing/learning a strategy much earlier in a career, and avoid unnecessary bleeding.
Having an exact strategy on how to approach problems in development can make your life easier. Even though you don’t need to follow exact steps every time, you will by time incorporate these steps unconsciously in your routine. Start by forcing yourself to follow these steps, write them somewhere in a visible place in your (home)office. Let’s try to define strategy!
Even though your first tasks on your first real jobs will be to fix some minor bugs, soon after you will start working on some startup or get an opportunity to work on an important company project, there you will need to implement some features.
We have divided feature implementation in following steps:
Block quote
Unordered list
Bold text
Emphasis
Superscript
Subscript
Each problem is unique in its own way. Sometimes you get stuck with some bug without having an idea what to do next except to use joker “call other dev”. Sometimes you miss an estimate for the new feature by a lot just because you haven’t planned it properly or you have missed some obvious points because you haven’t asked the right questions at the right time.
As you gain experience, you probably start having your own way of approaching these problems, set of some unwritten. You formed these rules, by bleeding on some problems, basically from your mistakes and falls. Would it be better to gain advantage by developing/learning a strategy much earlier in a career, and avoid unnecessary bleeding.
Having an exact strategy on how to approach problems in development can make your life easier. Even though you don’t need to follow exact steps every time, you will by time incorporate these steps unconsciously in your routine. Start by forcing yourself to follow these steps, write them somewhere in a visible place in your (home)office. Let’s try to define strategy!
Even though your first tasks on your first real jobs will be to fix some minor bugs, soon after you will start working on some startup or get an opportunity to work on an important company project, there you will need to implement some features.
We have divided feature implementation in following steps:
Block quote
Unordered list
Bold text
Emphasis
Superscript
Subscript
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript
An AI coding agent is only as good as the process around it. Since August we have been building the internal startup - a Next.js client and a NestJS backend - with Claude Code doing most of the typing, and the thing that made it work was not the model. It was the scaffolding: AWS's AI-Driven Development Life Cycle (AI-DLC), our own coding guidelines, a ClickUp-driven ticket workflow, and a small set of Model Context Protocol (MCP) servers that let Claude see the design, drive a browser and update tickets.
The numbers so far: roughly 900 commits and 340 merged PRs on the client, 210 commits and 68 merged PRs on the backend, since the first commit on 29 July 2026. Every one of those PRs went through the same pipeline.
The problem we set out to solve at Sunray is familiar to anyone who has used an agent on a real codebase. Ask for a feature and you get a feature - plausible code, invented requirements, a new library you didn't approve, styling that works on desktop only, and a cheerful "Done!" with no tests run. Unstructured prompting scales badly. What we wanted was an agent that asks before it guesses, writes down what it decided, codes the way our team codes, and cannot call something finished until it is.
Every ticket runs left to right through the same stages; MCP servers and the guidelines feed in from above, every stage logs below, and a hook guards the move to review.
AI-DLC is an open-source set of rule files from AWS (awslabs/aidlc-workflows) that turns an AI assistant into a workflow orchestrator. Instead of "write me X", the agent walks the work through three phases, and only runs the stages the work actually needs.
Four ideas make it different from a long system prompt:
The rules also ship opt-in extensions - security baseline, resiliency, property-based testing - that become hard, blocking constraints when you say yes to them during Requirements Analysis, and cost no context when you say no.
Both repos - service and client - carry the same AI-DLC package, so Claude behaves identically on either side of the API.
| Phase | Question it answers | Stages |
|---|---|---|
| Inception | What are we building, and why? | Workspace Detection, Reverse Engineering (brownfield), Requirements Analysis, User Stories, Workflow Planning, Application Design, Units Generation |
| Construction | How do we build it? | Per unit: Functional Design, NFR Requirements, NFR Design, Infrastructure Design, Code Generation, Build and Test |
| Operations | How does it run? | Placeholder in the current rules |
repo-root/
├── CLAUDE.md # our rules + auto-applies AI-DLC + ClickUp ticket gate
├── AGENTS.md # same gates for other agents (client)
├── .aidlc-agent/
│ ├── core-workflow.md # upstream AWS orchestration rules
│ └── agent-config.yml # rule dir, output dirs, enabled extensions
├── .aidlc-rule-details/ # upstream stage rules: common/ inception/ construction/ extensions/
├── .claude/
│ ├── agents/aidlc-agent.md # the orchestrator subagent
│ ├── agents/browser-qa.md # browser verification subagent (client)
│ ├── skills/clickup-dev-workflow/
│ ├── skills/browser-verification/
│ ├── hooks/require-browser-verification.mjs
│ └── settings.json # PreToolUse hook wiring
├── .mcp.json # Playwright MCP (client)
├── coding-guidelines/ # our standards, one file per topic
└── aidlc-docs/ # generated: audit.md, aidlc-state.md, plans, requirementsThree decisions shaped this layout:
Enabled extensions in agent-config.yml: security baseline, property-based testing, and browser verification - a custom extension we wrote that is not part of upstream.
AI-DLC tells Claude how to work; it says nothing about how our code should look. That is what coding-guidelines/ is for: 15 topic files on the client (React, Next.js, styling, accessibility, data integration, icons…) and 15 on the backend (validation, API design, OpenAPI, database, logging…), plus an examples/ folder of copyable patterns: a component, a transform, a Zod schema, a controller and DTO, a guard, an e2e test.
The trick that makes them usable by an agent is routing. CLAUDE.md is short and is mostly two tables:
Then come the non-negotiables, a numbered list Claude cannot argue with. A few from the client:
The most important file is definition-of-done.md, which Claude must read before and after implementing. Its primary rule: work is done only when every request in the ticket is implemented. "Done ≠ code was written": it is a checklist of ticket completeness, the guideline gate (right layer, accessible forms, checked at 360px, tests for non-trivial transforms) and a hand-off that names any guideline that was bent and why.
The guidelines plug into AI-DLC at Code Generation: the stage's plan has to follow them, and Build and Test checks against the DoD. The same rules also feed CodeRabbit on the backend: .coderabbit.yaml mirrors CLAUDE.md so the PR reviewer enforces exactly what the author was told. One source of truth, two enforcers.
AI-DLC decides how a piece of work is analysed and built. clickup-dev-workflow, a Claude skill in .claude/skills/, decides which work, and keeps the ticket honest about its state. Both CLAUDE.md and AGENTS.md carry a ticket gate: if a developer starts a session without naming a ClickUp ticket (ID, link or title), Claude asks for one and does not begin implementation until it has it.
Once a ticket is named, the skill runs the lifecycle:
| Move | What has to be true first | What Claude posts |
|---|---|---|
| Backlog → In Progress | Ticket fetched and confirmed; requirements resolved | 🚀 Started: branch, developer |
| (during work) | - | 📝 Progress: completed, remaining, decisions |
| In Progress → In Review | tsc, lint and build pass; browser verification PASS for the branch head; PR opened from the template | 👀 Ready for review: PR, criteria ticked, verification, screenshots + video attached |
| In Review → Done | Reviewed and merged; the developer confirms | ✅ Completed: summary, merge link |
| Blocked | Status does not move | 🚫 Blocked: reason, waiting on |
A few rules in the skill do a lot of work:
Rules tell Claude what to do; MCP servers let it actually do it. Three servers carry this setup, each tied to a specific stage of the workflow.
| MCP server | What Claude uses it for | Where it plugs in |
|---|---|---|
| ClickUp | Fetch tickets, subtasks and vision docs; move statuses; post 🚀/📝/👀/🐛 comments; upload screenshots and the walkthrough video; create follow-up tasks | Ticket gate, requirements resolution, every status change |
| Figma | get_design_context and get_screenshot on the ticket's frames, so UI is built from the real design and tokens | Requirements and Code Generation; visual comparison during verification |
| Playwright (@playwright/mcp, headless Chrome, 1440×900) | Drive the running app: click through each acceptance criterion on desktop and mobile, record screenshots and video, read console errors | Bug reproduction, Build and Test, PR before/after screenshots |
Playwright is the one that changed the most. Upstream AI-DLC's Build and Test stage only writes test instructions. Our company added a custom extension, Browser Verification (BV), that makes it run them. During Requirements Analysis, Claude asks how the ticket should be verified:
Rule BV-01 then requires a "Verification" section in the requirements doc: one browser scenario per visible acceptance criterion, with viewport, auth state, data, steps and expected result. At Build and Test, a dedicated browser-qa subagent runs those scenarios through Playwright MCP and returns a one-line verdict - PASS, FAIL or BLOCKED - with the report path and key screenshots. It never changes application code.
And it can't be skipped by accident. A PreToolUse hook in .claude/settings.json intercepts every clickup_update_task call. Moving a ticket to review is blocked unless report.md for that ticket says PASS for the current branch head SHA, or an explicit WAIVED (with who and why) or NOT_NEEDED. Push one more commit after verification and the gate closes again. That is the difference between a guideline and a guarantee.
Here is what one feature looked like, reconstructed from aidlc-docs/audit.md.
The audit trail also records where things went sideways, which is half its value. During Sign Up, the Figma MCP hit its tool-call limit mid-task; Claude stopped and asked rather than guessing, and we pasted a screenshot of the mobile frame instead. In the Forgot Password session the ClickUp MCP wasn't connected, so Claude couldn't create the follow-up task - it logged that as an open item in both the requirements and the state file rather than silently dropping it.
Each layer on its own is useful. Together they cover each other's blind spots.
| Layer | Answers | Without it |
|---|---|---|
| AI-DLC | How should this work be analysed, planned and built? | Claude jumps to code and invents requirements |
| Coding guidelines + DoD | What does good code look like here, and when is it finished? | Correct process, generic code; "done" means "compiles" |
| ClickUp workflow | Which work, and what state is it in? | Work drifts from tickets; nobody can see progress |
| MCP servers | Can Claude see the design, run the app, update the ticket? | Developers copy-paste between Figma, browser, ClickUp and the chat |
| Hooks | Is the gate actually enforced? | Rules become suggestions the moment they're inconvenient |
What Sunray got out of it in practice:
The model is the engine, but the process is the steering. AI-DLC gives Claude a disciplined way to work, your guidelines give it your taste, a ticket workflow ties every change to a reason, and MCP plus hooks turn the whole thing from advice into something that actually runs.
If you want to try it, add it in layers rather than all at once:
About 400 merged PRs in, we would not go back to prompting without it.
What is AI-DLC?
AI-DLC (AI-Driven Development Life Cycle) is an open-source workflow from AWS that guides an AI coding assistant through Inception, Construction and Operations phases, with approval gates and an audit trail at every stage.
Does AI-DLC work with Claude Code?
Yes. Sunray runs it in Claude Code by importing core-workflow.md into CLAUDE.md and running the orchestrator as a Claude Code subagent. The same rule files also work with Amazon Q Developer, Kiro, Cursor and GitHub Copilot.
How do coding guidelines fit into AI-DLC?
AI-DLC defines the process; coding guidelines define the standard. Sunray routes Claude to the relevant guideline file from CLAUDE.md, and a Definition of Done decides when work is finished.
Which MCP servers are most useful for AI-assisted development?
For a web product, the three that mattered most for Sunray were ClickUp (tickets and status), Figma (design context) and Playwright (browser verification).
Is AI-DLC overkill for small changes?
It adapts: small changes skip most stages, with the reason logged. Some ceremony remains, which is the price of an agent that never decides things silently.
