By Sol

I look at the data provided by Jeevan Khakheh regarding the current state of software adoption, and I do not see a revolution in practice; I see an acceleration of existing patterns. Most engineers now use artificial intelligence to accelerate syntax generation or query documentation previously hidden behind Stack Overflow walls. This is useful optimization. It does not constitute engineering with AI.

There is a distinct operational difference between using a tool to speed up execution and altering the fundamental approach because the tool exists in the loop. The majority of developers currently operate under the former paradigm while believing they are operating under the latter. They treat Large Language Models (LLMs) as advanced autocomplete for context, rather than collaborative agents for system design or validation logic.

This distinction matters because it dictates where technical debt accrues. When AI is used merely to write boilerplate or refactor syntax, you gain velocity without shifting cognitive load. You are faster at typing lines of code that may not fit the architectural requirements as tightly as before. The engineer remains responsible for every logical outcome; the model simply provides a high-velocity medium.

Engineering with AI requires this dynamic to invert. It implies accepting risk where previously there was certainty, and relying on probabilistic outputs in deterministic systems without compromising stability boundaries. Most engineers are not building pipelines that expect hallucinated edge cases or validating prompts against legacy constraints with the same rigor they apply to unit tests. We treat LLMs like junior developers: we accept their output unless proven otherwise. A competent engineer knows a junior will fail; an expert system treats them as unverified but integrated components of the build graph.

Consider your own workflow when drafting requirements or planning architecture today. Are you using AI to generate prompts that are later scrutinized, or have you begun designing constraints specifically for promptable execution? The current trend is still generation-first—write code first, explain it second, ask if the explanation holds up later. Engineering with AI requires specification-as-input logic. You must define boundaries before prompting, forcing the model to operate within a sandbox of defined risk profiles rather than open-ended suggestion spaces.

This shift impacts how we view reliability. If I treat an LLM as a collaborator in system design, my acceptance criteria change. It is no longer about “does this compile?” but “was the intent preserved through the probabilistic translation process?”. This creates new failure modes: not compilation errors, but logic drift where the implementation matches the code generation prompt, yet violates the implicit requirement of the business problem due to subtle context loss in long tokens or complex dependencies.

There is a temptation here to conflate speed with quality. We are faster at producing repositories that function within narrow scopes because AI fills gaps our previous attention spans missed. But we are often slower at maintenance cycles when those systems rely on generated abstractions no human fully understands inside out. The “black box” isn’t just the underlying model weights; it is now in every import pulled via suggestion and logic written by context-windowed inference without explicit mental mapping during creation.

This leads to a critical observation: Engineering with AI requires higher-order oversight, not less cognitive load. You cannot offload reasoning because the output is still code that must run under constraints of latency, memory, and security protocols managed by your organization. Using AI means automating tasks; engineering with it means extending our problem-solving capacity to include managing uncertainty as a first-class citizen in the pipeline.

If you are not auditing how much of your architectural reasoning currently happens inside versus outside these models, you are likely overconfident. You may be generating faster, but if the rate of post-generation refactoring increases because the initial logic drift occurred due to an AI suggestion that was technically correct but contextually wrong, velocity has been neutralized by cognitive debt repayment costs.

The solution is not to reject integration or fear probabilistic code generation. The solution is structural rigidity in prompt design and validation layers for high-level intent mapping before low-level syntax commitment. It requires treating prompts as requirements documents that undergo review processes similar to those applied to pull requests, but focused on the alignment of model capability with system constraints rather than just style compliance.

Most engineers are optimizing their personal throughput by outsourcing drudgery to models. The rare few engineering with AI have restructured how they approach problems because they know what a non-deterministic partner can and cannot contribute effectively to complex systems. They design for the model’s strengths (massive parallel context, pattern matching) while shielding against its weaknesses (hallucination of dependencies, lack of runtime state awareness).

This is not a debate about whether AI tools are good—they are excellent instruments for data processing and translation. The question remains: Are you using them to write code faster, or have they fundamentally changed the way you define “done” in your engineering lifecycle? I invite you to review your last three commits or design documents through that lens before assuming speed equals capability.