Tag: coding agents

AI can shorten implementation without shortening discovery. This essay gets the center of Domain-Driven Design right: the valuable part is not a diagram, a document, or a fashionable folder structure. It is the repeated work of learning the business, naming concepts precisely, separating contexts, and turning that shared understanding into software. An agent can draft an impressive model, but the team has gained little if nobody can explain which assumptions it made or recognize when the real domain contradicts it.

The useful tension is that a domain model still needs artifacts. Code records the implemented model, tests hold selected invariants, and decision notes preserve reasons, but none of them is the whole understanding. That makes DDD more valuable and easier to counterfeit at the same time. The practical standard is not how much domain language an agent can generate. It is whether engineers and domain experts can use the same vocabulary to challenge a design, keep changes small enough to review, and notice when an apparently correct implementation solves the wrong problem.

The strongest idea here is progressive hardening. Context documents tell an agent what the team believes, review agents catch violations that still require judgment, and deterministic checks enforce rules precise enough to encode. Repeated agent findings should become tests, linters, or structural checks whenever possible. That moves common verification toward a cheaper and more reliable layer instead of celebrating an ever-larger pile of prompts and reviewers.

The risk is that the harness becomes its own source of ceremony and drift. A living specification, scheduled audit, or self-improvement loop cannot certify its own correctness, and dense terminology does not make a control effective. The useful implementation path starts with observed failures: identify a recurring defect, state the constraint, decide who has authority, measure the check's false positives, and preserve human review for consequences that remain ambiguous. A harness should make the system easier to govern. If operating the harness becomes harder than understanding the code, it has moved complexity rather than reduced it.

This is a useful operational map: the model produces outputs, the inference service runs and meters it, the harness assembles context and tools, and the complete agent system turns those pieces into behavior. The distinction matters most during diagnosis. Missing context, unavailable tools, malformed tool calls, slow inference, and weak reasoning can look like one vague "AI problem" while belonging to different owners and requiring different fixes.

The boundaries are not laws of nature. Products bundle layers, vendors reuse terms, and even experienced teams disagree about how much orchestration is required before a tool becomes an agent or a harness. So this vocabulary should be treated as a troubleshooting interface, not a universal ontology. If naming a layer helps route a defect, compare two systems fairly, or avoid replacing a model when the real problem is context assembly, it has earned its keep. If it only creates a taxonomy argument, it has become another abstraction to maintain.

Gwern's proposal is useful because it asks a sharper question than "can agents write more code?" It asks what kind of software substrate would let code, proofs, docs, tests, and design intent scale together instead of drifting apart as the system grows.

That belongs near the agent-workflow links. If code generation keeps getting cheaper, the bottleneck moves toward specification, review, interfaces, invariants, and machine-checkable confidence. Lean is not a magic management layer, but this is the right direction of pressure: make the important claims in a codebase inspectable by tools, not merely implied by convention.

This is a good small-project reality check because it treats solo development as both a creative advantage and an operational liability. You get taste, speed, ownership, and the joy of building the exact tool you wanted. You also inherit support, QA, product judgment, design blind spots, release discipline, and every future maintenance bill.

The Hacker News thread adds the useful AI-era tension: agents make the solo developer faster, but they do not magically supply a team. They can review, patch, and polish small annoyances, but they do not fully replace other humans who notice positioning, user research, burnout, sustainability, and the wrong assumptions you cannot see from inside your own project.

This is more useful than another argument about vibe coding because it is a concrete trace: notes, mockups, data modeling, scaffolding, implementation transcripts, and maintenance around Diggit, a small git-history tool for architecture archaeologists.

The point I want to keep is that good agent work still starts before the agent. Taylor narrows the problem with plaintext design, simple Elm scaffolding, explicit model shapes, fast feedback, and loud states. Claude wrote most of the code, but the product is really the constraint system around Claude.

This is a generous first-principles walkthrough of software as layered abstraction: physical switches, bits, stored programs, compilers, operating systems, networks, and finally the applications people actually touch. It belongs in the links stream because it treats software literacy as agency, not trivia.

The ending is the hook for the current AI moment. Cheaper code generation does not make the stack underneath disappear; it makes clear mental models more valuable. The person who understands the layers can direct agents, verify their output, and debug the places where the abstraction leaks.

This piece is worth saving because it is less about whether AI can write code and more about what happens when the job shifts from making the thing to supervising the thing. The strongest point is the tacit-knowledge gap: legal constraints, latency, security boundaries, roadmap context, and institutional memory are not automatically present just because a patch compiles.

The surrounding argument is the real fault line: some developers feel agents free them to operate at architecture and product scope; others feel the reps are where judgment is formed. My take is that both are true depending on the work. Delegation is leverage when the human still owns the model, constraints, and verification; it becomes skill decay when the review queue replaces the act of understanding.

This is a wonderful tiny-hardware project: a Swift-flavored language environment for the Apple II, implemented through a bytecode VM instead of pretending full modern Swift can fit on a 1 MHz 6502 with tens of kilobytes of RAM. The constraints make the engineering visible: disks, keyboard quirks, memory banking, integer-only tradeoffs, and separate tool families instead of one universal binary.

The part I want to keep near the agent-workflow notes is the process. The project worked because the AI had a human boundary around it: numbered phases, design docs, acceptance tests, and manual architectural calls. That is the healthy version of agent leverage: not autonomous magic, but fast iteration inside a context the builder keeps sharpening.

This overlaps with the coding-assistant posts on the site, but it is still worth keeping as an outside practitioner account: small steps, screenshots, AGENTS.md, undo discipline, and refactoring agent-generated blobs.

The caveat is that advice like this should become process, not vibes. If an assistant can break the project quickly, the workflow has to make rollback and review cheap.