From DevOps to AIOps: CI/CD, Observability, Autoscaling, and AI Model Operations

A pager goes off at 2 a.m. Five hundred alerts say the same outage in five hundred dialects. A human is supposed to be the correlation engine. That is the old DevOps night shift. AIOps is the bet that a model can do the first pass: group the noise, name the likely cause, and sometimes fix it before a human opens a laptop (Gartner, 2025; TechTarget, 2024).

DevOps and AIOps are not rivals. DevOps is how you build and ship. AIOps is how you keep a noisy, multi-cloud estate from drowning the people who ship. One is a culture plus a pipeline. The other is event intelligence on top of telemetry. Teams that skip DevOps and buy an "AIOps platform" get a dashboard on a mess. Teams that stop at DevOps get fast deploys and a pager that never sleeps (Kim et al., 2016; Forsgren et al., 2018).

This post is a long walk through both: what they are, who does what, the tools and cloud services that actually matter now, CI/CD, monitoring and observability, visualization, autoscaling, training and deploying AI models, and the concrete path from a DevOps team to an AIOps practice. It also draws a hard line around MLOps. Training a model is not the same job as using a model to run operations.

Key Abbreviations in This Post

• DevOps: Shared ownership of build, test, release, and run. Culture first, toolchain second.
• AIOps (Artificial Intelligence for IT Operations): Machine learning on events and telemetry to cut noise, find cause, and trigger action. Gartner now files much of this as Event Intelligence Solutions.
• MLOps: The DevOps-shaped practice for training, registering, deploying, and watching machine learning models. Related, not a synonym.
• CI/CD (Continuous Integration / Continuous Delivery or Deployment): Every commit is tested. Every good build can go to production, often through GitOps.
• IaC (Infrastructure as Code): Terraform, Pulumi, Bicep, CloudFormation. The cluster is a file in Git.
• SRE (Site Reliability Engineering): Google's reliability craft: SLIs, SLOs, error budgets, toil reduction.
• OTel (OpenTelemetry): The open standard for metrics, logs, traces, and now more signals. The pipe almost everyone should use.
• MELT: Metrics, Events, Logs, Traces. The raw food of observability and AIOps.
• MTTR (Mean Time to Restore / Repair): How long you stay broken. AIOps is sold on shrinking this.
• HPA / VPA / KEDA: Kubernetes scalers. CPU/memory, vertical size, and event-driven (queues, custom metrics).
• GitOps: Desired state lives in Git. Argo CD or Flux makes the cluster match.
• SLO / SLI: Service level objective and indicator. The contract, not the raw CPU graph.

The One-Minute Version

• DevOps: make change cheap and safe. CI/CD, IaC, containers, shared on-call.
• AIOps: make operations cheap and safe at alert volume humans cannot read. Correlate, predict, remediate.
• They meet on telemetry: if OpenTelemetry is missing, neither story works.
• CI/CD that matters now: GitHub Actions or GitLab CI for build, Argo CD or Flux for deploy, plus a real security scan in the pipe.
• Observe, then visualize: Prometheus + Grafana (or a vendor suite) on an OTel collector. Dashboards are not the product. Questions are.
• Scale on the signal that hurts: HPA for CPU, KEDA for queues, Karpenter or a cloud node pool for GPUs.
• Models have two lives: you train and serve them (MLOps). You also use models to run the shop (AIOps). Do not mix the labels.
• The shift: instrument, one pipe, correlate, suggest, then auto-fix with a human brake.

What DevOps Actually Is

DevOps is not a job title that magically appears when you install Jenkins. It is a working agreement: the people who write the service also ship it and feel the production pain (Kim et al., 2016). The Phoenix Project and the later DevOps Handbook gave the industry a story. Accelerate gave it numbers: elite teams deploy more often, recover faster, and have lower change-fail rates when they combine automation with generative culture (Forsgren et al., 2018).

The technical skeleton is familiar in 2026:

• Version control as the source of truth (Git).
• CI on every change: unit tests, lint, SAST, image build, SBOM.
• CD through environments: staging, canary or blue/green, production.
• IaC so a region can be rebuilt from a repo.
• Containers and Kubernetes (or a serverless stand-in) so "it works on my machine" dies.
• You build it, you run it, with SRE-style SLOs if the org is large enough (Beyer et al., 2016).

Platform engineering is the current refinement. Instead of every squad inventing a pipeline, a platform team offers a paved road: a golden path template, a shared cluster, a catalog. DevOps did not end. It got a product manager (CNCF, 2024).

Problem: developers throw a build over the wall. Ops refuses Friday deploys.
Cause: incentives are split. Dev is scored on features. Ops is scored on uptime.
Effect: tickets, war rooms, and a six-month release train. DevOps collapses the wall. The same team owns the pipeline and the pager.

DevOps tasks and responsibilities

A working DevOps or platform squad typically owns:

• Pipeline design: what runs on pull request, what is required to merge, what promotes a build.
• Environment truth: Terraform/Pulumi modules, secrets via Vault or a cloud secret store plus External Secrets.
• Release mechanics: GitOps apps, rollout strategy, feature flags (LaunchDarkly, Unleash, Flagsmith, or cloud equivalents).
• Runtime: Kubernetes, service mesh or Gateway API, ingress, certificates, network policy.
• Quality gates: tests, image scan (Trivy, Grype), policy-as-code (OPA, Kyverno).
• Basic observability: emit metrics and logs, a default Grafana folder, an on-call rotation, a runbook.
• Cost and capacity: requests/limits, reserved instances, a first-pass FinOps tag.
• Security in the path: identity (IRSA, Workload Identity), least privilege, signed images (cosign).

What they are not automatically: the team that trains foundation models, the SOC, or the people who invent a correlation algorithm. Those sit next door.

What AIOps Actually Is

Gartner coined AIOps years ago. By 2025 they were telling buyers to look past the slogan and buy Event Intelligence: ingest alerts from many tools, correlate and enrich them, find patterns, and drive remediation (Gartner, 2025). That is the useful definition. A product that only draws a prettier graph is observability. A product that turns 400 duplicate CPU alarms and a trace spike into one incident with a suggested rollback is AIOps.

The loop is:

1. Ingest metrics, logs, traces, events, tickets, topology, change records.
2. Normalize so a CloudWatch alarm and a Prometheus alert can share a language.
3. Correlate by time, service, and dependency map.
4. Enrich with owner, SLO, recent deploy, customer impact.
5. Decide with rules plus models: suppress, page, or act.
6. Act by opening a ticket, paging the right squad, restarting a pod, or rolling back via GitOps.
7. Learn from the human who said "wrong root cause" so the next cluster is better.

Vendors in this neighborhood include Dynatrace, Datadog, Splunk, New Relic, BigPanda, Moogsoft-class tools, ServiceNow Event Management, Elastic, and the AI add-ons now bolted onto every observability suite (Network World, 2025). Open source stacks do a thinner version: Alertmanager inhibit rules, Grafana IRM, and homegrown correlation. The science is the same. The difference is how much topology and history you feed the model.

Problem: a Kubernetes node dies. Every pod on it pages a different team.
Cause: each monitor is local. None of them knows the shared cause.
Effect: six bridges and one still-broken node. AIOps should emit one incident: "node X, drain and replace, these five services degraded, last change was a Karpenter template at 01:12."

AIOps tasks and responsibilities

• Signal hygiene: kill duplicate monitors before you train anything. Garbage in, confident garbage out.
• Topology: keep a living map of services, queues, databases, and third-party APIs.
• Baselines: what "normal" looks like per weekday, per region, per release.
• Incident object: one ticket, many raw events. Link to the deploy SHA.
• Runbook automation: restart, scale, fail over, roll back, with an approval step until trust is earned.
• Feedback: operators mark true/false so models do not freeze in 2024's traffic shape.
• Guardrails: an AI that can restart prod without a recorded reason is an outage generator.

How They Differ, and How They Fit

Apples and oranges, as the usual explainer says, and still the same fruit bowl (TechTarget, 2024). DevOps shrinks the cost of a change. AIOps shrinks the cost of a signal. You need both once the estate is larger than one team can hold in their head.

CI/CD: What Matters Now

The CI/CD market is no longer "Jenkins versus the world." Jenkins still runs in banks that will not move. Greenfield teams in 2026 usually pick:

• GitHub Actions: closest to the repo most people already use. Matrix builds, OIDC to cloud, a huge action ecosystem. Watch minute cost and reusable workflows so every squad does not fork a broken YAML.
• GitLab CI: pipeline and repo and registry and security in one product. Strong if you want fewer vendors.
• Azure DevOps: still the default in Microsoft-heavy enterprises, Boards plus Pipelines plus Artifacts.
• CircleCI, Buildkite, Tekton: when you want dedicated runners, or Kubernetes-native pipelines as CRDs.
• Jenkins / Jenkins X: keep it if the plugin city is already paid for. Do not start there without a reason.

CI is the easy half. CD is where teams stall. The pattern that won is GitOps:

• Argo CD or Flux watches Git and reconciles the cluster.
• Argo Rollouts or Flagger does canary and blue/green, often gated on an SLO or a Grafana alert.
• Helm or Kustomize packages the app. Helm is the common language. Kustomize is the overlay.

A modern pipeline is not "build then kubectl apply." It is:

1. Test and scan on the pull request.
2. Build a signed OCI image and an SBOM.
3. Push to a registry (ECR, ACR, GAR, Harbor, GHCR).
4. Open a Git commit that bumps the tag in the env repo.
5. GitOps syncs. Rollout watches error rate. Fail and the canary dies.
6. Change event is written so AIOps can later say "this incident started six minutes after that SHA."

That last line is the DevOps-to-AIOps joint. If deploys are invisible, your correlation engine has no cause except "the moon."

CI/CD and automation tools, grouped by job

• Build: GitHub Actions, GitLab CI, Azure Pipelines, CircleCI, Buildkite, Tekton, Jenkins.
• Deliver: Argo CD, Flux, Spinnaker (legacy), Octopus, cloud-native CodePipeline / Cloud Deploy / DevOps release.
• Progressive delivery: Argo Rollouts, Flagger, LaunchDarkly-style flags.
• IaC: Terraform, OpenTofu, Pulumi, Bicep, CloudFormation, Crossplane if you want Kubernetes as the control plane.
• Config / desired state: Ansible (still fine for metal and VMs), Helm, Kustomize.
• Policy: OPA/Gatekeeper, Kyverno, HashiCorp Sentinel.
• Secrets: Vault, cloud secret managers, SOPS, External Secrets Operator.
• AI-in-the-pipeline: copilot review, test generation, flaky-test clustering. Useful. Not AIOps. Do not rename your Actions file and call the program done.

Monitoring, Observability, and Visualization

Monitoring asks "is it up?" Observability asks "why is it weird?" You need both. A green dashboard with no traces is a lie factory. A trace lake with no SLO is a hobby (Google SRE, 2016; Gartner, 2026).

The contract that matters now is OpenTelemetry. Instrument once. Export to whoever you pay this year. Gartner's observability definition now includes applications, infrastructure, and AI agents, with native OTel support as a must (Gartner, 2026). If your vendor still wants a proprietary agent as the only path, price the lock-in out loud.

The signals

• Metrics: cheap, numeric, good for SLOs and HPA. Prometheus, VictoriaMetrics, Mimir, cloud-native CloudWatch / Azure Monitor / Cloud Monitoring.
• Logs: expensive, high cardinality, still where the exception lives. Loki, Elasticsearch/OpenSearch, cloud log sinks.
• Traces: the request's path across 14 microservices. Tempo, Jaeger, Zipkin, vendor APM.
• Events / changes: deploys, scaling, feature flags, node death. The forgotten fourth signal. AIOps starves without it.
• Profiles and GPU telemetry: continuous profiling, DCGM for NVIDIA. Required once you serve models.

The open stack versus the paid suite

Open, common, and good enough for many teams: OpenTelemetry Collector, Prometheus, Grafana, Loki, Tempo (the LGTM stack), Alertmanager, maybe Grafana IRM. Add OpenCost or Kubecost for money. This is the default I would start on a greenfield cluster.

Paid suites that collapse the last mile: Datadog, Dynatrace, New Relic, Splunk Observability, Elastic Observability, Azure Monitor + App Insights, AWS X-Ray + CloudWatch, Google Cloud Operations. You pay to skip glue work and to get a stronger service map. Several of them now sell the AIOps layer as an add-on: anomaly detection, watchdogs, Davis, Watchdog, whatever the brand is this quarter (Network World, 2025).

Visualization that is not wallpaper

Grafana is the lingua franca. A useful board is built around a question:

• Are we burning the SLO?
• What changed in the last deploy?
• Which dependency is slow?
• Are we about to scale, or already late?
• For a model service: queue depth, TTFT, tokens per second, GPU memory, KV-cache hit rate.

Pretty red/green tiles with no unit and no owner are how on-call goes blind. One service, one SLO row, one drill-down to traces. Then let AIOps use the same queries as features, not a second copy of the truth.

Autoscaling and Scalability

Scaling is where DevOps automation and AIOps prediction shake hands. Classic DevOps writes an HPA: if CPU is above 70 percent, add pods. That is a thermostat. AIOps-shaped scaling asks a better question: will the queue explode in twelve minutes, and do we need a GPU node, not just another replica?

• Kubernetes HPA: CPU, memory, or custom metrics. Still the first tool. Fine for stateless HTTP.
• VPA: right-size the pod. Dangerous if you let it evict blindly. Use as a recommender first.
• KEDA: scale on Kafka lag, SQS depth, Prometheus queries, cron, or "requests waiting" on a model server. CNCF graduated. This is the workhorse for event-driven and inference queues (AWS, 2024).
• Cluster / node autoscaling: Cluster Autoscaler, Karpenter on AWS, GKE node auto-provisioning, AKS node pools. This is how GPUs appear when a training job or a vLLM replica asks.
• Cloud VM scale groups: ASG, VMSS, MIGs. Still real for the non-Kubernetes half of the company.
• Serverless: Lambda, Cloud Functions, Azure Functions, Cloud Run. The platform scales. You still observe cold starts and concurrency caps.
• Predictive / schedule-based: known peaks (9 a.m. login storm) should be a cron, not a surprise. Predictive AWS/Azure policies help. A model that scales on last month's Black Friday without a dry run will scale the wrong region.

Problem: a flash sale hits. HPA waits for CPU. CPU is fine because the app is blocked on checkout queue.
Cause: you scaled on the wrong signal.
Effect: latency dies, replicas stay at two. KEDA on queue depth, plus a load-test in CI, is the DevOps fix. Predicting the sale from marketing calendar plus last year's curve is the AIOps upgrade. Do the first before you buy the second.

Cloud Services: The Same Jobs, Three Catalogs

Pick a cloud for data gravity and people, not for a logo on a slide. The jobs stay the same.

Multi-cloud as a religion is expensive. Multi-cloud as "we can leave" is a Terraform module and OTel. AIOps products that only understand one vendor's events will lie about the other 40 percent of your estate. That is a buying criterion, not a footnote.

Deploying and Training AI Models (MLOps, Not a Rebrand)

Hidden Technical Debt in Machine Learning Systems is still the paper to hand a VP who thinks a Jupyter notebook is a product (Sculley et al., 2015). Models rot. Data shifts. A 2 percent accuracy drop can be a silent outage because no HTTP code turns red.

The path that matches a DevOps shop:

1. Data: versioned datasets, not a shared drive. DVC, a lakehouse table, or the cloud feature store (SageMaker Feature Store, Vertex Feature Store, Feast).
2. Train: a job, not a laptop. Kubeflow Training, SageMaker Training, Vertex Custom Jobs, Azure ML jobs, or Argo Workflows on a GPU pool.
3. Evaluate: holdout metrics plus, for LLMs, an eval harness (lm-eval, RAGAS-style checks, a golden prompt set). Gate the promote step on those numbers, the way you gate a canary on error rate.
4. Register: MLflow Model Registry, or the cloud registry. Name, version, lineage, who approved.
5. Package: a container, or a model URI that KServe / SageMaker / Vertex can pull. Sign it.
6. Serve: KServe for classic ML, vLLM or TensorRT-LLM for large language models, or a managed endpoint (SageMaker, Azure ML online, Vertex prediction, Bedrock/Azure OpenAI if you are calling a hosted API).
7. Observe the model: not only pod CPU. Drift, token latency, quality scores, GPU memory, queue depth. This telemetry is what AIOps later correlates with "checkout conversion fell."
8. Retrain or rollback: a GitOps tag back to the last good model is a first-class incident action.

Inference in 2026 has its own DevOps dialect: NVIDIA GPU Operator, MIG or time-slicing, KV-cache-aware routing, scale-to-zero for overnight dev models, KEDA on num_requests_waiting. That is still DevOps. The AIOps layer is "this model's p95 TTFT just left the SLO and it started six minutes after we shipped tokenizer X."

Automation: Scripts, GitOps, Then Closed Loops

Automation is a ladder. Climb it in order.

1. Manual with a checklist. You cannot automate a process you cannot name.
2. Scripted. Bash, Python, Ansible. Fine for a fleets of VMs. Still the glue.
3. Pipeline. CI/CD runs the script the same way every time.
4. Reconcile. GitOps and controllers. Drift is an error, not a lifestyle.
5. Policy. The cluster refuses a privileged pod. Humans stop being the linter.
6. Suggested action. AIOps says "roll back SHA abc, 80 percent confidence." A human clicks.
7. Closed loop. The same action runs inside a blast-radius box: only this namespace, only this runbook, only if the SLO is already burning.

Most companies that "bought AIOps" are stuck on step 2 with a nicer UI. The ones that get value already had steps 3 to 5. That is the entire thesis of this post in one ladder.

How a DevOps Team Becomes an AIOps Practice

You do not hire a prophet and a new logo. You grow the data and the trust.

1. Instrument everything that pages you. OTel SDK or auto-instrumentation on the top 20 services. No orphans.
2. One collector, one schema. Resource attributes: service.name, deployment.environment, version, team. This is how later clustering works.
3. Emit change events. Every Argo sync, every flag flip, every Terraform apply. Put them next to metrics.
4. Build a service map you would bet money on. Even a simple ownership YAML plus generated topology beats folklore.
5. Reduce monitors. Delete the ones nobody has acted on in 90 days. AIOps on junk is expensive junk.
6. Correlate before you predict. Dedup and grouping pay back in week one. Prediction is year two.
7. Suggest, then automate one runbook. Restart a known-stuck worker. Scale a known queue. Rollback a canary. Measure how often the human overrides.
8. Feed overrides back. If operators always reject a class of alerts, the model should learn or the monitor should die.
9. Put AI actions behind the same GitOps door. An auto-fix that kubectl-edits prod and leaves no commit is a ghost. Write the revert as a PR or a recorded sync.
10. Keep people. AIOps removes toil, not accountability. The on-call still owns the SLO. The model is a junior that never sleeps and sometimes hallucinates a root cause.

Problem: leadership bought a platform after a terrible quarter of incidents.
Cause: they wanted a brain. They had no consistent service names and three conflicting CMDB-ish spreadsheets.
Effect: the demo looked smart on vendor data. On yours it grouped nothing. Spend the first quarter on naming, OTel, and deploy events. Then turn the model on. That sequence is how DevOps becomes AIOps without a reorg theater.

What Really Matters Now

Ignore the slide that says "AI will replace Ops." The constraints that actually decide whether you ship and stay up in 2026:

• Telemetry cost. Logs will bankrupt you before models will save you. Sample, drop debug in prod, keep traces on the error path. Gartner now rates vendors on retention controls for a reason (Network World, 2025).
• Open standards. OTel, Prometheus remote write, Git, OCI. These outlive the AIOps logo on this year's PO.
• Change awareness. The highest-signal feature in any incident tool is "what shipped?" Wire GitOps into the incident object on day one.
• SLOs over raw alerts. Page on user pain, not on a disk that is allowed to be busy.
• Progressive delivery. A bad model or a bad binary should hit 5 percent of traffic, not 100 percent. Canary plus auto-rollback is worth more than a clever chatbot in Slack.
• GPU and queue signals. If you serve models, CPU HPA is a museum piece. Watch queue and TTFT.
• Identity and blast radius. Closed-loop remediation with a god-mode service account is how you automate a worse outage. Scoped roles, dry-run, and an audit trail.
• Platform, not heroics. One paved road. Ten unique Jenkinsfiles is why AIOps has nothing consistent to learn from.
• Humans who can still debug. When the model is wrong, someone must read a trace. That is still a DevOps skill. Teach it. The last post on visual programming was not a detour. Logic still comes before the copilot.

A Worked Example

Imagine a checkout API on EKS, a payments worker on a queue, and a fraud model on KServe.

DevOps layer. Code lives in GitHub. Actions runs tests and Trivy. The image is signed and stored in ECR. A tag bump in the env repo is synced by Argo CD. Rollouts sends 10 percent of traffic to the new checkout. Terraform owns the cluster and the IAM roles. HPA covers the API. KEDA covers the worker. The model has its own deploy pipeline and an MLflow version.

Observability layer. Each service emits OTel traces. RED metrics (rate, errors, duration) sit in Prometheus. Grafana has one checkout SLO board. Deploy events are annotations. The fraud model exports drift and score-latency.

AIOps layer. At 18:40 error rate climbs. Raw alerts: API 5xx, worker lag, KEDA scale events, a CloudWatch RDS CPU blip, and fraud latency. Correlation groups them. Enrichment shows a model version bump at 18:34 and a schema field the worker now drops. Suggestion: roll back model v17, not the API. A human confirms the first time. The second time, policy allows auto-rollback of that model registry stage only. MTTR is 11 minutes instead of 90. The GitOps repo has a commit that says why.

That is the whole architecture in one incident. No new job family required. A DevOps team that kept its telemetry honest, plus one closed loop.

What to Buy, What to Build

• Build (or standardize) the paved road: Git, CI, GitOps, OTel collector, a default dashboards folder, naming rules.
• Buy or adopt when glue hurts: a full observability suite if you lack people to run LGTM. An event-intelligence product when you already have more than ~20 noisy sources and a real CMDB/service catalog.
• Rent GPUs and model APIs: SageMaker, Vertex, Azure ML, Bedrock, Azure OpenAI. Keep registry, eval gates, and rollback in your repo.
• Do not buy: a second CI system "for AI," an AIOps tool before you have service names, or a copilot seat as a substitute for on-call training.

DevOps made change a habit. AIOps makes sense of the exhaust that habit creates. MLOps is the same habit applied to models. The fashion is to flatten all three into "we are an AI-driven enterprise." The work is plainer. Name the services. Ship through Git. Watch with OpenTelemetry. Scale on the signal that hurts. Let a model group the pages only after those sentences are true.

If you remember one line: AIOps is not a replacement for DevOps. It is DevOps with a memory, a map, and a brake.

References

• Amazon Web Services. (2024). Autoscaling Kubernetes workloads with KEDA using Amazon Managed Service for Prometheus metrics. https://aws.amazon.com/blogs/mt/autoscaling-kubernetes-workloads-with-keda-using-amazon-managed-service-for-prometheus-metrics/
• Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). Site reliability engineering: How Google runs production systems. O'Reilly.
• Cloud Native Computing Foundation. (2024). Platforms white paper. CNCF. https://www.cncf.io/
• Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The science of lean software and DevOps. IT Revolution.
• Gartner. (2025). Market guide for event intelligence solutions. Gartner.
• Gartner. (2026). Observability platforms. Gartner. https://www.gartner.com/reviews/market/observability-platforms
• Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps handbook. IT Revolution.
• Kim, G., Behr, K., & Spafford, G. (2013). The Phoenix Project. IT Revolution.
• Network World. (2025). In crowded observability market, Gartner calls out AI capabilities, cost optimization, DevOps integration. https://www.networkworld.com/article/4032218/in-crowded-observability-market-gartner-calls-out-ai-capabilities-cost-optimization-devops-integration.html
• OpenTelemetry Authors. (2024). What is OpenTelemetry? https://opentelemetry.io/docs/what-is-opentelemetry/
• Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. In Advances in Neural Information Processing Systems 28.
• TechTarget. (2024). AIOps vs. DevOps: Distinct approaches to IT automation. https://www.techtarget.com/it-infrastructure/feature/AIOps-vs-DevOps-Distinct-approaches-to-IT-automation

Read More

Digital Technology Revolutions Explained(1940~2020s): Computing, Internet, Mobile, Cloud, and AI

 

We are in an AI era. That sentence is already a marketing slogan. The quieter fact is older: digital technology did not arrive as one revolution. It arrived as stacked waves. Each wave made the next one cheap enough to ignore, then impossible to ignore.

A school student with a chatbot can draft an essay in a minute. That student still lives inside systems built by earlier waves: the transistor, the personal computer, the packet network, the phone in a pocket, and the data center that rents you a server by the hour. If you skip those layers, AI looks like magic. If you see them, AI looks like the latest digital technology revolution, not the only one (Schwab, 2016; Castells, 2010).

This post maps six waves that remade work, school, and home: computing, the personal computer, the internet, mobile, cloud and social, and artificial intelligence. It also puts the fashionable "Fourth Industrial Revolution" label next to the older digital revolution, because those two stories do not fully agree (Rifkin, 2011; Atkinson, 2019).

Key Abbreviations in This Post

• IC (Integrated Circuit): Many transistors on one chip. The reason computers left the room-sized cabinet.
• PC (Personal Computer): A machine for one person, not a shared mainframe behind a glass wall.
• TCP/IP: The internet's addressing and delivery rules. Packets, not a single leased phone line.
• WWW (World Wide Web): Pages, links, and browsers on top of the internet. Invented at CERN.
• IoT (Internet of Things): Sensors and devices that talk on a network without a human typing.
• Cloud: Someone else's computers, rented through a network. Storage and software as a service.
• AI (Artificial Intelligence): Software that finds patterns in data and acts on them. Today's wave is mostly machine learning.
• Industry 4.0: Factory talk for connecting machines, sensors, and software on the shop floor.
• 4IR (Fourth Industrial Revolution): Klaus Schwab's name for AI, IoT, robotics, and biology fusing with digital systems.
• CPS (Cyber-Physical System): Software that steers a real machine: a robot arm, a car, a grid.

The One-Minute Version

• Not one event: digital change is a stack. Each wave rides the last one's cheap chips and cheap links.
• Computing: transistor (1947) and the chip turn calculation into a product you can buy.
• PC: one machine per person. Offices and bedrooms get a keyboard.
• Internet and the Web: machines talk. Then people publish and search.
• Mobile: the computer leaves the desk. Most of the planet's first computer is a phone.
• Cloud and social: your files and your friends live in a data center.
• AI: software that writes, sees, and recommends. It still runs on the earlier stack.
• School takeaway: kids still need logic and languages before they treat a chatbot as a coworker.

Steam Moved Muscle. Digital Moves Information.

Textbook industrial history is tidy. First: steam and mechanized mills. Second: electricity and mass production. Third: electronics and computers that automate the factory. Schwab then adds a fourth: a fusion of physical, digital, and biological systems, moving at exponential speed (Schwab, 2016).

Jeremy Rifkin and later critics say the fourth label oversells a sequel. The digital revolution, in that reading, is the third industrial revolution, and AI, phones, and sensors are what you get when bits get cheaper for fifty years (Rifkin, 2011; Atkinson, 2019). Both stories are useful. Schwab is right that cars, clinics, and factories now run on code. Rifkin is right that the engine under that change is still digitization: turn a signal into numbers, then copy those numbers at almost no extra cost.

For a classroom, skip the branding fight. Teach the stack. A chatbot is not a steam engine. It is a program on rented computers, reached by a phone, trained on data that the internet made cheap to collect.

The Computing Wave

Digital technology starts when information becomes bits you can switch. Claude Shannon showed that communication is a numbers problem (Shannon, 1948). The hardware catch-up was the transistor at Bell Labs in 1947, then the integrated circuit at the end of the 1950s (Kilby, 1976; Noyce, 1961). Gordon Moore noticed in 1965 that chip density was doubling on a short clock. That observation, later called Moore's Law, is the hidden engine of every later wave (Moore, 1965).

Mainframes in the 1960s and 1970s put that power in banks, airlines, and governments. Ordinary people did not touch it. They filled forms. A clerk fed punch cards to a machine the size of a room.

Problem: a payroll for 10,000 workers cannot be recalculated by hand every week.
Cause: paper and mechanical calculators do not scale with headcount.
Effect: institutions computerize first. The public meets "the computer" as a distant, expensive authority, not a personal tool.

The Personal Computer Wave

Hobby kits in the 1970s, then the IBM PC in 1981, moved the machine onto a desk. One person, one keyboard, one screen. Spreadsheets, word processors, and later laptops turned offices and bedrooms into small computer rooms (Ceruzzi, 2003).

This is the wave schools still underestimate. A student who has only used a phone has not lived the PC idea: files you own, a folder you can lose, a program you installed on purpose. Cloud later hid that. AI hid it again. The PC wave is where "I ran the program" became a personal sentence.

Use it as a teaching hinge: show a local file, then the same file in a browser tab. The difference is the next two waves.

The Internet and Web Wave

The internet is not the Web. The internet is a packet network. ARPANET sent its first packets in 1969. Vint Cerf and Bob Kahn published the TCP design in 1974. Tim Berners-Lee proposed the World Wide Web at CERN in 1989 and the first public website arrived in 1991 (Cerf & Kahn, 1974; Berners-Lee et al., 1992).

Email, then browsers, then search, then always-on home links. Manuel Castells called the result a network society: the unit of power is no longer only the factory or the state. It is the node that can connect (Castells, 2010). Nicholas Negroponte's Being Digital told a mass audience the same shift in plainer words: atoms versus bits (Negroponte, 1995).

Problem: a researcher in Geneva and a lab in California cannot share a paper without mail or a tape.
Cause: computers were islands.
Effect: once packets and links exist, publishing, shopping, news, and later social life move onto the same pipe. The cost of a copy collapses. The cost of attention does not.

The Mobile Wave

Feature phones put voice and text in a pocket. The smartphone, marked in public memory by the iPhone in 2007, put a general-purpose computer there (Isaacson, 2011). Maps, cameras, payments, and messaging stopped being desktop jobs.

For most of the world, the first personal computer is a phone, not a beige box. That changes who is "online." It also changes what "programming" looks like to a child: an app icon, not a command prompt. Digital inclusion statistics now track mobile broadband more than home PCs, because that is how people actually connect (International Telecommunication Union, 2024).

Problem: a small shop cannot keep a desktop and a leased line.
Cause: PCs and fixed internet assume a desk and a bill.
Effect: the same shop runs inventory, payments, and WhatsApp on one handset. The next wave, cloud, makes that handset enough.

The Cloud and Social Wave

Amazon Web Services opened generally in 2006. Rent a server. Do not buy a room of them. That business model, copied across the industry, is why a two-person startup can look like a global service by Friday (Amazon Web Services, 2023).

Social platforms rode the same cheap servers and the mobile camera. Your photos, chats, and work documents stopped living mainly on a disk you could hold. They live in a data center you cannot visit. Convenience is the product. Lock-in and surveillance are the bill, paid in attention and data, not only in money (Zuboff, 2019).

This is the wave that trained the current AI models. No cloud, no scrape of the public Web at that scale. No social web, less of the text and images those models digested.

The AI Wave, and the Factory Label

Machine learning got cheap when three things stacked: GPUs, cloud, and huge public-ish datasets. Chatbots in the 2020s made that visible to people who never trained a model. The same stack is inside recommendation feeds, translation, medical image flags, and warehouse robots (Brynjolfsson & McAfee, 2014).

Industry 4.0 is the factory dialect of this wave: sensors on the line, software that schedules the line, robots that move parts. Schwab's 4IR adds cars, gene tools, and 3D printing to the same story (Schwab, 2016). Atkinson and Rifkin reply that this is digital technology finally gripping the physical world, not a new species of revolution (Atkinson, 2019; Rifkin, 2011).

Either way, the student-facing point is the same. AI is a layer. It does not replace knowing what a program is, who owns the data, or what happens when the model is wrong.

Problem: a hospital wants faster reads of scans, and a student wants faster homework.
Cause: both now have a model that is good on average and silent about its misses.
Effect: the hospital needs a human who can challenge the flag. The student needs enough programming logic to see that a fluent paragraph can still be a wrong algorithm. The wave is real. The exemption from thinking is not.

What Each Wave Changed

Why Schools Still Need Languages and Logic

A digital revolution is not a permission slip to skip the basics. The opposite is true. Each wave makes fluent output cheaper, so the scarce skill is judgment: did this program do the right thing, on the right data, for the right person?

That is why visual programming, flowcharts, and first languages still belong before heavy AI use. A child who has snapped a loop, drawn an if-diamond, or typed a function has a place to hang a chatbot answer. A child who has only seen a prompt has a slot machine (Resnick et al., 2009; Cook, 2015).

Problem: a year-10 class treats ChatGPT as a search engine that never cites.
Cause: they never had to make a machine follow three steps in order.
Effect: they cannot tell a hallucinated API from a real one. Teach a small program first. Then let them prompt. Then make them explain the output in the language of the earlier waves: input, process, output, and who stored the data.

What Is Not a New Revolution

A new app store category is not a revolution. A faster phone chip is usually Moore's Law doing its job. A company renaming its roadmap "AI-first" is a press release.

A revolution, in the sense used here, changes who can act and what an ordinary day looks like. Payroll on a mainframe did that for institutions. The PC did it for offices. The Web did it for publishing. The smartphone did it for the street. Cloud did it for startups and surveillance. AI is doing it for drafting, seeing, and recommending. If your "revolution" does not move one of those everyday acts, keep the word on the shelf.

The next layer will sit on the same stack: more sensors, more on-device models, more fights over data and power. Students who can see the stack will still be employable when the brand names change.

References

• Amazon Web Services. (2023). About AWS. https://aws.amazon.com/about-aws/
• Atkinson, R. D. (2019). The task ahead of us: Transforming the global economy with connectivity, automation, and intelligence. Information Technology and Innovation Foundation. https://www2.itif.org/2019-task-ahead.pdf
• Berners-Lee, T., Cailliau, R., Groff, J.-F., & Pollermann, B. (1992). World-Wide Web: The information universe. Internet Research, 2(1), 52–58.
• Brynjolfsson, E., & McAfee, A. (2014). The second machine age: Work, progress, and prosperity in a time of brilliant technologies. W. W. Norton.
• Castells, M. (2010). The rise of the network society (2nd ed.). Wiley-Blackwell.
• Cerf, V. G., & Kahn, R. E. (1974). A protocol for packet network intercommunication. IEEE Transactions on Communications, 22(5), 637–648.
• Ceruzzi, P. E. (2003). A history of modern computing (2nd ed.). MIT Press.
• Cook, D. D. (2015). Flowgorithm: Principles for teaching introductory programming using flowcharts. ASEE Annual Conference.
• International Telecommunication Union. (2024). Measuring digital development: Facts and figures. ITU.
• Isaacson, W. (2011). Steve Jobs. Simon & Schuster.
• Kilby, J. S. (1976). Invention of the integrated circuit. IEEE Transactions on Electron Devices, 23(7), 648–654.
• Moore, G. E. (1965). Cramming more components onto integrated circuits. Electronics, 38(8), 114–117.
• Negroponte, N. (1995). Being digital. Knopf.
• Noyce, R. N. (1961). Semiconductor device-and-lead structure (U.S. Patent No. 2,981,877). U.S. Patent and Trademark Office.
• Resnick, M., Maloney, J., Monroy-Hernández, A., Rusk, N., Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., & Kafai, Y. (2009). Scratch: Programming for all. Communications of the ACM, 52(11), 60–67.
• Rifkin, J. (2011). The third industrial revolution: How lateral power is transforming energy, the economy, and the world. Palgrave Macmillan.
• Schwab, K. (2016). The fourth industrial revolution. World Economic Forum. https://www.weforum.org/stories/2016/01/the-fourth-industrial-revolution-what-it-means-and-how-to-respond/
• Shannon, C. E. (1948). A mathematical theory of communication. Bell System Technical Journal, 27(3), 379–423.
• Zuboff, S. (2019). The age of surveillance capitalism. PublicAffairs.

Read More

Visual Programming Languages: Thirteen Tools That Teach Code Before Syntax

We are in an AI era. A student can paste a homework prompt into a chatbot and get working Python back in seconds. That does not mean they can read the result, fix it, or tell a good loop from a lucky guess. Before kids step into AI usage, they still need the old core: what a program is, how logic branches, and why a computer only does what you asked, not what you meant.

Visual programming languages (VPLs) are the school-friendly way to build that core. You snap a block, draw a flowchart, or move a character, then watch the idea run. Typing, and later prompting, come after the student can see sequence, choice, and loops. A first class that dies on a missing semicolon never gets that far. A class that starts visual usually does.

This post walks through thirteen tools that keep showing up on school laptops, lab benches, and phone screens: Flowgorithm, MIT Scratch, Blockly, Snap!, Sketchware, Alice, MIT App Inventor, Kodu, Moenagade, Open Roberta, Kojo (Kogics), Visual Logic, and Flowcode. They are not one product family. They share one bet: if you can see the program, you can think about the program, and that thinking is still required in an AI classroom (Resnick et al., 2009; Cook, 2015).

Key Abbreviations in This Post

• VPL (Visual Programming Language): A language you build by placing shapes, not by typing source first.
• IDE (Integrated Development Environment): The editor, runner, and debugger in one window.
• CS1: A first university or college programming course.
• BYOB (Build Your Own Blocks): The Scratch fork that became Snap!. Adds first-class procedures.
• NEPO: The block language used in Open Roberta Lab (Fraunhofer IAIS).
• APK (Android Package): The install file an Android phone runs.
• SoC / MCU (Microcontroller): The small chip Flowcode and robot labs actually flash.
• EV3 / micro:bit / Arduino: Common classroom robots and boards that Open Roberta and similar tools target.
• Scala: The text language behind Kojo. Looks like a modern Java cousin, with a gentler start.
• Export / code gen: Turning a flowchart or block stack into C++, Java, Python, or similar.

The One-Minute Version

• Scratch, Snap!, Blockly: Puzzle blocks. Scratch is the kids' studio. Snap! is the university-strength cousin. Blockly is the library other apps sit on.
• App Inventor and Sketchware: Same block idea, aimed at a phone app. App Inventor is browser plus companion. Sketchware lives on the phone.
• Alice and Kodu: 3D stories and games. Sequence and events without a blank text file.
• Flowgorithm, Visual Logic, Flowcode: Executable flowcharts. The first two teach algorithms. Flowcode talks to real boards.
• Open Roberta: Browser blocks for robots. No local install fight with school IT.
• Moenagade: Blocks that become real Java you can open in NetBeans.
• Kojo (Kogics): Turtle, art, math, and Scala. Visual canvas, text language.

Why These Tools Exist

Text languages punish beginners twice. First for the idea. Then for the grammar. A Hello World in Java already hides classes, static methods, and string arrays. The student needed output. They got object-oriented ceremony (Cook, 2015).

Research on CS1 keeps finding the same pattern. Students spend the hour hunting syntax, then leave without a working algorithm. Visual tools cut the grammar tax so the hour goes to sequence, choice, loops, and events (Gudmundsen et al., 2012; Cooper et al., 2000).

Problem: a 14-year-old can describe "if the sprite hits the wall, bounce," but cannot type the event handler.
Cause: the language wants listeners, coordinates, and braces before it will move a pixel.
Effect: they quit, or they copy a snippet they cannot read. A block editor lets them snap when touching edge, bounce and see it work the same afternoon (Resnick et al., 2009).

That is the whole family in one story. The tools differ in shape: flowchart, puzzle, 3D stage, robot, phone, or turtle canvas.

Block Studios: Scratch, Blockly, Snap!

These three get mixed up in every faculty meeting. Scratch is a product kids open. Blockly is a JavaScript library you embed. Snap! is a Scratch descendant that treats procedures as data, which is why UC Berkeley can teach CS10 with it (Harvey & Mönig, 2010; Fraser, 2015).

MIT Scratch

Scratch came out of the Lifelong Kindergarten group at the MIT Media Lab, led by Mitchel Resnick. The public 1.0 release was 2007. Scratch 2.0 moved to the browser in 2013. Scratch 3.0 (2019) rebuilt the editor on Blockly (Resnick et al., 2009; Scratch Foundation, 2019).

You drag colored blocks: motion, looks, sound, events, control, sensing, operators, variables. Sprites live on a 2D stage. The community is the other half of the product. Kids remix shared projects, which is how a cat-chasing-a-mouse game becomes a thousand variants.

Use it when: ages 8 to 16, clubs, intro computing, media and storytelling. Not when you need a published Android store app or a PIC microcontroller.

Problem → cause → effect: a middle-schooler wants a game by Friday. A text IDE asks for a window toolkit first. Scratch gives a stage, a green flag, and a forever loop. They ship a playable sketch, then later ask what a real loop looks like in Python.

Blockly

Google released Blockly as open source in 2012. Neil Fraser and the Blockly team built a drop-in block editor: toolbox, workspace, code generators for JavaScript, Python, PHP, Lua, Dart, and others (Fraser, 2015).

You do not "switch a class to Blockly" the way you switch a class to Scratch. You put Blockly inside something else. App Inventor, Code.org, MIT Scratch 3, Microsoft MakeCode, and Open Roberta all sit on that idea. The blocks look familiar because the library taught the industry a visual grammar: C-shaped loops, puzzle-piece types, a trash can.

Use it when: you are building an editor, a lesson site, or a hardware tool and you do not want to invent snapping from scratch.

Snap!

Snap! (often written Snap) grew from BYOB, a Scratch modification by Jens Mönig and Brian Harvey. The goal was a ceiling, not only a floor. You can build your own blocks. Lists and procedures are first-class. You can write a map or a recursive tree without leaving the block world (Harvey & Mönig, 2010).

Berkeley's Beauty and Joy of Computing course uses Snap! so students meet abstraction before they meet Java braces. If Scratch is "make a game," Snap! is "make a language that makes games."

Use it when: high school AP-style computing, CS0/CS1 that wants functions as values, or a Scratch kid who outgrew the built-in palette.

Phone Apps: App Inventor and Sketchware

Two answers to "can I ship something my friends can install?" One assumes a laptop. One assumes only a phone.

MIT App Inventor

App Inventor started at Google in 2009 and moved to MIT in 2011 and 2012. The current MIT App Inventor is a browser IDE: Designer for screens and components, Blocks for behavior. The block engine is Blockly. Companion apps on Android (and later iOS) let you live-test without a full compile every click (Wolber et al., 2014; MIT App Inventor, 2024).

You get sensors, maps, speech, TinyDB, and web APIs as components. That is why a civic-tech class can build a pothole reporter in two weeks. The limit is the component set and the performance of the generated app, not the student's ability to type Java.

Sketchware

Sketchware put the same block idea on the Android device itself. You design a layout, snap logic, and build an APK on the phone. The original commercial app later stalled. The community kept the idea alive as Sketchware Pro (Sketchware Pro, 2023).

It is messy in the way phone-native tools are messy: storage permissions, signing keys, Play Store policy. It is also the only option in rooms where there is no laptop cart.

Problem → cause → effect: a college club wants a campus bus app. App Inventor gives Designer plus Blocks on a lab PC, then a QR install. A student with only a phone uses Sketchware and sideloads the APK. Same visual habit. Different hardware constraint.

Stories and Games: Alice and Kodu

Alice

Alice is a 3D environment from Carnegie Mellon University. Randy Pausch, Steve Cooper, and Wanda Dann built it so novices could tell a story in a virtual world while learning objects, methods, and events (Cooper et al., 2000). Alice 3 added a path toward Java and aligned characters with a commercial 3D gallery.

A student drops a person in a room, writes walk to the door, then say "hello". The camera and the character make bugs obvious. If the person walks through the wall, the algorithm is wrong. You do not need a debugger log.

Kodu

Kodu Game Lab came from Microsoft Research (Matt MacLaurin and team). It started on Xbox and later landed on Windows. Rules look like tiles: WHEN see apple DO move toward. Terrain, characters, and scoring sit in a small 3D world (MacLaurin, 2011).

Kodu teaches event-condition-action, not algebra. That is a feature. A primary class can build a collect-the-coins game without variables if they do not need them yet. When they do, score and pages are there.

Use Alice when the course wants objects and storytelling on a PC.
Use Kodu when the course wants a game controller, a hill, and a rover, and the students are younger.

Flowchart Trio: Flowgorithm, Visual Logic, Flowcode

Blocks hide syntax. Flowcharts hide almost everything except control flow. Intro algorithm courses love them because the chart is the program.

Flowgorithm

Devin Cook at California State University, Sacramento, built Flowgorithm as a free, executable flowchart language. You drop start, input, assign, output, if, loops, functions, and arrays. You run it. A watch window shows variables. Then you generate C#, C++, Java, JavaScript, Python, Ruby, Swift, Visual Basic, and more, interactively, so the student can see how a diamond becomes an if (Cook, 2015; Flowgorithm, 2024).

It is Windows-first, light, and honest about its job: teach logic, then hand the student a real language.

Visual Logic

Visual Logic (visuallogic.org) is a commercial executable-flowchart tool used in U.S. program-logic courses. It covers variables, input and output, conditions, loops, procedures, arrays, and files. The demo watermarks and will not save. Departments buy a license when they want a whole CS0 term on charts, then a jump to Python or Java (Gudmundsen et al., 2012; Crews & Murphy, 2009).

Compared with Flowgorithm, Visual Logic is less about multilingual export and more about a closed teaching loop: draw, run, grade.

Flowcode

Flowcode, from Matrix TSL in the United Kingdom (the company once known as Matrix Multimedia), is a commercial visual IDE for embedded systems. Students draw flowcharts or use a mix of flowchart, blocks, and C, then simulate and download to PIC, Arduino, AVR, and other boards. Education licenses pair with E-blocks, AllCode robots, and curriculum packs for motors, sensors, and comms (Matrix TSL, 2024).

Do not treat Flowcode as a CS1 flowchart toy. It is an electronics and mechatronics tool that happens to be visual. The "Hello World" is an LED, not a console line.

Problem → cause → effect: a technician course must teach PWM before it teaches pointers. Flowcode lets the student chart "read pot, write duty cycle," simulate the LED brightness, then flash a board. They meet C later, when the generated code is no longer magic.

Robots and a Java Bridge: Open Roberta and Moenagade

Open Roberta

Open Roberta Lab is a browser environment from Fraunhofer IAIS in Germany, grown out of the Roberta initiative that put robots in schools. The language is NEPO, a Blockly-inspired block set. Pick a robot, snap actions and sensors, run a simulation or download. Targets have included LEGO EV3, NXT, WeDo, Calliope, micro:bit, Arduino-class boards, NAO, and others. Generated code depends on the target: Java, Python, C/C++, MicroPython (Fraunhofer IAIS, 2024).

The classroom win is logistics. No admin rights. Any OS. One URL. A teacher can move from EV3 one term to micro:bit the next without rewriting the pedagogy.

Moenagade

Moenagade is a small, honest tool. Franz-Josef Schmitt (fesch) published it around 2017 from Luxembourg (moenagade.fisch.lu, GitHub fesch/Moenagade). It is GPL-3. Blocks describe beginner Java structures. The point is the live conversion to real, executable Java that you can later open in NetBeans or Unimozer (Schmitt, 2017).

It is limited on purpose. Other block tools hide the text. Moenagade exists because the author wanted students to see the Java appear while they still remember why they snapped the loop.

Kojo, from the Kogics Foundation

People write "Kogics" on a syllabus and mean Kojo. Kogics is the foundation. Kojo is the learning environment Lalit Pant built: desktop app for Linux, Windows, and Mac, plus a web app. The language is Scala. The first contact is often turtle graphics, then pictures, animation, games, music, and even Arduino (Kogics Foundation, 2024).

Kojo is a hybrid, not a pure VPL. You type. The canvas answers. That is closer to Logo and Processing than to Scratch. Indian state curricula have used it in grades 7 to 10 because one tool can cover drawing, math, and a path into a real industrial language.

Use it when: you want art and algebra in the same window, and you are willing to teach a little text on day one.

How the Thirteen Compare

Which Tool Fits the Room

Do not start with the brand on a conference slide. Start with the artifact and the hardware you already own.

• Kids, games, remix culture: Scratch. If they outgrow it, Snap!.
• Phone in their pocket: App Inventor if you have laptops. Sketchware if you do not.
• 3D story, objects, later Java: Alice.
• Controller and a landscape: Kodu.
• CS0 algorithm unit, Windows lab: Flowgorithm (free) or Visual Logic (licensed, save/grade workflow).
• Electronics, PIC, Arduino kits you already bought from a UK catalog: Flowcode.
• Robot cupboard, locked-down school PCs: Open Roberta in the browser.
• Must see Java this term: Moenagade, then NetBeans.
• Math, art, India-friendly curriculum, Scala later: Kojo.
• You are the one writing the editor: Blockly.

A Classroom Path That Does Not Trap Students

Visual tools fail when they become a gated community. The student can snap forever and still freeze in front of a blank main. The better path is short and visible.

1. See the idea. Stage, flowchart, or robot. One output on day one.
2. Snap or draw the steps. Sequence, then if, then loop. Name the pattern out loud.
3. Run and watch. Step mode if the tool has it (Flowgorithm's watch window, Scratch's single-step, robot simulation).
4. Fix the bug you can see. The sprite walks through the wall. The LED never lights. The flowchart never reaches Output.
5. Export once, on purpose. Flowgorithm to Python. Moenagade to Java. Open Roberta to the target language. App Inventor students open the built APK and talk about events in words that will match later Java listeners.

Problem: year-10 students ace Scratch and fail the first Python quiz.
Cause: the course never showed that a C-shaped block is a while, and never made them type one.
Effect: they call visual languages "not real." Pair every unit with a 20-minute export or rewrite. The tool is a scaffold, not a career.

What These Tools Are Not

They are not a replacement for data structures, complexity, or systems programming. They will not make a production backend. Blockly inside a factory HMI is still an HMI, not a proof that blocks scale to every domain.

They also are not all free, and they are not all alive at the same speed. Visual Logic and Flowcode are commercial. Sketchware's original store listing went quiet. Moenagade's last public push was 2018. Scratch, Snap!, Blockly, App Inventor, Open Roberta, Kojo, and Flowgorithm are the ones you can plan a three-year curriculum around without holding your breath.

Pick the living tool that matches the artifact. Keep the export step. Treat the colorful blocks as a way to think, not as a place to hide.

References

• Cook, D. D. (2015). Flowgorithm: Principles for teaching introductory programming using flowcharts. ASEE Annual Conference. https://peer.asee.org/flowgorithm-principles-for-teaching-introductory-programming-using-flowcharts
• Cooper, S., Dann, W., & Pausch, R. (2000). Alice: A 3-D tool for introductory programming concepts. Journal of Computing Sciences in Colleges, 15(5), 107–116.
• Crews, T., & Murphy, C. (2009). A guide to working with Visual Logic. Course Technology.
• Flowgorithm. (2024). Flowgorithm: Flowchart programming language. http://flowgorithm.org/
• Fraser, N. (2015). Ten things we've learned from Blockly. In 2015 IEEE Blocks and Beyond Workshop (pp. 49–50). IEEE. https://developers.google.com/blockly
• Fraunhofer IAIS. (2024). Open Roberta Lab. https://lab.open-roberta.org/
• Gudmundsen, D., Olivieri, L., & Sarawagi, N. (2012). Reducing the learning curve in an introductory programming course using Visual Logic. Journal of Computing Sciences in Colleges, 27(4), 10–12.
• Harvey, B., & Mönig, J. (2010). Bringing "no ceiling" to Scratch: Can one language serve kids and computer scientists? Constructionism 2010. https://snap.berkeley.edu/
• Kogics Foundation. (2024). Kojo. https://www.kogics.net/kojo
• MacLaurin, M. (2011). The design of Kodu: A tiny visual programming language for children on the Xbox 360. Proceedings of the 38th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (pp. 241–246). ACM.
• Matrix TSL. (2024). Flowcode for education. https://flowcode.co.uk/education/
• MIT App Inventor. (2024). MIT App Inventor. https://appinventor.mit.edu/
• Resnick, M., Maloney, J., Monroy-Hernández, A., Rusk, N., Eastmond, E., Brennan, K., Millner, A., Rosenbaum, E., Silver, J., Silverman, B., & Kafai, Y. (2009). Scratch: Programming for all. Communications of the ACM, 52(11), 60–67. https://scratch.mit.edu/
• Schmitt, F.-J. (2017). Moenagade [Computer software]. GitHub. https://github.com/fesch/Moenagade
• Scratch Foundation. (2019). Scratch 3.0. https://scratch.mit.edu/
• Sketchware Pro. (2023). Sketchware Pro [Computer software]. GitHub. https://github.com/Sketchware-Pro/Sketchware-Pro
• Wolber, D., Abelson, H., Spertus, E., & Looney, L. (2014). App Inventor 2: Create your own Android apps. O'Reilly.

Read More