Building azlan.engineer with AI-Assisted Engineering

Overview

I built azlan.engineer for two reasons. I needed a single, maintained place to explain my work as an engineering manager, and I wanted to evaluate AI-assisted development on a real project rather than a demonstration.

A personal website is a useful test. It is small enough to finish, public enough that quality matters, and it has real constraints: accessibility, hosting cost and long-term maintenance. I approached it as I would approach introducing a new tool to a team. I defined the outcomes first, chose the tools second, and paid attention to where the tools helped and where they did not.

The initial version of the site was built and deployed over a small number of focused sessions rather than a traditional multi-week side project. That made it a useful opportunity to evaluate whether AI could accelerate delivery without compromising quality, accessibility or maintainability.

The Challenge

My professional history was spread across a CV, a LinkedIn profile and private notes. Each told part of the story and none was complete. A CV is written for a particular application. LinkedIn is a platform with its own format. My notes were written for me. None of them gave a hiring manager or an engineering director a clear view of how I lead teams and make decisions.

I also had a second question. Much of the discussion about AI-assisted development is either enthusiastic or dismissive, and little of it is specific. I wanted first-hand experience of what these tools do well, where they need supervision, and what that means for managing teams that use them.

The project therefore had two purposes: a professional online presence, and an evaluation I could describe with evidence.

Objectives

I set six objectives before choosing any tools.

• A professional website. Clear, fast and credible to a senior reader who may only skim it.
• An engineering leadership portfolio. Present me as a manager and technical leader, with case studies about decisions and outcomes rather than a showcase of code.
• Automated deployment. Publishing a change should not involve manual steps.
• Accessibility. Meet WCAG 2.x AA as a design constraint, not a final check.
• Low-cost hosting. Keep running costs small and predictable.
• AI-assisted workflow evaluation. Record what the tools contributed and what still needed my judgement.

Technology Choices

Each choice had a specific reason, and most had a trade-off.

• Astro. The site is mostly read-only content. Astro produces static pages and ships very little JavaScript by default, which suits that content and helps both performance and accessibility.
• Tailwind CSS. Utility classes, together with a small set of design tokens in one stylesheet, kept the visual system consistent and predictable to change. The cost is more verbose markup, which I accepted for a site of this size.
• GitHub. Source control, review history and the trigger for deployment. A reviewable history of every change mattered more because much of the code was generated.
• Cloudflare Pages. Static hosting that deploys from a Git repository, builds previews for branches, and has a free tier that met the cost objective.
• Cloudflare Registrar. Registering the domain where DNS and hosting already live removed a vendor and a configuration step.
• Cloudflare Web Analytics. I wanted to know whether the site was being read without adding cookies or a heavy third-party script. It provides basic traffic information and little else, which is enough.
• Claude Desktop. Used for larger pieces of work: structuring content, designing the page, and producing and revising code in conversation.
• GitHub Copilot. Used in the editor for smaller, local changes where a conversation would be slower than a suggestion.

Using two assistants was deliberate. They work differently, and I wanted to see which kinds of task suited each.

Where AI Added Value

Homepage and Layout Generation

The assistant produced a working first draft of the page structure, the responsive layout and the dark and light themes quickly. Critiquing a draft is faster than starting from a blank file.

Content Structuring

Turning scattered material into a clear sequence of sections is a structuring problem, and the tools were good at proposing options. I could compare several structures before committing to one.

Technical Implementation

Page templates, build configuration and the theme switch are routine work, and the tools handled them well.

SEO

Page metadata, Open Graph tags, canonical URLs and structured data are well documented but tedious. The assistant applied them consistently.

Accessibility Recommendations

When asked, the assistant listed what to check: contrast ratios, focus visibility, motion, target sizes and text spacing. It also found problems in its own first draft, described below.

Faster Iteration

The cost of trying an idea fell. I could change a layout, decide against it and revert in the time it would normally take to set up the experiment, which made design decisions less speculative.

Where Human Judgement Was Essential

The tools did not decide what the site was for. Every decision that mattered was mine.

Positioning the Site as an Engineering Manager

A generated site tends towards what is easy to show, which is code. I steered the content towards decisions, people and outcomes.

Deciding What Content Mattered

Most of what could go on the site should not. I chose five areas of expertise and a small number of case studies. Generated placeholder copy included claims about outcomes that I could not substantiate, and I removed them. Where a case study is not yet written, the site says so.

Reviewing Generated Code

I treated generated code like any other proposed change to a codebase: read it, ask why it is written that way, and reject what I do not understand or do not want to maintain.

Editing Generated Content

First drafts were competent but generic. Editing for accuracy, tone and specificity was my work.

Accessibility Verification

The assistant could recommend and calculate, but it could not experience the page. Whether the site works with a keyboard and a screen reader is something a person has to check, so I kept that responsibility.

Product and Design Decisions

Dark mode by default, restrained motion and minimal navigation were decisions about audience and trade-offs, not output the tools could produce on their own.

Accessibility Considerations

I set WCAG 2.x AA as the target from the start, because retrofitting accessibility costs more than designing for it.

Semantic HTML

Landmarks, a logical heading hierarchy, and real lists, links and buttons, so assistive technology can navigate the structure without extra markup.

Keyboard Navigation

Every control works from the keyboard. There is a skip link, and the mobile menu uses native elements.

Focus Management

Focus indicators are always visible. Anchored sections and focused elements are not hidden behind the sticky header, and Escape closes the mobile menu and returns focus to its button.

Responsive Design

The layout reflows on narrow screens without horizontal scrolling, text can be resized, and interactive elements meet the minimum target size. Buttons use minimum heights so their text still fits when users override text spacing.

Colour Contrast

The colour tokens were checked by calculation against the AA ratios in both the dark and light themes.

The first generated version was good but not compliant. When I asked for an explicit review against WCAG, the assistant found and fixed several defects in its own work: a button border with a contrast ratio of about 1.6:1 where 3:1 is required, a decorative background animation that never stopped, fixed-height buttons that would clip text under custom text spacing, and footer link targets that were too small.

None of these would have been obvious from a visual check. They were found because the question was asked explicitly, which is the point. Accessibility has to be intentional.

Outcomes

Launch

The site launched on its own domain using the stack described above.

Automated Deployment

A change pushed to GitHub is built and deployed by Cloudflare Pages without manual steps, and branch previews let me review a change before it goes live.

Analytics

Cloudflare Web Analytics is enabled, so I can see which pages are read without using cookies.

Professional Portfolio

My experience, approach and case studies are now in one place that I control and can keep current.

AI-Assisted Delivery

The project provided practical experience of using AI to accelerate delivery while maintaining review standards, accessibility requirements and control over technical decisions.

Lessons Learned

Summarised below.

Key Lessons

AI Works Best With Strong Context

The output improved as my instructions became more specific about audience, positioning, constraints and tone. Vague requests produced generic work. The same is true when briefing people.

Human Oversight Remains Critical

The tools produced confident output, some of which was unsupported or non-compliant. Review is not an optional step.

Accessibility Must Be Intentional

It did not appear as a by-product of reasonable defaults. It appeared when it was a stated requirement and was checked.

AI Enables Faster Iteration

The main benefit was not writing code faster. It was the lower cost of changing direction.

Engineering Leadership Matters More Than Tooling

The tool choices were among the least consequential decisions in the project. Clear objectives, review standards and accountable decisions made the difference.

What I Would Do Differently

With the benefit of hindsight, there are several things I would change.

• Move content management into Astro Content Collections earlier.
• Create reusable templates for case studies from the beginning.
• Generate Open Graph imagery as part of the publishing workflow.
• Introduce accessibility validation earlier in the design phase rather than during review.

None of these changes are major, but they would make future iterations easier and reduce the amount of rework required as the site grows.

Reflection

This was a small project with one person making every decision, so it is an incomplete model of a team. It does not show how adoption works across many engineers with different habits, or how review capacity copes with a higher volume of changes. In an organisation those are the questions I would take seriously: where generated changes are reviewed, how quality is measured, and how people keep the skills the tools are taking over.

The project reinforced the idea that successful AI adoption is primarily a leadership and organisational challenge rather than a technical one.