Vokai XYZ← Back to Vokai

Software Engineering Lab

Learn the code underneath the AI.

A practical, AuDHD-friendly learning environment for understanding the software engineering behind AI-assisted development — one concept, one experiment, one verified result at a time.

The core ideaAI can reduce implementation effort without lowering the engineering quality threshold. Your job is to understand the requirement, question the design, test the result, and know what is actually verified.

Learn by doing, not by waiting for the lecture

Use small, concrete experiments with a visible finish line.

1
LearnTake one concept at a time.
2
ExperimentBuild something tiny and disposable.
3
Break itTry bad input, failure and edge cases.
4
Fix + testProve the behaviour and explain why.
AuDHD-friendly rule

Don't try to “finish the curriculum”. Follow the next useful concept. After an interruption, record the exact resume point instead of relying on memory.

Three levels of practice

Move knowledge into increasingly realistic environments.

LAB

Disposable experiments

Learn one concept safely. Tiny apps, deliberate failures and no fear of breaking anything.

PLAYGROUND

Small combinations

Combine several concepts into experimental tools where you can still change things freely.

REAL PROJECT

Public-facing software

Apply the ideas to Vokai and other projects where reliability, security, privacy and maintainability matter.

Skill modules

Open one module when you have a reason to learn it. Each has a tiny experiment and reliable places to start.

🧱 HTML — structure & semantics
Experiment: tiny page

Understand document structure, semantic elements and meaning before styling.

  • Build a one-page document.
  • Make the structure make sense without CSS.
🎨 CSS — layout & responsive behaviour
Experiment: 3 widths

Learn layout, sizing, spacing and responsive changes by testing the same page at different viewport widths.

  • Desktop, tablet and mobile.
  • Fix one broken layout at a time.
🧠 JavaScript — logic & state
Experiment: calculator

Learn variables, functions, conditions, events and state through a tiny interactive calculator.

  • Normal inputs first.
  • Then deliberately try invalid inputs.
🌐 HTTP — requests, responses & status
Experiment: tiny API

Understand what travels between browser and server, including methods, status codes and response bodies.

  • Build one GET and one POST endpoint.
  • Observe successful and failed cases.
🖥️ Node/Express — server-side programming
Experiment: 3 endpoints

Learn routing, middleware and server-side execution without hiding everything behind a framework.

  • Make three deliberately simple routes.
  • Trace what happens to a request.
🔐 Secrets & configuration
Experiment: hide a secret

Understand why client code is public and why secrets belong on the server with environment-aware configuration.

  • Put a fake secret in client code.
  • Move it server-side and verify it is no longer exposed.
🛡️ Validation — trust boundaries
Experiment: bad input

Assume external input can be malformed. Validate syntactic and semantic constraints before processing it.

  • Missing, empty, wrong-type and huge values.
  • Malformed JSON and unexpected fields.
🚨 Error handling — predictable failure
Experiment: make it fail

Design useful failures without exposing internal implementation details.

  • Try dependency failures and malformed requests.
  • Return deliberate status codes and safe messages.
🧪 Testing — prove behaviour
Experiment: break a function

Write tests before and after a change, deliberately introduce a bug, watch the test fail, then fix it.

  • Test normal behaviour.
  • Add failure and edge cases.
🔑 Authentication — identity & sessions
Experiment: protected page

Understand authentication states before adding a large identity provider to a real app.

  • Build /, /login, /logout and /protected.
  • Test unauthenticated and expired-session cases.
🔌 External APIs — integration
Experiment: public API

Learn to distinguish your application from a dependency you do not control.

  • Handle success, empty and upstream failure.
  • Record what is observed versus inferred.
Learn from
MDN · HTTP
🤖 AI integration — model & tool boundaries
Experiment: one controlled feature

Give the model a narrow role and treat its output as untrusted input until validated.

  • Define a small tool contract.
  • Test malformed and unexpected model arguments.
🧱 Architecture — separation of concerns
Experiment: tame one messy file

Split responsibilities only when the current structure creates a real maintenance problem.

  • Extract one responsibility at a time.
  • Run tests after each change.
🔒 Security — defensive thinking
Experiment: attack your test app

Learn common web risks and test your assumptions in a disposable environment.

  • Think about access control, injection and misconfiguration.
  • Fix one real risk at a time.
♿ Accessibility — inclusive interfaces
Experiment: keyboard + mobile

Learn how semantic HTML, focus, labels and mobile interaction affect real users.

  • Navigate without a mouse.
  • Try mobile accessibility features.
📱 Responsive design — design for the device
Experiment: mobile-first

Design flexible layouts rather than shrinking a desktop layout after the fact.

  • Start narrow.
  • Add layout as space becomes available.
⚡ Performance — measure before optimising
Experiment: measure first

Learn to measure real user-facing performance before changing code for speed.

  • Measure page load and responsiveness.
  • Change one thing and measure again.
🚀 Deployment — from laptop to production
Experiment: deploy something tiny

Understand the difference between local assumptions and production reality.

  • Deploy a simple app.
  • Document configuration and rollback steps.
📊 Monitoring — know when something breaks
Experiment: health check

Make failures visible rather than relying on users to tell you something broke.

  • Add a simple health endpoint.
  • Log useful context without secrets.
🔄 CI — automate verification
Experiment: test on every change

Move repeatable checks out of your memory and into automation.

  • Run tests automatically.
  • Fail the check when verification fails.
🎨 Design for developers — make deliberate choices
Experiment: redesign one screen

Learn visual hierarchy, typography, alignment, whitespace, user-centred design and common interface patterns.

  • Identify what the user should notice first.
  • Compare two designs and explain the trade-off.

Working with AI

Use the model to reduce implementation effort without outsourcing engineering judgement.

Requirements
Design decision
Implementation
Verification
Observed state
A stronger prompt pattern

Ask the AI to inspect first, make a small change, explain significant decisions, add tests for normal and failure cases, run the relevant checks, and state exactly what it verified and what remains unverified.

Keep evidence separate from assumptions

Use the same vocabulary for code review that the Reddit toolkit uses for evidence-ranked workflows.

OBSERVED

Directly seen in code, output or runtime behaviour.

VERIFIED

Proven by a test or another explicit piece of evidence.

INFERRED

A reasonable interpretation that has not been directly established.

Questions worth asking every time

These are the questions that turn AI-assisted coding into engineering practice.

What requirement is this solving?Know the purpose before evaluating the implementation.
Why is it designed this way?Understand the principle and the simpler alternatives.
What assumptions is it making?Look for hidden dependencies and ideal-input thinking.
What happens with bad input?Test the boundaries, not only the happy path.
What happens when dependencies fail?External services, networks and models can all fail.
What could an attacker do?Think about misuse before public exposure.
How do we know it works?Prefer executable or observable evidence.
What is actually verified?Separate evidence from confident-sounding claims.
Learning links were checked against current official documentation. They are deliberately weighted toward maintained, authoritative sources including MDN, Express, Node.js, OWASP, web.dev, GitHub, Playwright and OpenAI.

Take the next concept into a real project.

Vokai is the place to apply the ideas once the experiment is understood.

Open Vokai →View the GitHub repo →