Your coding assistant is no longer just autocomplete with swagger; it is another production dependency.

The Weird Thing That Changed This Week

Most dev news is confetti with a changelog attached. This week was different.

On one side, OpenAI said an internal reasoning model disproved a longstanding conjecture in discrete geometry. Not “wrote a nicer regex.” Not “summarized a Jira ticket.” It produced work that external mathematicians checked.

On the other side, GitHub confirmed that roughly 3,800 internal repos were breached after an employee installed a malicious VS Code extension.

That is the whole developer moment in two tabs:

AI tools are getting frighteningly capable.

Developer workflows are getting hilariously porous.

The future is not “AI writes all the code.” The future is “AI can reason better than your Friday brain, while your editor extension can quietly steal the kingdom.”

Welcome to the new job.

The Tool Is Not The Workflow

A lot of teams are still treating AI coding tools like fancy autocomplete. Add the extension. Add the chat panel. Tell everyone to “use it responsibly.” Then wonder why the codebase feels like it got edited by five interns and a caffeinated spellchecker.

That model is dead.

The better framing is this: AI is now part of your software supply chain.

It reads code. It writes code. It suggests dependencies. It drafts tests. It explains failures. It may touch secrets, logs, architecture docs, stack traces, customer-shaped data, and everything else people paste when they are tired.

That means “which model should we use?” is only one small question. The bigger question is: what boundaries does this thing operate inside?

Because an assistant that can help solve hard problems can also help ship subtle nonsense at scale. And an extension that looks like productivity can become an incident report with syntax highlighting.

The Wrong Question Developers Ask

The wrong question is:

“Can AI do this task?”

That question is too easy now. For more and more tasks, the answer is “yes, kind of, depending on how much context and verification you give it.”

Can it write a migration? Sure.

Can it refactor a service? Often.

Can it debug CI? Sometimes faster than you.

Can it produce a convincing explanation for a bug it does not understand? Absolutely. It was born for that.

The dangerous part is not that AI fails. We already know software fails. The dangerous part is that AI fails with confidence, speed, and excellent formatting.

So the better question is:

“What system catches it when it is wrong?”

That is where real engineering starts.

The Better AI Workflow

Here is the boring, useful playbook. It will not trend as hard as “10 prompts that replaced my staff engineer,” but it will keep your repo breathing.

1. Give AI Smaller Blast Zones

Do not ask an assistant to “clean up the auth system” unless you enjoy archaeological debugging.

Give it narrow tasks:

• “Add validation for this input path.”
• “Write tests around this function before changing behavior.”
• “Explain why this query regressed.”
• “Refactor this file without changing public interfaces.”
• “Generate a migration and list rollback risks.”

Small tasks create reviewable diffs. Reviewable diffs create actual trust.

Big vague prompts create code fog.

2. Treat AI Output Like A Pull Request From A Stranger

Not an enemy. Not a genius. A stranger.

You would not merge a stranger’s PR because the comments sounded confident. You would check:

• Does the change match the existing design?
• Are the tests meaningful or just decorative?
• Did it introduce a dependency for a three-line helper?
• Did it change behavior outside the requested scope?
• Is the error handling real?
• Are edge cases named and covered?

The trick is to make this normal, not dramatic. AI code should go through the same path as human code: tests, review, observability, rollback plan when appropriate.

No special shrine. No special panic.

3. Lock Down The Editor Like It Matters

That GitHub incident is a reminder that the developer workstation is production-adjacent now.

If your editor can read private repos, tokens, env files, SSH configs, internal docs, and generated code, then editor extensions are not “personal preference.” They are executable supply-chain decisions.

Practical moves:

• Maintain an allowlist for extensions in company environments.
• Remove abandoned extensions from critical workflows.
• Prefer vendors with clear provenance and update history.
• Disable workspace trust bypasses.
• Keep secrets out of local files where possible.
• Rotate tokens when developer tooling gets weird, not three meetings later.
• Audit extensions that request broad filesystem or network access.

The edgiest thing your team can do in 2026 is basic hygiene.

4. Make The Compiler And CI Part Of The Conversation

One underrated trend: tooling is getting better at producing machine-readable feedback. GCC 16 work includes improved diagnostics and SARIF output, which fits a larger shift: compilers, linters, scanners, and CI systems are becoming structured signal feeds.

That matters because AI works better when it gets concrete feedback instead of vibes.

Bad loop:

“Fix the build.”

Better loop:

“Here is the failing test, compiler diagnostic, changed files, and expected behavior. Propose the smallest fix.”

Best loop:

AI proposes. Tools verify. Human reviews intent. CI blocks nonsense. The assistant gets the failure output and tries again inside a narrow scope.

That is not magic. That is a feedback system.

5. Stop Rewarding Prompt Theater

Contrarian take: prompt engineering is overrated inside mature engineering teams.

Not useless. Overrated.

The teams that win will not be the ones with the fanciest incantations. They will be the ones with clean interfaces, fast tests, readable errors, documented invariants, and boring automation.

AI loves a healthy codebase. It struggles in the same swamps humans do: hidden side effects, mystery globals, flaky tests, tribal deployment knowledge, and functions named handleThing2.

Want better AI output? Improve the terrain.

• Write smaller modules.
• Keep architectural decisions close to the code.
• Add examples to tests.
• Delete dead paths.
• Make local setup boring.
• Put invariants in types, schemas, and assertions.
• Make failure messages specific.

The prompt is not the product. The system is.

The New Senior Developer Skill

The senior move is no longer “I can personally hold the entire codebase in my head.”

That was always a cursed party trick.

The new senior move is designing workflows where humans and machines can both be useful without being trusted blindly.

That means knowing when to delegate to AI, when to pin it inside a sandbox, when to demand tests first, when to distrust a plausible answer, and when to turn the tool off and read the code like an adult.

AI is becoming a real collaborator. Great. Collaborators need boundaries.

Your editor is becoming a bigger attack surface. Fine. Attack surfaces need controls.

Your CI is becoming a negotiation partner. Excellent. Give it sharp teeth.

The Takeaway

This week did not say “developers are obsolete.”

It said the job is moving up a layer.

Less typing boilerplate. More designing guardrails. Less worshipping tools. More owning workflows. Less “can AI write code?” More “can our system survive code written at AI speed?”

Because the future belongs to teams that can move fast without letting every shiny extension hold the keys to the vault.