My Approach to AI-Assisted Web Development: An SDLC

Building a good website is not simply a matter of asking an AI agent to generate a page. The result depends on the research, design judgement, technical decisions, implementation guidance, and verification that happen around the agent. This is the process I follow when developing websites, from the first requirements discussion to review and QA.

The workflow combines human creativity and technical judgement with AI-assisted research and implementation. AI can accelerate many activities, but it does not remove the need to make decisions, challenge assumptions, review the result, or verify that the website is secure and accessible.

The lifecycle at a glance

The phases below form a practical lifecycle, not a rigid waterfall. Design work can return to research, implementation can reveal gaps in the specification, and review findings can send work back to an earlier phase.

flowchart TD
    A["1. Requirements and understanding"] --> B["2. Visual research and inspiration"]
    B --> C["3. Design exploration and mockups"]
    C --> D["4. Design synthesis"]
    D --> E["5. Component-by-component refinement"]
    E --> F["6. Architecture and technology research"]
    F --> G["7. Specifications and AI-assisted planning"]
    G --> H["8. AI-assisted implementation"]
    H --> I["9. Extensive review"]
    I --> J["10. Testing and QA"]
    J --> A
    I -. "Findings and rework" .-> G
    E -. "New references" .-> B

Security and accessibility run across the lifecycle. They are considered during requirements, design, architecture, planning, implementation, review, and final QA. They are not optional tasks to add after the website is finished.

Phase 1: Requirements and understanding

The first step is understanding the requirements.

• Read the requirements, task, or ticket carefully.
• Understand what is being requested and what the expected outcome should look like.
• Ask questions whenever something is unclear.
• Identify the actual needs of the project before moving into design or implementation.
• Identify security requirements, including authentication, authorization, sensitive data, privacy, and potential risks.
• Identify accessibility requirements and the expected accessibility target.

The goal is to understand not only what we are building, but also what we need to protect and who needs to be able to use it.

Phase 2: Visual research and inspiration

The second step is doing online research. Look for competitors, similar websites, and other examples on the internet.

You can also bring back websites or examples that you have seen before and liked. The goal here is to make your eyes rich, meaning that you observe as many good examples as possible to get inspired and develop a better understanding of what good design looks like.

Don’t limit yourself to one or two examples. Explore different websites, layouts, components, and design approaches.

Also, pay attention to accessibility while researching. Look at how good websites handle navigation, readability, contrast, interactive elements, and responsive layouts. Visual inspiration should not come at the cost of usability.

Phase 3: Design exploration and initial mockups

Depending on which design tools you use, you can start creating design concepts.

For example, I use Claude Design because our team uses Claude from Anthropic. You can also use Figma, which is traditionally one of the common tools for this stage.

What I usually do is identify around 3 to 7 examples from the internet that I consider the best ones or the ones I like. Then, I use AI to create replicas or adaptations of these designs and see how they would look with our own website content.

For example:

• Use our own website content instead of the original website’s content.
• Apply our own color palettes, fonts, and design files.
• Apply our own branding and visual identity.
• See how our actual website would look and feel if we adopted each of these designs.

Not every example will necessarily look good when you replace its original content with your own. Something that looks great on one website might not work as well with another website’s content.

I also like to put all these design concepts into one file so I can compare them side by side immediately.

You can use AI to accelerate this process. For example, Claude Design or Claude Code can help create these different design artifacts.

Another thing I have noticed is that superiors or team leaders don’t always immediately understand your vision. Sometimes, when you find something good, they keep asking for changes, and eventually, the result becomes something that doesn’t look as good as the original idea.

That’s another reason why I prefer to prepare different visual options first, so there is something concrete to compare.

Phase 4: Design synthesis and selecting the best ideas

This is where I start combining the best things from the different designs.

I keep looking at the examples and asking myself: What are the things that are good in each example? Why does this website look good? What is it about this particular design that attracts me?

For example:

• From one website, I might like the hero section.
• From another website, I might like the navigation bar.
• From another template, I might like a specific component or section.
• From another example, I might like the overall layout, colors, or interactions.

I keep cutting, adding, and combining different components from different designs until I come up with one or two options, sometimes three.

These are not necessarily final designs. They are more like final drafts or candidate mockups that combine the best things I identified from the original examples.

Sometimes, during this process, I discover another website or template that I like, so I go back and repeat the previous research and design exploration steps.

This is largely about my own taste and my ability to identify good design elements and understand what works well together.

Of course, to accelerate the process, I ask AI to make the changes. For example, I can tell it to bring a particular component from one template into another design. AI can implement these changes immediately.

By the end of this phase, I usually have two or three candidate mockups.

Phase 5: Component-by-component design refinement

Now comes one of the most important parts of the process.

You take every specific component, section, area, or page of the website and start developing, improving, and building on it, one by one.

I usually work section by section and component by component.

For example:

• Improve the UI and UX of each section.
• Adjust colors and visual consistency.
• Add motion and animations.
• Add effects and improve interactions.
• Improve how the components look and feel.
• Edit or prepare images when necessary. Sometimes I even use Canva for image editing.

And I do this for each of the candidate mockups, not just one of them.

This is where human creativity becomes particularly important.

AI can implement what you ask it to implement, but it cannot replace your own ability to identify what looks good, what should be changed, and how different design elements should come together.

For example, I might look at a component and think that adding a little motion would make it look much better. I then explain exactly what motion I want, and AI can implement it.

However, if you simply ask AI to “make it look better,” it doesn’t necessarily know what you have in mind or what you consider better.

No matter how much you ask AI, without providing a clear direction, an example, or an explanation of what you actually want, the result might not align with your vision.

Accessibility considerations are also part of design refinement:

• Make sure the color combinations provide sufficient contrast.
• Make sure text is readable and doesn’t rely entirely on color to communicate information.
• Consider keyboard navigation and visible focus indicators.
• Make sure buttons, links, and interactive elements are easy to identify and use.
• Consider animations and motion preferences, including reduced-motion settings.
• Make sure the design works across different screen sizes and zoom levels.

The goal is not to sacrifice visual quality for accessibility. It is to achieve both.

In this phase, your creativity and visual judgement provide the direction, while AI helps implement and accelerate your ideas.

Phase 6: Architecture, technology stack, and security research

Now, we start another research process, but this time, instead of researching design, we research the technology stack.

I go back to the requirements and start identifying multiple possible architectures, frameworks, and technologies that fit the specific requirements and needs of the website.

The goal is to identify which architecture, frameworks, and technology stack would be the best fit for this particular project.

This depends on the requirements. What works best for one website might not necessarily be the best choice for another. It could be a company website, a product website, a platform, or even a landing page.

You can do normal online research and documentation research, or use AI to help with the process.

You can also empower AI with proper plugins or MCPs for web research, web crawling, and scraping. For example, I use Firecrawl as a tool for web research and crawling.

Security needs to be considered during architecture selection, not added later as an afterthought.

Depending on the project, I also consider:

• Authentication and authorization architecture.
• Data flows, trust boundaries, and the attack surface.
• Secure handling and storage of sensitive information.
• Secrets and credential management.
• API security and input validation.
• Dependency security and maintenance.
• Appropriate logging, monitoring, and error handling.
• The principle of least privilege.

I also consider whether the selected frameworks and component libraries support accessible implementation and work properly with assistive technologies.

By the end of this phase, you should have identified the most suitable architecture and technology stack for the project, taking both functionality and security into consideration. The OWASP Application Security Verification Standard can help turn web application security expectations into testable requirements. NIST’s Secure Software Development Framework provides practices that teams can integrate into their own SDLC.

Phase 7: Specifications and AI-assisted planning

Now we move into the planning stage, which is part of the AI-assisted SDLC.

At this point, I use AI to help prepare the specifications and implementation plan.

You need to define:

• What should be included and what should not be included.
• The actual requirements and scope of the implementation.
• What the official documentation recommends.
• What needs to be implemented and how.
• What might have been overlooked during the initial requirements phase.
• What security requirements and protections need to be implemented.
• What accessibility requirements need to be satisfied.

You can first create a specification document (spec), which is similar to the requirements but much more detailed. After that, you can create the implementation plan based on the specification.

You can also ask AI to help identify missing requirements, ask questions, and highlight things you might not have considered.

Personally, I use Ultrapowers from the marketplace/plugin ecosystem to help with brainstorming and planning.

Reviewing the specification and implementation plan

Now comes another important step: reviewing the specification and implementation plan created by AI.

You need to make sure that the plan is exactly what you wanted. Nothing more, nothing less.

One thing I have noticed is that AI tends to make a lot of assumptions on your behalf. This depends on the model and the AI agent you are using, whether it is Claude, Codex, OpenCode, Pi, Devin, or something else.

For example, I have noticed that Claude models can sometimes make many assumptions, which is something I strongly disagree with when it comes to implementation planning.

You need to carefully review the plan and make sure that AI hasn’t assumed anything that doesn’t align with your requirements.

One good thing about Ultrapowers, for example, is that it forces AI to document the assumptions it has made at the bottom of the plan file.

That’s helpful, but you still need to read the entire plan and make sure everything is aligned with what you actually require.

If you find assumptions that are outside the scope or don’t match what you want, you need to ask AI to revise the plan or manually change it. You can also answer the missing questions or fill the gaps that were overlooked during the planning phase.

Security and accessibility planning gate

Before moving into implementation, I consider security and accessibility explicit requirements that must be included in the approved specification and implementation plan.

Security checklist:

• Identify the main threats and potential attack vectors.
• Define authentication and authorization requirements.
• Identify sensitive data and how it should be protected.
• Define input validation and output encoding requirements.
• Identify security testing and dependency scanning requirements.
• Document security assumptions, risks, and mitigations.

Accessibility checklist:

• Define the accessibility target. A recommended baseline for many web projects is WCAG 2.2 Level AA, unless the project has different requirements.
• Define keyboard navigation and focus management requirements.
• Define semantic HTML and accessible component requirements.
• Include color contrast, labels, alternative text, and screen reader considerations.
• Identify how accessibility will be tested and verified.

The gate here is simple: the specification and implementation plan should not be approved until security and accessibility requirements are understood, documented, and included in the implementation scope.

Phase 8: AI-assisted implementation

Now we move into implementation.

You can ask AI to implement the approved plan. There are multiple approaches you can use.

Option 1: Native sequential development

This is the usual approach, where the AI agent takes the implementation plan and works through the tasks one after another.

Option 2: Sub-agent development

Here, the main AI agent acts as an orchestrator and spawns multiple sub-agents to handle different responsibilities.

For example:

• An implementer agent.
• A reviewer agent.
• Other specialized agents depending on the requirements.

The approach you choose depends on how many tokens you are willing to spend, how much time you have, and how complex the project is.

Sub-agent development can be slower and is a little more advanced. If you don’t really know how to guide the orchestrator or the main agent, it can become a very slow process.

Anyway, both approaches can be used to implement the approved plan. The important thing is to provide AI with a clear plan and make sure it follows it.

Security and accessibility must also be implemented as part of the actual development work.

For security, this means following secure coding practices, validating inputs, enforcing authorization on sensitive operations, protecting secrets, handling errors safely, and avoiding unnecessary exposure of sensitive information.

For accessibility, this means using semantic HTML, accessible components, appropriate labels, keyboard-operable interactions, visible focus states, and properly structured content.

These should be implemented component by component and feature by feature, rather than waiting until the end to discover that the website is inaccessible or insecure.

Phase 9: Extensive review

Now comes the tricky part, and probably one of the most important phases: reviewing the implementation.

You need to do a really strong review of what AI has implemented.

AI can help you review its own work, but you can also use third-party reviewers, specialized tools, or other AI agents to review the implementation independently.

For example, I use Ultrapowers. It has a skill called Task Review, which is actually a group of different skills. It performs multiple review activities and can spawn multiple agents to check the code and even perform UI testing.

There are different approaches and tools you can use here, but the important thing is that you should not simply trust the implementation because AI says it has completed the task.

What I usually focus on during this phase is AI drift.

AI can drift during implementation. Sometimes it can claim that it has done something when it hasn’t, sometimes it takes an easy or lazy approach, and sometimes it overcomplicates things.

It can also drift away from the original requirements or the implementation plan that we agreed on earlier.

These are some of the main problems you face when working with AI agents.

That’s exactly why I consider this an extensive review phase. You need to verify that what AI implemented is actually what you asked for, that it follows the approved plan, and that the quality is acceptable.

Security review gate

Security review needs to be an explicit part of the implementation review.

Depending on the project, I would use:

• Static application security testing (SAST).
• Software composition analysis and dependency vulnerability scanning.
• Secret and credential scanning.
• Dynamic application security testing (DAST), where applicable.
• Manual review of authentication, authorization, API access, and sensitive data handling.
• Review of input validation, output encoding, injection risks, session management, and security configurations.
• Verification that sensitive information is not exposed through logs, error messages, client-side code, or public endpoints.

You can use specialized security tools, third-party reviewers, or independent AI agents to help with these checks.

Security pass criteria: No unresolved critical or high-severity security findings should proceed to sign-off without explicit, documented risk acceptance by the responsible owner and appropriate mitigation. Security testing results and any accepted risks must be recorded.

Accessibility review gate

Accessibility also needs an explicit review, not just a visual inspection.

I would combine automated accessibility testing with manual testing.

For example:

• Check color contrast and text readability.
• Verify keyboard-only navigation.
• Verify visible focus indicators and logical focus order.
• Check semantic HTML, headings, labels, and accessible names.
• Check alternative text for meaningful images.
• Test forms, validation messages, dialogs, menus, and interactive components.
• Check responsive layouts and zoom behavior.
• Test screen reader compatibility.
• Verify that animations respect reduced-motion preferences.

Automated tools can help identify many problems, but they cannot replace manual testing.

Accessibility pass criteria: The implementation should meet the agreed accessibility target, ideally WCAG 2.2 Level AA. Known blocking Level A and AA issues must be fixed before sign-off, or formally documented with an approved exception and remediation plan.

The important thing is that both security and accessibility have their own review criteria and evidence. Passing a general code review does not automatically mean the implementation is secure or accessible.

Phase 10: Testing and QA

After the review phase, you move into testing.

At this point, the implementation needs to go through proper testing and QA. You can move the task into the development and QA stages and have an independent reviewer, including a human reviewer, verify the result.

The goal is to make sure that the website works as expected and that the implementation meets the original requirements.

Testing should include:

• Functional testing of the implemented features.
• UI and responsive testing across different screen sizes.
• Performance and loading checks.
• Regression testing.
• Security testing and verification of previously identified issues.
• Accessibility testing, including keyboard and assistive technology checks.

Final QA and release-readiness gate

Before the task is considered ready for delivery:

Security:

• Required security checks have been completed.
• No unresolved critical or high-severity security findings remain without approved, documented risk acceptance.
• Sensitive data, authentication, authorization, and security configurations have been verified.
• Any remaining security risks are documented and assigned to a responsible owner.

Accessibility:

• The agreed accessibility target has been tested.
• Automated and manual accessibility checks have been completed.
• No known blocking accessibility issues remain without an approved exception and remediation plan.
• The website has been verified for keyboard navigation and relevant assistive technology support.

General QA:

• Functional and regression tests pass.
• The implementation matches the approved requirements and specification.
• UI and responsive behavior have been verified.
• An independent human reviewer has reviewed the result.

After these checks, the task can proceed through the normal CI/CD and deployment process.

CI/CD, deployment, automated code-quality checks, and additional release controls are part of the broader delivery process. They are slightly outside the scope of the development process I’m describing here, but security and accessibility gates should remain part of release readiness.

The overall process

The general lifecycle can be summarized as follows:

1. Requirements and understanding
2. Visual research and inspiration
3. Design exploration and initial mockups
4. Design synthesis and selecting the best ideas
5. Component-by-component design refinement
6. Architecture, technology stack, and security research
7. Specifications and AI-assisted planning
8. AI-assisted implementation
9. Extensive review
10. Testing and QA

Three important quality gates

Security and accessibility are not isolated phases. They are cross-cutting requirements that should be considered throughout the entire lifecycle.

Gate	When	What must be verified
Design and planning gate	Before implementation	Security requirements, threat considerations, accessibility target, and acceptance criteria are documented and approved.
Implementation review gate	After implementation, before QA sign-off	Security review, vulnerability scanning, code review, and accessibility testing have been completed.
Release-readiness gate	Before deployment	Critical risks are resolved or formally accepted, accessibility requirements are met or documented exceptions approved, and QA is complete.

Final thoughts

The process is iterative rather than strictly linear. For example, during design exploration, I might return to visual research and find new references. During implementation, I might identify something that requires revisiting the specification or architecture.

The central idea is that AI accelerates execution, research, and implementation, but human creativity, technical judgement, decision-making, security awareness, accessibility considerations, and quality control determine the direction and the final result.

References

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2. The W3C Recommendation for testable web accessibility success criteria.
• OWASP, Application Security Verification Standard (ASVS). A framework of security requirements for designing, developing, and testing web applications and services.
• NIST, Secure Software Development Framework (SSDF). Secure development practices that can be integrated into an organization’s SDLC.