Hackathon Projects Showcase

Python * FastAPI * Pydantic * SQLAlchemy * Ollama integration * Pytest Databases * PostgreSQL * pgvector * Neo4j Frontend * Next.js * TypeScript * React * TailwindCSS AI * Ollama * Local LLMs (Llama / Qwen / Gemma) * Retrieval-Augmented Generation (RAG) Infrastructure * Docker * Docker Compose * GitHub * Vercel (hackathon deployment) Data & Search * Vector embeddings * Semantic search * Knowledge graph relationships These are the simplified and specific use of technologies

The project addresses the preservation and structuring of organisational knowledge, which often exists uniquely within a team, department or organisation. This knowledge can include sensitive operational, technical or business information, and the selection of data was guided by principles of privacy, confidentiality and responsible AI. The selected datasets were designed to reflect realistic knowledge-transfer and organisational-memory scenarios, without unnecessarily disclosing sensitive information. This approach allowed for the development and testing of the platform’s knowledge extraction, organisation, search and risk-analysis capabilities in a safe and ethical manner. The rationale was thus to not maximise the dataset size, but to ensure relevance to the problem being solved: knowledge continuity, succession planning, and preservation of institutional expertise. For datasets they were samples genrated through either ChatGPT or Codex.

Delegated to AI * Initial code set-up * Create documentation *Database schema recommendations * UI component development Testing support * Recommendations for refactoring Alternative architecture proposals Human judgements: * Choice of problem * Product vision * Security requirements Knowledge continuity model *Risk scoring concepts * Prioritising features * Final architecture decisions * Review of AI outputs prior to implementation Responsible AI practices: * AI outputs were reviewed prior to use. * No sensitive or real organisational data was provided to AI systems. * AI recommendations were considered recommendations and not definitive answers. * The project decisions were still human-made. * The demo data was made up and was only used for demonstration purposes.

This project was motivated by recurring themes in the Python ecosystem including: * Development of responsible AI * Open source, collaboration * Rapid prototyping with Python AI-assisted software engineering * Knowledge sharing in technical community * Developing maintainable software systems Python was chosen because of its strong ecosystem to: * Artificial Intelligence *Data processing * Extraction of knowledge * APIs Development * Automate LegacyOS Lite implements these ideas in practice, using Python to quickly convert undocumented organisational knowledge into structured, searchable institutional memory. As the development progressed, the project was focused on maintainability, documentation and responsible AI usage rather than just maximising feature count.

This project was my long term goal and still is hense the licence on my code base. I wish to make something along this my end goal and will continue to code what I envisioned with my favourite assistant Codex, because I now know it has now become easier to code for good.

Python, Pandas, Openpyxl, Git, Sparse skill-vector space, knowledge graph, telegram bot API, OpenAI Agents

https://jobsandskills.skillsfuture.gov.sg/skills-frameworks Offline dataset

Delegated to AI: resume/JD skill extraction, parser verification, explanation drafting, documentation drafting, workflow diagrams, and iterative code implementation support. Human-judged: product direction, workflow design, scoring methodology, privacy boundaries, judging priorities, and whether recommendations were understandable or useful. Responsible use: final suitability scores are calculated by a deterministic scoring engine, not by an AI model. Parser/explainer agents can suggest or explain, but they cannot change scores or rankings. Fallbacks: if AI parsing or explanation fails, the system falls back to rule-based extraction and deterministic reporting. Transparency: users can review, edit, remove, or add skills before scoring, and recommendations are explained through matched skills, gaps, and SkillsFuture dataset rows. Privacy: raw resume/JD text is used at runtime only; normal Telegram reports are sent as transient attachments and not saved locally.

The Codex talk definitely helped me to try out different plugins and settings to help improve my workflow.

Python: core backend, scraper orchestration, PDF processing, summarisation pipeline Flask: lightweight web backend and API server Playwright for Python: browser automation for scraping judgment pages and downloading PDFs PyMuPDF: extracting text from downloaded judgment PDFs ReportLab: generating long-form summary PDFs SQLite: local demo database storing cases, summaries, tags, users, and preferences OpenAI GPT-5.4: judgment summarisation and legal topic tagging Amazon Bedrock Claude Haiku: alternative LLM provider used during demo generation Firebase Firestore / Storage: optional cloud persistence for case records and summary PDFs Apify: planned hosted scraper runtime / scheduled weekly scraping HTML, CSS, JavaScript: frontend interface, preferences page, digest page, login page

Used playwright and apify to scrape public legal judgement sources.

The plan and use case was decided by me based on issues i have faced and issues lawyers at the firm i intern at came to me with. AI helped me planned the tech stack and solution where i was not clear, taught me how to use apify and helped to build the system within the short timeframe i had.

I was not able to attend the conference

Python 3.13. Desktop: PyQt6 (transparent per-monitor overlay), Win32 APIs via ctypes (click-through layered windows, DPI awareness, single-instance mutex). Capture/input: mss (screen capture), pynput (global hotkey), sounddevice + numpy (audio I/O), Pillow (image resize). AI: OpenAI GPT-4o vision plus an experimental GPT-Realtime speech-to-speech mode, behind a provider abstraction that also supports Anthropic Claude and local Ollama. AssemblyAI (speech-to-text), Cartesia / ElevenLabs (text-to-speech). Storage: SQLite (WAL) index + plain markdown for memory. Packaging: PyInstaller + Inno Setup. Tests: pytest (363, mock-based). Keys: keyring (Windows Credential Manager).

Clicky doesn't train on or ship a public dataset. It works on live screenshots captured at the moment you ask a question, which never get stored or sent anywhere except your own chosen AI provider's API. The two "data" sources it does use, both user-owned and local: - Per-app memory: plain markdown files Clicky writes at ~/.clicky-windows/memory/<app>.md as you use it. - Drop-in knowledge base: markdown docs you put in ~/Documents/Clicky Wiki/<app>.md so it understands niche or company-internal software.

Built with an AI coding agent for implementation, with OpenAI Codex running an adversarial review pass over every diff before commit (it caught real bugs in this project). The judgment stayed human. Delegated to AI: most implementation code, boilerplate, test scaffolding, refactors, and a multi-agent adversarial review pass to catch bugs before commit. Human-judged: the architecture (a provider abstraction so Claude, OpenAI, Ollama, etc. are drop-in swaps), and every real-world debug. The hard bugs were mine to diagnose: three Clicky processes answering one question at once (a Windows keyboard-hook race, fixed with a named mutex), a bundled-exe that silently ignored config, and the first external bug report which I root-caused and shipped a fix for the same day. Rule I held: AI writes the code, I own whether it's pointed at the right thing and whether it actually works under real conditions, not just in a demo.

- "SKILL.md is the SOP your AI agent never had" (Yeo Wee Kiang, NUS) and "Beyond the System Prompt: Scaling AI Capabilities with Agent Skills" (Jiawei Lin): this is exactly Clicky's drop-in knowledge folder: a plain markdown file per app that turns a generic model into an expert on niche software. Same idea, applied to a desktop buddy. - "Building with Codex" workshop (Gabriel Chua, OpenAI): I run an OpenAI Codex adversarial-review pass over my diffs before committing; it caught real bugs in this project. - "Efficient Python Testing: Parametrization, Fixtures, Monkeypatching and Marks" (Cheong Yu Jia, Zenika): Clicky's 363 tests lean on exactly these: dependency-injected fixtures and monkeypatching so the whole screen-to-voice pipeline is testable without a real mic or GPU. - Anthony Tung's keynote "Using Tools Without Being Used: The Four Stages of AI Fluency": matches the whole point of Clicky: learn by doing with the tool next to you, not by watching a tutorial.

i love python :)

Flask, OpenAI, URL Lib, VSCode, venv

OpenAI Language Model Knowledge (GPT-4o-mini via API) Source: https://platform.openai.com Used to generate mood-based music recommendations dynamically from user input. Rationale: Enables real-time personalization without needing a fixed dataset. Curated Seed Playlist (Fallback System) Manually defined list of songs inspired by common mood categories (sad, happy, neutral). Rationale: Ensures the application remains functional even without API access or internet connectivity. Mood Keyword Mapping (Rule-based logic) Derived from user input text (e.g., “sad”, “tired”, “happy”). Rationale: Provides lightweight mood detection for fallback scenarios.

AI was used for: Generating mood-based playlist recommendations from user input Structuring responses into strict JSON format for consistent frontend rendering Helping design fallback logic when the API is unavailable Debugging backend issues (Flask routing, API errors, environment variables) Improving prompt design to make outputs more consistent and relevant Suggesting UI improvements (e.g., replacing free-text mood input with structured mood selection) Human decision-making was responsible for: Designing the overall application concept and user experience Selecting final mood categories and playlist structure Implementing Flask architecture and frontend integration Deciding when to use fallback vs AI output Handling error management and API failure strategy Final UI/UX design choices (layout, flow, styling, interaction model) Ensuring outputs remained appropriate, safe, and relevant to user emotions

https://github.com/royaleleaf/Moodify/commits/main/ Interaction evidence is demonstrated through GitHub commit history showing iterative development of the system.

have been learning about LLMs and how to connect APIs. The event booths provided excellent opportunities to explore new technologies to enhance my projects. Additionally, the mentoring and talks at PyCon gave me the perfect push to build my first back-end and AI web application

I didnt get the credits for API so i cant rlly run my web app with the AI :( but i hope my idea was good because it has been an idea that i thought of quite some time ago too and i hope to further develop it aswell. i hope the MVP was a good base for potential. I received help frm volunteer Evan good mentor woohoo

Python, embedded Python in BespokeSynth, pybind11, C++, JUCE, CMake, BespokeSynth’s modular audio/MIDI engine, macOS build tooling, and Sardine-inspired live-coding syntax. The module adds Python helper functions such as N(...), CC(...), again(...), panic(), and now(), which translate live-coded Python patterns into BespokeSynth note/control events.

No training dataset was used. This is a software/tooling project, not a model-training or data-analysis project. References used: - BespokeSynth source branch: https://github.com/geeksperiments/BespokeSynth/tree/sardine - BespokeSynth implementation commits: - https://github.com/BespokeSynth/BespokeSynth/commit/e1e7053e42d3010e0daaa37f271137a41a1b5b25 - https://github.com/BespokeSynth/BespokeSynth/commit/b50cd56f91637561af9af03d21f1721cd3d75281 - Sardine project reference: https://sardine.raphaelforment.fr/ - Project documentation: https://github.com/whatevergeek/sardine-bespoke-module

AI tools were used as a pair-programming assistant. I delegated codebase exploration, implementation suggestions, C++/Python edits, debugging support, build guidance, and documentation drafting to AI. I kept human judgment over the product idea, musical goals, what felt usable inside BespokeSynth, demo content, testing, and final decisions. The AI output was not accepted blindly: changes were built, tested interactively in BespokeSynth, revised when behavior failed, and documented with links to the exact implementation commits. No private dataset or model training was involved. The project remains transparent by publishing the implementation branch, commit references, demo video, and documentation.

Project documentation and development notes are in the public repo: https://github.com/whatevergeek/sardine-bespoke-module The implementation history is visible in the BespokeSynth branch and commits: https://github.com/geeksperiments/BespokeSynth/tree/sardine AI-human collaboration: AI was used as a coding and documentation assistant to inspect the BespokeSynth and Sardine codebases, propose implementation approaches, edit C++/Python documentation, debug module behavior, and draft hackathon documentation. Human judgment was used for project direction, musical behavior, testing inside BespokeSynth, demo recording, UX decisions, and final acceptance of changes.

I applied ideas from the PyConSG26 Hermes workshop, where I explored AI-agent workflows, promptable coding assistants, and the importance of keeping humans in the decision loop. My workshop notes/work are here: https://github.com/whatevergeek/hermes_workshop. I applied that learning in this project by using AI as a pair-programming assistant to inspect code, draft implementation changes, debug behavior, and document the work, while keeping human judgment over the musical goals, UX decisions, live testing inside BespokeSynth, and final acceptance. The result is still Python-first: a BespokeSynth module that embeds Sardine-inspired Python live-coding syntax directly into a modular music environment.

This project was a fun collision of two things I care about: Python and live music. The most challenging part was not just making notes play, but making the loop timing feel musical inside an existing modular synthesizer. I tested the module by actually patching it into BespokeSynth, listening, debugging crashes, and iterating until it behaved like something I would want to perform with. Thanks to the PyConSG26 hackathon for creating a space where a playful music-tool idea still counts as serious Python exploration.

Python powers the backend with FastAPI, Pydantic, Tortoise ORM, SQLite, ChromaDB, httpx, openpyxl, and pypdf for APIs, data processing, vector search, resume parsing, and local LLM integration. The frontend uses Next.js, React, TypeScript, Tailwind CSS, and pnpm, with llama.cpp for the local LLM, Mermaid for diagrams, Swagger/OpenAPI for API docs, Playwright for demo capture, and FFmpeg for video export.

We use official SkillsFuture Jobs and Skills datasets from the Interactive Skills Frameworks portal (https://jobsandskills.skillsfuture.gov.sg/frameworks/interactive-skills-frameworks#interactive-skills-frameworks), supported by the broader SkillsFuture Skills Framework reference (https://www.skillsfuture.gov.sg/skills-framework). These include the Skills Framework dataset, Unique Skills List, and TSC-to-Unique-Skills Mapping, which provide structured job roles, sectors, career tracks, role descriptions, key tasks, technical skills, proficiency levels, and standardized skill names. We chose these datasets because they are official, Singapore-relevant, and suitable for local vector indexing, allowing the app to generate explainable career pathways, skill gaps, and next-step recommendations grounded in credible workforce evidence rather than relying only on generic LLM responses.

AI tools were used as an engineering and documentation assistant, while product direction and final judgement remained human-led. The human contributor defined the problem, selected the data source, provided the local LLM setup, specified the workflow, architecture and system design. AI was delegated implementation support tasks such as inspecting the codebase, drafting documentation, generating C4/UML diagrams. AI outputs were kept grounded in the repository and official/local data sources, with generated artifacts reviewed, corrected, and cleaned up. Temporary tools such as Playwright were removed after use, local services were stopped, and the system was documented transparently so the workflow can be reproduced.

I only participated in the workshop portion of PyConSG26. The workshop introduced how to build graph-based and RAG-style workflows for LLM applications, which gave me the idea to ground career recommendations instead of relying on the LLM alone. I applied this by processing SkillsFuture job-role and skills datasets, storing the evidence in ChromaDB, retrieving relevant role and skill matches, and then passing that context to a local LLM to generate explainable career pathways, skill gaps, and next actions.

LoopIn is built primarily with Python, using FastAPI as the backend framework, Uvicorn as the ASGI server, and Python modules such as `httpx`, `python-dotenv`, and `pydantic` for API calls, environment configuration, and data validation. The backend handles Telegram webhook events, Twilio WhatsApp webhook events, message normalization, bridge-state management, and cross-platform relay logic. Other technologies used include the Telegram Bot API for Telegram group integration, Twilio WhatsApp Sandbox/API for WhatsApp messaging, OpenAI-compatible AI provider support for optional summarization/action-item features, HTML/CSS/JavaScript for the web relay monitor, WebSockets/polling for live updates, Render for public deployment, GitHub for version control and collaboration logs, and ngrok during local testing for webhook tunnelling.

LoopIn does not rely on any pre-trained or static external dataset. The system uses live, user-generated message events from connected Telegram and WhatsApp conversations during the demo. Telegram data is received through the official Telegram Bot API webhook update format, while WhatsApp data is received through Twilio’s WhatsApp Sandbox webhook payloads. These live message streams were chosen because LoopIn is a real-time communication bridge, so synthetic benchmark datasets would not represent the actual cross-platform relay problem. For the AI assistant features such as summarization, catch-up notes, translation, and action-item extraction, LoopIn uses only the recent messages inside the active bridge as temporary context and does not train or fine-tune any model on user data. Sources: * Telegram Bot API: https://core.telegram.org/bots/api * Telegram Webhooks: https://core.telegram.org/bots/webhooks * Twilio WhatsApp API: https://www.twilio.com/docs/whatsapp/api * Twilio WhatsApp Sandbox: https://www.twilio.com/docs/whatsapp/sandbox * OpenAI API Documentation: https://platform.openai.com/docs

AI tools were used creatively and responsibly as a development accelerator, not as a replacement for human judgement. We used AI to brainstorm the initial LoopIn concept, compare technical approaches, draft architecture ideas, generate FastAPI/Twilio/Telegram integration scaffolds, debug webhook and deployment issues, and refine pitch materials such as the problem statement, dataset rationale, and demo flow. AI was also used to suggest possible features like summarization, translation, catch-up notes, and action-item extraction. Human judgement was used for all key product decisions: defining LoopIn as a cross-platform relay protocol instead of a new chat-room app, choosing Telegram and WhatsApp as the demo platforms, deciding not to use unsafe WhatsApp scraping, validating Twilio Sandbox limitations, testing real message flows, checking whether outputs worked in practice, and deciding what was suitable for the final PyCon demo. Sensitive credentials and private messages were not intentionally included in public documentation, and AI-generated code or text was reviewed, tested, and modified before use.

Interaction logs are documented in the project repository under the `docs/` folder: https://github.com/tejaaswinv/loopin/tree/main/docs The logs include AI-human collaboration records showing how ChatGPT was used to ideate, debug, refine, and implement LoopIn, including prompts related to Telegram integration, WhatsApp/Twilio Sandbox setup, OpenAI assistant features, media relay, deployment, and project pitching. The folder also includes human-human collaboration evidence, including team discussion notes, testing feedback from WhatsApp sandbox participants, and contribution records describing who worked on protocol design, backend integration, frontend monitoring, Twilio setup, Telegram bot testing, and pitch preparation. Sensitive credentials, phone numbers, and private message contents have been removed or anonymized.

From the PyConSG26 programme, we learned that modern Python projects should not simply use AI as a decorative feature, but should combine strong software engineering, responsible AI use, reliable deployment, and community usefulness. Georgi Ker’s keynote on staying relevant in an AI-shaped world influenced LoopIn’s focus on helping people keep learning and communicating together rather than being separated by tools. Anthony Tung’s keynote on “using tools without being used” shaped our decision to keep humans in control of LoopIn while using AI only for support features such as summaries, translations, catch-up notes, and action-item extraction. We also applied lessons from talks on trustworthy Python agents, notification systems, and agent skills. The Microsoft session on trustworthy Python agents and Azure reinforced the need for observability and reliability, so LoopIn includes a relay monitor and debug endpoints. The talk on building a scalable notification system inspired our relay architecture, where messages are normalized into a common protocol and then distributed across connected platforms. The “Beyond the System Prompt” session influenced our AI feature design: instead of one large monolithic prompt, LoopIn separates commands such as summarize, translate, catchup, and actionitems into clear assistant behaviours. The PyConSG26 sponsor and partner ecosystem also influenced our implementation choices. Since OpenAI is listed as a hackathon sponsor, we integrated an OpenAI-compatible AI provider layer for intelligent bridge features. Google Cloud’s presence as a platinum sponsor and the Google keynote on the future of Python developers encouraged us to think about deployability, agentic workflows, and production-minded Python engineering. We also learned from the broader community focus of PyConSG, Python Software Foundation, Python Asia Organisation, PyLadies Singapore, and AI Singapore, and applied that by designing LoopIn as an inclusive communication tool that helps people remain on their preferred platforms while still collaborating in one shared conversation.

One unexpected challenge was that our original idea sounded simple: “connect WhatsApp and Telegram.” In reality, we quickly realised that every platform has its own rules, APIs, privacy limits, and webhook behaviour. A big learning moment was understanding that WhatsApp cannot simply be treated like Telegram, where a bot can easily join a group. This forced us to redesign LoopIn honestly around a relay protocol and Twilio Sandbox instead of unsafe scraping or unrealistic claims. Our team also had a nice collaborative testing process. Madichetti Akshara contributed as a team member by helping test the WhatsApp relay flow, giving feedback on the user experience, and helping us think from the perspective of someone actually using the product rather than just building it. A few friends also joined the WhatsApp sandbox and helped us test real message relays, which exposed small but important issues like bridge codes, participant joining, webhook changes, and message delays. What made the experience meaningful was that the bugs were not just coding bugs; they were product-design lessons. Each failure helped us understand how real communication systems need trust, consent, reliability, and clear onboarding. LoopIn became better because of those messy testing moments.

React frontend Tailwind CSS design system Vite build workflow Python ThreadingHTTPServer backend Browser localStorage persistence No paid runtime service required for the demo

The built-in demo uses the public PyConSG programme/schedule as a sample event agenda: https://pycon.sg/schedule Rationale: the project is an event companion, so a real conference schedule is the most relevant test dataset. The sample agenda lets the app demonstrate parallel sessions, venues, breaks, keynotes, workshops, and social/community blocks. The app also supports user-provided event data through pasted agenda text, CSV files, .ics calendar files, manual quick-add, and best-effort website import. These inputs are used only to generate the attendee’s local plan. Source and provenance notes: https://github.com/GoodGuyKeith/pycon-2026-hackathon/blob/main/SOURCES.md

AI was used as a coding and product-design collaborator. It helped generate interface ideas, implement the React/Tailwind/Vite app, write the Python backend, create verification scripts, draft submission materials, and produce a captioned demo video. Human judgement decided the product direction, which features mattered, what visual style felt appropriate, what claims were safe to make, and what should be simplified or removed after review. The app itself does not send attendee data to a live AI model. Recommendations are deterministic and explainable, based on selected interests, energy level, social preference, venue movement, break protection, and session metadata. Reward claim IDs are demo request IDs only, not real secret voucher codes. Responsible-use boundaries are documented here: https://github.com/GoodGuyKeith/pycon-2026-hackathon/blob/main/AI_USE_AND_ETHICS.md

AI-human collaboration and verification evidence are documented in the repo through the handoff, audit, demo, and submission notes: https://github.com/GoodGuyKeith/pycon-2026-hackathon/blob/main/FINAL_HANDOFF.md https://github.com/GoodGuyKeith/pycon-2026-hackathon/blob/main/SUBMISSION_AUDIT_REPORT.md https://github.com/GoodGuyKeith/pycon-2026-hackathon/blob/main/DEMO_SCRIPT.md https://github.com/GoodGuyKeith/pycon-2026-hackathon/blob/main/AI_USE_AND_ETHICS.md Human judgement drove the product direction, feedback, and final scope: the app changed from a generic planner into Event Buddy after repeated review of what felt useful, readable, and practical for attendees. AI helped with implementation, design iteration, documentation, testing, and packaging.

The PyConSG programme shaped the app around real conference behaviour: attendees must choose between parallel talks, move between rooms, protect breaks, and still find useful hallway conversations. I applied this by building: - agenda import for messy event schedules, - session recommendation based on interests such as AI/data, Python internals, security, community, and backend topics, - room-code verification for attended sessions, - buddy-code exchange for hallway-track participation, - venue rhythm guidance for room movement and tight transfers, - reward readiness that turns verified learning and networking into claimable AI-credit-style reward requests. The project also reflects the spirit of PyCon: learning, community, practical tooling, and honest technical boundaries.

This started as a schedule helper, but the most interesting part became the human side of conferences: how people decide where to go, when to rest, and how to talk to someone without making networking feel forced. A challenging part was avoiding over-claiming. For example, PDF/image OCR and real sponsor voucher minting are clearly marked as future work. The current demo uses safe local mechanics: room codes, buddy codes, and non-redeemable claim request IDs. I also wanted the project to feel warm and useful rather than like another productivity dashboard. The final design is intentionally playful, but the core workflow is practical: bring an agenda, get a realistic plan, verify attendance, connect with people, and leave with a lightweight proof trail.

Python: FastAPI + LangGraph for Agentic Essay Generation Web Dev: React + Vite + Tailwind CSS v4 + React Bits

Not Open Source as it's a collection of model essays used for educational purposes, I can't publish it openly. Regardless, - Raffles Institution KS Bull - Taken as a source of reference for the elegant language use in writing essays - DuckDuckGo Search API - This is free and aggregate sources from more trustable sites used in the "Random Paragraph" section

Much of the design was delegated to Codex which did not cause impressive results. Some iteration was done with Skills.md which was human found in the internet to make it look slightly better but it was not the pivot to be tested in this hackathon. For the essays to be tailored to be applicable to H1 General Paper, the output was first verfied by a human and the prompt used to generate future essays will be updated. After about 10 rounds of reiteration, the agentic architecture was formed and a hypothesis was validated - models still could not write to the style of GP essays, but asking the model to write smaller paragraphs before combining them gave desirable results. By judging the outputs, I effectively asked Codex to rewrite the entire architecture and used LangGraph in order to orchasterate the entire essay writing process. Now, it is able to generate essays with the correct level of vocabulary and personal voice which can be further fine-tuned to be a GP tutor at API pricing rates :)

Applied the LangGraph Supervisor model taught by MongoDb workshop in generating the final essays Applied the best cybersecurity practices for the agent permissions from the ByteDance talk to prevent the 'deputy' attack flow with restricted tool calls and permissions Applied the (similar) ADK routing with prompt decomposition in order to generate arguments which are in sync with general paper.

Did this to justify the GPT Pro submission. Entire project with meta-prompting took about 2 hours of productive work and it's just PoC of whether models can be force prompted to help students with GP. This aligns with my envisioning that students are one day tech-savvy enough for students to use these open source learning applications for their learning instead of paying money to "rent a space" and an "environment" to study :)

Python, fastapi, agent-skills, codex (lovely experience)

Used skills to help with sizing-step of analog circuits

Skill was reviewed based on domain knowledge. AI tools suggestion was reviewed by simulator.

codex workshop was very helpful

thank you

codex for code, chatgpt for ideas

Create the first draft, then everything else refined was done by me

how to use codex properly, prompt engineering, preperty-based testing w AI,

i really want to win

Python was the main programming language. Technologies used: - Python - Streamlit for the web app interface - Pandas for cleaning and displaying event data - JSON for storing/exporting event data - Apify for collecting public event-listing data - GitHub for version control and hosting project files - Streamlit Community Cloud for deployment/demo hosting - ChatGPT/OpenAI tools for ideation, debugging, prompt testing, and documentation support - HTML/CSS concepts for basic interface styling where needed The app reads the event dataset, displays relevant events, provides registration links, and helps generate post-event LinkedIn content.

We used public event-listing data collected through Apify and exported as JSON for our ProofPost event discovery feature. The dataset included event title, date/time, venue/location, event URL, and where available, organisers/speakers. This was suitable because ProofPost needs real upcoming events to help users register, remember to take photos, and generate post-event LinkedIn drafts. Rationale: We chose public event data because the app is about improving the event journey before, during, and after attending events. We only used publicly available event information and avoided collecting private attendee data.

AI tools were used as a support tool, not as the final decision-maker. We delegated brainstorming, code debugging, wording improvement, test-case suggestions, and LinkedIn post-draft generation to AI. AI helped us quickly explore different user flows, fix Streamlit/Python errors, and improve the clarity of the app interface. However, the human team judged the final product direction, selected the useful features, checked whether the generated posts sounded appropriate, verified dataset fields, and decided what should or should not be automated. For example, ProofPost suggests a LinkedIn draft, but the user still edits and approves it before posting. We used AI responsibly by keeping the process transparent, documenting prompts and outputs, avoiding private attendee data, using public event information only, and designing the app so that AI assists users rather than pretending to replace their own voice or consent.

Interaction logs and collaboration evidence are stored here: [PASTE GOOGLE DRIVE FOLDER OR GITHUB REPO LINK HERE] The folder/repo includes: - AI-human logs: prompts used for ideation, debugging, improving Streamlit code, dataset cleaning, UI wording, and submission writing. - Human-human collaboration: team discussions on feature selection, dataset issues, demo planning, and final decisions. - Stakeholder/user perspective: feedback from testing the app flow, especially whether the event discovery, registration link, and post generator were clear and useful. Team contribution summary: - Dataset collection and cleaning: [NAME] - Streamlit app development and debugging: [NAME] - UI/UX flow and demo planning: [NAME] - AI prompt testing and responsible-use checks: [NAME] - Final submission and documentation: [NAME] We kept these logs to show transparency in how the project evolved, including errors such as dataset size changes and how we fixed them.

I applied several ideas from the PyConSG26 programme to ProofPost. From the PyConSG26 hackathon, I learned that a good Python project should not only work technically, but should also show data integrity, user focus, project value, and clear execution. I applied this by making ProofPost transparent about where its event data comes from and by designing it around a real user pain point: people attend events but often forget to document them, connect with people, or post meaningfully afterwards. I was also influenced by the PyConSG26 talks on AI and data. The talk “Designing Python APIs for Data You Don’t Control” by Saurav Jain from Apify was relevant because our dataset came from public event pages that can change or be incomplete. We applied this by cleaning the JSON data, handling missing fields, and not assuming every event has perfect information. The AI-related keynotes and workshops also shaped our responsible AI approach. Instead of using AI blindly, we used it to support brainstorming, debugging, and draft generation, while keeping human judgement for the final post, feature choices, and ethical decisions. This connects to the PyConSG26 theme of using AI as a tool for better thinking and building, not just “vibe coding”. Sponsors and partners such as Apify, OpenAI, AI Singapore, Google Cloud, Python Software Foundation, and others also influenced the project because our build used Apify-style public data collection, AI-assisted development, and Python community practices.

FastAPI, Pydantic, postgres + postgis, sqlalchemy/alembic, rabbitmq/cloudamqp, react, typescript, vite, tailwind, clerk, mapbox

None at the moment.

Vision, product thinking, user feedback are all human-created initially. Expanded upon and discovery was a back and forth with OpenAI GPT5.5 and further iterated. AI coding agents scaffolded project, built new features, updated documentation and debug and deployed the project.

Too much! Just a few from day 1 sessions - From Audio to Ecology: A BirdNET Pipeline for Bird Monitoring in Singapore. Learned about platform for citizen scientists to contribute to data on birdcalling, data quality cleaning, considerations on public projects. Building Practical HealthTech AI Systems with Python: Lessons from HealthPredictor.AI - availability of medical focused models that can be used, combined with data science, software engineering and domain knowledge make for a potent force to change the world :) Building a Flexible and Scalable Notification System - think carefully about the contract for scalability. Adopting uv and pyproject.toml for mono-repo: Challenges and Approach. - per job isolation is not simple!

Actually putting together a conference for the most diverse group of users (Python) with the different use cases, balancing the needs of the audience for learning fundamentals, practical/usefulness is quite challenging. Kudos for the team, especially Mr Teh who has patiently answered my questions re the hackathon for making this work. There's also a lot of side quests - singles meetup, second brain workshop to keep everyone entertained and fulfilled. Good work people!

React 18, Vite, React Router DOM, TailwindCSS, Axios, Fastapi, Uvicorn, MongoDB, Kong, OpenAI API, PyJWT, Docker

We used the datasets provided in the track information so as to curate the different potential skills that users may be asked to learn on the skill path. We also extracted the 6-tiered proficiency scale and tweaked it from the data sets so that users can have a more intuitive label of understanding.

We used AI throughout the development process, treating it as a productivity and engineering assistant rather than a replacement for human judgment. From a development perspective, AI was primarily used to generate skeleton code and boilerplate implementations, allowing us to accelerate prototyping and focus our efforts on product design, architecture, and user experience. Rather than accepting generated code blindly, we reviewed, tested, and refined all outputs to ensure they met our technical and security requirements. This allowed us to benefit from faster development cycles while maintaining accountability for the final implementation. AI was also instrumental in helping us build and integrate our LLM-powered services. We leveraged AI-assisted development to design endpoints, structure prompts, and ensure that the information returned by the models aligned with the intended user experience. This enabled us to rapidly experiment with different approaches and iterate on our service architecture. To improve effectiveness, we used AI to seek guidance on model selection, prompt engineering, and temperature tuning for different use cases. By adjusting model parameters according to the desired outcomes, we were able to optimize the performance of our LLM workflows for different user scenarios. Responsible AI usage was a key consideration throughout the project. We carefully reviewed all AI-generated code and system designs to minimize security risks, prevent unintended data exposure, and ensure that user information was handled appropriately. We avoided relying solely on AI-generated outputs for critical decisions and maintained human oversight across all stages of development. In addition, we designed our system with resilience and reliability in mind by implementing a model fallback and rollback chain. If the primary model became unavailable or failed to respond, alternative models could continue serving users, ensuring continuity of service and reducing the risk of disruption. This approach improved both the robustness of the platform and the overall user experience. Overall, AI enabled us to develop faster, explore more ideas, and build more sophisticated capabilities, while our engineering controls, validation processes, and fallback mechanisms ensured that the technology was used responsibly and safely.

At PyConSG 2026, one of the most impactful sessions for us was "How I Run My One-Man Company with Hermes Agent" by Auxten Wang. It demonstrated that the value of AI does not come from prompting alone, but from designing systems that combine workflows, memory, tools, and decision-making processes. This reinforced a key lesson that pushed us to move beyond simple chatbot interactions and towards structured, engineering-driven AI solutions using agents and workflows. We applied this learning directly to our product. While reviewing Auxten's slides and the broader discussions on AI agents, we realised that prompting in isolation provides limited value. Users need systems that can understand context, guide actions, and support outcomes. As a result, we designed our solution around helping individuals close the gap between their current and desired skill states through structured workflows rather than relying solely on ad-hoc prompts.

Gender diversity: we have 2 guys and 1 girl! Credits to SkillsFuture for their well-scraped dataset! In the case that the Vercel link is down, please refer to the source link README.md file (https://github.com/vigalodean/vlojster/blob/main/README.md) for the Setup & Running Guide so that the local setup is working.

backend: FastAPI, Python, OpenAI GPT-4o, SkillsFuture Singapore, PyMuPDF, JWT, passlib, JSON, pytest, httpx frontend: React, TypeScript, Vite, Tailwind CSS, React Router, Zustand, TanStack Query, Recharts, Axios

https://jobsandskills.skillsfuture.gov.sg/skills-frameworks#download-the-latest-skills-framework-dataset The LLM alone will invent role requirements based on training data patterns — which may reflect global job markets, not Singapore's. SkillsFuture is Singapore's nationally curated, employer-validated framework. Using it as the input to the LLM means the skill list is authoritative, not generated. The AI then reasons over real data rather than making it up.

we delegated the baseline code to ai, along with the implementation of the extraction of pdf to text which we are unfamiliar with. vs code testing, considering user usability & app experience, the ideation & what measurements and how to measure

from workshops like building with codex, i learnt how to use ai to optimise my workflow, as well as for coding for my web app. from keynote 3, i learnt how to move past vibe coding and understand that having proper fundamentals laid out is crucial as well as using human judgement in my development of web app.

Python stdlib backend (http.server), deterministic recommendation engine, JSON API, unittest test suite, static HTML/CSS/JavaScript frontend, GitHub Pages for the public demo, Git/GitHub for source control. No paid runtime, database, or external API key is required for the demo. Optional OpenAI-compatible chat completions can add a short coaching note via OPENAI_API_KEY, but the app works fully offline and the recommendation scores remain local/auditable.

Primary data model: SkillsFuture Jobs-Skills / Skills Framework-style role-skill data schema (sector, role, key tasks, technical skills, critical core skills, proficiency, source notes), based on the official hackathon resource: https://jobsandskills.skillsfuture.gov.sg/skills-frameworks. The demo includes a compact curated sample dataset in src/skillbridge/data.py so judges can inspect the logic without external API dependency. Rationale: the product needs transparent role-to-skill mapping, not opaque web search. The app is structured so the official Q2 2026 spreadsheet can replace/extend the sample data.

AI was used as an ambitious teammate for research, product strategy, coding, UX copy, and submission drafting. Human judgment was applied to choose Track 1, prefer explainability over a generic chatbot, and keep the ranking logic transparent. In the product, AI is intentionally bounded: the core score is deterministic Python math (65% technical skill overlap, 20% critical-core overlap, 15% interest fit). OpenAI is optional only for a short coaching note if an API key exists; no AI model can silently change the ranked recommendations. This makes the learner pathway inspectable, contestable, and safer.

Process / interaction log: https://github.com/abelcjh/pyconsg26-lifelong-pathfinder/blob/main/docs/PROCESS_LOG.md Judging alignment: https://github.com/abelcjh/pyconsg26-lifelong-pathfinder/blob/main/docs/JUDGING_ALIGNMENT.md Key implementation trail is visible in Git commits and source files. The log documents event-context reading, problem selection, AI delegation, human accountability checkpoints, and the decision to keep recommendation scoring deterministic and auditable.

I applied the hackathon theme “Architecting the Future of Lifelong Learning” directly: the product answers the official Track 1 learner questions — where can I go next, what skills matter, and what should I do today? I also applied the PyConSG emphasis on AI learning-by-doing and responsible AI use: instead of outsourcing judgment to a black-box chatbot, the app exposes the data, scoring method, evidence, and next actions. The AI Ready ASEAN framing influenced the product’s emphasis on AI fluency, ethics, explainability, and human accountability.

This was built solo but with an explicit human-AI collaboration process. The most interesting design choice was to deliberately avoid the flashiest “AI career chatbot” route and instead build a product a learner can inspect, challenge, and trust. The project is small but complete: public demo, source repo, tests, process log, judging alignment, and a clear path to plugging in the full SkillsFuture dataset.

IDE : VS Code Backend and Frontend: Streamlit Version control and sharing: GitHub

1. Jobsandskills dataset from SkillsFuture (jobsandskills-skillsfuture-skills-framework-dataset.xlsx) This dataset provides a wide range of jobs and the corresponding skills required. It also provides well written descriptions for the jobs, which works well when we generate embeddings. The dataset is also reliable, as it is sourced from SkillsFuture, a trusted Singapore government-supported platform. 2. MySkillsFuture Course Directory (https://data.gov.sg/datasets/d_b5802b76f409764c16dde4bf2feb19cd/view?utm_source=chatgpt.com ) This dataset is highly relevant, as it contains the list of MySkillsFuture courses from the MySkilsFuture website. There are many courses, with varied course topics, giving us a good data set to work with. There were also details on course fees etc, which will help us better tailor to the needs and budgets of our user. The dataset is also reliable, as it is sourced from MySkillsFuture, a trusted Singapore government-supported platform.

We used AI while building our product. At different stages of building our product, we use AI in different ways. In the ideation phase, we used large language models like ChatGPT to help us brainstorm a wide range of solutions. We used targeted prompting, asking AI to analyze changes specific to Singapore, which helped us narrow down what we wanted to achieve. We practiced efficient prompt engineering, by being specific in our prompts, giving our LLMs the context and goals. We also verified the information provided by AI by requesting the sources behind its factual claims and cross-checking them against reliable sources such as credible news articles and government websites to ensure the accuracy and reliability of the information used. We also ran our own original ideas through AI and prompted it to discuss with us the feasibility of the project given time constraints. We also used AI to discuss the various possible tools. For example, when deciding how to build the UI of our app, we prompted AI to weigh the pros and cons between using Lovable, Django and Streamlit. Our discussion led to the conclusion that Streamlit would tie best to our written code in python. While building our app, we used AI to help speed up the code writing, debugging and design of our project. We strictly used AI as an assistant and remained in control. We segmented our code and used AI to help write certain parts of the code. We ensured that we understood the code provided to us by AI before implementing them in our product. This allowed us to generate clean and usable code while still focusing on the core architecture of the app. Our application integrates OpenAI APIs for matching jobs to their likely skills. We used the model ‘text-embedding-3-small’ for this function. We chose this for the cost effectiveness, high performance and semantic understanding capabilities. As our dataset is large, we broke it down into batches in order to ensure the code does not exceed the token limit. Before the next step, we also integrated a human in the loop function by asking the user to verify which skills they actually have after we generate their likely skills. Our application integrates Open AI APIs to explain how a certain course can help a user breach from current job to dream job through addressing the missing skills. We used the model ‘gpt-4.1-mini’. We ensured that we provided enough information for the LLM to provide good explanations.

The keynote talk “Using Tools Without Being Used: The Four Stages of AI Fluency and What They Make Possible Together” on conference day 1 deepened our understanding of how AI models work and reinforced the importance of using AI responsibly and critically. The talk “SKILL.md is the SOP your AI agent never had” on conference day 2 gave us an understanding of machine learning workflows (understand the problem->prepare the data-> train the model-> evaluate performance-> interpret the results) and guided the development of our app in a structured and systematic manner, as the process is similar to how our recommendation system is built. Furthermore, it helped us better understand how AI works and what is happening behind the code. There were many other conference talks that went into many tools such as Apify, CPython interpreter. These talks helped us widen our knowledge of the tools available that we could use for our project. The workshop “Build Your First Web App with Django” increased our familiarity on how to host a web app with python. Although we did not use Django in the end, this workshop showed us still valuable to our hackathon as it gave us a basic idea of how web apps actually work. The workshop “Building with Codex” was helpful as it showed us just how useful Codex could be. Before we started to write our code, we used Codex to build a prototype of how we would like the interface and flow of our project to be. This helped us greatly as we were much better able to visualize our end product while working on our app.

fastapi, nextjs, keras, scikit-learn, google ADK, supabase

https://jobsandskills.skillsfuture.gov.sg/skills-frameworks#download-the-latest-skills-framework-dataset all 3 datasets in this page The three SkillsFuture workbooks were chosen because together they're authoritative (the government's own role<>skill <>funding map), rich enough to reason over (40k role-skill links and 150k knowledge/ability statements), and they carry the one signal a learner actually needs—what the state will help pay for via the Emerging/CASL funding flags—with File 1 supplying the role catalogue and skill links, File 2 providing the crosswalk that collapses ~12k proficiency-specific codes into ~2.3k unique skills, and File 3 giving the clean deduplicated skill master with ground-truth funding labels.

AI tools were used creatively as an exploration partner to discover non-obvious relationships across the three SkillsFuture workbooks and to research the problem space, which shaped features like the reachable-role graph and the "next-to-be-funded" watchlist, and effectively to accelerate non-critical work like ML feature brainstorming, FastAPI/Pydantic boilerplate, documentation, NextJS frontend designing, debugging, and the semantic crosswalk that maps resume skills onto framework skills by meaning.

workshop 1,2,3: recap of python, building web app and use of data science libraries for the datasets provided workshop 7: learnt how to use codex and effectively prompt AI Kopitiam: using google adk to build and show agent workflow

The hardest part wasn't the code but simply understanding an overwhelming dataset, three dense Excel workbooks with 40k role-skill links and figuring out a sensible use case for it, which we cracked by going back to the data science fundamentals from our coursework (pandas, numpy) to break the data apart and find the hidden connections. We also pivoted mid-project: we started with Django but found its frontend/backend coupling too rigid, so we moved to an API-first FastAPI + Next.js stack that let the data engine and UI evolve independently. Talking with the participants, sponsors and organisers helped definitely also helped made our project better and gave us clarity. Very grateful for this event and hackathon!

Python-first stack: Python 3.11, FastAPI, Uvicorn, openpyxl for SkillsFuture Excel datasets PyMuPDF for resume PDF parsing, icalendar/tzdata for calendar export, httpx, and Python unittest. The frontend uses React 19, Vite, and lucide-react, with Playwright for E2E tests. External integrations include GitHub API, Exa, Apify, optional OpenAI/Anthropic, SQLite for demo persistence, and Vercel for deployment.

We used the official SkillsFuture Job & Skills Skills Framework datasets, including the role-skill framework, TSC-to-unique-skills mapping, and unique skills list from SkillsFuture Singapore: https://jobsandskills.skillsfuture.gov.sg/skills-frameworks#download-the-latest-skills-framework-dataset. We chose this source because it provides an official Singapore-based taxonomy of job roles and skills, letting PathForge AI compare a user’s current role against a target role, identify transferable skills, detect skill gaps, and recommend relevant upskilling paths.

we used ai as part of our loop engineering process, not as an autopilot. chatgpt helped with direction and thinking, while cursor and claude code helped us build, test, debug, and iterate faster. our loop was usually: discuss the problem with ai, choose a direction as humans, let ai scaffold or implement, run it in the actual app, observe what broke, fix it, then review again before merging. this helped us move quickly while still keeping human judgement in the loop. creatively, ai helped us get unstuck when we hit real product constraints. for example, linkedin does not have an api to directly drop a draft into its composer, and apple does not have a calendar push api. instead of forcing a complicated oauth flow, we iterated toward a simpler solution: a single .ics download, a linkedin share link, and a proof of learning step where a session only counts as done after the user writes what they learned. the hybrid scheduler idea also came from this loop. the actual scheduling logic is deterministic, so sessions are always placed correctly. ai is only used to polish the wording and make the experience feel more natural. effectively, ai handled the fast execution parts: building the scheduler, calendar and linkedin endpoints, react panels, writing tests, reproducing ui bugs in the browser, diagnosing root causes, and drafting docs. each output still went back into the loop: run, check, adjust, and review. responsibly, we kept a clear boundary. the score is fully deterministic from the skillsfuture data. ai only explains the score, it does not decide it, invent evidence, or promise a guaranteed job outcome. there was even a case where claude assumed a fix was already merged, then caught the mistake, and we re-checked it in the running app. that is why our process was not just “ask ai and trust it”, but “ask, build, test, verify, then merge”. we delegated brainstorming, ui scaffolding, endpoint and component implementation, tests, bug diagnosis, copywriting, docs, and approach suggestions to ai. humans still owned the product direction, scope, scoring interpretation, ethical guardrails, correctness checks, safety, and final approval for every commit before it went to main.

https://github.com/Luci6n/pycon26/tree/main/logs. Interaction logs are in the repo's /logs folder: AI–human prompts and decisions in claude_code_logs.md, chatgpt_logs.md, ▎ cursor_logs.md; human–human collaboration and ownership in team_discussions.md and contribution_tracker.md.

We applied learnings from the PyConSG26 programme into PathForge AI’s design and implementation. Georgi Ker’s keynote on staying relevant in an AI-shaped world shaped our focus on helping people who feel lost about role transition. Anthony Tung’s keynote on AI fluency influenced our choice to make AI a guide, not the final decision-maker: the app uses deterministic Python scoring from SkillsFuture data, while AI only supports explanations and planning. The SkillsFuture Advice Workshop directly inspired our use of SkillsFuture role-skill datasets to identify in-demand skills and upskilling paths. We also learned from talks/workshops on practical AI engineering, testing, and evaluation, such as Google’s Generative AI keynote, the LangGraph/MongoDB agent workflow workshop, and the LLM evaluation workshop, which pushed us to keep the system structured, testable, and grounded in real data. Sponsor/product learnings also shaped the app: Apify is used for job-market validation, while the wider sponsor ecosystem such as Google Cloud, Navicat, and the Python Software Foundation reinforced deployment, data, and open-source best practices.

our project da best, 1st place confirm thx.

Career Radar is built with Python 3.12, FastAPI, SQLAlchemy, PostgreSQL on Supabase, React + TypeScript + Vite, and Recharts on the frontend, with Anthropic Claude via the anthropic SDK for chat and structured extraction. It also integrates Google OAuth/Gmail API for job-alert ingestion, Apify for active job search, Rapidfuzz, pandas, and openpyxl for matching and dataset processing.

Career Radar uses the SkillsFuture Jobs-Skills Portal datasets as its core reference layer: the SkillsFuture Skills Framework dataset, the TSC-to-Unique-Skills mapping, and the Unique Skills List. These are combined to create a canonical, explainable skill taxonomy across sectors, so the app can map CVs, job alerts, and work logs to real SkillsFuture skills instead of free-form AI guesses. I also use live job-alert signals from Gmail and active job search results from Apify as ingestion sources, so the app reflects both passive and active career signals. The link is from the SkillsFuture website https://jobsandskills.skillsfuture.gov.sg/skills-frameworks#download-the-latest-skills-framework-dataset

AI was used as a helper, not as the source of truth. Claude was used to speed up structured extraction, chat responses, and implementation support, but the important product decisions remained human-judged: data source selection, explainability requirements, ranking logic, scope boundaries, and what to expose in the demo. Deterministic code handles the core matching and ranking so the output stays auditable. I also used interaction logs to document decisions, tradeoffs, and limitations so the AI usage stays transparent and responsible.

Interaction logs: interaction-logs/ folder in the repo — github.com/erickch123/career-skills- radar/tree/main/interaction-logs. DECISIONS.md — ~20 AI-human judgment calls logged contemporaneously: what was delegated to AI, what the human decided, and cases where human corrected AI direction (e.g. Gmail OAuth design, Resend over Clerk/SendGrid, skill synonym validation against real dataset). Also documents how a PyCon SG 2026 Day 2 talk (GyeongSeon Park, Kakaobank) directly shaped the notification architecture. - EXECUTION_PLAN.md — phased build plan (Phases 0–9) agreed before any code was written. - Human-only: problem framing, all final architecture calls, recognising the PyCon talk was applicable, correcting AI assumptions. - docs/ folder (PRD, ARCHITECTURE, ERD, USER_STORIES) — co-authored iteratively with Claude throughout planning.

I drew directly from several PyCon SG 2026 sessions. The keynote “So Kiasu, Still Kena Replaced by AI?” reinforced the core problem: staying career-ready even when you are not actively job hunting. Designing Python APIs for Data You Don’t Control” and the Apify workshop influenced defensive parsing, schema-aware job ingestion, and cost-capped scraping.

This project is has intentional limitation, it is single-user for the hackathon, email job alerts only expose the metadata those providers actually send, and the app avoids pretending that AI can infer everything perfectly.

For our project, we mainly used Python for the backend because this is a PyCon project and Python was the best fit for handling the API, data processing, AI matching, and working with the SkillsFuture datasets. We used FastAPI to build the backend server. The browser extension sends the extracted job description to this API, and the API returns the extracted skills, the closest official SkillsFuture matches, confidence scores, definitions, and whether the skill is an emerging skill. In Python, we used pandas to read and process the SkillsFuture Excel datasets, especially the Unique Skills List. We used NumPy to calculate cosine similarity scores between the job skills and the official SkillsFuture skill embeddings. We also used sentence-transformers with the all-MiniLM-L6-v2 model to create embeddings for the official SkillsFuture skills, so our system could match skills based on meaning instead of only exact keywords. For AI, we used the OpenAI API in the main backend to extract key skills, tools, qualifications, and requirements from job descriptions. We also created a local version using transformers and google/flan-t5-small, so the project could still demonstrate AI-based skill extraction without depending completely on the OpenAI API. We used Pydantic to define and validate the request format sent to the backend, and Uvicorn to run the FastAPI server locally. We also used python-dotenv to load environment variables such as the OpenAI API key from a .env file, instead of hardcoding secrets directly into the code. For preparing the skill matching database, we wrote a precompute script that reads the SkillsFuture Excel file, combines each skill title and description into text, generates embeddings in batches, and saves the result into skills_with_local_embeddings.pkl. This made the actual demo faster because the backend did not need to regenerate all embeddings every time it started. For the frontend, my teammate and I built a Chrome/Edge browser extension using JavaScript, HTML, CSS, and Chrome Extension Manifest V3. The extension adds an “Analyze with SkillsFuture” button onto supported job pages, extracts the job description text, sends it to the Python backend, and displays the matched SkillsFuture skills in a side panel. We also added logic in JavaScript to handle different job websites such as MyCareersFuture and LinkedIn Jobs. The extension tries to extract only the real employer job requirements and avoid unrelated page content such as navigation text, footer text, and profile prompts like “Tell employers what skills you have”. The extension also uses browser storage to save recent analysis history, so users can view previous job analyses without running the same analysis again. We included a local test page as well, which helped us test the extension and backend connection during development. Overall, our tech stack combined Python, FastAPI, pandas, NumPy, Pydantic, Uvicorn, sentence-transformers, OpenAI, transformers, JavaScript, HTML, CSS, and Chrome Extension APIs to build an AI-powered SkillsFuture job skill matcher that connects real job postings to official SkillsFuture skills.

The project mainly uses the SkillsFuture Singapore Unique Skills List as the core dataset. This is the file jobsandskills-skillsfuture-unique-skills-list.xlsx, which contains 2,316 official skill records with skill titles, descriptions, skill type, and whether each skill is an emerging skill. This is the most important dataset because the backend converts these official skills into embeddings and saves them as skills_with_local_embeddings.pkl, allowing the app to match skills extracted from job descriptions against an official SkillsFuture skill taxonomy. The project also includes the SkillsFuture TSC-to-Unique-Skills Mapping dataset, jobsandskills-skillsfuture-tsc-to-unique-skills-mapping.xlsx. This maps sectoral Skills Framework skill codes and titles to the newer unique SkillsFuture skill titles. The rationale is that SkillsFuture skills can appear under different sector frameworks, so this dataset helps connect detailed industry skill codes to a cleaner, deduplicated skill list. A broader SkillsFuture Skills Framework Dataset is also included as jobsandskills-skillsfuture-skills-framework-dataset.xlsx. It contains job roles, critical work functions, key tasks, TSC/CCS titles, proficiency levels, and knowledge/ability items. The current backend does not directly load this full workbook at runtime, but it is useful as supporting reference data because it gives richer context around how skills relate to job roles and proficiency levels. The extension also uses live job description text from supported job pages, mainly MyCareersFuture and LinkedIn Jobs. This is not a fixed stored dataset; it is runtime input collected by the browser extension. The rationale is that the project needs current employer requirements from real job postings, then maps those requirements to official SkillsFuture skills. Sources: SkillsFuture Singapore Unique Skills List File: jobsandskills-skillsfuture-unique-skills-list.xlsx Link: https://www.skillsfuture.gov.sg/skills-framework SkillsFuture TSC-to-Unique-Skills Mapping File: jobsandskills-skillsfuture-tsc-to-unique-skills-mapping.xlsx Link: https://www.skillsfuture.gov.sg/skills-framework SkillsFuture Skills Framework Dataset File: jobsandskills-skillsfuture-skills-framework-dataset.xlsx Link: https://www.skillsfuture.gov.sg/skills-framework Live job description text Sources: https://www.mycareersfuture.gov.sg/ and https://www.linkedin.com/jobs/

AI tools were used in two main ways: Codex/ChatGPT helped us build and improve the project, while the OpenAI API was used inside the app for skill extraction. We used Codex and ChatGPT as development assistants throughout the project. They helped us understand the SkillsFuture datasets, plan the hackathon workflow, design the FastAPI backend, build the browser extension, debug errors, improve the side panel, write test steps, and explain technical parts in simpler language. Codex also helped us troubleshoot issues such as virtual environment setup, backend startup errors, CORS problems, extension injection, and testing the extension on MyCareersFuture. The OpenAI API was used inside the actual product for the language-heavy part of the workflow. When a user analyses a job description, the backend can use the API to extract relevant skills, tools, and requirements from the employer’s text. These extracted skills are then matched against local SkillsFuture skill embeddings and course data. Human judgement came in when deciding how much of the AI output to trust and use. We did not accept everything AI suggested immediately. For example, some AI suggestions were too large for a six-day hackathon, such as building a full production database system, a complex agentic workflow, or a complete course-planning system too early. We chose to simplify those ideas into a realistic MVP first. We also rejected or changed AI suggestions when they did not fit the product. For example, AI suggested some approaches that sounded impressive but were not necessary, such as adding agentic AI before the basic skill-matching workflow was stable. We decided that a grounded RAG-style approach made more sense than calling the product “agentic” without a real need for multi-step autonomous reasoning. We also used judgement when AI-generated code or plans were not fully suitable. If a suggestion created bugs, was too broad, or did not work well in our environment, we adjusted it. For example, we had to debug backend startup issues, CORS issues, extension injection problems, and browser testing problems instead of assuming the first AI-generated solution was correct. We also refined the UI when earlier outputs looked too generic or not useful enough for users. We have decided to make the API usage more token-efficient by choosing a hybrid embedding-based matching approach. We setted up a precomputed SkillsFuture embeddings pkl file which was automated by a Python Script. Instead of sending the whole SkillsFuture dataset to the OpenAI API, we used the API mainly to only extract skills from the job description. Those extracted skills were then matched locally against precomputed embeddings to retrieve the closest official skill candidates. This meant the AI only had to work with the job text or a small shortlist of matches, instead of the entire dataset, reducing token usage while keeping the results grounded in official SkillsFuture data. In short, AI helped us move faster, generate ideas, write code, debug, and extract skills from job descriptions. Human judgement decided what to keep, what to reject, what to simplify, and what needed to be tested or rewritten. We treated AI as a collaborator, not as the final decision-maker.

It will be in the github repo in the evidence folder (interaction-logs.md)

We learned from the PyConSG26 programme that a good project should not just “use AI”, but use it in a way that is useful, explainable, and grounded in real data. One part we applied directly was the Job & Skills Track from the hackathon. The track asked teams to build things like career explorers, skill gap analysers, and upskilling pathway tools using public jobs-skills datasets. That matched our project closely, so we focused our idea around real job descriptions and the SkillsFuture skills dataset. We also followed the guidance that good products should explain why recommendations are shown and offer actionable pathways, instead of just giving users a long list of skills. We also learned from the keynote “Using Tools Without Being Used: The Four Stages of AI Fluency” by Anthony Tung. The main takeaway we applied was that AI should support human thinking, not replace it. In our project, we let AI extract and match skills, but we still used human judgement to choose the dataset, decide what text should be trusted, and design the output so users can understand the results. Another talk that influenced us was “This Talk Was Generated by AI. Please Don’t Trust It.” by Dr Weihan Goh. It reminded us that AI output can sound confident even when it is wrong. Because of that, we did not want our app to pretend every match is perfect. We added confidence scores, showed other possible matches, and made sure the system only analyses employer job requirements instead of random page text. We also took inspiration from “Designing Python APIs for Data You Don’t Control” by Saurav Jain. Our browser extension reads job pages like MyCareersFuture and LinkedIn, but those websites are not controlled by us and their layouts can change. Because of that, we designed the extraction logic more carefully, with fallbacks and filters to avoid navigation text, footer text, and profile prompts. The SkillsFuture Advice Workshop also connected strongly to our project because it focused on emerging industry trends, in-demand skills, and using SkillsFuture resources for career planning. That helped us frame our project less like a normal job analyser and more like a tool that helps users understand what skills they may need for upskilling. We also learned from the PyLadies Python workshops, especially the focus on using Python with real datasets, pandas, numpy, and basic data processing. We applied that through our backend, where we used Python to read the SkillsFuture Excel files, process the skill records, generate embeddings, and perform similarity matching. From the sponsors and partners side, we used the hackathon resources and OpenAI support to build the AI part of the project. OpenAI was used for extracting skills from job descriptions, while the official SkillsFuture dataset gave us the trusted source of skills to match against. This combination helped us build something that was not just a chatbot, but a Python-based tool connected to real public career data.

One thing we would like to share is that this project was more challenging than we first expected because it was not just about building an AI feature. A big part of the work was making sure the system used the right text from a job posting. For example, on MyCareersFuture, the page includes extra text such as profile prompts and job-match suggestions. At first, that kind of text could accidentally get mixed into the analysis, which would make the AI extract the wrong skills. We had to spend time improving the extraction logic so that the system focused only on the employer’s real responsibilities, requirements, qualifications, and tools. Another interesting part was learning that AI matching is not always a simple “correct or wrong” answer. Sometimes a job skill can be close to more than one official SkillsFuture skill, so we decided to show confidence scores and other possible matches instead of pretending the system is always perfectly certain. My teammate and I also learned a lot from connecting different parts together: Python backend, official datasets, AI models, embeddings, and a browser extension. Each part worked differently, so getting them to communicate smoothly was one of the most satisfying parts of the project. We would also like to acknowledge that this project was built with support from the open-source Python ecosystem, including FastAPI, pandas, NumPy, sentence-transformers, and transformers. These tools made it possible for us to build something meaningful within a short time. Overall, this project reminded us that AI is most useful when it is combined with careful human judgement, good data, and thoughtful design.

OpenCV - webcam video capture and image processing MediaPipe FaceMesh/Iris landmarks - face, eye, and iris tracking NumPy - landmark calculations and smoothing PyAutoGUI - mouse control, clicking, scrolling, and zoom shortcuts Tkinter - on-screen crosshair and status overlays Pillow - rendering translated text in preview/status displays HTML, CSS, JavaScript - web frontend interface Python http.server - local web server/API bridge between frontend and backend

No external dataset was used. My project uses live webcam input from the user’s own laptop instead of a stored dataset. This was chosen because the app needs to respond to the user’s real-time eye movement, blinking, lighting, camera angle, and face position. The eye and face tracking is based on MediaPipe FaceMesh/Iris landmarks, which provides pre-trained landmark detection rather than requiring me to collect or train on my own dataset.

AI tools were used to help build, debug, and refine the project quickly. The AI assisted with writing backend Python code, creating the web frontend, improving accessibility features, fixing errors, packaging the app, and preparing deployment instructions. Human judgement was used to decide the project goal, test the eye tracking in real conditions, judge whether the interface felt usable, choose which features mattered most, and approve changes such as colour themes, text size, language options, and blink controls. AI handled implementation support, while humans made the design, usability, and ethical decisions.

I learned from the PyConSG26 programme that AI should be used as a tool to support human thinking, not replace it. From the AI keynotes and talks about responsible AI, prompt engineering, and not blindly trusting AI-generated output, I applied this by using AI to help write code, debug errors, and improve the frontend, while I personally tested the eye tracking, judged the usability, and decided what features were actually useful. I also learned from the community, D&I, and Python ecosystem focus that technology should be inclusive and practical. I applied this by adding accessibility features such as high contrast mode, colour-blind friendly colours, soothing colours, adjustable text size, language options, and safe-test mode. The Python-focused sessions also influenced how I built the project: a Python backend, a local API, computer vision tracking, and a web frontend that connects to the backend.

If further developed, it could be a tool that many people will want to use and it will be very beneficial. We were able to share this idea to a person who had one arm and although he mentioned that he is able to use the web, in many scenarios, he has faced many difficulties and he shared that this idea will benefit him a lot.

Python, Fastapi, React.

https://jobsandskills.skillsfuture.gov.sg/skills-frameworks#download-the-latest-skills-framework-dataset The above SkillsFuture datasets are used as the trusted skills intelligence layer behind myskills.fit: they give the app a structured way to connect a person’s existing experience to recognized skills, job roles, and learning pathways. Rationale: The app’s purpose is to help users understand “where they fit” and “what to learn next,” so it needs more than free-text career advice. SkillsFuture datasets provide a common national taxonomy of skills, occupations, and training options, which lets the app translate messy user inputs like past roles, projects, interests, or self-described abilities into standardized skill profiles. Those standardized skills can then be compared against role requirements or career pathways. This allows myskills.fit to identify strengths, gaps, adjacent opportunities, and practical next steps instead of giving generic recommendations. The datasets also make the recommendations actionable. Once a skill gap is found, the app can map it to relevant SkillsFuture-aligned courses or learning areas, helping users move from self-assessment to a concrete upskilling plan.

AI tools sped up the development immensely but the team comprising product management and engineering expertise had to be involved at each change stage reviewing and testing each iteration output from the AI pull requests. Product research, management and design was done with AI (Gemini) separately first before starting with openspec to plan the implementation.

Openspec Spec Driven Development (SDD) methdology was used for this app. All specifications written with openspec AI assistance using Hermes Agent, and then assigned to Codex for implementation. All specifications of the initial app and change iterations can be found in https://github.com/edwin-nz/myskills.fit/tree/main/openspec

Codex, Hermes Agent, Google ADK where the AI Studio API key was used for this app since OpenAPI credits was not available for the hackathon.

Thanks to all the organisers and everyone who helped make PyCon26 successful. It was good to target the grassroots and charge an afforable price so that more can attend. It is really by the people for the people!

Python backend (the core): FastAPI — REST API, with Uvicorn as the ASGI server pandas + openpyxl — ingesting the 3 SkillsFuture Excel workbooks (~2,027 roles, 2,316 skills, 12,326 mappings) into SQLite rapidfuzz — fuzzy matching AI-returned skill titles back to canonical catalogue entries pydantic — typed request/response schemas httpx — async calls to the OpenAI API and the Apify job-scraping actor pdfplumber — parsing uploaded resume PDFs into text for the AI pytest — test suite (with a conftest that isolates the test DB from the ingested production data) AI / data services: OpenAI gpt-4.1 (intake, inference, gap analysis); Apify Google Jobs scraper for live Singapore job listings. Frontend: Next.js 16 + TypeScript + Tailwind CSS. Deployment: Render (FastAPI backend, with build-time data ingest) + Vercel (Next.js frontend).

AI was used both inside the product and as a build assistant, with a clear line between what we delegated and what we judged ourselves. Delegated to AI: Inside the app: OpenAI gpt-4.1 drives the conversational intake — inferring a user's current SkillsFuture role and their TSC/CCS skills from natural language or an uploaded resume. AI also generates role rationales, gap summaries, and course suggestions. During development: Claude (Claude Code) accelerated boilerplate, UI scaffolding, API wiring, and debugging — e.g. tracing a deployment hang down to stale server processes. Human-judged: Grounding & guardrails. We did not let the LLM invent skills or roles. Every inferred skill is constrained to the official SkillsFuture catalogue (2,316 unique skills); the model must return exact catalogue titles, which we then match and validate in code. This was a deliberate human design decision to prevent hallucination. Explainability. We required every AI-driven recommendation to carry an (i) tooltip citing its ground-truth source (the 3 SkillsFuture workbooks or the live job data) — so users can audit the AI, not just trust it. Honesty over hype. We hand-wrote the plan's framing to tell users plainly that "30 days won't fully retrain you for a new career" — choosing responsible expectation-setting over an inflated promise. Graceful degradation. When no API key is present or a call fails, the app falls back to deterministic logic instead of breaking — a reliability choice we made, not the model. In short: AI handled language understanding and generation; humans owned what's true, what's cited, and what we promise the user.

I wasn't able to attend the sessions live this time — work caught up during the event. But the programme's focus on the Python web/API ecosystem pushed me to dig into FastAPI and Pydantic on my own in the lead-up. That reading is what sparked the direction of this project: it got me genuinely interested in building and deploying real APIs, not just running things locally. It's also why I pushed myself to take the backend all the way to a live deployment on Render and test it end-to-end — something I hadn't done before. So while my learning came from the topics and materials around PyCon rather than the talks themselves, it directly shaped both the stack (FastAPI + Pydantic) and the goal of shipping a deployed, testable API.

Honestly, I underestimated how much time this would take. Between the AI intake, grounding everything in the real SkillsFuture data, the live job scraping, and getting it deployed, there was a lot more depth than I expected going in. I'm proud of what's working, but I know that with more time I could have polished it further — tightened the UX, added more tests, and refined a few rough edges. It was a good reminder of how much careful scoping matters, and it's left me wanting to keep building on it beyond the hackathon.

Python stack: FastAPI, Pydantic, LlamaIndex, Python demo scripts, Pytest, Pygame, MicroPython on ESP32. AI/RAG: RAG-ready seed knowledge base, bilingual term mapping, safety boundary classifier, structured JSON contracts, optional OpenAI API / embeddings, optional HuggingFace local embeddings. Hardware: ESP32, MicroPython, AMOLED round display, WebSocket device connection, hardware directives for listening, breathing, exercise countdown, reminders, and location-related states. Frontend/App: Mobile-first voice UI, Talk / Breathe / Move / Timeline / Me flows, fixed demo-safe skill flows, large-font accessible UI, App-to-device synchronization. Dev: GitHub, local-first demo mode, mock/live AI fallback, structured demo scripts.

https://docs.sea-lion.ai/models/sea-embedding/sea-modernbert https://huggingface.co/aisingapore/SEA-LION-ModernBERT-Embedding-300M

We used AI tools as assistants for product design, UI prompting, API contract design, code support, README refinement, and demo scripting. AI was delegated ideation, wording drafts, UI prompt generation, structured JSON schema drafting, RAG scaffolding, and implementation suggestions. Human team members made the final decisions on target users, product scope, safety boundaries, cultural tone, hardware interaction, demo flow, and ethical positioning. We used AI responsibly by keeping the product non-diagnostic, avoiding medication or prescription advice, using structured JSON outputs, applying safety boundaries, and saving records only with user consent.

We learned from the PyConSG26 programme in three main ways and applied them directly in Her Otta Lah. First, the hackathon brief encouraged us to build with PyConSG programmes and partner tools, not just make a generic AI demo. We applied this by making Python the core of our backend and demo stack: FastAPI for the AI service, LlamaIndex for the RAG-ready knowledge base, Pydantic-style structured JSON contracts, Pytest tests, Pygame for an accessible micro-game flow, and MicroPython on ESP32 for the otter hardware companion. Second, the PyConSG26 workshops and programme emphasised practical Python learning, agent workflows, and building systems that actually run. We applied this by designing a full end-to-end flow: user voice input → language normalization → safety boundary → RAG/action recommendation → structured JSON → App UI / ESP32 hardware / Pygame demo flow. Instead of keeping AI as a chatbot, we used Python to connect AI reasoning with real product and hardware behaviour. Third, we learned from the hackathon sponsor ecosystem. Inspired by AI Singapore / SEA-LION’s focus on local language inclusivity, we designed the product to handle Mandarin, English, Singlish-style phrasing, and common Malay terms such as “sakit” and “makan”. From OpenAI, we applied the idea of structured outputs: AI responses are constrained into predictable JSON so they can safely drive App screens, record cards, and hardware directives. From Google Cloud / Vertex AI, we kept the architecture cloud-deployable and extensible toward multimodal support, while keeping the demo local-first and fallback-safe. We also applied the PyCon community spirit: build something useful, open, demoable, and understandable. Our final project is not just an AI pitch; it is a Python-based working prototype combining AI, RAG, safety boundaries, accessible UI, and ESP32 hardware interaction.

Backend / engine: Python 3.11, FastAPI and Uvicorn as a single service that serves both the API and the React SPA. DuckDB is the analytical store (read in-process from a snapshot baked into the deploy image), with MotherDuck as the canonical write/ingest store for live jobs and a Cloud SQL (Postgres, via psycopg) ingestion path. pandas and numpy for data work, openpyxl for the SkillsFuture XLSX, pypdf and python-docx for resume ingestion, and Pydantic for schemas. Dependencies and runs are managed with uv. AI (all OpenAI): Structured Outputs for profile parsing, text-embedding-3-small for semantic matching, and the Responses API for tool-calling orchestration over deterministic backend functions. Model: gpt-5.4-nano. Frontend: Vite, React, and TypeScript, with three.js via react-three-fiber and drei for the 3D career sphere. Data and ingestion: the SkillsFuture Skills Framework dataset, the MyCareersFuture jobs API, the SSG-WSG Courses API, and the data.gov.sg dataset API. Apify keeps the live job listings freshly populated each day (through a Google Cloud scheduled job). Infrastructure (Google Cloud, region asia-southeast1): Docker images built and deployed via Cloud Build, stored in Artifact Registry, with secrets in Secret Manager (MotherDuck token, OpenAI key). The web app runs on Cloud Run (serving API and SPA, reading the baked DuckDB in-process); a separate scheduled job handles the daily jobs refresh into MotherDuck. The deploy pipeline snapshots MotherDuck, bakes it into the image, pushes, and deploys. Tested with pytest.

SkillsFuture Skills Framework (official roles, role descriptions, required skills, and proficiency levels) is the backbone of all role-fit scoring. One auth-free XLSX covering all sectors: https://file.go.gov.sg/jobsandskills-skillsfuture-skills-framework-dataset.xlsx (the portal 403s non-browser user agents, so we send a browser User-Agent.) SkillsFuture Unique Skills List plus the TSC-to-Unique Skills mapping give a canonical skill vocabulary and connect sector-specific framework skills to canonical ones MyCareersFuture jobs API provides live Singapore job postings with structured per-job skills, used for grounded job-fit ranking: POST https://api.mycareersfuture.gov.sg/v2/search (filtered, sliced ingest) GET https://api.mycareersfuture.gov.sg/v2/jobs/{uuid} (per-job detail, fetched lazily) SSG-WSG Courses API (live SkillsFuture course directory) is used to suggest real courses for the user's top skill gap, replacing a stale snapshot: OAuth: https://public-api.ssg-wsg.sg/dp-oauth/oauth/token Search: https://public-api.ssg-wsg.sg/courses/directory (we use the live API where possible; some course-detail links still 404 in practice) Rationale: we deliberately keep every fact (roles, skills, scores, salaries, courses, jobs) sourced from official Singapore government data rather than the model. The LLM only parses input, routes between deterministic tools, and explains computed results in plain English; it never invents roles, skills, proficiency levels, scores, salaries, or courses.

We kept a hard boundary between language work (AI) and factual computation (deterministic code). Our rule is "the data decides; the AI interprets." Delegated to AI (all OpenAI): - Parsing messy resume/profile text into structured skills and evidence, using Structured Outputs so the output is schema-adherent rather than loose JSON. - Semantic matching between user skills, official SkillsFuture skills, and role/job text, using embeddings (text-embedding-3-small). - Tool-call orchestration: the model routes between allowlisted deterministic backend functions via the OpenAI Responses API, choosing which tool to call next. - Explaining an already-computed JSON result in plain English. Human-judged / deterministic code only: - Every fact and number: role-fit scoring, gap ranking, job ranking, course lookup, salary bands, and the evidence rows. The LLM cannot create roles, change skill definitions, invent proficiency requirements, decide fit scores, or invent salaries, courses, or source rows. - The scoring formulas, thresholds, and product/UX decisions, recorded as we made them (including what we rejected and why) in DECISIONS.md. Creatively: because all our matching is similarity in embedding space, we turned that math into the product itself, a 3D career sphere where nearby roles are genuinely closer in vector space, so the visual metaphor lines up with the model rather than being decorative. Effectively: we benchmarked models on a real resume and standardised on gpt-5.4-nano for speed and stability, hardened every LLM call with timeouts and retries, and run a live tool-calling agent in production that composes grounded calls rather than a single black-box prompt. Responsibly: facts always come from official government data, never the model; the app fails fast on a bad parse instead of guessing; and it says plainly when a goal, timeline, or salary expectation is unrealistic instead of pretending everything is equally achievable. In development, we used an AI coding agent (Codex) to implement features under these guardrails, while humans owned the architecture, the data-integrity rule, and every product and scoring decision. We leaned on the agent's workflow features to stay in control rather than hand it the wheel: scoping each change into a goal-driven run (/goal) so the intent was explicit before any code was written, using /loop to iterate and re-run checks on a task, and fanning out parallel subagents to cover broad multi-file work (for example the results-UX and live-course pass) while a human still reviewed and decided. Every decision and the reasoning behind it, including what we rejected, is logged in DECISIONS.md and docs/ai_collab_log.md.

Several project choices were either inspired by or validated by sessions during PyCon SG, but mostly in a practical way: they gave language to problems we were already running into while building. For example, the AI-agent and reliability sessions matched what we were already feeling: agents are useful, but only if they are bounded. That pushed us toward allowlisted tools, deterministic scoring, fallback behaviour, and evidence payloads instead of a freeform career chatbot. Talks like "Merlions, Agents & Copilot: Trustworthy Python on Azure", "This Talk Was Generated by AI. Please Don't Trust It", and Anthony Tung's keynote on using tools without being used by them helped us frame that choice more clearly. The data/API side also became more real once we worked with MyCareersFuture and Apify. External data was useful, but schema changes, blocking, caching, and source preservation mattered more than expected. That made sessions like "Designing Python APIs for Data You Don't Control" feel directly relevant rather than abstract. The testing and evaluation workshops reinforced the same point from another angle. If we were going to claim that the data decides, we needed tests and failure cases around scoring, parser guardrails, and fallback behaviour. "Do you know how well your model is doing? Evaluate your LLMs" was a useful reference for that. The agent-process sessions also validated something more mundane but important: shared instructions matter when multiple humans and agents are touching the same repo. "SKILL.md is the SOP your AI agent never had" lined up with our use of AGENTS.md, DECISIONS.md, and collaboration logs. Those docs were not process theatre; they kept the project moving. Finally, the Python tooling discussions lined up with how we treated Python in this project: not flashy, just reliable. "Adopting uv and pyproject.toml for mono-repo: Challenges and Approach" matched our choice to keep setup reproducible with uv and pyproject.toml. Google Cloud was also a practical fit for hosting and scheduled refreshes. We used Cloud Run and Cloud Scheduler because they were straightforward for this kind of small app plus recurring data job.

A lot of our direction actually came from people, not the model. The clearest example: while we were talking through the project at Rohan's house, his family asked the very ordinary question "but can someone actually do this within their timeline?" That offhand comment ended up shaping the whole product, it's why every recommendation is wrapped around a realistic timeline and why the app pushes back when a goal or timeline is not realistic instead of cheerleading. The most humbling episode was a bug where a clearly senior CV kept getting labelled as a junior, sub-8k candidate. We assumed our new ranking code was at fault and almost rewrote it, but reading the logs first showed the real cause was the profile parser silently timing out on long CVs and falling back to keyword matching. It was a good reminder to look at the evidence before trusting our own assumptions, especially in a time when coding agent jump to conclusions really fast, and we blindly trust them. We also learned to measure instead of guess on infrastructure: our original plan to query the cloud database at runtime turned out to be unusable once we actually timed it (hundreds of milliseconds per lookup across regions), so we pivoted to baking a local snapshot into the image. Credits: built by Rohan and Kieran, who split the work across the matching/UX engine and the live jobs data pipeline. Thanks to the PyCon SG organisers, speakers, sponsors, partners, and the hackathon community, and to everyone who gave us feedback in person and over Telegram. Where possible, we tried to answer as many questions if we could, if they weren't already answered! ( You can see messages sent by @rhnjk in the hackathon telegram chat)

JS/TS/Python and React

We used SkillsFuture Singapore’s public Jobs-Skills datasets because the project needs an official baseline for job roles, skills, proficiency levels, knowledge/ability rows, CASL skills, and emerging skills. Sources: * Skills Framework Dataset: https://jobsandskills.skillsfuture.gov.sg/frameworks/skills-frameworks#download-the-latest-skills-framework-dataset * Unique Skills List: https://jobsandskills.skillsfuture.gov.sg/frameworks/skills-frameworks#download-the-latest-skills-framework-dataset * TSC to Unique Skills Mapping File: https://jobsandskills.skillsfuture.gov.sg/frameworks/skills-frameworks#download-the-latest-skills-framework-dataset

AI was used to brainstorm, build, test, and iterate quickly, but the key product judgment stayed human-led. I used AI for implementation help, UI refinement, scoring logic, proof guardrails, tests, browser QA, deployment, and submission wording. Human judgment decided the final idea, rejected generic career-pathfinder concepts, kept the product focused on “does this course really prepare me for this job?”, and checked that the demo was understandable and not misleading. The app itself uses deterministic scoring against public SkillsFuture data, not hidden AI claims.

Codex!