Personal experiment · Agentic coding
Built with AI.
Verified in stages.
How this personal website took shape—and what was checked before it went live.
- Article date
- Experiment began
- Sources checked
01CASE STUDY
Scope and evidence
I used Codex to create this English personal website with Vite and TypeScript. It presents my interests, experiments and research notes. The site is static: there is no application backend, account system or payment flow. Fonts and media are served with the site.
The first local implementation and its initial checks took about twenty minutes: 10 October 2026, 18:48–19:08 CEST. Planning preceded that turn. The current site, additional review and public release came later. This is elapsed time for one recorded implementation turn, not a benchmark or the total time spent on the website.
The chronology and results below are drawn from this project’s execution records. “Plan requirement” means a check was already in my approved acceptance criteria. “Agent-initiated” means the agent selected an action within the task. “Owner-requested review” identifies my additional prelaunch instruction. “Configured check” means a check was set up in this project. These describe this run, rather than universal Codex defaults.
02CASE STUDY
From plan to public website
Define the experiment
I approved the visual reference, minimal English copy and personal projects. The plan specified mobile navigation, keyboard access, reduced motion, a Canvas fallback and a successful production build. These acceptance criteria shaped the implementation and its checks.
Create the first local version
Codex implemented the landing page, point field, intro, project ring and accessible dialogs. It ran TypeScript and build checks, inspected the browser and corrected issues. The result at this stage was a local version, rather than the complete public site.
Refine the content and interfaces
Further iterations added the AI journey, insights, research articles, threat catalogs and project captures. Personal wording, navigation and privacy copy were refined; the session display was removed. Checks of changed layouts and journeys caught mobile text overlap and graphic layout issues, which were corrected.
Request an additional prelaunch review
I explicitly requested technical, editorial and security-oriented review, with findings reported before publication. Separate AI reviewers examined the implementation, claims and public assets. A read-only review-agent workflow was used; dependency audits were added.
Fix findings and review the fixes
Codex corrected the six findings listed below, repeated the affected checks and inspected the resulting build. The follow-up also caught a startup behavior that could replace already rendered content and lose reading state; that was corrected before release.
Publish and verify the live result
Private version control was connected to Vercel and the domain configured through Hostinger. Codex checked HTTPS, redirects, live pages and assets, interactive behavior and the public Privacy Note. The domain’s existing email records were preserved.
Check subsequent changes
Subsequent edits were kept in version control, built, reviewed in the affected scope and inspected after publication. Later changes included replacing the illustrative JSON panel with catalogs and research questions. A passed build is one repeatable gate; it does not replace reviewing a changed source, interaction or data boundary.
03CASE STUDY
What was checked
Results describe the corrected initial release, checked on 11 October 2026. The checks answer different questions; their combined presence does not establish complete security coverage.
TypeScript and production build
pnpm check runs tsc --noEmit. pnpm build runs that TypeScript check followed by vite build; Vercel uses the same build command. Later edits also used git diff --check to inspect whitespace. These check types, build output and formatting issues, rather than linting or vulnerabilities.
Browser behavior and accessibility
Browser checks covered layouts at 1440, 1024, 390 and 320 pixels, including short viewports; navigation, direct routes, reloads and fragments; ring drag and keys, dialog dismissal and focus return. They also covered forward and backward scrolling, reduced motion, Canvas fallback, console errors and missing assets. These were tool-driven checks, not a retained automated regression suite.
Code and security-oriented review
A separate reviewer inspected rendering, media boundaries, data handling, event cleanup, navigation, dialogs and motion behavior. The review examined the current implementation; no earlier Git baseline existed at its start. This was AI-assisted source inspection, not a SAST tool or a configured GitHub Codex review.
Dependency vulnerabilities (SCA)
Both pnpm audit --prod and pnpm audit returned “No known vulnerabilities found” on 11 October 2026. This is a point-in-time check against known dependency advisories. It does not analyze the website’s own logic or establish that dependencies have no undiscovered vulnerabilities.
Privacy and public asset boundaries
Reviewers searched code and the build for storage, tracking, network calls, credentials and internal material, and inspected screenshots and image metadata. A project capture exposed internal development details and was replaced. No credentials, raw private documents or source maps were found in the inspected bundle. The implementation used no application cookies, persistent visitor identifiers, analytics or remote font/media dependencies. Hosting still processes requests as described in the Privacy Note.
Editorial claims and readable HTML
Reviewers checked the personal framing, source references and article scope. Articles and catalog sources were made available in built HTML; browser scripts were changed to enhance existing content. Privacy wording was updated for the actual hosting arrangement.
Live deployment
Live checks confirmed valid HTTPS, HTTP-to-HTTPS and www-to-apex redirects. They verified 57 initial-release files and 16 HTML documents against the local build, including article text, sources and canonical links, and exercised project media, dialogs and motion controls. These counts belong to that initial release, before later articles such as this one.
04CASE STUDY
What the additional review changed
The review found concrete problems beyond a successful build. Each finding received a correction and an affected-scope recheck.
Internal details in a screenshot
A project capture included repository, path and revision details. It was recaptured with personal example content and the replacement inspected.
Motion only paused during hover or focus
A persistent Motion switch was added for the ring and ticker, held in page memory. Visitors can stop movement without retaining hover or focus.
Mobile process steps were inaccessible
Three of four Approach steps could be hidden on mobile. Every step was made accessible in the reading flow.
Article text depended on JavaScript
Complete articles, catalogs and sources were rendered into production HTML, preserving direct route and fragment access.
Privacy wording still described a preview
Local-preview wording was replaced with compact disclosures for Vercel web hosting and Hostinger domain and email services.
Startup replaced already rendered content
Startup was changed to enhance the existing page, preserving opened disclosures, focus and reading state.
05CASE STUDY
A comparison with the secure lifecycle
For the lifecycle and test phases, I use one reference: OWASP WSTG v4.2, chapter 3. Its framework is adaptable rather than prescriptive. The five original phases below remain separate from my account of this website. Other frameworks are not merged into a new model. [01]
- WSTG / PHASE 1Before Development Begins (opens in a new tab)
Establish the lifecycle, guidance and measurable criteria.
Observed. The approved plan defined scope, acceptance criteria and privacy constraints.
Not covered. No formal organizational secure-development program or security metrics program was established.
- WSTG / PHASE 2During Definition and Design (opens in a new tab)
Review security requirements and architecture; model threats.
Observed. The design used a static site and local assets, with no analytics or application backend. Public-content and media boundaries were defined.
Not covered. No documented threat-model exercise or formal architecture security assessment was performed.
- WSTG / PHASE 3During Development (opens in a new tab)
Understand code flow and review code for security defects.
Observed. Type/build and browser checks, separate AI reviews and dependency audits were run; findings were corrected.
Not covered. No SAST scanner, lint configuration or retained automated regression suite was set up. Functional browser checks do not establish security-test coverage.
- WSTG / PHASE 4During Deployment (opens in a new tab)
Test the running application and its deployment configuration, including penetration testing.
Observed. HTTPS, redirects, published files, readable HTML, assets and selected live interactions were checked.
Not covered. No penetration test, DAST scan or dedicated security-header audit was performed.
- WSTG / PHASE 5During Maintenance and Operations (opens in a new tab)
Review operations, perform periodic health checks and verify changes.
Observed. Subsequent edits used version history, build checks, scoped review and live verification.
Not covered. No continuous vulnerability monitoring or scheduled security health-check process was configured at the initial release.
06CASE STUDY
Limits and what I take from it
The initial release did not include ESLint or Biome, a SAST tool such as CodeQL or Semgrep, DAST or penetration testing, a dedicated secret scanner, or a persistent unit, integration or end-to-end test suite. GitHub automatic Codex Code Review and a dedicated Codex Security Review were not configured or run. Keyword searches and AI reviewers should not be described as substitutes for those tools.
The additional instruction expanded the review scope and produced useful findings. It did not turn an informal personal project into a complete SSDLC. The WSTG comparison records observed activities and gaps; it does not establish compliance or a validated secure-development model.
My practical lesson is to define the expected behavior early, record what actually ran and keep each result tied to its scope. Fast generation made a first version possible. Review changed the release. Future checks should follow changes in functionality, exposure and data handling, with an explicit decision about the remaining uncertainty.
An agent completing a task, a check passing and a release being acceptable are distinct decisions. I want the evidence for each to remain visible.
REFERENCES / 01
Sources.
The project chronology and check results are my account of the recorded implementation and initial release; private execution logs are not published. OWASP supplies the lifecycle reference only. Its version and chapter are identified below, with direct phase links in the comparison. The distinction matters: my observations are not recommendations attributed to OWASP.
- OWASP — WSTG v4.2 / lifecycle reference (opens in a new tab)
Chapter 3: overview and phases 1–5. Used only for the lifecycle comparison.