Frequently asked questions

Microservices can work. They're just not where most teams should start anymore. Most systems don't need independent scaling for every component. They don't need polyglot runtime freedom or hard failure isolation at the service boundary. A modular monolith or universal-interface approach gets you faster delivery, simpler operations, tighter governance. And you can still extract services later when you have data proving you need to.

Both support local serving, but practicality differs. GLM-5.1 is tuned for local deployment and lists support via SGLang, vLLM, xLLM, Transformers, and KTransformers — it's the more obvious choice if self-hosting is the goal. Kimi K2.6 supports vLLM, SGLang, and KTransformers too, but its 1T-parameter MoE size means most users run it through Moonshot's stack or a serious inference cluster rather than on a laptop. Weights being open doesn't mean serving is free: you trade token bills for infra, latency, monitoring, and maintenance.

Yes. The architecture works with any serverless platform that supports HTTP endpoints and scheduled functions. Modal was chosen for its Python-native developer experience and one-command deployment, but Lambda with API Gateway or Vercel serverless functions would work with the same pipeline logic.

Yes. As of February 2026, the gap has closed dramatically. GLM-5 (open source, MIT license) scores 77.8% on SWE-bench versus Opus 4.6's 79.4%. Kimi K2.5 scores 76.8% with unique agent swarm capabilities. Open-source models now offer comparable coding performance with added benefits of self-hosting, fine-tuning on proprietary codebases, and no vendor lock-in.

Developers write less code from scratch and spend more time prompting, reading diffs, and checking output. Senior engineers move toward system design and requirements. Junior engineers can ship faster, but blindly accepting suggestions builds bad habits fast. The tool changes the workflow. It doesn't take ownership of the result.

Diagram with User (API call) to console (front-end) which calls back-end service connected to DB. Hosted on AWS, chosen just because its 30% of the market. !PlantUML sequence diagram showing user to API to database service communication on AWS

Laptop via SSH is the safest option. Agent stays local, connects to servers over SSH. Credentials stay off servers, works across machines, fewer dependencies to manage. Use SSH config names and separate keys for automation. A server container setup runs the agent as a Compose service. Easy to replicate, keeps runtime isolated. Mount only the stack directory and Docker socket. Treat socket access as root-equivalent because it basically is.

Treat the platform like a product. Give it owners, access rules, environments, versioning, logs, tests, and a path to custom code. Pair domain experts with engineers early. Otherwise the company gets shadow IT with nicer drag-and-drop boxes.

Before getting into workflows, there are three concepts that govern how every AI tool works. Worth understanding even if you never build an agent yourself. It knows only what you give it right now It doesn't remember past sessions or decisions It repeats mistakes unless rules live in files

AI tools generate code that works but doesn't carry intent. Each session makes independent architectural choices based on whatever context is available that day. Without explicit constraints, reviewers approve working code without catching style deviations, and the next AI session reads those merged patterns as precedent. Over weeks, this compounds into multiple conflicting patterns for the same operations — error handling, data validation, API formatting — that nobody deliberately chose.

They make the routing argument stronger. DeepSeek V4-Pro adds a 1M-context, MIT-licensed open-weight option at $1.74 input / $3.48 output per 1M tokens on OpenRouter, with strong SWE Verified and Terminal-Bench signals. GPT-5.5 pushes the closed frontier price ceiling to $5 input / $30 output per 1M tokens when API access opens. That doesn't make either one the automatic winner. It means teams need to test price, review burden, context behavior, and workflow fit together.

Start with the simplest code possible and only refactor toward a pattern when friction repeats. If you can't explain the pattern to a junior developer in two minutes, it's too complex. Prefer composition over inheritance and let patterns emerge through refactoring.

Define your task clearly, assess its complexity (low, medium, or high), choose an approach (automation, AI workflow, or agent), then test 2-3 candidate models on real examples from your use case. Start with the smallest model that might work and scale up only if needed.

Evaluate four factors: volume (50+ daily repetitions is a strong candidate), complexity (3-5 decision branches works well, 10+ usually doesn't), error cost (low-stakes tasks first — a misrouted appointment is minor, a botched quote commits you to unprofitable work), and integration depth (1-2 systems is straightforward, 5+ is a fundamentally different project). If most factors land favorable, you have a strong automation candidate.

Use the formula: Batch Size <= (Lambda timeout * 0.8) / p95 per-message processing time. The 0.8 factor provides a 20% safety margin, and using p95 instead of average prevents skew from outlier messages.

Store an idempotency key (preferably a business key like order_id, or the SQS MessageId) in DynamoDB before processing. Check for the key at the start of each handler invocation and skip duplicates. AWS Lambda Powertools also provides a built-in idempotency decorator.

Check what's already there. You might already have the index you need, or close enough. sql SELECT indexname, indexdef FROM pgindexes WHERE schemaname = 'public' AND tablename = 'orders'; I've found redundant indexes more than once. Like (userid, createdat) and (userid). The second one is wasting space.

Use remote state storage (like S3) with locking (like DynamoDB) to prevent concurrent modifications. Encrypt state files since they contain secrets, restrict access, and maintain separate state files per environment (dev, staging, prod). Never use local state files in a team setting.

Add three questions to standard code review: Can a teammate who didn't write this explain the approach in 60 seconds? Does it follow your team's blessed patterns or introduce a new one? If you deleted it and asked a different AI to rebuild from the same spec, would the structure be similar? These add about 5 minutes per review and catch drift that standard 'does it work' review misses.

Watch for hallucinated imports that don't exist in your codebase, confident logic errors in edge cases, unnecessary abstractions you didn't ask for, silent behavior changes to function signatures or defaults, and stale context artifacts. If a diff looks right but you can't explain why, slow down and read line by line.

MCP uses a default-deny, least-privilege model where you explicitly grant capabilities rather than restrict them. Tools have typed input/output schemas with JSON Schema validation, auth scopes, and a side_effects boolean that tells the client when to ask for user confirmation before executing.

Terraform models infrastructure as a dependency graph using HCL (HashiCorp Configuration Language). You describe the desired state of your resources, run 'terraform plan' to see exactly what will change, and run 'terraform apply' to execute. It works with AWS, GCP, Azure, and thousands of other providers.

Agent harnesses are the operating environment around a model: instructions, tools, permissions, memory, verification, and handoff notes. Tests, types, module boundaries, naming conventions, stable interfaces, and PR expectations are all harness. A short repo-level file that tells the agent how to build, test, and avoid dumb mistakes is harness.

No code. No manual steps after setup. Here's every piece working together. Step 1: Potential client fills out a Tally form. Name, email, company, what they need. Step 2: Make.com fires. Creates a ClickUp task with the lead's info, tags them as a new lead, creates a deal in your pipeline view.

Every proposal I sent used to start with the same Word doc. I'd open the template, swap out the client name, rewrite the problem statements, adjust the solutions section, fix the formatting that broke somewhere in the middle, export to PDF, and send it. This took 30-60 minutes per proposal, and every one looked slightly different because I was editing a living document instead of generating from a clean source.

Someone fills out your contact form. The submission sits in your email. You see it that afternoon. Or the next morning. Or Monday. You reply with "Thanks for reaching out, let me know a good time to chat." Three days have passed. They've already talked to two competitors.

I used to spend hours writing boilerplate code. Now, the AI does that in seconds. My job has shifted from typing code to reviewing code. The catch: AI writes code that looks right but often fails in subtle, stupid ways. It introduces security holes with total confidence.

Taste is what happens when System 2 thinking — slow, deliberate, conscious — runs so often on the same kind of decision that it drops into System 1. The choice stops being conscious. You just know.

Most small business automations pay for themselves in 1-3 months. A $50/month DIY automation saving 3 hours per week at $35/hour saves $455/month — immediate payback. A $3,000 custom build saving 8 hours per week at $40/hour saves $1,280/month and pays back in about 2.5 months. After the payback period, every month is pure margin.

The sweet spot is 250-500 tokens. Keep instructions concise to avoid prompt length drift, but don't skip examples — they matter more than extra explanation for guiding model output.

Teams that implement cost-based routing typically report 30-50% reduction in LLM spend. The math is straightforward: routing a classification task from Opus to Sonnet saves 40% on both input and output tokens. Routing it to Haiku saves 80%. Most production LLM traffic is simpler than people assume — classification, extraction, formatting, short summarization — and runs fine on cheaper models. The savings compound when you realize most teams are sending all of that traffic to their most expensive model by default.

Off-the-shelf tools like Bland AI, Vapi, or Smith.ai run $200-500/month for standard scheduling, FAQ, and call routing. Platform-plus-customization using n8n or Make costs $1,000-5,000 setup plus $50-200/month ongoing. Custom implementations for complex multi-system integrations run $15,000-50,000+. But add hidden costs: integration maintenance (2-3 hours/month), staff retraining, and weekly failure monitoring. A $300/month voice AI platform costs closer to $500-800/month in total loaded cost.

Three tiers: DIY with existing tools costs $0-50/month plus 2-10 hours setup time. Serious automation with Zapier Pro ($20-70/month), Make.com Pro ($9-16/month), or self-hosted n8n ($5-20/month for the server) runs $50-300/month total with 10-20 hours of setup. Custom-built automation designed for your specific workflows costs $2,000-10,000 one-time plus $50-200/month ongoing. Most businesses should start at Tier 1 or 2.

$0 per month at beta volume. Modal's free tier covers hundreds of webhook calls, Resend allows 3,000 emails per month, Tally is free for unlimited submissions, and Google Sheets is free. You only hit paid tiers if you're processing thousands of signups per month.

Pick skills that connect to work you're already doing. Learn enough to build something real, then decide whether the subject deserves more depth. Collecting tutorials feels productive, but a working system exposes gaps much faster.

Your answers Your level ------ 4-5 A's Level 1 — Individual experimentation, no foundation Mostly A's and B's Level 2 — Foundation exists, standardization starting Mostly B's and C's Level 3 — Convention-driven workflows, measured ROI 4-5 C's Level 4 — Multi-team adoption, architectural integration

Agents are only as useful as the context you give them. The operational problem isn't which agent to use. It's how you make an agent understand your project, your conventions, your history, without pasting the same background into every session.

Circuit breakers trip when error rates for a dependency spike, temporarily stopping requests to give the failing service time to recover. Combine them with bulkheads to isolate resource pools per dependency so one failure doesn't cascade across your entire system.

Introduce patterns iteratively: write a failing test for the new requirement, extract a seam around the unstable behavior, apply the pattern at the seam, rename for clarity, and delete dead code. This keeps changes localized and avoids risky rewrites.

Treat benchmarks as a starting filter to identify which models are worth testing, not as a final decision. A model can top one benchmark and rank fifth on another. Always test candidates on 50 or more examples from your actual use case and measure quality, cost, and latency.

You check your invoicing tool every few days. Two clients haven't paid. You draft an email that's professional but firm but not too firm. You send it. You feel weird about it. Check again next week. Meanwhile your accounts receivable ages. Cash flow tightens. You're giving clients interest-free loans because asking for money feels uncomfortable.

Start with read-only tools like search or retrieval to prove the integration model is safe. Then wrap existing services with MCP interfaces. Only add side-effecting tools like ticket creation or deployments after read-only flows are tested, and include dry-run modes with approval gates for destructive actions.

The best operators I've worked with see anomalies before their users notice anything's wrong. That requires multiple vantage points and clear, non-noisy signals. It also requires someone looking at those signals, but that's a staffing conversation.

They should get more specific. Keep the lessons that still show up in real work, drop the ones that only sound good, and add examples from new mistakes. A living notebook is useful because it can admit when an old rule stopped working.

Treat prompts like code: use version control, run code reviews, test with real data, log prompts, responses, token counts, latencies, and errors. Have deterministic fallbacks for when the model fails, and use cheaper models with tighter prompts for high-volume workloads.

Here's the test. I wrote one ~300-word section about the "delegate, review, own" model emerging in AI-assisted teams. Then I processed it four ways. The section covers the same insight. The treatments change how it reads. No post-processing. This is what the agent produces with just the writing patterns as context.

A framework helps humans assemble agents. LangGraph, LangChain, and similar tools give you abstractions: graphs, state, nodes, retrievers, tool bindings, memory options, middleware, and routing. You can use those pieces to build a harness. But the framework itself is not automatically the harness.

Only for high-stakes work. Opus 4.7 costs $5 input / $25 output per 1M tokens — roughly 3.6x more on input and 5.7x more on output than GLM-5.1. It earns that premium on architecture decisions, security-sensitive review, multi-file refactors with subtle system boundaries, and failure analysis where the obvious fix already failed. For routine refactors, test scaffolding, or boilerplate, it's wasted spend.

GLM-5 scores 77.8% on SWE-bench Verified compared to Opus 4.6's 79.4%, a gap of just 1.6 percentage points. At roughly $0.11 per million input tokens versus Opus's $5.00, GLM-5 delivers comparable coding performance at about 1/45th the cost. The tradeoff is that Opus has deeper reasoning chains and Agent Teams for complex multi-step tasks.

Use an existing tool. LiteLLM in proxy mode is open source, supports 100+ providers through a unified API, and handles cost tracking, fallback, and rate limiting out of the box. Building a custom routing layer is almost never justified — routing models by task complexity is a configuration problem, not a software engineering problem. SaaS alternatives like Portkey and Helicone exist if you don't want to run the proxy yourself, but the per-request pricing adds up at scale.

Multiple. Smart teams route simple tasks like formatting and boilerplate to cheap models like Haiku or GLM-5, medium tasks to Codex 5.3 or Sonnet, and complex architecture work to Opus 4.6. Tools like Claude Code, Cursor, and Continue all support model switching. Teams using this approach typically spend 5-10x less than teams running everything through a single frontier model.

Route between multiple. The best teams don't standardize on one model — they standardize on an evaluation loop. Use GLM-5.1 or Kimi K2.6 for routine refactors, test scaffolding, and first-pass implementation. Escalate to Claude Opus 4.7 only for architecture review, hard debugging, security-sensitive changes, and final review before risky merges. Pick the cheapest model that handles the task; escalate when a wrong answer is expensive.

Boilerplate and scaffolding -- CRUD endpoints, data models, CLI skeletons, pipelines, config. Tests, fixtures, and CI skeletons so you don't start from a blank page. Translation and refactoring -- port patterns across languages or frameworks. Surgical refactors: extract functions, tighten types, simplify conditionals. Test-first workflows -- propose unit tests before implementation. Property-based and edge-case tests that humans often forget. Search and comprehension -- answer "where is this used?

Avoid overbroad capabilities by splitting tools by action and resource instead of building 'do everything' servers. Don't inline massive data in responses — use streaming with explicit limits. Always pin tool contracts to documented invariants so prompts don't break when implementations change.

Avoid conflicting instructions like 'detailed summary,' vague output formats, missing context, no role assignment, and ambiguous language. These lead to inconsistent and unreliable outputs. Be explicit about everything — the model should never have to guess what you want.

SLIs (Service Level Indicators) measure what users feel, such as availability and latency. SLOs (Service Level Objectives) set targets with time windows. Error budgets represent the allowed failure you can spend on change — when you burn through your budget, you slow down releases to protect reliability.

Use remote state with locking (S3 + DynamoDB for AWS), keep stacks small and focused, write reusable modules for repeated patterns, review infrastructure changes via pull requests with plan output included, run Terraform in CI, pin provider versions, and never commit secrets to your repo.

The top four coding models as of February 2026 are Claude Opus 4.6 (79.4% SWE-bench, best for complex reasoning), Codex 5.3 (77.3% Terminal-Bench leader, best for fast iteration), GLM-5 (77.8% SWE-bench, MIT license, 45x cheaper than Opus), and Kimi K2.5 (76.8% SWE-bench, agent swarm architecture with 100 parallel sub-agents).

MCP organizes capabilities into four categories: Tools (typed functions with explicit side-effects like 'create_ticket'), Resources (read-only context like documents or URIs), Prompts (parameterized reusable templates), and Sessions (scoped interactions with time limits, budgets, and capability restrictions).

The five core responsibilities are: hands-on fluency with AI tools, setting higher output expectations, managing API budget and token consumption, maintaining precise goal clarity, and creating synchronization forcing functions to prevent coherence drift in parallel agent work.

Start with clear service boundaries mapped to business capabilities, design for failure with timeouts, circuit breakers, and bulkheads, choose consistency levels deliberately, and treat observability as a design constraint with SLIs, SLOs, and error budgets.

AI code review isn't one thing. There are three distinct approaches, each with different tradeoffs. Most teams end up using a combination. Approach 1: Local AI Reviewer (Skill or Sub-Agent) The simplest entry point. You're using Claude Code or a similar agentic tool, and you invoke a review agent directly.

Plain text that diffs cleanly, which makes pull request reviews straightforward. Full version control and change management out of the box — history, blame, and rollback all just work. LLMs and scripts can modify, generate, or interpret them. Fits naturally into "docs‑as‑code."

Generic AI advice assumes one monolithic session that handles everything. I use specialized agents instead. Each agent is a markdown file with a YAML frontmatter header. Claude Code reads these at startup and surfaces them as delegatable sub-agents within any session. Here's the real definition for my code reviewer:

A good structured output starts before prompting. You design the shape you want, then you teach the model to fill it. Define a schema that matches the job Keep schemas small and purposeful. Each field should drive a decision, a join, or a stored artifact. This reduces "creative" values like "Billing Issue (urgent)". Min and max lengths for strings Regex patterns for IDs Numeric bounds for scores Maximum array sizes to control payload bloat If a field supports a join, constrain it heavily.

Most terminal agents need the same building blocks. Command execution with guardrails. Dry-run mode, confirmation steps for risky operations (rm, mv, firewall changes), command/path restrictions, execution logs. File reads and edits. The agent reads compose.yaml, .env, Nginx configs, proposes patches, applies edits with a diff you can review. Productivity spikes here.

AI went from an occasional tool to part of the daily workflow, the job market got rougher, and old career advice stopped feeling reliable. The lessons shifted toward judgment: choosing where to go deep, knowing what to ignore, and staying useful while the tools keep moving.

Think of the old ChatGPT as a librarian. You ask a question, it gives an answer. Useful, but passive. You give it a goal—"Update the documentation for this API"—and it figures out the steps. It might check the code, write the draft, verify the links, and then ask you for approval. A shift from "calculator" to "collaborator."

Avoid letting people make manual console changes that drift from your Terraform code, putting all resources in one massive state file, using overly clever loops that become unreadable, not pinning provider versions (which can cause unexpected resource recreation), and giving Terraform overly broad IAM permissions.

Every CRM integration falls into one of these buckets: Native integrations: built into the CRM or vendor marketplace. Connector tools: Zapier, Make, and similar platforms. Webhooks and email parsing: “send data when X happens.” File-based: CSV imports, scheduled exports, and SFTP.

A BGP anomaly is any unexpected condition that affects reachability, path selection, or propagation scope. Could be accidental (most common), benign (sometimes), or malicious (rare but memorable). The useful test is user impact. You can have technically "correct" BGP behavior that still makes your application slow or unreachable. I think about this in two layers:

A prompt helps the agent complete a task. A skill preserves a decision you don't want to make again. That distinction matters because reusable instructions sound more valuable than they often are. The moment a useful prompt works once, the temptation is to package it, name it, and add it to the library. But one successful run proves almost nothing. You haven't seen where the instructions break, whether the trigger is clear, or if the behavior will matter again.

The agent isn't working from a blank prompt. It's operating inside a system I've been building for two months. Component What It Provides Count --------- CLAUDE.md Operating manual: folder structure, conventions, workflows, rules, no-fabrication policy 1 file, ~400 lines VAULT-INDEX.

The content-reviewer agent scored this draft 7/10. Here's what it flagged. Strongest areas: Pillar alignment (9/10, direct hit on "AI Agents in Practice"), structure (8/10), and the unique concept. The reviewer noted the production prompt as "the strongest transparency move" and flagged the sensitivity-as-variable finding in Block B as the most actionable insight.

Taste is lived judgment — the ability to make the right small call fast. It's a moat because it's earned through years of doing, not inferred from reading, so it can't be copied the way output can.

If you're going the DIY route, here's the blueprint. Good starter jobs: Summarize the PR in 5 sentences List the top 5 risk areas with reasons Suggest missing tests with concrete cases "Review this code for any issues" is too vague. The narrower the job, the easier it is to measure quality and improve.

1. Define the problem. Not "refactor this service" but "extract the notification logic from the monolith into a standalone service with these specific interfaces, these error handling patterns, and these test requirements." 2. Decompose into agent-sized tasks. Each task should be completable by a single agent in a single session without losing context. If the task requires remembering too much, it's too big.

Every agent workflow (Claude, Copilot, Gemini, custom CLI tools) follows the same five steps. I call this PTMRO: Planning → Tools → Memory → Reflection → Orchestration Step What It Does ------ Planning Define the task, scope, and constraints Tools Select models, agents, or integrations Memory Track context, history, and state across steps Reflection Evaluate outputs, detect errors, learn patterns Orchestration Coordinate multiple agents, manage parallel execution, ensure completion

A structured output is an LLM response that follows: A known format, like JSON A schema, like JSON Schema or a typed class A constrained set of values, like enums A validation contract, enforced in code You usually want all four. Common structured formats Teams pick formats based on where the data lands. It maps cleanly to objects, arrays, and strings. It also fits schema tooling across languages.

Five questions. Pick the answer closest to your team's current state. Count your A's, B's, and C's. 1. How does your team evaluate AI output quality? A. Each person decides for themselves. If it passes the sniff test, it ships. B. Output review catches AI slop, but it's the same slop repeating across workflows. C. Output reviews flag AI-specific failure modes, and convention files killed the most common ones before they ever reached a human reviewer.

Adopt assistants like you'd adopt any production-impacting tool: with a plan. 1. Define allowed use cases. Safe: documentation, tests, small refactors, scaffolding, example code. Caution: security-critical paths, cryptography, auth flows, billing logic. 2. Enforce least privilege. Read-only repo access by default; opt-in write permissions in sandboxes. Ephemeral credentials for any runtime tooling the assistant can invoke. 3. Keep secrets out of prompts. Redact keys, tokens, and customer data. 4. 5. 6. 7.

New client signs on. Two things need to happen: a welcome email with next steps and a calendar link, and a ClickUp task so the engagement doesn't vanish. Before this, I wrote each welcome email from scratch. Sometimes the tone was off. Sometimes I forgot the calendar link. Sometimes I'd send it an hour after signing. Sometimes a full day passed. For someone selling automation services, that gap between what I sold and how I operated was becoming noticeable.

The dedup check reads the entire sheet on every webhook call, which slows down around 500 rows. At that point, migrate the lead log to Postgres or Airtable with proper indexing. The rest of the pipeline (emails, webhook, cron) stays the same.

CLAUDE.md is a project context file that loads automatically at the start of every Claude Code session. It should include your project structure, build and test commands, naming conventions, things the agent should never do, and the reasoning behind constraints so the agent can generalize beyond specific rules.

Agentic engineering is a different mental model. In vibe coding, the human writes a prompt and the AI generates code. The human is the typist and the AI is the tool. In agentic engineering, the human architects a system and the agents plan, execute, and iterate on their own. The human is the governor. The AI is the workforce.

It automatically splits a failed batch in half and retries each half separately, continuing to bisect until the poison pill message is isolated. Enable it alongside ReportBatchItemFailures to prevent a single bad message from blocking an entire batch.

Context engineering is the practice of deliberately shaping what an AI agent knows before it starts working. It includes writing project context files (like CLAUDE.md or .cursorrules), scoping conversations to single tasks, using plan mode, encoding repeatable workflows as skills, and delegating subtasks to subagents.

Few-shot prompting means including one or more examples of the desired input and output in your prompt. It anchors the model's behavior more effectively than lengthy explanations and helps produce consistent, correctly formatted responses across runs.

Infrastructure as Code (IaC) defines your cloud infrastructure in text files instead of manual console clicks. It lets you preview changes before applying them, track who changed what via git history, recreate entire environments from scratch, and revert broken changes by reverting a commit.

n8n uses a visual node editor. Each node does something: fetch from an API, transform data, send a webhook. You wire them together. Need custom logic? Drop in JavaScript. Want to run it on your laptop? Fine. Kubernetes? Also fine. Everything's transparent—you can see executions, inspect payloads, trace what failed.

Plan mode tells the AI agent to research your codebase, map dependencies, and present an implementation plan before writing any code. Reviewing a plan for five minutes can save hours of debugging by catching architectural risks and edge cases before implementation begins.

ReportBatchItemFailures lets your Lambda return only the IDs of failed messages instead of failing the entire batch. If 1 out of 10 messages fails, only that 1 is retried, avoiding unnecessary reprocessing of successful messages.

SWE-bench Verified tests AI models on real-world bug fixing in open-source repositories, measuring actual software engineering capability rather than isolated algorithm puzzles. It is considered the gold standard benchmark for evaluating coding ability in AI models.

The Adapter pattern wraps external APIs behind a stable interface your code controls. This protects your business logic from third-party SDK changes and gives you a clean boundary for testing with mocks.

As of April 2026, it depends on the workflow. GLM-5.1 is the best open-weight choice for long-running coding agents, privacy-sensitive codebases, and high-volume routine engineering — it's MIT-licensed with local serving via SGLang, vLLM, xLLM, Transformers, or KTransformers. Kimi K2.6 is the better first test for visual, frontend, or design-to-code work given its 400M vision encoder and agent-swarm architecture (300 sub-agents, 4,000 coordinated steps).

There's a subtler problem that doesn't show up in any of the studies. Because coding delivery sped up, more features feel feasible. A feature that would have taken two sprints now looks like a long afternoon, and that changes the calculus on whether it's worth building.

GLM-5 at approximately $0.11 per million input tokens offers frontier-tier coding capability under an MIT license. It scores 77.8% on SWE-bench Verified, within 1.6 points of the top proprietary model. It is also self-hostable, making it the most cost-effective option for teams with high-volume coding tasks or privacy requirements.

People blur these words together, so separate them first. Term Plain-English meaning Example --------- Model The brain that predicts, reasons, and writes Claude, GPT, Gemini Agent The model plus a loop that lets it take actions Claude Code fixing a bug Harness The system around the agent that guides and checks the work Instructions, tools, memory, tests, hooks Tool Something the agent can use Shell, browser, file search, calculator, MCP server Memory Context that survives beyond one prompt CLAUDE.md, AGENTS.

Traditional assistants like autocomplete and chat work from fragments or partial views of your code. Agentic tools like Claude Code, Cursor agent mode, and Codex CLI operate inside your environment with direct access to your file system, shell, git, and test runners, allowing them to read, write, execute, and iterate autonomously.

Automation is rule-based and deterministic with no AI involved. AI workflows use LLMs for specific steps with human review and approval in the loop. AI agents operate autonomously across multiple steps, planning, using tools, and self-correcting with minimal human intervention.

If you didn't read the original, the shape is three layers with a clean separation between them: Directive. Plain-language instructions in markdown. Goals, inputs, expected outputs, edge cases. What should happen. Orchestration. The control plane. Reads directives, routes work, manages errors and state. When and how. Execution. Deterministic code doing the actual work. API calls, file ops, data processing. The part you don't trust the model to improvise.

Follow this order: Context, Instructions, Output format, Rules, then Examples. Assign the model a role (who), give it a goal (what), provide all relevant context, define the output format explicitly, and optionally let it ask clarifying questions before answering.

MCP is an application-layer protocol that standardizes how AI systems discover tools, read resources, and invoke actions. It provides typed interfaces, capability security, and observability so you can write one server and serve multiple AI clients without building custom adapters for each integration.

Observer lets one action trigger multiple side effects (analytics, notifications, audit logs) without bloating the original function. It keeps your core logic small, allows new subscribers to be added independently, and forms the basis of event-driven architectures.

Models recall information near the beginning and end of their context window better than material buried in the middle. The practical implication: your most important instructions — naming conventions, anti-patterns, what to never modify — belong at the top of your config files, not buried in section 7 after a wall of boilerplate. Instructions at line 300 of a bloated CLAUDE.md are functionally invisible no matter how well-written they are.

The saga pattern breaks distributed workflows into small compensatable steps. If a later step fails, previous steps can be undone with compensating actions instead of leaving data half-committed. Use it for multi-service transactions where a traditional distributed lock is impractical.

The supervision gap is the mismatch between AI-accelerated code generation and the roughly constant time required to review, understand, and validate that code. Pull requests are up 20% year over year while incidents per PR are up 23.5%, indicating review capacity hasn't scaled with generation capacity.

VACUUM cleans up dead rows. After big deletes or updates, autovacuum might lag. Run it manually. ANALYZE updates stats. Do this after bulk inserts or when data distribution changes a lot. Otherwise the planner makes bad guesses. VACUUM FULL rewrites the entire table and locks it. Only do this during maintenance windows when bloat is bad.

A skill that survives repeated use needs four parts: !The anatomy of a skill that holds: a scoped trigger, role and authority, positive instructions, and hard stops A scoped trigger tells the agent exactly when to load it. "When I say wrap up this session" is useful. "For maintenance" is vague enough to fire at the wrong time or never fire at all.

I've seen workflows break in creative ways. Here's what prevents fires. Make every workflow idempotent. Use external IDs and upserts — if your workflow runs twice, nothing breaks. Add retries with exponential backoff so you don't hammer a service that's already struggling. And paginate. Don't pull 10,000 records in one request.

You are a session-maintenance agent for this vault. You record what changed and keep the navigation layer current. You don't write or edit the content.

I used to spend 30 minutes every morning scanning Hacker News, Reddit, and GitHub Trending. Some mornings I'd skip it. Then I'd miss a trend for a week and watch others publish about it first. The inconsistency was a problem. I needed something that ran whether I remembered to or not.

Treat Docker socket access like root. An agent with socket access can mount the host filesystem into a container and do basically anything. Use a workspace directory. Decide where the agent operates. Mount that directory. Keep other stuff out. This also makes your homelab reproducible. Back up the workspace, clone to a new host, automation still works.

Licenses are being activated and developers using the tools however they figured out on their own. There are no convention files in the repo or shared patterns. Two employees on the same team prompt Claude Code completely differently, and neither is wrong, but neither is shared. Most teams are here right now, and most of them think they're at Level 2. The output variance you're seeing is baked in.

A CLAUDE.md should act as a navigation layer, not a README. It should give the AI a project overview, folder map, tech stack, naming conventions, an explicit list of files/folders to never touch, and anti-patterns to avoid. Keep it lean — move subdirectory-specific rules into CLAUDE.md files within those subdirectories. A monolithic 800-line root file is context bloat with a reading time penalty every session.

Start with appointment scheduling and confirmations — high volume, low complexity, minimal error cost. FAQ and service inquiry responses are close seconds (the same 15 questions make up most inbound calls). After-hours call routing and review request follow-ups round out Tier 1. Avoid automating complaint handling, emergency triage, or complex quoting until simpler automations are running smoothly and your team trusts the system.

A new client signs. You send a welcome email. Create a project folder. Add them to your PM tool. Share a Google Drive. Schedule a kickoff call. Set up their portal login. Except sometimes you forget the Drive folder. The kickoff email goes out three days late. You realize midway through the first deliverable that nobody sent the intake questionnaire.

Design, verification, security, and the final judgment call stay with the developer. Keep AI-generated diffs small, require tests, and review critical paths with two humans. If nobody on the team can explain the generated code, the team doesn't own it yet.

Four categories: blessed patterns (your team's specific approaches to errors, endpoints, naming, file organization), explicit anti-patterns (what the AI should never do — no raw SQL, no default exports, no new utility files without checking if one exists), exclusion zones (files and directories the AI shouldn't modify like generated code and migrations), and architectural decisions with reasoning (ADRs that prevent the AI from 'improving' intentional design choices). Anti-patterns matter most because AI tools don't know your history of past mistakes.

Keep performance-sensitive systems, complicated domain logic, and work that needs tight testing or portability in code. Visual builders hide implementation details, which is convenient until you need to debug an N+1 query or leave the vendor. Every no-code system needs an escape hatch.

The visibility timeout should be at least 6 times the Lambda timeout. This covers retries, cold starts, and jitter, preventing duplicate message pickup and rapid retry loops that exhaust retries and flood your DLQ.

The same few ideas kept showing up: small habits compound, communication changes careers, good teams raise your standards, and writing things down saves people from relearning the same lesson. The examples come from engineering, but most of the advice is about judgment and how you carry yourself.

ORM gives you some legitimately useful things. Unit of Work tracks changes across your transaction. The identity map keeps entities unique. You get declarative mapping for relations and cascading. JPQL and entity graphs mean you're not locked into one database vendor.

On SWE-Bench Pro, Kimi K2.6 scores 58.6 and GLM-5.1 scores 58.4 — a 0.2-point gap that is effectively noise. The real differences are architecture and pricing: Kimi K2.6 is a 1T-parameter MoE with 32B active, a 400M vision encoder, and an agent-swarm runtime aimed at visual and frontend work. GLM-5.1 is MIT-licensed open weights tuned for long-running coding agents (hundreds of rounds, thousands of tool calls) and costs $1.40 input / $4.40 output per 1M tokens vs Kimi's $0.95 / $4.

A sidecar proxy runs as a library or sidecar alongside each service — minimal latency, but each instance tracks its own costs with no cross-service visibility. A centralized gateway is a dedicated service all LLM traffic routes through — one network hop added, but you get a single dashboard showing every team's spend, every model's usage, and every feature's cost. Most mid-market teams with 3+ services should go centralized. The visibility is worth the few extra milliseconds.

Skills are lightweight instruction files loaded at session start — they tell the agent how to do something with a fixed context cost paid once. MCP (Model Context Protocol) connects the agent to real-time external services mid-session, with variable cost paid per call. Use MCP when you genuinely need live data that can't be pre-written. Use skills for repeatable workflows. Every unnecessary MCP call is a context tax paid on every execution.

If you can't answer 'what is each team spending per feature per month on LLM calls,' you need one. The clearest triggers are: 3+ services making LLM calls, monthly LLM spend above $3K, need for provider redundancy (automatic failover when Anthropic or OpenAI has an outage), or data residency requirements that force geographic routing. Below those thresholds, single-provider routing with tiered models handles most use cases without additional infrastructure.

A modular monolith keeps one deployable unit and a single runtime but enforces strict internal boundaries. Compile-time enforcement beats network isolation for most teams. Explicit domain modules with public interfaces and internal packages. If another module needs something, it goes through the port. No cross-module database access. Period. In-process message bus for events. Add an outbox if you need external integration. Unified observability, logging, config. One deployment, many bounded contexts.

Add these one at a time, only when you feel the gap. Forms are the front door to most automations. Lead capture, client intake, project briefs, feedback surveys. Data enters through forms. Tally is free, clean, and connects to everything. Build a form in 5 minutes, hook it to Make.com, and data flows straight into your CRM on arrival.

Four situations: your process isn't defined yet (automating chaos gives you faster chaos), the task happens fewer than 10 times per week (setup costs don't justify it), every instance requires genuine human judgment (custom proposals, sensitive client communications), or you're automating to avoid fixing a broken process (unhappy customers just get unhappy faster). Fix the experience first, automate the execution second.

Use /compact when you're mid-task, need to shed conversation weight, and the working context (decisions made, files read, direction established) is still relevant to where you're going. Start a new session when the task is complete, when you're switching domains, or when accumulated context has drifted from what you're doing. Old context isn't neutral — it's noise that pulls the model toward decisions you've already discarded.

Use strong consistency for identity, authorization, money, and inventory where anomalies would be unacceptable. Use eventual consistency for search, analytics, recommendations, and notifications where slight staleness is tolerable and availability matters more.

Use Strategy when you have multiple ways to perform an operation and the logic changes based on context, such as pricing rules per region or different authentication methods per tenant. It replaces growing if/else chains with interchangeable, testable implementations.

If the database work is the actual feature, write SQL directly. Don't try to bend JPA to do it. Analytics (window functions, CTEs, rollups) Database-specific features (Postgres arrays, JSONB, PostGIS) Locking strategies JPA can't express Read paths where you need precise projections and indexes Pagination over gnarly joins Maintenance jobs like backfills

Anthropic released Claude Opus 4.7 on April 16, 2026. Pricing stayed the same ($5 input / $25 output per 1M tokens) and the context window remained 1M, though on 4.6 that was beta and on 4.7 it's the default. Anthropic positions 4.7 as stronger on advanced software engineering; Cursor reports a 13% lift on its own 93-task coding benchmark, with stronger long-run follow-through and fewer tool errors.

AI assistants carry sharp edges. Know them, plan around them. Hallucinations and misplaced confidence. They sometimes invent APIs or gloss over edge cases. The writing reads plausible, which can trick even seasoned reviewers. I've seen PRs where the code looked fine until you ran it.

No-code works well for forms, CRUD apps, dashboards, and routine workflows where speed beats customization. Domain experts can own more of the solution, while developers spend less time rebuilding the same internal tools. Once performance, security, or unusual behavior dominates the problem, the platform starts fighting back.

The AI tax shows up as drag across the development loop - you pay a little bit extra at each step. Review tax: generated diffs compete for senior attention. Reviewers have to answer a harder question than "does this compile?" They have to decide whether the solution belongs in the system.

Faros AI measured DORA metrics on the same teams: deployment frequency, lead time, change failure rate, time to restore service. Unchanged. Meanwhile code review times increased 91%. The METR study found experienced developers on familiar codebases took 19% longer on real-world tasks while estimating they were 20% faster. Developers felt faster. The customer deliverables didn't move.

AI feedback before humans look is the highest-use placement. The old flow: developer opens PR, waits for reviewer, gets 15 comments, fixes them, waits again. The new flow: developer opens PR, CI runs AI review in 90 seconds, developer fixes 6 issues, human reviewer sees a cleaner diff.

Boilerplate, test scaffolds, API clients, config wiring, documentation, and low-risk refactors are the easy wins. The payoff drops on hard debugging and subtle production problems. AI can move quickly through the obvious work, then sound equally confident when it has no idea what's wrong.

Writing tests, documenting decisions, reading other people's code, and reflecting on the week all pay off slowly. That's why they're easy to skip. Nothing dramatic happens when you miss one week, but the difference is obvious after a year.

Fetch strategy: the defaults will bite you In JPA, ManyToOne and OneToOne are EAGER by default. OneToMany and ManyToMany are LAZY. This seems reasonable until you realize what it means. EAGER on a big collection? You just loaded the entire table. LAZY without thinking it through? Get ready for a hundred extra queries.

Triggers start workflows. Could be a schedule, a webhook, a new file in S3, whatever. Nodes are the building blocks — one node, one job. Fetch from an API. Transform JSON. Send to Slack. Branch on a condition. Credentials stay separate from workflows. You reference them by name, and when someone leaves you revoke their creds without touching 50 workflows.

Skills are nearly a 1:1 replacement for the Directive layer. They load on demand based on frontmatter descriptions, scope tool access per skill, and compose cleanly. You don't have to write a separate directive router, because Claude's harness does the routing for you through the description field. Invocation is mostly automatic. Claude picks the right skill based on the description, but you can also trigger one directly with a /skill command if you know the name.

Orchestration still matters for anything non-trivial. A few cases where I still want my own O layer. Multi-model routing. I typically run Opus for architecture decisions, Sonnet for implementation, and Haiku for cheap parallel work. And I've even been replacing these with Codex/ChatGPT-5.4 in recent weeks due to the level of service from Claude.

Get these right and you'll automate most of your repetitive work without writing a line of code. Make.com gives you a visual workflow builder. Drag, drop, connect: "When this happens in Tool A, do this in Tool B, then this in Tool C." Conditional logic, branching, scheduled runs. Zero code.

The easiest mistake to make with agents is blaming the model for everything. Sometimes the model really is the problem. Most of the time, it isn't. The same model and task can produce wildly different output because the environment around the model changes what it sees, what it can do, how it gets checked, and when it is allowed to stop.

Taste lives in the chooser, not the output. It's formed by defending choices to peers, breaking social norms, and thousands of small feedback loops from real consequences. Models can imitate the output but not the calibration that produced it.

Without agent instruction files (like CLAUDE.md), guardrails, and content guidelines, engineers improvise every prompt from scratch. Teams with this foundation consistently outperform teams with better tools and no setup because the infrastructure makes AI output consistent and reviewable.

Mostly? Human error. Wrong neighbor type, copy-paste policy mistakes, filter scope that made sense at the time but doesn't anymore. Templates that diverged between your edges and route reflectors (and nobody noticed for six months) Stale IRR data, missing ROAs, ROAs signed with the wrong origin Automation scripts with no validation. They run fast and break things efficiently. Policy interactions across different vendors or ASes. The classic assumption that "the peer will filter bad routes." They won't.

Most beginners assume the tool is the problem. The failures usually come from data and workflow design. These are the pain points teams repeat across industries: Duplicate data: “Every time a new client signs up, I have to manually sync between CRM and QuickBooks.”

All AI tools in an enterprise environment need to be enterprise-approved, integrated with SSO, and restricted to enterprise workspaces. That's not bureaucracy for its own sake. It prevents data leakage, untracked changes, and compliance violations.

Those Anthropic survey numbers are all individual metrics — how much each engineer used the tool, how fast they felt, how many PRs they shipped. By any of those measures, the tool was clearly working. The solo developer story is even more dramatic. A case study published in February 2026 documented one developer delivering what was scoped as a "4 people x 6 months" project in 2 months, working alone.

Microservices fail when organizational and technical forces misalign. I keep seeing the same problems: High cognitive load. Services, contracts, failure modes—they all multiply. One team I worked on had 47 services for what could have been eight modules. Our manager noticed the same thing. We refactored to a mono-repo, but this took time.

Matt Pocock has a useful example for this in Why Software Fundamentals Matter More Than Ever. He describes the specs-to-code dream: write a specification, ask the model to compile that spec into an application, and when the application is wrong, go back to the spec instead of the code.

AI makes it cheaper to cross boundaries. A developer who understands product, systems, writing, and automation can connect pieces that used to require separate specialists. You still need depth somewhere, but the ability to move between domains creates more options.

It feels like every week there's a "breakthrough." Why? , it's just convergence. The models are finally usable, the compute is cheaper, and it's being shoved into every tool we own. Adoption is up, but real value is lagging. Everyone has ChatGPT open, but not everyone is solving actual business problems with it.

Structured outputs reduce ambiguity at the one place it costs the most: system boundaries. They turn "model said something" into "system received a record." 1) Validate before you trust Validation gives you a hard gate. If the output fails schema checks, it doesn't enter downstream systems. The failure mode shifts from "silent corruption" to "handled error" — and that shift is the whole game. 2) Measure quality with real signals Text-only evaluation relies on fuzzy heuristics.

Karpathy coined "vibe coding" in early 2025. The idea: describe what you want in natural language, accept the output without reading it too carefully, and iterate by feel. "See stuff, say stuff, run stuff, and copy-paste stuff." The vibes are the spec.

AI trend: At large enterprises, AI pair programmers now author a material share of net‑new code. GitHub (Microsoft) reports developers accept roughly 30-40% of Copilot suggestions on average, with some languages and teams exceeding 50%. AWS customers using CodeWhisperer report ~57% faster task completion in controlled benchmarks.

Beginners try to connect everything at once. Start with a triangle: 1) Your CRM (Salesforce, Advyzon, or HubSpot) 2) A system of record (accounting, property management, case management) 3) A communication tool (email, calendar, SMS) !CRM integration triangle showing connections between CRM, system of record, and communication tools

I used to guess at what was slow. "Must be the join." "Probably needs an index on userid." Wrong half the time. EXPLAIN shows you what the planner thinks will happen. EXPLAIN ANALYZE shows what happened. Big difference. EXPLAIN: plan only, no execution EXPLAIN (ANALYZE, BUFFERS, VERBOSE): runs it and shows actual time, rows, disk I/O In DBeaver, the plan view shows this as a tree you can click through

Overpowered models waste money (up to 15-20x more per token), respond more slowly hurting user experience, and tend to over-elaborate on simple tasks. They can also mask bad prompt design since the model brute-forces through poor instructions.

I primarily run Claude Code from the terminal (Ghostty) rather than the IDE chat panel or web UI. The terminal gives me access to the full agent system: file reads, file writes, bash commands, git operations, and web search (for agents that declare it), all within one session. When I open a session in a specific project directory, Claude Code inherits that context and everything in it — the CLAUDE.md operating manual, the project structure, the history of decisions in the knowledge base.