AI Engineering Skills Beyond ChatGPT: What Building With AI Means for Developers

Summary

AI engineering skills are the abilities that let a developer place a language model inside a working system. That means feeding it real data, constraining its output, validating the result, recording what happened and deciding where a human must stay in control. Using ChatGPT or Gemini well is useful, but it is a different skill. A chat window produces text for one person. An engineered workflow produces dependable outcomes for an organisation.

Ts. Lukas J. Tan, who founded Maple Software Creation in 2007, has described a talent gap he observed through the Penang Digitalisation-AI Conference & Exhibition (PDX) and the AI Future Makers Bootcamp 2026. Businesses are not short of AI applications. They are short of people who can turn those applications into research, prototypes, automation and integrated workflows. This article looks at that gap from the programmer's side: what ‘building with AI’ involves technically, a reference architecture using recruitment as the example, and how technical teams can test for these skills in an interview.

The Problem in Technical Terms: Chat Usage Is Not System Design

From an engineering point of view, a typical chatbot session has four properties that make it unsuitable as a business process on its own.

• Manual input. A person copies and pastes the data. Nothing arrives from the systems where the data actually lives.
• Unstructured output. The response is prose. Another system cannot consume it reliably without parsing and checking.
• No verification. Whether the answer is correct depends on the reader noticing an error.
• No record. There is usually no audit trail linking an input, a model response and the decision taken because of it.

None of this is a criticism of the tools. Chat interfaces are designed for individual productivity, and they serve that purpose well. The difficulty begins when a candidate, or a team, treats familiarity with that interface as evidence that they can deliver AI inside an organisation.

The participant survey from AI Future Makers Bootcamp 2026 showed the pattern. Many students were familiar with ChatGPT and Gemini, while their exposure to other AI development tools and approaches appeared much more limited. Lukas has been clear that this is not a criticism of the students. It reflects how AI education often stops at prompts, presentations and image generation, which should be the start of the journey rather than its end.

For developers, the useful question is concrete: what has to exist around a model before its output can be trusted inside a workflow?

A Reference Architecture for an AI-Assisted Recruitment Workflow

Human resource management is one of the challenge areas in AI Future Makers Bootcamp 2026, so it makes a practical example. HR teams often receive applications from several platforms, spend considerable time reading résumés and must evaluate candidates consistently and fairly. A developer who only knows the chat interface might draft a better job advertisement. A developer with AI engineering skills looks at how the whole pipeline behaves.

A reasonable first design separates the workflow into stages, each with a clear contract:

1. Ingestion. Connectors or scheduled imports collect applications from each source and store the original files unchanged.
2. Normalisation. Documents are converted to text, deduplicated and linked to a single candidate record.
3. Structured extraction. A language model maps each résumé into a defined schema covering education, skills, work history and certifications.
4. Validation. Code, not the model, checks types, required fields and obvious inconsistencies. Failures go to a review queue.
5. Matching support. Extracted fields are compared against a rubric written by the hiring team. The output is a set of evidence notes, not a verdict.
6. Human review. A recruiter sees the original document beside the extracted data and makes the decision.
7. Audit log. Every model call, model version, prompt template, output and human decision is recorded.

The model appears in only two of the seven stages. In practice, much of the engineering effort in an AI workflow goes into the data and controls around the model rather than the model itself.

Implementation Details

Treat the model as an untrusted component

The most useful habit is to handle model output the way you would handle user input from the internet: parse it, validate it and reject what does not conform. The pseudo-code below shows the shape of the extraction step. The llm.complete call is a placeholder for whichever hosted or local model the team chooses.

SCHEMA = {
  "full_name": str,
  "skills": list[str],
  "years_experience": int | None,
  "education": list[{"level": str, "field": str}]
}

def extract_profile(resume_text, template_version):
    raw = llm.complete(prompt=render(template_version, resume_text))
    try:
        data = json.loads(raw)
        validate(data, SCHEMA)
    except (ParseError, ValidationError) as err:
        audit.log("extract_failed", template_version, err)
        return review_queue.add(resume_text, reason=str(err))
    audit.log("extract_ok", template_version, data)
    return data

Two details matter. Failure is an expected path, not an exception to hide. And the prompt template carries a version, so a change in behaviour can be traced back to a change in instructions.

Keep judgement with people

Matching support should produce explanations a recruiter can check, such as ‘lists Python and SQL; two internships in data roles’, with a pointer to where that evidence appears in the document. Automatic rejection based on a model score is a design decision with real consequences for candidates. In our view, a prototype should not make that decision without explicit agreement from the HR owners of the process.

Design for fairness from the data layer

Fairness is partly a data-handling problem. Fields that should not influence screening, such as photographs, age or marital status, can be removed before matching runs, so the model never sees them at that step. The rubric should be written and reviewed by people, and stored as configuration rather than buried inside a prompt.

Security and personal data

Résumés are personal data. Before any document leaves your environment, the team needs to know where the provider processes it, whether it is retained and who can read the logs. Practical controls include least-privilege service accounts, encryption at rest, redaction of contact details before model calls where they are not needed, and a retention policy for both documents and audit records. Obligations under Malaysia's Personal Data Protection Act should be reviewed with whoever is responsible for compliance.

Testing a non-deterministic component

Ordinary unit tests still apply to everything around the model. For the model step itself, build a small evaluation set of anonymised or synthetic résumés with hand-checked expected fields. Run it whenever the prompt template, model version or schema changes, and compare field-level results with the previous run. The aim is not a perfect score. It is to notice when a change makes things worse before recruiters do.

Deployment

Ship behind a feature flag, starting in shadow mode: extraction runs, but recruiters keep working as before and compare the output with their own reading. Only when the review queue is manageable and the evaluation set is stable should results appear on the recruiter's screen. Keep a switch that disables the AI stage entirely and falls back to the manual process.

Pitfalls and Engineering Trade-offs

• Prompt-only solutions. Logic hidden in a long prompt is hard to test and review. Move rules into code and configuration where possible.
• Hosted versus local models. Hosted models reduce operational work. Local models give more control over where data goes. The choice depends on data sensitivity, budget and the team's ability to run infrastructure.
• Real-time versus batch. Recruitment rarely needs instant extraction. Batch jobs are simpler to retry and easier to monitor.
• Over-automation. Every automated stage removes a point where a person might catch an error. Automate repetitive administration first and leave decisions with people.
• Silent model changes. Providers update models. Pin versions where possible and rerun the evaluation set when they change.
• Prototype code in production. A prototype proves the idea. It is not yet the system. Budget time for error handling, logging and access control.

How to Assess AI Engineering Skills in a Technical Interview

Lukas's suggestion to employers is to stop asking whether candidates know AI and start asking what they have built with it. For technical roles, that means a practical demonstration instead of a list of tools. Useful questions include:

• Walk us through a workflow you designed. Where does the data come from, and where does the result go?
• Show a prototype and explain one limitation you have not solved yet.
• How did you check whether an AI-generated result was reliable?
• What went wrong during development, and how did you correct it?
• Which parts would you not automate, and why?

An imperfect prototype is acceptable. What the interviewer is looking for is the reasoning: identifying a problem, researching options, experimenting and turning an idea into something tangible. Communication, ethics, teamwork and an understanding of users still matter. A candidate who can generate impressive code but cannot explain its risks is not automatically a strong hire.

Domain knowledge counts as well. An HR or business student may see a process weakness that a programmer would overlook. Strong teams often pair that understanding with someone who can build the system around it.

FAQ

What are AI engineering skills?

They are the skills needed to integrate a model into a working system: connecting data sources, enforcing structured output, validating results, logging decisions, testing behaviour and keeping people in control where it matters.

Is knowing ChatGPT or Gemini enough to count as AI talent?

No. These tools are useful for personal productivity, but almost everyone can access them, so familiarity alone is a weak differentiator. Employers increasingly look for evidence of what a candidate has built.

How should AI output be validated in a business workflow?

Treat it as untrusted input. Parse it against a schema, route anything that fails to human review, log it with the prompt and model version, and test changes against an evaluation set.

Should AI make hiring decisions automatically?

We recommend against it. Let AI handle repetitive administration such as extraction, and let recruiters make decisions with the original documents in front of them and every step recorded.

Do you need to be a software engineer to build with AI?

Not necessarily. Domain knowledge, a willingness to learn and the discipline to experiment are valuable. Production systems still benefit from engineers who understand security, testing and deployment.

Conclusion

Accessible AI tools have shortened the distance between an idea and an early working prototype. That changes what a developer's value looks like. Knowing the popular chat applications is now common. Knowing how to place a model inside a validated, logged and testable workflow, with people still in control, is far less common, and it is what many organisations are struggling to find.

For developers, the next step is simple: choose a real problem, build a small pipeline around it and be ready to explain every stage. For technical leads, it is to make that kind of evidence part of how you hire.

AI Future Makers Bootcamp 2026 holds its final competition on 7 November 2026, and you can learn more about the initiative at aifm.asia. If your team is planning an AI-assisted workflow and wants an engineering view of its architecture, data handling and testing before you build, you are welcome to read our other Insights or book a Discovery Session with Maple Software Creation.