[SF Ruby Feb'26] The Silicon Heel

Does architecture still matter when AI writes the code?

Transcript

1. "Does architecture still matter when AI writes the code?" V.Dementyev, Evil Martians THE SILICON HEEL #NotADystopia #NoVibedBS San Francisco, 2026
3. In the end, does it even matter?* * spoiler: yes, go buy the book :-)
4. Code complexity Human coordination Why we used to care about architecture
5. Complexity is redefined Teams are shrinking Expectations are rising The paradigm shifts
6. Performance Stability Feedback loop What still matters
7. Vibe-coded feature human intervention
8. Performance Stability Feedback loop What still matters
9. –My gut feeling “Architecture is the key to maintainable and high-quality generated code.”
10. Fizzy Authorization: base vs. action_policy Adding a new role: viewer The experiment Order No 2026 Add a new role: viewer. - Viewers can see accessible boards and cards on them - Viewers cannot be assigned to cards - Viewers can comment on cards but only on cards being triaged - Viewers cannot create cards or boards - Viewers has no access to other parts of the app - The restrictions hold even for user owned cards/comments Ensure there is no UI controls associated with actions not available to viewers.
12. Fizzy: authz Base Model predicates Concerns before_action guards Layered Policies authorize! / allowed_to? / authorized_scope
13. module User::Role extend ActiveSupport::Concern included do enum :role, %i[ owner admin member system ].index_by(&:itself), scopes: false end def can_change?(other) (admin? && !other.owner?) || other == self end def can_administer?(other) admin? && !other.owner? && other != self end def can_administer_board?(board) admin? || board.creator == self end def can_administer_card?(card) admin? || card.creator == self end end
14. class CardPolicy < ApplicationPolicy authorize :board, optional: true relation_scope do |scope| scope.joins(board: :accesses).where(accesses: {user_id: user.id}) end def create? allowed_to?(:show?, board) end def manage? allowed_to?(:show?, record.board) end def destroy? allowed_to?(:manage?) && (admin? || record.creator == user) end end
15. class CardsController < ApplicationController # ... private def set_board - @board = Current.user.boards.find params[:board_id] + @board = Current.account.boards.find(params[:board_id]) + authorize! @board, to: :show? end def set_card - @card = Current.user.accessible_cards.find_by!(number: params[:id]) + @card = Current.account.cards.find_by!(number: params[:id]) + authorize! @card end - def ensure_permission_to_administer_card - head :forbidden unless Current.user.can_administer_card?(@card) - end - end
16. How to compare? Bugs/gaps (stability) Tokens usage (cost) Reviewability (human-in-the-loop-ability)
17. Viewer: naïve Prompt (one-shot): "Implement the following feature..." Review with advanced skills/agents
18. Viewer: naïve Base Unprotected actions: 7 UI gaps: 3 Files changed: 52 Layered Unprotected actions: 0 UI gaps: 6 Rule bugs: 1 Files changed: 33
19. Viewer: compound Plan, work, review, repeat (Most) Bugs/gaps are identified during development https://github.com/EveryInc/compound-engineering-plugin
20. 3-phased experiment Add a viewer role Add ability to hide columns from viewers Add ability to define a minimal role to see the column
21. 3-phased experiment Files Changed 0 12.5 25 37.5 50 Base (C1) Layered (C1) Base (C2) Layered (C2) Base (C3) Layered (C3) Controllers Models Views Policies ! [Base] Scattered guards: 27 controllers with before_action :ensure_contributor — each is a maintenance point for new endpoints
22. 3-phased experiment P1 bugs 0 0.25 0.5 0.75 1 Base (C1) Layered (C1) Base (C2) Layered (C2) Base (C3) Layered (C3)
23. Layers win? Both authz architectures work well with AI Stricter separation of concerns reduces review surface significantly Without clear boundaries, bug can escape even when using smarter AI workflows Layers demonstrate stronger compounding effect
24. Tokens Measured /usage, not tokens (Max plan) Layered version spent ~10% more than base Planning and reviewing are the most consuming Skills have a room for improvement
25. Idioms, patterns, system design, and now... Skills and skills again Order No 2026
26. Idioms, patterns, system design, and now... AI orchestration patterns! Skills and skills again Order No 2026
27. Some skills Layered Rails: https://github.com/palkan/skills Inertia Rails: https://github.com/inertia-rails/skills ...more to come (from you?)
28. ▐▛███▜▌ Claude Code v2.1.47 ▝▜█████▛▘ Opus 4.6 · Claude Max ▘▘ ▝▝ /Users/vladimirdementyev/dev/fizzy
29. ▐▛███▜▌ Claude Code v2.1.47 ▝▜█████▛▘ Opus 4.6 · Claude Max ▘▘ ▝▝ /Users/vladimirdementyev/dev/fizzy > /layered-rails:analyze • I'll run a comprehensive layered architecture analysis of the Fizzy codebase. Let me start by gathering structural information and running violation detection in parallel. • 3 Explore agents finished (ctrl+o to expand) ├─ Analyze model concerns/modules · 69 tool uses · 44.7k tokens │ 㽾 Done ├─ Analyze controllers for violations · 65 tool uses · 43.7k tokens │ 㽾 Done └─ Analyze jobs and helpers · 47 tool uses · 38.1k tokens 㽾 Done • Now I have all the data needed. Here's the full analysis:
30. │ 㽾 Done └─ Analyze jobs and helpers · 47 tool uses · 38.1k tokens 㽾 Done • Now I have all the data needed. Here's the full analysis: --- Layered Architecture Analysis Summary - Overall health: Good - Layer compliance: ~90% - God object candidates: 1 (Card, via concern proliferation) - Callback concerns: 3 (minor) - Anti-patterns detected: 3 (minor) The Fizzy codebase demonstrates strong layered architecture discipline, consistent with Basecamp's "vanilla Rails" philosophy. Controllers are thin, models are rich, and side effects are well-organized. The most notable pattern is namespace-scoped concerns (e.g., Card::Closeable) rather than a flat app/models/concerns/ bag ....
32. /layered-rails:* /layered-rails:review /layered-rails:analyze:callbacks /layered-rails:analyze:gods /layered-rails:spec-test
33. Layered Design for Ruby on Rails Applications, Chapter 5, "When Rails Abstractions Are Not Enough", p.107
34. > Specification test (inferred from the implementation) describe TrelloImport do describe "#process" do context "when import succeeds" do it "sets status to processing then completed" # ✅ Domain: state transition it "records started_at and completed_at" # ✅ Domain: state tracking it "delegates to Processor" # ✅ Domain: orchestration end context "when import fails" do it "sets status to failed with error message" # ✅ Domain: state transition it "re-raises the error" # ✅ Domain: error propagation end context "when system user does not exist" do it "creates a system user on the account" # ⚠ Belongs on Account — duplicates account.system_user end end # ... end
35. > Existing Test Analysis class TrelloImportTest < ActiveSupport::TestCase test "process_later enqueues TrelloImportJob" # ✅ Domain test "process imports board from Trello JSON" # ⚠ Integration: runs full Processor, tests Processor behavior test "process imports columns from lists" # ⚠ Integration: same test "process imports cards" # ⚠ Integration: same # ... test "process sets status to failed on error" # ✅ Domain: state transition test "store_id_mapping and get_fizzy_id work correctly" # ✅ Domain: unit behavior test "accessible_to? returns true for owner"# ✅ Domain: unit behavior test "import with API credentials attempts attachment download" # ❌ Infrastructure: uses stub_request(:get, /trello\.com/) # ... end
36. Pattern-oriented architecture 2026+ Order No 2026 Idioms ! ! ! Design patterns ! ! % Architectural patterns ! % % AI orchestration patterns % % %
40. Thank you Vladimir Dementyev Evil Martians