Introduction to AI and Machine Learning with Python Programming

Course Description

Introduction to AI and Machine Learning with Python Programming introduces students to machine learning and deep learning concepts and algorithms, before progressing to topics in data analysis. Students explore foundational principles of artificial intelligence and machine learning through practical programming applications using Python, developing both theoretical knowledge and implementation skills.

Within the SCNS taxonomy, CAI is the Computing and Artificial Intelligence prefix. Daytona State publishes this at 3 credits, offered fall, with COP1000 as prerequisite. ⚠ The single term of offering is worth planning around.

The most useful thing an introductory machine learning course can leave you with is not an algorithm — it is an accurate mental model of what these systems actually do. A trained model finds statistical patterns in the data it was given and reproduces them. It does not understand anything, it has no access to truth, and it will confidently reproduce whatever regularity exists in the training data, including regularities nobody intended it to learn. Almost every serious failure of a deployed machine learning system follows from someone forgetting that.

Daytona State does not publish a lecture and laboratory split for this course. Its computing and office systems courses are unsuffixed and run at the standard 15 contact hours per credit — CEN4010, CEN3722, CNT2402, OST2401 and CGS1570 are all live at 3 credits and 45 hours. This course is priced at that convention.

Learning Outcomes

Required Outcomes

• Describe artificial intelligence, machine learning, and deep learning and how they relate.
• Describe supervised, unsupervised, and reinforcement learning.
• Use Python and its scientific libraries for data work.
• Load, inspect, and clean a dataset.
• Handle missing, inconsistent, and outlying data appropriately.
• Perform exploratory data analysis and visualise data.
• Engineer and select features.
• Split data into training, validation, and test sets correctly.
• Describe why the test set must remain untouched until the end.
• Train and evaluate a regression model.
• Train and evaluate a classification model.
• Describe decision trees and ensemble methods.
• Describe clustering and apply it to an unlabelled dataset.
• Describe dimensionality reduction.
• Describe neural networks and how they are trained.
• Describe deep learning architectures at an introductory level.
• Select evaluation metrics appropriate to the problem.
• Interpret a confusion matrix, precision, and recall.
• Recognise and diagnose overfitting and underfitting.
• Recognise data leakage and describe how it produces false results.
• Describe cross-validation and hyperparameter tuning.
• Identify bias in data and describe its consequences in a deployed model.
• Describe the ethical and legal issues raised by machine learning systems.
• Communicate a model's results and its limitations honestly.

Optional Outcomes

• Describe natural language processing at an introductory level.
• Describe computer vision at an introductory level.
• Describe large language models and generative systems.
• Describe model deployment and monitoring.
• Describe model drift and retraining.
• Complete an end-to-end machine learning project.

Major Topics

Required Topics

• AI, machine learning, and deep learning
• Supervised, unsupervised, reinforcement learning
• Python for data work
• Loading and inspecting data
• Missing and outlying data
• Exploratory analysis and visualisation
• Feature engineering and selection
• Train, validation, test splits
• Protecting the test set
• Regression
• Classification
• Decision trees and ensembles
• Clustering
• Dimensionality reduction
• Neural networks
• Deep learning architectures
• Choosing metrics
• Confusion matrix, precision, recall
• Overfitting and underfitting
• Data leakage
• Cross-validation and tuning
• Bias in data and in deployment
• Ethics and law
• Honest communication of results

Optional Topics

• Natural language processing
• Computer vision
• Large language models
• Deployment and monitoring
• Model drift and retraining
• End-to-end project

Resources & Tools

• Build things and keep them. In computing the portfolio is the qualification — a public repository of working projects with readable code and a clear README does more for employment than a transcript.
• Git and a public repository host — free; version control is expected of every candidate, and using it from your first course is the cheapest habit to acquire.
• Free-tier cloud accounts (AWS, Azure, Google Cloud, Oracle) — real infrastructure to practise on at no cost; set a billing alert before you start.
• Virtualisation and containers — VirtualBox and Docker are free, and a broken lab you can rebuild in a minute is what makes experimentation cheap.
• Official documentation — language, database, and framework docs are authoritative and version-correct in a way that copied answers are not. Learning to read documentation is the skill that separates practitioners.
• Vendor certifications — Microsoft, AWS, Oracle, CompTIA and Cisco credentials are named by employers in job advertisements; many have free training paths and student pricing.
• Your instructors and the lab — supervised time on real systems is the part you cannot get from a video.
• Internships and co-op placements — the strongest single predictor of employment at graduation. Start looking a year before you think you should.
• scikit-learn, pandas, NumPy and Matplotlib documentation — free; the scikit-learn user guide is unusually good and is a genuine textbook.
• Kaggle (kaggle.com) — free datasets, notebooks, and competitions; the fastest way to get practice on data you did not construct yourself.
• Google Colab — free hosted notebooks with GPU access; removes the hardware barrier entirely.
• NIST AI Risk Management Framework (nist.gov) — free; the emerging reference for evaluating and governing these systems responsibly.

Career Pathways

• Software developer — SOC 15-1252.
• Computer systems analyst — SOC 15-1211; the requirements-and-design role.
• Database administrator and architect — SOC 15-1242 and 15-1243.
• Data analyst, business intelligence developer, and data engineer — strong demand and a common entry route for people who like data more than application code.
• Network architect — SOC 15-1241; and network and systems administrator, SOC 15-1244.
• Information security analyst — SOC 15-1212; strong growth, and systems or database work is the usual route in.
• Data scientist and machine learning practitioner — SOC 15-2051.
• Systems integration and enterprise applications — frequently overlooked by students and consistently well paid.
• Florida's defence, space, and simulation sector, plus healthcare, hospitality, financial services and a large public sector — ⚠ many defence roles require U.S. citizenship and some a security clearance.
• Managed service providers and consultancies — broad exposure quickly, and a common early career step.
• Continue to a bachelor's or graduate degree — Daytona State's computing bachelor's programmes are the direct route.

Special Information

⚠⚠ The model learns the data, including the parts you did not want it to

• A model reproduces the patterns in its training data. If the data reflects a historical bias, the model reproduces that bias and launders it through the appearance of objectivity — which makes it harder to challenge than the human decision it replaced.
• ⚠⚠ This is not hypothetical. Deployed systems in hiring, lending, criminal justice and healthcare have been shown to produce systematically worse outcomes for particular groups, and in several cases the model was doing exactly what it was trained to do.
• Removing the protected attribute does not remove the bias. Other fields correlate with it — postcode, school, purchase history — and the model will find them.
• ⚠ Models find shortcuts, not explanations. The instructive example: a medical imaging model that appeared to detect disease and had actually learned to recognise which hospital's scanner produced the image, because the sicker patients were scanned at a particular site. It scored beautifully and was useless.
• Ask what the data represents before you model it — who is in it, who is missing, how it was collected, and what the label actually measures. A label that records who was arrested is not a record of who committed a crime.
• Evaluate performance across subgroups, not only in aggregate. A model with good overall accuracy can perform badly for a minority group, and the aggregate figure conceals it.
• Be careful with proxies for outcomes you cannot measure. Optimising a measurable proxy for the thing you actually care about is where a great many systems go wrong.
• ⚠ Say what the model cannot do when you present it. Overstating a model's reliability is the failure mode with the largest real-world consequences.

⚠⚠ If your accuracy looks wonderful, suspect leakage before celebrating

• Data leakage is information from outside the training set finding its way in, and it produces results that look excellent and collapse in production.
• ⚠ The classic causes: scaling or imputing using statistics computed over the whole dataset before splitting; including a feature that is only known after the outcome; and tuning repeatedly against the test set until it stops being a test set.
• Split first, then do everything else. Every transformation should be fitted on the training data and merely applied to the rest.
• Hold the test set back and look at it once. If you have used it to choose anything, it has become a validation set and you no longer have an honest estimate.
• ⚠⚠ Accuracy is the wrong metric on imbalanced data. A model predicting a condition with 1% prevalence achieves 99% accuracy by always answering "no" — and it is worthless. Use precision, recall, and the confusion matrix.
• Decide which error matters more. A false negative and a false positive have different costs in almost every real application, and choosing the threshold is a domain decision rather than a technical one.
• Respect time order in time-series data. A random split lets the model see the future, which is a particularly convincing form of leakage.
• Establish a trivial baseline first. If a simple rule does nearly as well, the complicated model is not earning its keep.
• ⚠ Be sceptical of your own good results. In this field the surprisingly good number is usually a bug.

⚠⚠ Generative AI — use it well, and know what it is doing

• A large language model predicts plausible text. It is not consulting a database of facts, and it produces confident, fluent, well-formatted output that is sometimes simply wrong — including invented citations, invented functions, and invented statistics.
• ⚠ Verify anything you will rely on. Run the code, check the citation, test the claim. Fluency is not evidence.
• ⚠⚠ Do not paste confidential, personal, or client data into a third-party service. You may be disclosing it, and in regulated sectors that is a reportable breach — this is now one of the most common ways employees create incidents.
• Know your institution's and employer's policy before using these tools on coursework or work product, and be aware that academic integrity rules apply.
• Understand what it is good for. Drafting, explaining unfamiliar code, generating test cases, and rubber-ducking are genuine productivity gains; using it to produce code you cannot read is how unmaintainable systems get built.
• Take responsibility for the output. "The model wrote it" is not a defence for a defect, a licence violation, or a false statement.
• ⚠ Training-data provenance and copyright are actively contested, and the legal position on scraped training data is unsettled.
• ⚠ Rule 11 applies emphatically. This is the fastest-moving area in this repository — capabilities, tooling, law and institutional policy are all changing; verify current position rather than relying on any guide.

⚠⚠ Real data carries real obligations — and students meet this first in a database course

• The moment a system holds data about people, it is subject to law and to duties that have nothing to do with whether the code works.
• ⚠⚠ Never copy production data into a development or test environment casually. It is one of the commonest sources of real breaches, it is frequently prohibited by policy, and a development database is almost never secured to the standard the production one is. Use synthetic or properly de-identified data.
• De-identification is harder than removing names. Combinations of ordinary fields — date of birth, postcode, sex — re-identify people surprisingly often.
• Collect only what you need and keep it only as long as you need it. Data you do not hold cannot be breached, and retention is a policy decision with legal consequences.
• ⚠ Access only what your task requires. Broad database access is normal for a developer and querying a colleague's or a public figure's record is still a dismissible act — audit logs attribute it to your account.
• Encrypt sensitive data in transit and at rest, and never store passwords recoverably — they are hashed with a purpose-built algorithm, never encrypted and never plain.
• ⚠ Sector rules stack on top: health data under HIPAA, student records under FERPA, card data under PCI DSS, and Florida's Digital Bill of Rights for businesses meeting its thresholds.
• Report a suspected breach immediately. Notification obligations carry deadlines, and concealment turns a manageable incident into a serious one.
• ⚠ Rule 11 applies — privacy law is moving quickly at state level; verify current requirements.

⚠⚠ Authorisation is the line between a computing professional and a defendant

• Never access, scan, modify, or extract data from a system you do not have permission to touch. The technical knowledge these courses give you is exactly what makes unauthorised access easy, which is why the rule matters more in this field than in most.
• Federal exposure: the Computer Fraud and Abuse Act criminalises unauthorised access to a protected computer, and "exceeding authorised access" has been read broadly.
• ⚠⚠ Florida exposure is separate and additional: the Florida Computer Crimes Act, Chapter 815, Florida Statutes, makes offences against computer users, systems and data punishable under state law independently of federal law.
• Having credentials is not the same as having authorisation. Being technically able to query a table or read a record does not mean you may, and systems log that you did.
• Use the lab and build your own. A local database, a virtual machine, or a personal cloud account costs little or nothing and lets you practise lawfully anything that would be unlawful elsewhere.
• Get scope in writing before any authorised testing or administrative engagement.
• ⚠ Rule 11 applies — computer crime and privacy law changes; verify rather than relying on a course guide.

How Florida course levels affect transfer

The first digit of an SCNS number denotes the year of offering, not transferability. Courses at the 1000 and 2000 levels transfer transparently between Florida public institutions, and 3000 to 4000 is unproblematic since both are upper division. The boundary that actually matters is 2000 to 3000, where lower-division credit generally cannot satisfy an upper-division requirement — and it is live here, since Daytona State offers both associate-level and bachelor of science coursework in these prefixes.

CAI2010 is 3 credits and approximately 45 contact hours, offered fall only at Daytona State, with COP1000 as prerequisite.

Build an end-to-end project and publish it — loading through cleaning, modelling, evaluation and an honest write-up of limitations. It is worth more to an employer than a grade.