AI
Has AI Conquered Coding? (It’s Not So Simple…)
Cal Newport (computer science professor and author) discusses a recent essay by Lars Faye, Agentic Coding Is a Trap. To validate whether Lars’ statements had merit, Cal conferred with a colleague with nearly 30 years of industry experience. This colleague made four points: (1) The tools will work faster if you’re already a highly skilled developer. (2) Context switching and attention fragmentation are a huge problem. (3) Skill atrophy is real and psychologically impacts people where coding was their source for deep work. (4) Companies are already using the misguided “token count” as a measure of productivity, and agentic AI reduces friction in the wrong places. The solution is not to outright eliminate AI: AI should come second so that you don’t sacrifice skills at the altar of productivity. If you don’t go through the uncomfortable period of learning engineering, you won’t be able to understand what the AI writes or how to fix it when it’s broken.
This essay makes some salient points about how AI is negatively impacting junior and senior developers. Even in a study by Anthropic there’s a “paradox of supervision” where orchestrators (the new role for software engineers) must be able to supervise the agents, and to do so must have enough skills. “To grow skills, people need to go through hardship.” Agentic coding can bring speed, but when forced on teams can lead to low accuracy. I appreciated the section about how some people plan and think better by working in code: “…me typing out code is the process by which I figure out what we should even be doing.” Vendor lock-in also creates issues with uptime and cost; “model providers are heavily subsidized, and the models themselves are built on shifting sands.” You know how much your employees cost; you have no idea how much your AI will cost. Lars’ workflow: (1) LLMs help with specs and plans while he codes. (2) Have LLMs turn your pseudocode into actual code. (3) Use models for researching and asking questions. (4) Don’t generate more than can be reviewed in one sitting. (5) Don’t ask LLMs to implement something you couldn’t do on your own. “Use them like the Ship’s Computer, not Data.”
This essay describes how an engineer found work he truly enjoys and why he enjoys it. The social impact — working with other humans — is something LLMs take away. “When we automate critical thinking, we begin to lose our own skills to build resilient, lasting software.”
AI in the SDLC: From experimentation to real-life delivery impact
- Most enterprises are somewhere between individual AI augmentation and team AI augmentation. (The desired end state is agentic delivery.)
- Solution: shared context, governance & rules, experts in the loop
- Shared context (what we know)
- Current understanding of the system (product intent, domain rules, tech constraints)
- Explicit decisions, assumptions, and standards
- Actively maintained
- Lives in repos (code, specs, ADRs, READMEs), work management tools, and design & architecture artifacts
- Reduces ambiguity, enables consistent decisions over time and across functional boundaries
- AI helps you keep context up to date, plus you’re incentivized to do so
- Repo location is
/context. Put things like technical and product specs, target user info, product overview there. - Governance and rules for enabling consistent delivery (how we operate)
- Rules for how AI is allowed to operate
- Standards, patterns, and constraints that guide execution
- Clear boundaries for safety, security, and architecture
- Lives in skills, rules, system instructions, coding standards, templates, CI/CD checks, policies, and automated reviews
- Encodes expert expectations into the system
- Removed ambiguity before AI runs, which reduces hallucination/improvisation by AI
- Enables scale without loss of control
- Aligns AI with org intent
- Experts in the loop
- Explicit points where experts review/approve work
- Clear ownership of decisions, trade-offs, risks
- Experts guide direction, AI executes tasks
- Lives in reviews of specs/designs/requirements, PR and code review workflows, approval gates
- Preserves human judgment in critical decisions
- Prevents silent failures and unchecked automation
- Keeps accountability clear as AI use grows
- Builds trust in AI-enabled delivery
- Phase 1 of 5: requirements definition
- Product needs to use AI or else they become the new bottleneck
- Spend more time on the strategy and review parts, otherwise you end up going fast in the wrong direction
- Make strategy friendly for AI to consume
- Demo: create a story in GH, have Claude refine it (from a template) via Slack.
- Phase 2 of 5: tech spec creation.
- Spec-driven design (which is basically behavior-driven design)
- Lives in
/specs
- Phase 3 of 5: implementation. (Give the spec to the LLM.)
- Phase 4 of 5: validation and test generation (generate test cases, analyze for edge cases, run tests)
- Phase 5 of 5: context lifecycle (update context docs for the next round)
- Note: Agents used in the demo… commit, context manager, developer, product, skill governance, spec architect, testing
How To Save 90% of Claude Code Token Usage
- Strategy 1: Index the code to stop AI from reading things it doesn’t need. https://github.com/colbymchenry/codegraph builds the graph, and you can tell AI how to use the query tool. This allows AI to use semantics to search instead of raw file parsing. Issues:
- Two sources of truth: your codebase, the index
- Need to keep the graph in sync with your code
- It can miss a module’s CLAUDE.md
- Strategy 2: Compress the output. Tool output and log files are generally noisy. For example, AI doesn’t need to know all of the tests that pass, just that all the test passed. https://github.com/rtk-ai/rtk Issue: less accurate because of lossy compression. Know when to turn it on/off.
- Strategy 3: Use “caveman” to get AI to talk less. https://github.com/juliusbrussee/caveman. This is a skill that sets your Claude Code session into a specific mode. Issue: correctness is at risk, because of compression (and Claude missing out on high-quality responses in the context window).
- Strategy 4: manage your sessions properly
- Clear context between unrelated tasks.
- Sonnet by default. Opus for really hard work (planning, deep-dives). Haiku for grunt work (e.g., browser manipulation).
- Prefer CLI tools
- Use plan mode first, and agree on a plan before working to eliminate rework.
- Keep CLAUDE.md < 200 lines. Move workflow detail into on-demand skills.
Software Engineering
Modern Software Engineering by David Farley
- Software engineering is about learning and managing complexity.
- Learning: iteration, feedback, incrementalism, experimentation, empiricism
- Managing complexity: modularity, cohesion, separation of concerns, abstraction, loose coupling
- Stability and throughput are important properties.
- Work in ways that leave the door open to us making a mistake and being able to correct it; deepening our understanding of the problem we face and reflecting on our new understanding in our design.
- Strive to have systems that are both testable and deployable.
- Production is not our problem, because the process of delivering bits is well known and fairly cheap. Ours is a discipline of design engineering.
- We have a duty of care to do a good job and understand what it takes to develop software.
- Anyone can write code; that’s not our job. Our job is to solve problems, and that requires us to take care in our design and consider the effectiveness of the solutions we produce.
- It’s not “A is bad” and “B is the only way”; but we prefer something close to B. For example, you can have concerns so separated that the system is hard to understand; however, aim for separation of concerns.
- Readability is a fundamental property of good code.