AI Engineering Hub

Introduction

AI has become part of modern software engineering. That does not mean every team needs to reorganize itself around a chatbot, pretend code review is obsolete, or ship whatever a coding agent can make compile. It means engineering teams now have another powerful tool in the system, and powerful tools need discipline.

The useful work is not "adopt AI." The useful work is building engineering practices that let experienced software engineers use AI safely: clear intent, bounded scope, reproducible verification, code review, test strategy, security review, platform governance, and ownership. Coding assistants and agents can accelerate boring work, explore unfamiliar code, draft tests, and explain build failures. They can also create confident nonsense, oversized pull requests, fragile tests, and subtle security problems if the surrounding engineering system is weak.

This hub collects Slaptijack's AI engineering articles into a practical map for software engineers, Staff Engineers, Engineering Managers, Tech Leads, Platform Engineers, SREs, DevOps engineers, and AI engineering practitioners. The focus is production engineering, not demos: developer productivity, review discipline, CI, merge protection, governance, platform design, prompt injection risk, and the leadership work required to adopt AI without lowering the quality bar.

Use this page as the front door for the AI engineering cluster. Some sections already link to finished articles. Others include TODO placeholders for articles that should exist as this topic grows.

AI Coding Agents

AI coding agents are tools that can inspect a repository, reason across files, edit code, run commands, draft tests, and produce pull requests or patches with less step-by-step human instruction than traditional autocomplete. They are most useful when the task has a clear target, the repository has predictable conventions, and the human provides enough context for the agent to avoid wandering.

They work well for mechanical changes, test scaffolding, code navigation, documentation updates, migration chores, and narrow bug fixes with a clear reproduction path. They work poorly when the problem is ambiguous, the system boundaries are unclear, the change requires deep product judgment, or the code needs architectural restraint more than raw output.

The important point is simple: an AI coding agent does not own the change. The engineer does. Human review matters because someone still has to understand the intent, inspect the tradeoffs, verify the behavior, and decide whether the patch belongs in the system. The agent can produce work. It cannot be accountable for the production result.

Related articles:

AI Code Review

Reviewing AI-generated code is not a separate discipline from code review. It is code review with a few failure modes turned up.

The most common mistake is reviewing the surface polish instead of the behavior. AI-generated code often looks consistent, names things plausibly, and fills in tests that appear to match the surrounding style. That does not prove the code is correct. A serious review still asks what changed, why it changed, what behavior is protected, which assumptions moved, and whether the validation evidence can be reproduced by another engineer.

AI code review should preserve human-written intent. The pull request should explain the goal, the scope, the non-goals, the risk, and the verification path in human language. The reviewer should be able to separate semantic changes from mechanical cleanup, identify generated tests that merely assert the implementation, and decide whether the author actually understands the diff.

Ownership is the dividing line. "The agent wrote it" is not an acceptable explanation for confusing code, missing tests, or risky behavior. The author owns the change, and the reviewer should hold the author to the same standard as any other production patch.

Related articles:

Pull Requests and Merge Protection

AI-generated pull requests need guardrails because they can increase change volume faster than review capacity. A team that accepts larger diffs, weaker PR descriptions, or vague test evidence because the author used an agent has made the process worse, not better.

Good guardrails are boring in the best possible way. CI should run the same checks, in the same reproducible way, for human-authored and AI-assisted changes. Merge requirements should protect risky paths. CODEOWNERS should route sensitive files to the right reviewers. Path-based review can distinguish documentation edits from authentication changes, build-system edits, data migrations, and production infrastructure code. Risk classification should be explicit enough that engineers know when a change needs deeper review.

The goal is not bureaucracy. The goal is to keep throughput from outrunning judgment. AI-assisted changes should be small enough to review, clear enough to understand, and verified enough that a reviewer can reproduce the evidence without reverse-engineering the author's prompt session.

Related articles:

AI Governance

AI governance is where engineering leadership, platform engineering, security, legal, compliance, and developer productivity meet. The point is not to produce a giant policy document that engineers ignore. The point is to define how AI tools are approved, where they can be used, what data can be shared, what logs are retained, which repositories are off limits, and who owns decisions when the tool output affects production systems.

For engineering organizations, governance should be close to the developer workflow. Approved tools should be easy to use. Unsafe paths should be difficult or impossible by default. Platform teams can help by providing blessed integrations, repository templates, policy-as-code checks, secure secret handling, and observability around adoption patterns. Developer productivity teams can help by measuring friction and making the safe workflow pleasant enough that engineers do not route around it.

Good AI governance is practical. It acknowledges security, compliance, privacy, licensing, and customer trust without pretending every code completion needs a committee meeting. It gives teams a clear lane for experimentation and a clear bar for production use.

Related articles:

Prompt Injection & Security

Prompt injection is not only a chatbot problem. Developer tools can read issues, documentation, repository files, generated logs, dependency metadata, and pull request comments. If an AI workflow treats all of that text as trustworthy instruction, it can be manipulated into doing the wrong thing.

The security model has to account for repositories, permissions, secrets, build logs, third-party dependencies, generated artifacts, and tool access. An agent that can read source code, run shell commands, open pull requests, or call internal APIs needs tight boundaries. Secrets should not be exposed to prompts. Untrusted text should not be treated as authority. Tool permissions should be scoped to the task. Generated changes should be verified through normal engineering evidence, not trusted because the model sounded confident.

The practical posture is defensive and boring: least privilege, clear data boundaries, reproducible commands, protected secrets, dependency scrutiny, and human review for changes that cross security-sensitive boundaries.

Related articles:

Developer Productivity

AI can be a force multiplier for experienced engineers, but only when the team knows what kind of productivity it is trying to improve. Faster typing is not the same as faster delivery. More pull requests are not the same as better software. A higher volume of generated code may even make the system slower if review, CI, incident load, and maintenance cost go up with it.

The right productivity questions are more operational:

  • Are engineers spending less time on repetitive glue work?
  • Are build and test failures easier to understand?
  • Are pull requests smaller, clearer, and faster to review?
  • Are defects, incidents, and rework staying stable or improving?
  • Are senior engineers using AI to increase leverage without becoming review bottlenecks?
  • Are teams learning durable practices, or copying tool rituals they do not understand?

Avoid cargo cult adoption. A serious developer productivity program measures friction, cycle time, review quality, build reliability, onboarding time, and developer experience. AI belongs in that system as one lever among many, not as a magic explanation for every productivity problem.

Related articles:

Engineering Leadership

AI adoption is a leadership problem as much as a tooling problem. Engineering leaders have to decide where to encourage experimentation, where to require standards, where to invest in platform support, and where to slow down because the risk is not well understood yet.

The best rollout strategies tend to be incremental. Start with low-risk use cases: code explanation, test scaffolding, documentation updates, local build debugging, migration planning, and small reviewable patches. Capture what works. Turn repeatable practices into templates, checklists, repository guidance, and platform defaults. Expand into higher-risk workflows only when the review and verification system can keep up.

Balancing velocity and quality requires clear standards. Teams should know when AI assistance is encouraged, when it must be disclosed, when extra review is required, and which systems require stronger controls. Staff Engineers, EMs, Tech Leads, and platform teams should treat AI adoption as an operating system for engineering work, not a novelty project.

Related articles:

Recommended Reading

Start with these if you want the practical core of Slaptijack's AI engineering coverage:

AI Engineering Roadmap

Use this progression if you are building an AI engineering practice from the ground up:

  1. How to Use AI Coding Agents Without Losing Engineering Judgment
  2. Designing Guardrails for AI-Generated Pull Requests
  3. Reviewing AI-Written Tests Without Fooling Yourself
  4. How to Write Secure Prompts for AI-Driven Developer Workflows
  5. TODO: AI Governance for Engineering Organizations
  6. TODO: Measuring AI Developer Productivity
  7. TODO: Engineering Leadership for AI Adoption

The roadmap should expand as the AI engineering cluster grows. The structure is intentionally stable: start with individual agent use, add pull request and review guardrails, address security and governance, measure productivity, and then turn the working practices into durable engineering standards.

More at Slaptijack.

Slaptijack's Koding Kraken