Build, do not watch
Every step is completed by producing an artefact, not by finishing a course. A video course generates a certificate; a build generates something a hiring manager can open.
Career development
Where I am, where I am going, and what is missing.
Two things on this page. A twelve-step technical roadmap towards AI engineering, where every step is completed by building something rather than by finishing a course. And an honest role-by-role assessment for the jobs I am applying for — with the gaps listed next to the evidence.
Learning roadmap
Twelve steps, in dependency order
The order is not arbitrary. Kubernetes is tenth because it is useless before containerisation and managed inference; Python is first because every other step assumes it.
-
Python fundamentals
In progressWhy Everything downstream assumes it, and it is the single biggest gap between what I can currently build with assistance and what I could build unaided.
Completed when Rewrite one existing production script of mine from scratch, unaided, with tests — and have it pass against the original's output.
Where I am Real Python in production across the course pipeline, episode builders and render orchestration, written with AI assistance. Formal fundamentals are incomplete, which is why this is active rather than complete.
-
Git and GitHub
Complete & verifiedWhy My work is unreviewable by anyone else, which is a hiring problem before it is a technical one. No employer can assess code they cannot see.
Completed when This portfolio repository published publicly, with meaningful commit history, a README that explains the architecture, and at least one reviewed pull request.
Where I am Done, in part: this portfolio is published at github.com/tshivhidzombedzi1-lgtm/portfolio with a documented commit history, a README explaining the architecture, and continuous deployment that gates on a verification step. The collaborative half is still absent — no reviewed pull request, no shared branch, no resolved conflict — so the next move on this step is working with someone else, not more commits of my own.
-
APIs and backend development
In progressWhy The layer every AI product needs. I have built one in production and learned it by necessity rather than properly.
Completed when A documented API with authentication, validation, error contracts and an automated test suite — not the hand-verified endpoint I currently operate.
Where I am I have built and operated an HTTP service in production that other software depended on at startup, including authentication and state handling. It had no automated tests and no formal error contract, which is the gap this step closes.
-
Generative AI and LLM architecture
In progressWhy I build on these models daily. I want to understand attention, tokenisation and context limits as mechanics rather than as constraints I have learned to work around.
Completed when Complete CS50 AI with Python, then implement a small transformer from scratch and write up what the exercise changed about my product decisions.
Where I am CS50 AI with Python commenced February 2025, not complete. Applied experience across four shipped systems. The practical knowledge is real; the theoretical foundation is not finished.
-
Prompt engineering and evaluation
In progressWhy I already do the evaluation half rigorously. What I lack is the formal apparatus — rubrics, inter-rater agreement, scored test sets — that makes a judgement defensible to someone else.
Completed when A published evaluation harness: a rubric, a scored test set, and agreement measured between my ratings and a second rater.
Where I am Split-half validation, instrument validation and documented rejections in real use. None of it expressed as a scored rubric another person could be calibrated against.
-
RAG and vector databases
QueuedWhy The most common production AI pattern, and the clearest gap in my portfolio. I have built context-constrained LLM features and never a retrieval pipeline.
Completed when Retrieval over my own technical corpus — decisions, rejected experiments, documentation — with citations, plus an evaluation set scoring retrieval relevance and answer groundedness separately.
Where I am Not started. No capability claim.
-
Docker
QueuedWhy Everything I run is installed on one machine by hand. That is the reason none of my AI work is reproducible by anyone else.
Completed when One of my existing local pipelines containerised and runnable by someone else with a single command on a machine I have never touched.
Where I am Not started. No capability claim.
-
AWS Bedrock
QueuedWhy Managed inference is how AI products are actually deployed commercially. All my model serving is local GPU.
Completed when A deployed service of mine calling a managed model, with cost per request, latency and failure handling measured and documented.
Where I am Not started. No capability claim.
-
AWS SageMaker
QueuedWhy Training and hosting a model is the boundary of what I have never done. I have only ever consumed models.
Completed when One model trained, evaluated against a held-out set using the discipline on my Verification page, and deployed to an endpoint.
Where I am Not started. No capability claim.
-
Kubernetes
QueuedWhy Required for AI systems that scale beyond a single host. Deliberately late in the order — it is of no use to me before steps 7 and 8.
Completed when A containerised inference service running with health checks, resource limits and a survivable rolling deployment.
Where I am Not started. No capability claim.
-
Production AI deployment
QueuedWhy The gap between my workstation and a system real users depend on. Honestly stated: this is the boundary of my current ability.
Completed when One of my own AI features deployed as a real service with a defined availability target, metered cost and a documented rollback path.
Where I am Not started. No capability claim.
-
AI system testing and monitoring
QueuedWhy The natural destination of my existing strengths. I already gate on measured quality before delivery; the missing half is watching for drift after release.
Completed when A deployed AI feature with automated output-quality monitoring, drift detection and alerting that has caught at least one real regression.
Where I am Pre-delivery gates and verification are in daily use. Post-deployment monitoring does not exist in any of my systems.
Method
How this roadmap is run
Nothing is marked complete without proof
A step stays in progress until its named artefact exists and has been verified. There are no complete steps on this page today, which is the honest state.
The order is dependency-driven
Kubernetes is tenth because it is useless before containerisation and managed inference. Python is first because every other step assumes it.
Use real work as the exercise
Each proof artefact is built on a system I already run, so the learning produces a working improvement rather than a disposable tutorial project.
For recruiters
Role-by-role fit, with the gaps
Three role groups, ordered by how well I actually match them. Each one lists the evidence and then the gaps. I would rather you discount me now on an accurate picture than in a technical interview on an inflated one.
Strongest match
AI Quality, Evaluation and Training
- AI Quality Rater
- AI Trainer
- AI Evaluator
- AI Content Analyst
- AI Quality Assurance Analyst
These roles ask one question: can this person tell a correct output from a convincing one, and will they say so when the convincing one is their own? I have six documented cases where I found the fault in my own results and reversed my own conclusion.
The evidence
-
Documented self-correction under no external pressure
Six recorded cases of discarding my own results on measurement grounds, including a full session of parameter work invalidated by a single simulator setting. Nobody asked me to check.
-
Content evaluation judgement, not just fact-checking
I caught a chart in my own instructional material that was entirely accurate and taught the opposite of its lesson. Evaluating the inference a reader draws — rather than only the facts on the page — is the core of quality rating work.
-
Automated evaluation as a release gate
Speech recognition used to verify synthesised narration against its source script, and delivery gates that measure output against a specification and refuse to ship on failure.
-
Held-out validation as standard practice
Split-half in-sample and out-of-sample testing with an adoption rule, and documented rejections of changes that improved the aggregate while failing a half.
-
Instrument validation
Established that a platform metric I had been relying on was wrong for my system and rebuilt the measurement. Trusting the dashboard would have rejected a genuine improvement.
-
Written communication
Technical documentation, honest limitation statements and scripted instructional material. Rating work is only useful if the rationale is legible to the next person.
The gaps
- I have never worked to a published rating rubric or had my ratings calibrated against another rater. My judgements are documented and consistent, but inter-rater agreement is a measurement I have not been subject to.
- No experience with commercial annotation platforms or their specific guideline formats.
- My evaluation experience is on my own systems, where I set the standard. I have never rated another organisation's model outputs, to their guidelines, at volume, against a deadline.
Where I would start
I would be productive in the first week. The judgement is there and demonstrable; the rubric and platform specifics are a short onboarding, not a skills gap.
Strong match
AI Operations and IT Support
- AI Operations Specialist
- IT Support Specialist
- Software Testing Assistant
Formally qualified in IT support services, and running the full operational side of my own technical work: a GPU workstation under sustained load, long unattended jobs, and the diagnosis that follows when something fails at three in the morning.
The evidence
-
Formal IT qualification
Higher Certificate in Information Technology Support Services, IIE Rosebank College, completed March 2024. Hardware, operating systems, networking fundamentals, user support and service practice.
-
Root-cause diagnosis
Traced a repeating GPU-level display failure on a render workstation to a verified cause rather than replacing parts; found systemic output defects with an automated geometry scan after they passed human review.
-
Operating AI systems in practice
Local model serving on GPU, long unattended job scheduling, storage lifecycle management under multi-hundred-gigabyte workloads, and recovery when a queue stalls or a disk fills.
-
Resumable, restartable process design
Render queues that survive the session that started them, and publishing automation with tracked state, because a process that cannot be restarted is a process that will eventually lose a night of work.
-
Security-minded operational practice
Audited this repository before publication, found server credentials in a file about to go public, removed them and rewrote them out of git history. Backed by a distinction in Information Security at NQF level 8.
-
Documentation discipline
Runbooks, architecture notes and deployment guides, including this site's own. I document for the version of me that has forgotten.
The gaps
- No formal ticketing system experience — Jira, ServiceNow, Zendesk.
- No enterprise environment experience: no Active Directory, no managed fleet, no change-control process.
- No containerisation or cloud infrastructure. Everything I operate is a single workstation. This is roadmap steps 7 to 11.
- My support experience is with my own systems and users rather than in a service desk with queues, priorities and response targets.
Where I would start
The troubleshooting instinct, the ownership and the formal grounding are all there. The gap is enterprise tooling and process, which is learned on the job rather than studied.
Developing — honest about the gap
AI and Software Engineering
- Junior AI Engineer
- AI Product Developer
I ship working AI products: two released desktop applications built on locally hosted models. I do it with AI assistants as my engineering partner, and I will not claim otherwise in an interview or on a CV.
The evidence
-
Shipped AI products, not demos
Two released Windows applications built on local speech and language models, publicly downloadable. Twenty animated episodes produced through one of them.
-
Non-obvious AI architecture decisions
Spoiler safety enforced by context windowing rather than prompt instruction; zero latency achieved by read-ahead scheduling rather than faster inference; an information boundary enforced by an automated test.
-
Systems that run unattended
A resumable render queue that outlives its controlling session, an autonomy loop with no operator input, and automated delivery gates with rollback.
-
Engineering discipline
Dependency-free code where it matters, 38 automated tests on the simulation engine, checksum-stamped builds with retained rollback artefacts, and seeded determinism.
-
This site is itself a worked example
A zero-dependency static site generator, a verification gate that fails the build on broken links or missing headings, an ATS-safe .docx written directly as WordprocessingML, and a hand-rolled PNG encoder for the share image.
The gaps
- I cannot currently write production code unaided at interview speed, and this portfolio does not claim I can. What I can do is specify, direct, test and verify systems — a genuine and useful engineering contribution, stated accurately.
- No team engineering experience: no code review given or received, no shared branch, no CI pipeline beyond my own, no on-call rotation.
- No cloud, containers or orchestration. Roadmap steps 7 to 11.
- No model training. I integrate and evaluate models; I have never trained one. Roadmap step 9.
Where I would start
A junior AI engineering role where the work is building and evaluating AI product features, in a team that treats AI-assisted development as normal practice. I would be honest about my level on day one.
Long-term direction
AI/ML Engineer, and eventually AI/ML Lead Engineer. The route runs through the twelve steps on this page's companion roadmap, and it is deliberately not a short one. The nearest realistic step is work in AI evaluation or AI operations, where what I already have — measurement discipline, operational ownership and the willingness to discard my own results — is immediately useful, and where the engineering gaps close through the work instead of alongside it.