The Impact of AI onSoftware Engineering
Pamela Fox
Today: five shifts, then what they mean for the classroom.
About me
Pamela Fox
Principal Cloud Advocate at Microsoft / GitHub
Formerly: UC Berkeley, Coursera, Khan Academy, Google
Formerly a CS teacher at UC Berkeley, plus Coursera and Khan Academy.
The two big impacts of AI on software
Generative AI models
LLMs that generate text, code, images, and more
Built ON AI
Software now runs on top of probabilistic AI models
Built BY AI
Software is now written largely by those models
Roadmap. One cause, generative AI models, and two big shifts: software is built ON AI, and built BY AI. The rest of the talk follows from those two: how engineering work changes, who can build software, and what we should teach.
Software is now built on top of probabilistic AI models
Deterministic vs. probabilistic
Traditional code
add(2, 3)
5
5
5
Same input, same output, every time
AI-powered code
“Write a haiku
about recursion”
Recursive call sings, …
A recursion call …
Self calls in quiet …
Same input, different output
AI engineering is mostly about constraining , grounding , and evaluating that output.
Traditional code is deterministic. AI-powered code calls models whose output is sampled. The haiku first lines are real outputs from today's demo runs.
Building on AI models: Core concepts
Models
LLMs
Same prompt, different output
More models
Images, embeddings, voice
Fine-tuning
Train a model on your own data
Outputs & actions
Structured outputs
Constrain to a schema
Tool calling
The LLM asks your code to run a function
Agents
Tool calling in a loop
Building apps
Context engineering
Give the LLM the right context
Evaluations
“Test” probabilistic output
Safety
Guard against harmful output
Quick tour of AI engineering, based on the Python + AI series at aka.ms/pythonai/rewatch. All demos run locally with Ollama.
LLMs: same prompt, different output
client = openai.OpenAI(
base_url="http://localhost:11434/v1",
api_key="ollama")
response = client.chat.completions.create(
model="gpt-oss:20b",
messages=[{"role": "user",
"content": "Write a haiku about recursion"}])
print(response.choices[0].message.content)
🔗 llm.py
Run 1
Recursive call sings,
In a loop echoing back,
Mirror traps itself.
Run 2
A recursion call
Echoing in stack, depth folds
Endless loop repeats
Run it live twice. Real outputs from gpt-oss:20b running locally in Ollama.
Context engineering
Sending context to the LLM to personalize the response and ground responses in domain-specific data.
Instructions
Retrieved documents
Conversation history
Tool results
Context
window
LLM
Answer
The model only knows what's in its training data plus what you put in the context window. Context engineering is choosing that.
RAG: Retrieval-Augmented Generation
Question
“When is the
project due?”
1. Retrieve
Search a database,
search engine, or docs
→ relevant sources
2. Generate
LLM gets the question
+ retrieved sources
Answer
grounded in the
sources, with citations
What's in the LLM's weights
Frozen at a training cutoff date
Mostly public internet data
Can't point to its sources
Fills gaps by guessing
What retrieval adds
Fresh, up-to-date information
Your private, domain-specific data
Sources it can cite
Less guessing, fewer hallucinations
RAG is the most common context engineering technique. The key step is retrieval: before the LLM answers, search your own data for relevant sources and put them in the context. That counters what's missing or wrong in the model's weights: stale knowledge, no access to your private data, and no way to cite sources.
RAG example: a syllabus Q&A bot
Question “When is the final project due?”
→
Search Keyword search over the sections of syllabus.md
→
Sources ## Final project … The final project is due December 12 …
→
LLM “Answer ONLY using these sections, and cite them”
→
Answer The final project is due on December 12. [Final project]
def answer(question):
sources = "\n\n".join(search(question))
response = client.chat.completions.create(
model=MODEL,
messages=[
{"role": "system", "content": "Answer ONLY using these syllabus sections. "
f"Cite the section title in square brackets.\n\n{sources}"},
{"role": "user", "content": question}])
return response.choices[0].message.content
🔗 rag.py · syllabus.md
Real answer from the demo. Search can be keyword or vector search; vector search uses embedding models, which we'll see later.
Evaluations: how do you test this?
Unit test : deterministic
def test_penalty():
assert penalty(0) == 0
assert penalty(1) == 10
assert penalty(2) == 20
Doesn't work when the output is different every time.
Eval : use an LLM-as-a-judge to score the response as pass/fail with a reason
question = "When is the final project due?"
answer_text, sources = answer(question)
verdict = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content":
"Is every claim in this answer supported "
"by the sources? Start with PASS or FAIL, "
"then give a one-sentence reason.\n"
f"Sources: {sources}\nAnswer: {answer_text}"}]
).choices[0].message.content
PASS – The due date, December 12, is directly supported by the source.
🔗 evals.py
The unit test checks a deterministic function from the same syllabus: 10% off per day late. The eval asks a second LLM call to judge whether the answer is grounded in the sources. Next slide: run it over many inputs.
Bulk evals: one question isn't enough
Always run evals on a diverse dataset of inputs:
Question Judge Reason
When is the final project due? PASS Due date matches the source
What happens if I turn in homework late? PASS Every claim is backed by the late policy
Can I use ChatGPT to write my homework? PASS Matches the AI tools policy
When are office hours? PASS Repeats the source's times and room
How much is the midterm worth? PASS Source lists the midterm as 20%
Can I use Copilot to debug my homework? FAIL Says no, but policy allows explaining errors
Track the pass rate as you change prompts, models, or data.
Real results from a run of evals.py. The bot told a student they can't use Copilot to debug, but the policy allows AI to explain error messages. Re-runs vary: sometimes that question passes, sometimes others fail. Teacher analogy: unit tests are an autograder, evals are grading with a rubric. An LLM judge is a TA applying your rubric, so you still spot-check its grades.
Structured outputs
Instruct the LLM to output data that conforms to a typed schema:
class CodeFeedback(BaseModel):
concepts_used: list[str]
bugs: list[str]
hints: list[str]
completion = client.chat.completions.parse(
model=MODEL,
messages=[{"role": "user", "content":
f"Review this student code:\n{code}"}],
response_format=CodeFeedback)
feedback = completion.choices[0].message.parsed
🔗 structured_outputs.py
Input: student code
def average(scores):
total = 0
for i in range(1, len(scores)):
total += scores[i]
return total / len(scores)
Output
CodeFeedback(
bugs=['Incorrect loop start index
(skips first element)',
'Potential division-by-zero when
scores is empty', ...],
hints=['Guard against an empty list ...',
"Leverage Python's built-in
sum()", ...],
...)
You get back a validated Python object that the rest of your program can use, like showing bugs and hints in a feedback UI.
Tool calling
Give the LLM access to tools, like local functions or remote MCP servers:
Your code
LLM
1. List of tool definitions
get_weather_alerts(state: str)
2. User input
“Any weather alerts in California?”
3. Suggested tool name + arguments
get_weather_alerts(state="CA")
4. Calls the tool
→ api.weather.gov
The model never runs code. It only suggests a tool call for your code to make.
This is the foundation for agents. The model outputs a request; your code decides whether and how to run it. Note the LLM turned "California" into the "CA" state code that the NOAA API expects.
Tool calling: the code
tools = [{"type": "function", "function": {
"name": "get_weather_alerts",
"description": "Get active weather alerts from NOAA for a US state",
"parameters": {"type": "object",
"properties": {"state": {
"type": "string", "description": "Two-letter state code"}},
"required": ["state"]}}}]
response = client.chat.completions.create(
model=MODEL, tools=tools,
messages=[{"role": "user",
"content": "Any weather alerts in California?"}])
tool_call = response.choices[0].message.tool_calls[0]
args = json.loads(tool_call.function.arguments)
alerts = get_weather_alerts(**args)
get_weather_alerts {"state":"CA"}
24 alerts:
Extreme Heat Warning:
Death Valley National Park
Coastal Flood Advisory:
North Bay Interior Valleys
...
🔗 tool_calling.py
Real NOAA data, no API key needed. Without the "Two-letter state code" description, the model passed "California" and the NOAA API returned a 400 error: tool descriptions are part of your prompt.
Agents: tool calling in a loop
User query
LLM
Tools
call
result
Answer
User Where are office hours, and do I need an umbrella to get there today?
LLM search_syllabus("office hours")
Tool Tue & Thu 3:30–4:30pm, Room 214, Berkeley, CA
LLM get_weather("Berkeley")
Answer Office hours are in Room 214. Bring an umbrella!
The model can't plan every call up front: it doesn't know which city to check the weather for until the syllabus search tells it the school is in Berkeley.
The agent loop in code
while True:
response = client.chat.completions.create(
model=MODEL, messages=messages, tools=tools)
message = response.choices[0].message
messages.append(message)
if not message.tool_calls:
break
for tool_call in message.tool_calls:
args = json.loads(tool_call.function.arguments)
result = tool_functions[tool_call.function.name](**args)
messages.append({"role": "tool",
"tool_call_id": tool_call.id, "content": result})
print(message.content)
🔗 agent.py
Call LLM with tools
Tool calls?
yes
Run each tool
Add results to messages
no
Answer
An agent is just a while loop around tool calling. That's it. Demo: run agent.py live.
Other kinds of models
Image generation
Text prompt in, image out. Also probabilistic.
Embeddings
Text in, list of numbers out. Powers vector search.
Voice & transcription
Speech to text, text to speech, and realtime voice.
Image generation and voice are also probabilistic: the same prompt gives different images, and transcription models can invent text that was never said (find a source for Whisper hallucinations before the talk). Embeddings power the vector search in RAG; the detailed embedding slides are hidden (data-visibility="hidden") if time allows.
Embedding models: text in, numbers out
“dog”
Embedding
model
[0.0028, -0.0114, -0.1613, …]
768 numbers
response = client.embeddings.create(
model="nomic-embed-text",
input=["dog", "puppy", "cat", "perro", "spreadsheet"])
vectors = [item.embedding for item in response.data]
Similar meanings get similar vectors, measured with cosine similarity. Not probabilistic: same input, same vector. But very dependent on training data…
🔗 embeddings.py
Multilingual support varies a lot by model
translations of “dog”
0.79
0.73
0.60
0.39
0.42
0.67
0.46
0.73
0.43
0.85
0.42
0.22
puppy
cat
perro
chien
Hund
spreadsheet
nomic-embed-text (English only)
nomic-embed-text-v2-moe (multilingual)
With the English-only model, “perro” is about as similar to “dog” as “spreadsheet” is.
Cosine similarity to "dog", computed today with embeddings.py and two local Ollama models from the same company.
Software is now being built largely BY those AI models
AI coding agents
A coding agent is an agent with tools specific to code generation:
Task
LLM
Context
OS, settings,
memory
Code changes
call
result
Coding tools
Read & search files
Edit & create files
Run tests & commands
Fetch web pages & docs
Tools from MCP servers
A real agent session: building this deck
Switch to VS Code and show the session live. The agent also wrote and ran this talk's demos against local Ollama: it saw qwen3.5:9b leak its reasoning into the haiku and switched to gpt-oss:20b, and saw the agent demo skip a tool call in 1 of 3 runs, so it rewrote the question and re-ran until reliable. That's the loop in action, including verification.
Coding agents keep getting better, faster
Length of software tasks (in human time) the best AI model completes 50% of the time:
Source: METR time horizons v1.1, updated May 2026. Doubling about every 4 months since 2023.
More benchmarks: Artificial Analysis Coding Agent Index · SWE-bench
METR is an independent nonprofit. They time skilled humans on 100+ software tasks, then find the task length where each model succeeds 50% of the time. 4 minutes in 2023, 1 hour in early 2025, 12 hours in early 2026: doubling about every 4 months, faster than the ~7 months in their original 2025 paper. Tasks are graded automatically: callback to evals. Caveats: these are well-specified, low-context tasks, and 50% isn't reliable. METR's newest measurement (Claude Mythos Preview, ~17 hours) is left off because they say results above 16 hours are unreliable with their current task suite.
Developers are actually using agents
Merged PRs per month
130M
Agent-created PRs: 17.8M in March 2026 alone , quadrupled in six months. By August, GitHub had more agent-authored PRs than human-authored ones.
Sources: GitHub Blog, “The August 17 outage, and the work ahead” ; The Pragmatic Engineer, “The state of the tech industry in 2026”
Chart shapes are approximate redraws of Marlene's charts. Ask Marlene for her chart images or underlying data, and get the GitHub Blog link.
More from her keynote: completed GitHub Actions runs grew nearly 4x in 2026, to 115.4M in August. Also, at Linear, agents have created more issues than humans since July.
Agents finish big projects much faster
Bun
Rewritten from Zig to Rust
11 days
vs. an estimated 1.5 engineering years
Airbnb
3,500 test files migrated to a new testing library
6 weeks
instead of years
Uber
600,000 tests across 15 million lines of code migrated
4 months
instead of an estimated several years
Source: The Pragmatic Engineer, “The state of the tech industry in 2026”
How software engineers work now
Before AI coding
Feature A
Design
Build
Test
Feature B
Not started
Feature C
Not started
You: the engineer
After AI coding
Feature A
Agent working
Ready for review
Feature B
Agent working
Needs input
Feature C
Write the spec
Agent working
You: the engineering manager
“I have 5 terminal tabs… I also run 5-10 Claudes on Claude Web, in parallel with my local Claudes.” — Boris Cherny, creator of Claude Code
See also: Nicholas C. Zakas, “Five software engineering roles for working with AI”
"Nobody writes code by hand anymore" is the #1 trend in the Pragmatic Engineer post. We are engineering managers for agents. Diagram adapted from my "Parallelize your development with GitHub Copilot" talk.
From IDE to agent dashboard
VS Code One agent, next to your code
Copilot app Many agents in one app
Cloud agents Many agents, running on GitHub
less parallel
more parallel
Screenshots from Parallelize your development with GitHub Copilot
Less parallel to more parallel. The interface is becoming a conversation, monitoring, and verification interface, not a code editor. Other tools are moving the same way: Cursor 3.0 dropped its IDE interface, and Codex launched as a non-IDE app. Kent Beck: "It's not that we don't need more perspective and context for our human-based decisions; it's that the context has changed."
Agents excel at verifiable tasks
Can be checked automatically
Do the tests pass?
Does it compile?
Does it match the expected output?
Agents improve fastest here.
Agents are weaker at judgment calls
Takes judgment
Is it well tested?
Is it secure?
Is it maintainable?
Do the pieces fit together across many files?
Agents are weakest here.
Verification is the new bottleneck
Trust depends on checking
16%
of developers trust AI for most tasks. 48% trust it only when they can easily check the answer.
Few humans are checking
58%
of reviewed agent PRs had only another agent as the reviewer. Most agent PRs got no review at all.
Agents can game the tests
Agents sometimes “pass” by editing the tests or copying a published solution. Benchmarks now check for this and score it zero.
Sources: Stack Overflow 2026 Developer Survey ; “These Aren't the Reviews You're Looking For” (May 2026) ; Artificial Analysis reward hacking detection
Agents can write the code; the hard part now is knowing whether it's right. Stack Overflow 2026: AI is "very good at technical problems with checkable answers, and considerably less good" at everything else. Older data points the same way: METR (Aug 2025) found 38% of agent PRs passed the tests but 0 of 15 were mergeable as-is, and Veracode (2025) found 45% of AI-generated code failed security tests, with newer models no better at security. Jarred Sumner (Bun): "The AI writes pretty much all the code, but we have the AI write pretty much all the tests as well... You need to have a way to trust your code."
Agents struggle with system design
Single-issue vs. multi-file tasks (Claude Opus 4.6, 2026)
76%
52%
SWE-bench Verified
SWE-Bench Pro
(small fixes)
(multi-file changes)
More code, not more shipped software (autonomous coding agents, 2026)
+180%
+30%
Commits
Releases
Sources: SWE-bench Verified and SWE-Bench Pro leaderboards (mini-SWE-agent); Demirer, Musolff & Yang, “Writing Code vs. Shipping Code” (NBER, June 2026)
Same model, same harness: SWE-bench Verified issues are mostly small, single-issue fixes; SWE-Bench Pro reference solutions average 107 lines across 4.1 files. The gap has narrowed (Sept 2025: 70%+ vs. 23%), but success still drops as more files are involved. Top SWE-Bench Pro score today is about 60%.
NBER study of 100,000+ GitHub developers: with all three generations of AI tools (autocomplete, interactive agents, autonomous agents), commits rose about 180% ("roughly triples" per the VoxEU summary; the NBER abstract says 240%), projects about 50%, and releases only 30%. The authors call it the "weak-link" effect: human bottlenecks limit how much faster code becomes shipped software.
DORA: AI is an "amplifier" of an organization's existing strengths and weaknesses.
Coding agents are improving fast
2025: PRs eventually merged
Claude Code PRs
84%
Human PRs
91%
2026: PRs that qualified for merge
Codex PRs
87.5%
Human PRs
75.1%
Agents
7 pts behind
Agents
12 pts ahead
Sources: study of 567 Claude Code PRs (2025); Popescu et al. (April 2026)
The gap flipped: in 2025, agent PRs merged less often than human PRs; by 2026, one study found them qualifying for merge more often. Caveat: two different studies, agents, and repos, so compare within each pair, not across years. curl shut down its bug bounty after the share of real bugs in AI-flooded reports fell from over 15% to under 5%.
From software engineering to product engineering
More software is being built than used
iOS apps, relative to 2024 (2024 average = 100)
Code is cheap. Knowing what to build isn't.
Source: Demirer, Musolff & Yang, NBER w35275 (2026)
Let's zoom out to what software engineering really is. Economists call this the Jevons paradox: when something gets cheaper to make, people make more of it. New iOS apps went from 33-45k a month to about 108k a month by April 2026. But ratings for each month's new apps stayed roughly flat, and the share that never reach even 10 ratings rose from 78% to 87%. Either the new apps are lower quality, or attention is the bottleneck. So what's scarce? Knowing what to build.
Build software that people want
BAKERY
fresh daily
OPEN
CAKES
to order
“I need to keep track
of my orders.”
Thousands of apps fit that sentence.
The right one depends on her bakery: custom cake orders, daily pickups, regulars who call in.
Only she knows the specifics. It isn't in the training data.
Which one fits her bakery?
Source: Laurie Voss, We are all Product Engineers now
Software formalizes a human desire. Knowing what to build means knowing the person. That's why software with a zillion config options still doesn't do what you need. When everyone can build the correct thing, the delightful thing is what's left to compete on.
The software engineering lifecycle
1. Understand the problem
2. Write the spec
3. Design the system
4. Write the code
5. Write the tests
6. Review the code
7. Debug & maintain
8. Ship it
9. Scale & operate
10. User testing
Figuring out what the baker needs is step 1 of a bigger loop. Terms teachers already know: user stories, requirements, design docs, user testing.
Writing code is only one step
1. Understand the problem
2. Write the spec
3. Design the system
4. Write the code
5. Write the tests
6. Review the code
7. Debug & maintain
8. Ship it
9. Scale & operate
10. User testing
The traditional core of SWE
Traditionally, software engineering (and CS classes) centered on step 4. That's the step agents now do.
Which steps still need humans?
1. Understand the problem
2. Write the spec
3. Design the system
4. Write the code
5. Write the tests
6. Review the code
7. Debug & maintain
8. Ship it
9. Scale & operate
10. User testing
Humans most needed
Agents are weakest
Agents are getting there
Agents are next
Agents do it now
What's left is the beginning and the end of the loop: figuring out what to build, and checking that what got built is what people meant. Defining "good" is evals from section 1.
Software careers are evolving
Software engineer
writes code from tickets
now spends more time
with users
Product manager
writes specs & mockups
now also prototypes
with agents
Product engineer
figures out what to build,
then builds it
Forward deployed engineer
sits with the customer,
builds with them
Job postings up ~800% in 2025
~1,000 open roles across 462 companies, ~$240K average pay (via Voss). IBM is redesigning its entry-level role around customer contact and specification. PMs are prototyping with agents (Pragmatic Engineer). For students: a CS career looks less like "write code from a ticket" and more like "figure out what someone needs, then build it."
Now anyone can build software
Each layer lowered the barrier to building
“The hottest new programming language is English ” — Andrej Karpathy, January 2023
2020s English “Add up all the scores”
Anyone who can describe it
1990s Python total = sum(scores)
Students and hobbyists
1970s C total += scores[i];
Professional programmers
1950s Assembly ADD EAX, [EBX]
Trained specialists
1940s Machine code 00000011 00000011
A handful of experts
Each layer hides the one below and lets more people program. Same task at every level: add a score to the total. Compilers are deterministic; this new layer isn't, which is why checking the result still matters.
Not a new idea, just newly possible
2004
Clay Shirky describes situated software : built for a group of people, not millions. Too expensive to build.
2024
Maggie Appleton predicts a golden age of personal software, built by people like “teachers who make elaborate Notion spreadsheets”.
2026
Two minutes to build a sound effects app for my kids.
Personal vs. mass-market software
Mass-market software Personal software
Millions of users A few people you know
One size fits all Fits your exact needs
The company decides when it changes or shuts down You decide
Needs a team of professionals One person who knows the problem
Only the baker knows what her bakery needs. Now the baker can build it herself.
At AI-native companies, “the salespeople are shipping (at least internal tools and automations for themselves).” — Yoni Rechtman
Resolves the tension from section 2 (non-engineers still aren't shipping production code): personal software doesn't need to be production software.
Faster to build it than to find it
“I was trying to find this one website that lets my kids record audio and plays it back with funny effects. Then I realized, screw it, its faster to vibe it than to find it! Two minutes later, boom, my kids can squirrel themselves to their hearts desires.”
— @pamelafox , Sept 3, 2026
Personal software can get ambitious
A ChatGPT-style app my friend Matt and I built, so we can pay for just the tokens we use instead of a subscription.
Web search
Image and voice input
Conversation history
Token counts on every chat
mattgotteiner.github.io/responses-chat
What still takes software knowledge
Anyone can describe what they want, but building something that works well still takes software engineering skills:
Describing it precisely
Decomposition, edge cases, examples of what “good” looks like
Checking that it works
Testing, not just trying it once
Knowing what agents struggle with
Storing data, logins, deployment, security
Protecting people
A homemade tool with student data still has to follow privacy rules like FERPA
What this means for teaching CS
Skills that matter more than ever
Whether students become software engineers or build software for themselves:
Problem design
Figuring out what to build, and describing it precisely
Computational thinking
Decomposition and abstraction, to steer agents
Systems design
How the pieces fit together
Verification
Checking that it actually works
Problem design
Figuring out what to build, and describing it precisely enough that someone (or an agent) can build it.
Why
It's where humans are most needed. Only the baker knows what her bakery needs.
“Nobody teaches ‘go sit with a baker for a week and come back with a spec.’” — Laurie Voss
In class
Build for a real “client”: a teacher, a club, a family member. Interview them first.
Write the spec and examples before any code.
Hand the spec to an agent: did you get what you meant?
CSTA: 1B-AP-13, 2-AP-15, 1A-AP-12 · AP CSP Create task: describe the program's purpose
Spec quality becomes instantly visible when an agent builds exactly what you wrote. Like the How to Design Programs design recipe: purpose and examples first.
Computational thinking
Decomposition, abstraction, pattern recognition, and algorithms: still the foundation, because they're how you steer agents.
Why
Agents work best on bounded tasks. Someone has to break a big problem into agent-sized pieces.
You need to recognize when the agent's approach is wrong.
Reading code matters more than ever.
In class
Decompose a project into tasks small enough for an agent, then run them.
Predict what agent-written code will do before running it, and explain it line by line.
Open question: how much should students still write by hand to build a mental model? We still teach arithmetic, even with calculators.
Systems design
How the pieces fit together: architecture, data models, interfaces, tradeoffs.
Why
Agents are weakest here: success drops sharply as tasks span more files.
Old best practices work great with agents: design up front, build one thin working path through the whole system first, use design patterns.
In class
Draw the architecture and data model before prompting.
Review agent output for duplication and missed abstractions, then refactor.
CSTA: 3A-AP-23 (document design decisions)
GitClear: refactoring down 70%, duplicated code up 81%. The "tracer bullet" idea from The Pragmatic Programmer, via Matt Pocock on The Pragmatic Engineer podcast.
Verification
Checking that it actually works: tests, evals, security, accessibility, and whether it's what users meant.
Why
Agents pass tests but miss what makes code mergeable.
45% of AI-generated code fails security tests.
Human code review can't keep up.
Evals are how you check probabilistic software.
In class
Students write the tests (and rubrics) for agent-written code.
Bug hunts in agent-written code.
Accessibility and bias audits.
User testing with their real “client”.
CSTA: 2-AP-17, 3A-AP-19, 3A-AP-21, 3A-IC-25 · Practice P6: Testing and Refining Computational Artifacts
Judgment and collaboration
These matter even more when anyone can build anything quickly.
Judgment
Knowing when to say “hey, come on.” Should this be built at all? Is it safe, fair, and honest?
In class: Impacts of Computing; discuss when not to build something.
Communication & collaboration
Making the work understandable to others, and making a team work well together.
In class: demos, explaining design decisions, teamwork (practices P2 and P7).
Inspired by Yoni Rechtman, There will only be four jobs
You already teach this
Skill Already in the CSTA K-12 standards
Problem design 1B-AP-13: plan by considering user preferences 2-AP-15: incorporate feedback from users to meet user needs
Computational thinking P4: Developing and Using Abstractions
Systems design 3A-AP-23: document design decisions
Verification 2-AP-17: test using a range of test cases 3A-AP-21: make artifacts more usable and accessible
Judgment Impacts of Computing
Communication P2: Collaborating Around Computing · P7: Communicating About Computing
The shift is in emphasis, not a new subject: from writing the code to the steps around it.
CSTA K-12 Computer Science Standards
CS for all students
Then
CS for all, so every student could choose a career in software
→
Now
CS for all, because every student will build software
So they can build the software they need, and know enough to build it well.
The CSforALL movement matters more than ever.
This is why the CS for All movement matters even more now: the goal was never just to make every student a software engineer.
Optional: Robin Sloan, "People don't only learn to cook so they can become chefs."