The "Trust, But Verify" Pattern For AI-Assisted Engineering

Why verification, not generation, is the next development bottleneck

tl;dr: Blind trust in AI-generated code is a vulnerability. Never skip manual review for AI-generated code and establish clear team guardrails. Be aware that verification - not generation - is the new development bottleneck, and ultimate accountability always remains with the human engineer.

An AI coding assistant is like a new high-speed junior developer – incredibly fast, often correct in syntax and style, but prone to mistakes that only experienced eyes or rigorous tests can catch. Embracing AI in software engineering therefore calls for a disciplined “trust, but verify” mindset, which we’ll unpack in detail.

“Trust, But Verify”: A pragmatic approach to coding with AI

Senior software engineers are justifiably skeptical about letting AI write code on their behalf. While tools like Cursor, Copilot and Cline can generate functioning code in seconds, experienced developers know that writing code is only half the battle – the other half is verifying that the code truly does what it should. This principle can be summarized as “trust, but verify.” In the context of AI-assisted programming, it means you can trust your AI pair-programmer to help produce code, but you must rigorously review and test its output before relying on it. In this write-up, we’ll explore why “trust, but verify” is an essential pattern for AI-assisted engineering, and how to apply it in practice. We’ll draw on recent research and industry insights to provide pragmatic guidance for even the most skeptical developers.

The promise and perils of AI code generation

AI coding tools have undeniably impressive upsides. Modern code generation models produce code much faster than a human can type, often syntactically correct and (in many cases) following idiomatic best practices by default . This means routine boilerplate or well-known patterns could be laid down in seconds. With AI handling the grunt work, human developers can in theory focus on higher-level design and complex problem-solving.

However, speed and fluency come with a caveat: you only get what you ask for . If a prompt is ambiguous or the AI has gaps in its training, the generated code may be superficially correct yet deeply flawed. AI has no true understanding of your specific project’s architecture, invariants, or security model – it patterns matches to likely code, which can include outdated or insecure practices. Critically, AI lacks the human developer’s intuition for edge cases and the “smell” of a subtle bug. In other words, AI can produce zero-day vulnerabilities – bugs so sneaky that developers have “zero days” to fix them because they never realized a vulnerability was introduced .

Beyond security, other risks include quality and performance anti-patterns (e.g. inadvertently writing an O(n²) loop on large data) or violations of architectural principles. AI is focused on making the code work, not on the long-term maintainability within your specific context. It might introduce a dependency that conflicts with your stack, or produce a solution that “technically” solves the prompt but in a brittle way. Maintainability can suffer too – AI-generated code can feel like code written by someone else entirely (because it is!), making it hard to grok later . In short, the AI is a prolific junior programmer with no stake in your project’s future: it won’t stick around to fix bugs or explain design choices. It’s on you to verify that its contributions meet your team’s standards.

The “Trust, But Verify” mindset

Given these pitfalls, how should senior engineers approach AI assistance? “Trust, but verify” captures the balanced mindset required. In practice, this means leveraging AI’s speed and generative power, but always subjecting its output to human judgment and additional checks before considering the task done. It’s a conscious decision to treat AI suggestions as helpful drafts – not final solutions.

This philosophy mirrors approaches in other domains. In cybersecurity, for example, “trust, but verify” has evolved into zero trust architecture (ZTA) – a model where nothing is implicitly trusted without verification, even after initial authentication . Just as a network using zero trust will continuously authenticate and monitor devices (assuming any component could be compromised), a developer using AI should continuously question and test AI-generated code. In essence, “blind trust is a vulnerability” . You might trust an AI model to quickly draft code, but you cannot assume it’s correct or safe until verified. Modern security breaches teach us that initial trust must be continuously earned and re-confirmed – a lesson equally applicable to collaborating with an AI coding partner.

It’s helpful to draw an analogy: AI coding assistants are copilots, not autopilots. As Microsoft’s own Copilot documentation emphasizes, “these tools are there to be your assistant… rather than doing the work for you” . A human pilot (the developer) must remain vigilant at the controls. Similarly, GitHub’s CEO has stressed that they named it “Copilot” intentionally – it’s not meant to fly solo. The human in the loop remains accountable for the final outcome.

Peer perspectives: Within software teams adopting AI, there’s a growing recognition that AI’s outputs should undergo the same rigor (or more) as human-written code. For example, The New Stack advises organizations to “implement the proper guardrails in the SDLC as early as possible so developers can check the quality of AI-generated code”. These guardrails include steps like code reviews, testing, and policy checks integrated from the start of development . Rather than treat AI code as a shortcut that bypasses process, treat it as any other code contribution: run it through your standard quality assurance pipeline (or even tighten that pipeline given AI’s known quirks). By shifting verification left – integrating it early and often – teams avoid painful surprises later in the cycle .

In essence, the “trust, but verify” mindset means welcoming AI as a productivity booster but never becoming complacent about its outputs. Seasoned engineers likely already do this subconsciously: when a new developer submits code, you review it; when Stack Overflow offers a snippet, you test it. AI should be no different. If anything, the skeptical instincts of experienced engineers are an asset here – that healthy doubt drives the verification that catches AI’s mistakes.

Why verification Is non-negotiable

AI models are trained on vast swaths of code and text, but they are far from infallible. They can produce results that look perfect at first glance – well-formatted code with plausible logic – yet conceal subtle mistakes. The output often feels correct, which is exactly why it demands a skeptical eye.

Here are some of the common failure modes and risks when using AI-generated code:

• Hallucinated APIs or packages: Large language models sometimes invent functions, classes, or even entire libraries that don’t exist. For example, an AI might suggest using a non-existent fast_sort() method or import a fictional package. These “hallucinations” are instantly caught when you run or compile the code – you’ll get an error if a method or module isn’t found . In that sense, obvious hallucinations are the least harmful form of AI error . The real danger is subtler.

• Subtle logic bugs: More insidious are mistakes that do compile and run, but produce incorrect behavior. An AI could off-by-one an array index, use a suboptimal algorithm, or miss an edge case. These issues won’t trigger immediate errors; they might even pass basic tests. In other words, code that appears correct may still be wrong, and only thorough testing or analysis will reveal it.

• Security and reliability issues: AI-generated code can inadvertently introduce security vulnerabilities or performance problems. It might omit input validation, use deprecated or insecure functions, or produce code that doesn’t handle failures robustly. Microsoft researchers examined 22 coding assistant tools beyond just functional correctness and found that “they generally falter” on aspects of reliability, security, and maintainability, hinting at fundamental blind spots in current training . The code might work for the happy path but can fail under real-world conditions.

• Outdated or incorrect assumptions: An AI’s knowledge has a cutoff, and it may suggest solutions that were appropriate years ago but are now outdated. It might use a library API that has since changed, or a practice that is no longer recommended. Improvements in AI knowledge quality may often factor in the popularity of libraries/patterns meaning less prominent solutions may continue to suffer from cutoff issues. Tools may try to workaround cutoffs using RAG or injecting the relevant documentation inside the context window, but these remain imperfect. If you trust without verifying, you could be baking obsolete techniques into your codebase.

• License and supply-chain risks: Treat AI suggestions like third-party code – because effectively, that’s what they are. You wouldn’t copy-paste random code from the internet into production without checking its license or provenance; similarly, AI-generated code could accidentally reproduce someone’s copyrighted implementation. There’s also the emerging threat of “package hallucinations.” If a developer blindly tries to install such a package, a malicious actor could have anticipated this and published a package by that name containing malware . This so-called “slopsquatting” attack takes advantage of unwary developers’ trust in AI suggestions. The lesson: verify that dependencies and code references are real and trustworthy before use.

Given these risks, blindly accepting AI output is asking for trouble - perhaps this is less of an issue if you are building personal software for just yourself or an MVP you will review before shipping it to production users. Otherwise, tread carefully. Every experienced engineer has stories of “that one line” that broke the system or “that one unchecked error” that caused a security hole. AI can generate a lot of code quickly, but speed is no excuse for skipping verification. In fact, the higher velocity makes rigorous review even more important – otherwise you’re just creating bugs and tech debt faster. If we don’t verify AI outputs, we risk accelerating straight into a maintenance nightmare.

So the question becomes: how do we integrate verification into our AI-assisted workflow without negating the productivity gains? To answer that, we should recognize why verification feels like a bottleneck and explore strategies to make it more efficient.

Generation is fast, verification is hard

Non-developers often think that programming is primarily typing out code. Ironically, seasoned engineers know that programming is largely reading, thinking, and debugging – the coding itself (the keystrokes) are a small fraction of the job. AI tools supercharge the typing part; they can spew out dozens of lines in the blink of an eye. But this doesn’t automatically make developers 10x or 100x more productive, because now the bottleneck shifts to understanding and verifying all that output. It’s a classic case of Amdahl’s Law: speeding up one part of the process (code generation) doesn’t help much if another part (verification) remains the slow, dominant factor.

AI can flood you with new code, but you still have to stop and make sure that code actually works and makes sense. If code generation becomes 100x faster but code review and testing remain the same, your overall speed improvement is limited – your workflow is now gated by how quickly you can verify correctness.

To visualize it, consider the creative process as having two interwoven modes: generation and evaluation. This duality is seen in many creative fields. A painter makes a brush stroke, then steps back to judge the effect; a writer drafts a paragraph, then edits it for clarity. AI coding is no different – except today the AI handles much of the generation, leaving the human to do the evaluation. The trouble is, evaluating code is cognitively demanding. It’s not as immediately intuitive as spotting a glaring flaw in an image or skipping through a video. Code can be logically complex, and subtle bugs can hide behind perfectly ordinary syntax. Verifying code often means mentally simulating its execution, writing tests, or reading documentation – tasks that require focus and expertise.

In fact, verifying correctness can sometimes take longer than writing the code yourself, especially if the AI’s output is large. You have to read through potentially unfamiliar code, understand what it’s doing, and check it against requirements. If something doesn’t work, you then have to diagnose whether the flaw was in the prompt, in the AI’s logic, or in assumptions about context. This effort is the price paid for code that “writes itself.”

This doesn’t mean AI assistants aren’t useful – it means we need to use them wisely, with an awareness that verification is the new labor-intensive step. The goal should be to leverage the AI for what it’s good at (rapid generation, boilerplate, repetitive patterns) while containing the cost of verification to a manageable level. In the next section, we’ll discuss practical ways to do exactly that.

Integrating verification into your workflow

Adopting AI in development workflows calls for some practical adjustments. How exactly can a team “verify” AI-generated code? It turns out many of the best practices are extensions of things good teams already do – with extra emphasis in the AI context:

1. Human code review and pair programming

Never skip peer review for AI-written code that’s going into production. A senior engineer (or any engineer other than the one who prompted the AI) should review AI contributions with a fine-toothed comb before code lands in production . This might mean treating an AI’s output as if a new junior developer or intern wrote it – giving it extra scrutiny for correctness, style, and integration issues. In fact, peer review is a best practice regardless, so keep doing it , but double down when AI is involved.

The reviewer should ask:

• Does this code actually meet the requirements?

• Is it idiomatic for our codebase? Could it be simpler?

• Does it introduce any subtle bug or vulnerability?

Given that AI can sometimes introduce weird logic or over-engineered solutions, human judgment is key to spot red flags that automated checks might miss.

Many teams find pair programming with AI effective: the developer treats the AI like a partner, constantly dialoguing and reviewing each chunk it produces in real-time. For instance, you might prompt the AI to write a function and then immediately walk through the code with the AI – asking it to explain each part, or to add comments explaining its approach.

This technique forces both you and the AI to articulate the reasoning, potentially revealing flaws. You can even prompt the AI with questions like “Does this code follow security best practices?” or “Can you think of any edge cases this might fail?” to invoke the AI’s own verifier mode. (While the AI’s self-critiques aren’t perfect, they can sometimes catch oversights or at least provide a second description of what the code is doing.)

Paradoxically, introducing AI may require more collective expertise on a team, not less, to effectively audit the AI’s work. A novice team might trust the AI too much; a seasoned team member will approach it with informed skepticism and prevent disasters.

On a team level, consider establishing explicit code review guidelines for AI-generated changes. For example, reviewers might ask for the original prompt or conversation that led to the code (to understand context), or require the author to annotate which parts were AI-generated vs. human-written. Some organizations adopt “AI annotations” in commit messages or pull requests (e.g. a tag or comment indicating AI involvement) so that reviewers know to look carefully. While code should be reviewed thoroughly no matter what, anecdotally reviewers tend to be extra vigilant when they know a machine wrote a section. The bottom line: treat AI as a contributor whose code always needs a human teammate’s eyes on it.

2. Testing, testing, testing

If “code is truth” then tests are the judge. Automated testing is a non-negotiable companion to AI coding. AI models currently have no inherent guarantee of logical correctness beyond pattern matching, so comprehensive testing is how we verify functional behavior and catch regression or logic errors. This includes: unit tests for fine-grained logic, integration tests to ensure the AI’s code plays well with the rest of the system, and end-to-end tests for user-facing scenarios.

One issue is that AI often isn’t proactive about writing tests unless prompted (and even then, it might produce trivial tests). So it falls to developers to insist on testing. Many experts recommend a test-first or test-parallel approach even when using AI: either write your tests upfront (so you can validate any AI-generated implementation immediately), or have the AI help generate tests as soon as it generates code. For instance, after getting a code snippet from the AI, you might prompt, “Now generate tests for this function covering edge cases X, Y, Z.” Even if you don’t fully trust the AI’s test quality, it’s a starting point that you can then inspect and refine. This serves two purposes: (a) it verifies the code to some extent by executing it in tests, and (b) it helps reveal the AI’s assumptions. If the AI fails to generate a test for a particular edge case, maybe it didn’t consider it – which is a hint you should.

Crucially, tests should not only be executed, but also manually reviewed when first written by AI. An AI might generate a test that always passes (e.g. by asserting something it knows will be true in its implementation, effectively tautological testing). Ensure the tests actually assert meaningful, correct behavior and not just mirror the code’s logic. Once a solid test suite is in place, it becomes a safety net for future AI contributions too – if an AI change breaks something, tests should catch it immediately in CI.

Automated testing extends to security and performance verification as well. Incorporate static analysis and security scanning tools into your pipeline to catch common vulnerabilities or bad practices. AI-generated code, like any code, can be run through linters, static application security testing (SAST) tools, dependency checkers, etc.

In fact, some AI tools are now integrating scanning by default. For example, Amazon’s CodeWhisperer not only suggests code but can flag potential security issues (like injection flaws or weak cryptography) in the generated code via built-in scans. This trend – AI that generates and then immediately evaluates the code for problems – is promising. But even without fancy integrated tools, you can manually run a static analysis after generation. If your AI inserts a new library or call, run it through your vulnerability scanners. Did it add any dependencies with known CVEs? Does the code raise any warnings in a linter or type-checker? These automated checks act as an additional “AI verifier” layer, catching issues that humans might overlook in review.

Lastly, consider fuzz testing or property-based testing for critical sections generated by AI. Since AI can introduce weird edge-case behaviors, fuzzing (feeding random or unexpected inputs to see if it breaks) can uncover things a deterministic mindset might miss. If your AI wrote a complex parsing function, throw a corpus of random inputs at it to ensure it doesn’t crash or misbehave.

3. Establishing AI usage guidelines and guardrails

At the organizational level, it’s wise to formulate guidelines for how developers should use AI and what verification steps are mandatory. Many companies should consider having an internal AI code of conduct. For example, they might mandate that no AI-generated code goes straight to production without at least one human review and one automated test pass. Or they instruct developers to preferentially use AI for certain safe tasks (like generating boilerplate or tests) but not for others (like security-critical code) without extra scrutiny.

Consider starting these governance measures early in the development lifecycle . That could mean during design and planning, engineers document where they plan to use AI, and identify any high-risk areas where AI use should be limited. Some teams conduct design reviews that include an AI-risk assessment: e.g., “We used AI to scaffold this component – here are the potential weaknesses we identified and plan to verify.” By talking about verification from the outset, it normalizes the idea that AI is a tool that must be managed and checked, not an infallible oracle.

In summary, integrating “verify” into the workflow means augmenting each phase of development with extra checks when AI is in play. Design with verification in mind, code with an AI in a tight feedback loop (not as a one-shot code dump), review with human expertise, test thoroughly and automatically, and continuously monitor and improve these guardrails as you learn. It’s better to catch an AI mistake in a code review or test suite than have it blow up in production. As the old saying goes (now with a modern twist): an ounce of prevention is worth a pound of cure.

Verification challenges: bottlenecks

If all this verification sounds like a lot of work – you’re right, it can be. A critical concern arises: does verifying AI output erode the productivity gains of using AI in the first place? Skeptics often point out that if you have to meticulously review and test everything the AI does, you might as well have written it yourself. This is a valid point and represents a current bottleneck in AI-assisted development.

Technologist Balaji Srinivasan recently framed it in a concise way: “AI prompting scales, because prompting is just typing. But AI verifying doesn’t scale, because verifying AI output involves much more than just typing.”

In other words, asking an AI for code is easy and infinitely replicable – you can churn out dozens of suggestions or solutions with minimal effort. But checking those solutions for subtle correctness is inherently harder. You often have to actually read and understand the code (which could be dozens or hundreds of lines), run it, maybe debug it, consider edge cases – all of which take time and expertise. As Srinivasan notes, “for anything subtle, you need to read the code or text deeply - and that means knowing the topic well enough to correct the AI” . The heavy lifting (semantics, reasoning, domain knowledge) remains largely on the human side. This asymmetry is why AI is great for generating a UI or a simple script that you can eyeball for correctness, but much trickier for complex logic – you can’t just glance at a block of novel algorithmic code and know if it’s 100% correct; you must step through it mentally or with tests.

This raises a scenario where verification could become the rate-limiting step in development. Imagine an AI can generate code 10 times faster than a human, but a human then spends an equal amount of time reviewing and fixing it – the net gain in speed might only be marginal (or even negative if the AI introduced a lot of issues). In essence, “if we only get much faster at (writing code), but we don’t also reduce (time spent reviewing it)… the overall speed of coding won’t improve”, as one commentator noted, because coding is as much (or more) about reading and thinking as it is about typing.

Does this mean AI-assisted coding is futile? Not at all, but it highlights an active challenge. The industry is actively seeking ways to reduce the verification burden so that AI’s benefits can be fully realized. Some possible approaches to alleviate this bottleneck include:

• Better AI instructions to minimize errors: Prompt engineering can help get more correct output upfront. For example, telling the AI explicitly about constraints (“Don’t use global variables”, “Follow our API conventions”, “Consider security implications for X”) can sometimes prevent mistakes. Additionally, requests like “provide reasoning for each step” or “list any assumptions you made” might surface potential issues proactively. In an ideal scenario, the AI of the future will “anticipate the work of verification and reduce it”, perhaps by breaking solutions into smaller, verifiable chunks . Today’s AI often dumps a large blob of code; a smarter assistant might instead have a dialogue: “Step 1, I’ll write this small function, test it quickly. OK, looks good. Step 2, let’s proceed to next part…” This iterative approach could make human verification easier at each step, rather than forcing a human to untangle 500 lines after the fact.

• AI “self-checks” and evaluator models: Researchers are exploring having one AI model critique or verify another’s output. The idea is to automate the verification process itself. For instance, one model generates code, and another model (trained specifically as a code auditor) examines the code for bugs or deviations from spec. There’s already some progress: researchers have trained AI verifiers that predict if a generated program is correct based on the input, the code, and the code’s execution results. Such techniques, while not yet silver bullets, hint that AI might assist in verification too, not just in generation.

• Advanced tooling and formal methods: In safety-critical fields, formal verification tools mathematically prove certain properties of code (e.g. a algorithm meets a spec or a program is free of certain bugs). Applying formal methods to arbitrary AI-generated code is extremely difficult in general, but for specific scenarios, it could be a solution. Even lightweight formal checks (like using a type system to prove absence of type errors, or using model checkers for certain algorithms) can catch issues without full manual review. Integrating these into AI workflows (perhaps the AI itself suggests an invariant that a formal tool can verify) might reduce manual effort. We already see hints of this in things like AI-assisted test generation – e.g., tools that attempt to generate edge-case tests automatically for your code, effectively trying to “break” the AI’s output to see if it holds up.

Despite these mitigations, a hard truth remains: ultimately, accountability lies with human developers. Until AI advances to the point of guaranteeing correctness (a distant goal, if ever attainable for complex software), verification will remain a necessary step that requires human judgment. Forward-thinking teams accept this and budget time for it. They treat AI as accelerating the first draft, knowing the polishing and review still take effort. For now, “AI verifying is as important as AI prompting”, as Srinivasan puts it – users must invest in learning how to verify effectively, not just how to prompt effectively.

The verification bottleneck is a challenge, but being aware of it is “half the battle” . By acknowledging verification as a first-class problem, teams can allocate resources (tools, training, processes) to address it, rather than being blindsided.

Debates and future directions

Some voices in the community argue that the endgame should be fully automated verification – after all, if an AI can write code, why not eventually have AI that can 100% correctly check code? Optimists point out that computers are excellent at running tests, checking math, and even scanning for known problematic patterns, so maybe much of the verification can be offloaded to tools.

Indeed, there are companies like Snyk exploring automatically governing and securing AI-generated software . These platforms aim to enforce guardrails (security, quality rules) in real-time as code is written by AI, theoretically reducing the risk of flaws slipping through. It’s an intriguing vision: an AI pair programmer that not only writes code, but also instantly flags, “Hey, I might have just introduced a bug here,” or “This code deviates from your design, should I fix it?” – essentially self-verifying or at least self-aware assistance.

On the flip side, many experienced engineers remain cautious about over-reliance on automation. They argue that no matter how good AI tools get, human insight is needed to define the problem correctly, interpret requirements, and ensure the software truly does what it’s supposed to (including all the non-functional aspects like security, performance, compliance).

Programming is fundamentally a human intellectual activity, and AI can’t (yet) replace the deep understanding required to verify complex systems. The middle ground – and where we likely are headed – is human-AI collaboration where each does what it’s best at.

There’s also a debate on trust vs. efficiency. Some fear that excessive verification requirements could negate the efficiency gains of AI or even slow things down. But proponents counter that the goal isn’t to remove humans from the loop, but to make the loop faster and safer. If AI can get you 90% of the way to a solution in minutes, and then you spend an hour verifying and refining, that can still be a net win over spending several hours coding from scratch. Additionally, as AI improves, the hope is that the effort required to verify will decrease.

Perhaps future models will have more built-in checks, or industry standard libraries of prompts will emerge that reliably produce correct patterns for common tasks. The first automobiles were unreliable and required a lot of maintenance (like frequent tire changes and engine tinkering) – early drivers had to effectively verify and fix their cars constantly. Over time, car engineering improved, and now we drive without expecting the car to break every trip. AI coding may follow a similar trajectory: today it’s a bit rough and needs a lot of hands-on verification, but a decade from now it might be far more trustworthy out of the box (though some verification will likely always be prudent, just as even modern cars need dashboards and sensors to alert the human driver of issues).

Conclusion

“Trust, but verify” is a working strategy for integrating AI into software development without losing the rigor that quality software demands. For senior engineers and a discerning tech audience, it offers a path to embrace AI pragmatically: use it where it helps, but backstop it with the full arsenal of engineering best practices. AI might write the first draft, but humans edit the final copy.

By trusting AI to handle the repetitive and the boilerplate, we free up human creativity and accelerate development. By verifying every important aspect of AI output - correctness, security, performance, style – we ensure that speed doesn’t come at the expense of reliability. This balance can yield the best of both worlds: code that is produced faster, but still meets the high standards expected in production.

In practical terms, a robust “trust, but verify” approach means having guardrails at every step: design reviews that anticipate AI-related concerns, coding practices that involve humans-in-the-loop, peer review and pair programming to bring seasoned insight, comprehensive testing and static analysis, and organizational policies that reinforce these habits. It’s about creating a culture where AI is welcomed as a powerful tool, but everyone knows that ultimate accountability can’t be delegated to the tool.

For teams beginning to leverage AI, start small and safe. Use AI for tasks where mistakes are low-consequence and easy to spot, then gradually expand as you gain confidence in your verification processes. Share stories within your team about AI successes and failures – learning from each other about where AI shines and where it stumbles. Over time, you’ll develop an intuition for when to lean on the AI versus when to double-check with extra rigor.

Importantly, maintain a bit of healthy skepticism. AI’s competence is rising rapidly, but so too is the hype. Senior engineers can provide a realistic counterbalance, ensuring that enthusiasm for new tools doesn’t override sound engineering judgment. The “trust, but verify” pattern is a form of risk management: assume the AI will make some mistakes, catch them before they cause harm, and you’ll gradually build trust in the tool as it earns it. In doing so, you help foster an engineering environment where AI is neither feared nor blindly idolized, but rather used responsibly as a force multiplier.

In conclusion, the time of AI-assisted coding is here, and with it comes the need for a mindset shift. We trust our AI partners to assist us – to generate code, suggest solutions, and even optimize our work. But we also verify – through our own eyes, through tests, through tools – that the end result is solid.

Trust the AI, but verify the code – your systems (and your users) will thank you for it.

Btw, I’m excited to share I’m writing a new AI-assisted engineering book with O’Reilly. If you’ve enjoyed my writing here you may be interested in checking it out.