Skip to main content
Need help?
Ask in DiscordOpen a GitHub issueSupport guide
Specialization ID: PT01 · Professional · Internship (real-project engagement) The AI-Native Internship is a technical specialization that connects learning with evidence of software delivery. Participants develop a modern full-stack application, contribute through a public engineering review process, and prepare for supervised work in an existing client or internal project. This is a separate pathway from the six-class GW02 · Professional AI Agent Course. The internship has three phases; its 4–6 private coaching sessions make up Phase 1, not the entire program. The number of sessions depends on the student’s existing skill proficiency.

​
Program at a glance

Phase 1 includes 4–6 two-hour coaching sessions, with the number and pacing agreed after reviewing the student’s existing skills. Sessions can run weekly, with implementation work between meetings. Phase 2 begins once the core development workflow is stable. Phase 3 follows a readiness review and project matching. The duration of Phases 2 and 3 depends on the selected issue or project, not a fixed classroom calendar.
Project access and placement are not automatic. Assignment depends on demonstrated readiness, available backlog, project fit, and confidentiality constraints. Pull-request merge remains subject to the repository’s review standards.

​
Who this pathway is for

The technical track is intended for learners with programming foundations and some application-building experience who want to strengthen production-oriented engineering skills. Coaching starts with a private review of prior work, learning objectives, and gaps in demonstrated capability. The content areas below define what the coaching covers, not a fixed session-by-session syllabus. Their depth and emphasis are adapted to each participant rather than requiring repetition of skills already demonstrated. Personal assessments, resumes, grades, and contact details stay outside the public handbook. Throughout the pathway, AI-assisted or “vibe” coding operates inside an engineering workflow: clarify requirements, plan a small change, implement, test, review, and explain the result. Participants remain responsible for correctness, source verification, security, and communication.

​
Phase 1 · Personalized technical coaching

Phase 1 provides 4–6 one-to-one coaching sessions, depending on the student’s existing skill proficiency, built around a single application. The content areas below can be combined, reordered, or revisited across sessions; each topic does not correspond to a particular session. Coaching builds on existing strengths, focuses on capability gaps, and uses work between meetings to produce reviewable evidence.

​
AI-native engineering workflow and app skeleton

  • Builds on: Programming, version control, and previous project experience.
  • New layer: Requirements-to-review workflow, disciplined AI-assisted coding, TypeScript conventions, a React-based full-stack app structure, branch and commit hygiene, and architecture notes.
  • Evidence: A working application skeleton with a reproducible development setup, task plan, README, and architecture map.

​
React and TypeScript frontend engineering

  • Builds on: JavaScript, HTML/CSS, and any existing frontend experience.
  • New layer: Typed props and state, reusable components, hooks, forms and validation, routing, loading and error states, client/server boundaries, and accessibility.
  • Evidence: A working, typed frontend flow with reusable components, ready to connect to real APIs.

​
RESTful APIs and backend contracts

  • Builds on: Application logic, backend endpoints, and separation of concerns.
  • New layer: HTTP semantics, resource modeling, request/response validation, consistent errors, service and repository boundaries, asynchronous flows, integration tests, and API documentation.
  • Evidence: A documented API with validated endpoints and tests connecting frontend actions to backend behavior.

​
PostgreSQL, ORM, and secure authentication

  • Builds on: SQL, data modeling, and basic user-account concepts.
  • New layer: PostgreSQL migrations, ORM-backed data access, relations and transactions, OAuth/OIDC concepts, sessions and tokens, protected routes, and role-based access.
  • Evidence: A secure end-to-end feature with sign-in, protected routes, persistent data, migrations, and an ORM-backed domain model.

​
Deployment, testing, and production readiness

  • Builds on: Git-based delivery, debugging, and testing experience.
  • New layer: Environment and secrets management, cloud deployment, CI checks, unit and integration tests, logging, error monitoring, performance and security basics, and release checklists.
  • Evidence: A deployed application with documented setup, automated checks, test results, and production-readiness notes.

​
Agent SDK and LLM feature integration

  • Builds on: Programming and data-processing experience; prior machine-learning work can help but is not assumed.
  • New layer: LLM application architecture, prompts as software inputs, structured outputs, tool/function calling, agent loops, SDK integration, evaluation, failure handling, cost and latency awareness, and safe fallbacks.
  • Evidence: One working agent-powered feature in the application, plus an evaluation note covering behavior, limitations, tests, and next improvements.

​
Phase 2 · Formal GitHub open-source contribution

Move from a coached practice repository into the Prompthon Agent Systems Handbook repository. The goal is to complete a real issue-to-review cycle and produce public evidence of engineering judgment and collaboration.

​
Contribution workflow

  1. Select a scoped issue that fits the repository backlog and the participant’s learning objectives.
  2. Read the contribution workflow, relevant repository instructions, and existing architecture or content.
  3. Create a branch and implement a focused, reviewable change.
  4. Verify AI-assisted work against source material and actual code behavior; run the relevant checks.
  5. Open a pull request with the problem, change summary, tests or other evidence, and screenshots when useful.
  6. Respond to maintainer review, revise the work, and record the outcome, whether merged or concluded with documented feedback.

​
Example contribution scopes

  • Code and examples: Agent workflows, integration snippets, small utilities, or test improvements.
  • Technical documentation: MDX explanations, reading paths, setup guides, and architecture diagrams backed by sources.
  • Repository quality: Issue reproduction, test baselines, documentation-drift checks, or contribution tooling.
  • Developer experience: Documentation-site navigation, content structure, and runnable code samples.
Target evidence: At least one substantive public pull request with review history. A merged contribution is the preferred outcome when it meets maintainer standards, not a guaranteed result of participation.

​
Phase 3 · Supervised real-project engagement

After readiness review and matching, take on a bounded task in an existing client or internal repository. This phase introduces real requirements, established architecture, review standards, delivery constraints, and team communication.

​
Example project workstreams

The following categories describe possible work, not a list of confirmed openings:
  • AI-native applications and internal tools: Full-stack features, API/data/auth integration, and agent-powered user workflows.
  • Product modernization: Incremental improvements to existing software, interfaces, integrations, and delivery practices.
  • Data and intelligent workflows: Data modeling, analytics interfaces, API connections, automation, evaluation, and reliability.
  • Product localization and market readiness: Adapt interface behavior, content, and technical integrations to the intended users and operating context.
  • Learning and community infrastructure: Open-source tools, technical documentation, community-product features, and operational automation.
Specific projects and access are confirmed during matching. Private client scope is not inferred from public websites, and confidential code, credentials, architecture, or requirements are shared only after assignment and authorization.

​
Delivery expectations

Read the repository and explain its architecture and data flow before changing code. Clarify the request, agree on a bounded implementation plan, and follow the project’s existing conventions. Deliver the feature or fix with tests, documentation, a reviewable pull request, and evidence from the project’s checks. Communicate progress, blockers, trade-offs, and next steps at the team’s agreed cadence. Use AI tools within the project’s confidentiality and access rules, and retain traceability from the request to implementation and verification.

​
Readiness review before project assignment

Participants should be able to:
  • Explain the Phase 1 application’s architecture and trade-offs in their own words.
  • Diagnose and fix a non-trivial bug with logs or tests, and explain the root cause.
  • Prepare a focused, documented, testable pull request and respond constructively to review.
  • Change authentication or data handling without exposing secrets or bypassing access controls.
  • Independently check AI-generated code, behavior, and source material.
  • Communicate blockers early and agree on realistic next steps.
Meeting these criteria supports project matching; it does not remove backlog, access, or confidentiality requirements.

​
Expected outcomes and portfolio evidence

The pathway emphasizes demonstrated capability rather than attendance alone:
  • Build: A TypeScript/React application with APIs, PostgreSQL/ORM, and secure authentication.
  • Ship: A deployed environment with setup instructions, tests, automated checks, and operational notes.
  • Integrate AI: An agent/LLM feature with evaluation evidence and documented failure handling.
  • Contribute: A public issue, pull request, and review record that accurately describes the contribution’s status.
  • Work in an existing system: A scoped project delivery and review record when assignment is available and authorized.
  • Communicate: Clear architecture/API notes, progress updates, demonstrations, and explanations of trade-offs.
Public portfolios must omit private assessment details, client data, secrets, and unapproved project material. Describe only work actually completed and evidence that may be shared.