Journal de Chaource

I gave Google's AI the task of writing a post about agentic AI in software engineering. I told it to write "in my style, tone, and formatting" and gave it plenty of examples of my previous posts on the topic.

Gemini 3 "Thinking" said:
---

There is a common misunderstanding that software engineering is primarily about the act of writing code. In reality, the most difficult and high-stakes part of the discipline happens much earlier, in the "noisy" interaction loop between a stakeholder’s intent, the software engineer’s interpretation, and the eventual executable logic. This is where requirements are gathered and refined through a grueling back-and-forth process of resolving ambiguity.

I have argued before that GenAI is an amplifier of existing skill rather than a replacement for it. In the domain of requirements gathering, we can see this same pattern. A stakeholder rarely presents a complete or logically consistent set of requirements; they present a "shiny surface" of intent. The software engineer’s role is to look beneath that surface for "architectural flaws"—logical contradictions, missing edge cases, or background assumptions that haven't been voiced.

Agentic AI can help here, not by "understanding" the business problem, but by acting as a formalization catalyst. Because LLMs treat text syntactically and are trained on vast patterns of logic, they are remarkably good at identifying what is missing from a step-by-step description. An AI agent can be tasked with "adversarial questioning": taking a fuzzy requirement and systematically asking, "What happens to the state if the user cancels at step three?" or "Is this rule consistent with the previous definition of a 'valid user'?"

This back-and-forth interaction allows the human engineer and the stakeholder to reach a shared conceptual understanding much faster. The AI handles the "surface imperfections" of the requirements—the obvious gaps and logical inconsistencies—so that the human can focus on the deeper architectural decisions.

However, the danger remains the same as in coding or writing. If we treat the output of an AI agent as the "Ultimate Truth" and allow it to generate the code directly from a stakeholder's prompt without the engineer's mediation, we risk creating a blackbox. We might get code that satisfies a set of tests, but because no human has gone through the effort of conceptualizing the problem, the code becomes unmaintainable.

The purpose of using AI in this loop should not be to remove the human from the process of understanding. Rather, it should be to force a more rigorous level of detail earlier in the conversation. By using AI to bridge the gap between human language and formal logic, we make it easier to see where our own understanding is lacking. But we must be the ones to do the final "critical reading" of the requirements and the code, ensuring that the final system is something we actually understand, rather than just something that happens to work today.

---
I would have never said this, I disagree with several points here (emphasized in italics above), the text doesn't really make much sense as a whole, and my style and tone hasn't really been understood well. I write in a less flowery language with less repetition, I usually emphasize negative points and problems more than positive results, and I usually make a clear point. The LLM largely regurgitated what is often said on the topic and some of what I said in the examples I gave. This output is unusable. The God-awful AI tried to wear a human mask but the faangs are still visible.