Info Setronica
Over the past two years, AI has changed more than just the way software is written. It has changed what customers expect from software companies.
Businesses have always wanted faster delivery. That part is nothing new. What has changed is the assumption about what is possible.
The rise of AI coding assistants and autonomous agents has created a new perception of software development. Every week brings another demo of an application built in hours instead of weeks. Vendors promise dramatic productivity gains. Startups proudly advertise AI-native development. Whether every claim holds up in practice is almost beside the point.
The market is listening.
Customers increasingly arrive with a different expectation. They are no longer asking, “Can you build this?” They are asking, “Why can’t you build it faster?”
For engineering teams, this creates a difficult situation. The traditional explanations – limited engineering capacity, long implementation cycles, expensive changes, and complex coordination – sound less convincing than they did only a few years ago. AI has changed the conversation before it has fully changed engineering itself.
Ignoring that shift is becoming a competitive risk.
But there is another trap. Many companies respond by focusing on tools. They roll out AI coding assistants, encourage engineers to experiment with agents, and hope productivity follows.
We at Setronica chose a different starting point.
Instead of asking which AI tool to standardize on, the team asked a more fundamental question:
What actually prevents AI from producing reliable software?
The answer, we concluded, wasn’t code generation. It was everything that happens before the first line of code is written.
The experiment started with a bottleneck, not with AI
Most AI adoption stories begin with a tool. This experiment started somewhere else.
Rather than asking how to generate code faster, we focused on a different question: what prevents AI from producing reliable software?
That led us to examine the stages before implementation rather than implementation itself.
The pilot started with specifications. Or, more precisely, with the entire decision chain that leads to implementation.
The process begins with identifying the original source of the request. Then comes an explicit Understanding step – a short explanation of how the team interprets the problem before proposing a solution.
Only after that is a specification written. Implementation follows the specification. Evidence demonstrates that the change has been validated. Finally, everything needed to review, release, or maintain the change is handed off to the next stage.
None of these ideas are entirely new. Experienced engineers often go through this reasoning mentally. The difference is that the reasoning is no longer left inside someone’s head.
It becomes an artifact that can be reviewed, discussed, improved, and understood by everyone involved – including AI.
That doesn’t make the process more bureaucratic. It makes it more explicit.
The goal isn’t to produce more documentation. The goal is to make sure that the business, the engineer, the reviewer, and the AI are all working from the same understanding of the problem.
This is especially important because AI changes the cost of making mistakes.
In traditional software development, implementing the wrong solution could consume weeks of engineering effort. Today, regenerating code may cost only a few dollars in tokens. The expensive part is no longer rewriting code. The expensive part is realizing too late that the team solved the wrong problem.
That’s why the pilot isn’t measuring success by the amount of AI-generated code.
🎯 The goal was much simpler: teach teams to write specifications that could become a reliable starting point for implementation by either a human or an AI agent.
Why specifications suddenly matter again
For years, specifications had an image problem.
In many companies, they became synonymous with heavyweight processes and documentation that nobody wanted to maintain. Agile encouraged teams to value working software over comprehensive documentation, and experienced engineers often filled in the missing details through conversations, code reviews, and shared context.
That approach worked because people are remarkably good at handling ambiguity. Experienced engineers recognize missing information, question assumptions, and clarify requirements before moving forward.
AI doesn’t. When information is incomplete, it tends to generate a plausible answer rather than pause for clarification.
That changes the role of a specification. It is no longer a document created to satisfy a process. It becomes the control surface for implementation.
To support that shift, we introduced an additional section called Understanding. Before proposing a solution, the engineer writes down a simple statement: This is how I understand the problem.
The purpose isn’t to add documentation. It’s to make interpretation explicit. Every handoff – from business stakeholder to manager, analyst, and engineer – introduces assumptions. Capturing those assumptions before implementation allows the team to validate that they’re solving the right problem before anyone writes code.
To support this approach, we introduced a shared specification template, review guidelines, and a simple requirement: every specification should be understandable by business stakeholders, engineers, and AI alike.
This is not an AI-only process. The same specification should work whether implementation is written by a developer, generated by an AI agent, or produced through a combination of both. Once the input is clear, the implementation method becomes a secondary decision.
AI-first SDLC instead of an AI coding workflow
One of the more interesting decisions in this experiment had very little to do with AI itself. We deliberately chose not to standardize tools.
There is no mandatory IDE, no approved AI assistant, and no requirement that every engineer should work with the same agent. Teams are free to choose the tools that fit their projects and workflows. Some write specifications manually. Others use AI to draft them. Some rely heavily on AI during implementation, while others prefer to write most of the code themselves.
What we do standardize is the outcome.
Every change is expected to produce the same set of artifacts. The team should be able to trace where the request came from, how it was understood, what solution was chosen, how it was validated, and what evidence supports the result before it is handed over for review or delivery.
This distinction is intentional. The goal is not to prescribe how engineers work. The goal is to ensure that everyone works from the same engineering process, regardless of the tools they use.
The team describes this approach as providing rails, not buttons. Engineers remain free to experiment with different AI assistants, IDEs, and workflows. At the same time, the organization expects every project to produce a consistent, reviewable chain of decisions.
Without that consistency, AI simply makes existing problems happen faster.
A shared coding assistant doesn’t guarantee a shared development process. If every team produces different artifacts, documents decisions differently, and validates changes in different ways, introducing AI only increases variability across the organization.
That’s why the long-term objective isn’t to build an AI coding workflow. It’s to build an AI-first software development lifecycle where specifications, evidence, and handoffs remain consistent, regardless of who – or what – implements the change.
Work with a team that uses AI beyond code generation
Book a free consultation to discuss your project
We’ll get back to you within 1 business day to suggest possible next steps.
Early lessons from the pilot
The pilot is still at an early stage, and the team is careful not to draw broad conclusions. The experiment isn’t trying to prove that AI dramatically increases productivity. Its immediate goal is much simpler: understand whether a specification-driven workflow changes the way engineers approach software development.
The first feedback suggests that it does:
“Writing a specification changes how I start my work. Instead of thinking through the problem while writing code, I spend more time understanding the request before implementation begins. Questions that would normally appear during development or code review surface much earlier, when they are still easy to resolve.”
Another recurring observation is that clearer specifications often lead to less work.
As engineers describe the intended change, they frequently discover that part of the original implementation isn’t actually necessary. Sometimes the scope becomes smaller. Sometimes the solution itself changes. Either way, the discussion happens before code is written instead of after it.
These observations reinforce an old engineering principle: the earlier a misunderstanding is discovered, the cheaper it is to fix. AI doesn’t change that principle – it simply makes the cost of poor problem definition more visible.
The biggest shift isn’t technical – it’s managerial
As the pilot progressed, the team noticed another shift – one that had little to do with code generation.
Working with AI changes the way people think about delegation.
An AI agent can produce an impressive amount of work, but it doesn’t own the business context or take responsibility for the outcome. It is a strong executor, but the decisions still belong to people.
That changes what it means to write a good task.
The emphasis moves away from describing implementation details and toward defining intent, boundaries, and acceptance criteria. The question is no longer how should this be built? but what exactly are we trying to achieve, and how will we know we’ve achieved it?
The team believes this shift may favor people who are already good at framing problems rather than simply solving them. Engineering managers, architects, business analysts, and senior engineers spend much of their time defining goals, constraints, and expected outcomes.
In an AI-paired programming, those skills become even more valuable because they directly influence the quality of the implementation.
At the same time, the pilot exposed an important limitation.
If a specification leaves critical questions unanswered, AI will rarely stop and ask for clarification. It will choose an architecture, assume business rules, or make decisions about security, data handling, or retry logic based on incomplete information.
Those decisions should not belong to the model.
Human | AI |
Define intent | Generate implementation |
Set constraints | Execute |
Clarify ambiguity | Fill gaps |
Approve decisions | Suggest solutions |
Own outcome | Produce output |
For that reason, the team is introducing another discipline into the workflow. Before implementation begins, the specification should be reviewed not only for completeness but also for readiness.
The key question is simple: is this specification clear enough that neither a human engineer nor an AI agent has to guess?
If the answer is no, implementation should wait.
That may ultimately become one of the most important changes introduced by an AI-first software development lifecycle. It shifts responsibility away from writing code and toward defining the problem with enough clarity that the implementation – whether human or AI-generated – can be trusted.
Rethinking quality in an AI-generated world
As the discussion around AI-assisted development evolves, another long-standing engineering assumption is beginning to change.
For decades, software teams have invested enormous effort in defining what good code looks like. Entire books, conference talks, and coding standards have been built around readability, elegance, naming conventions, and architectural patterns. Those discussions remain valuable, but they also raise an uncomfortable question.
Who is “good code” actually for?
From a business perspective, code is rarely the end goal. What matters is whether the software is reliable, secure, maintainable, observable, and inexpensive to evolve over time. Clean code has always been a means to achieve those outcomes – not the outcome itself.
AI challenges that relationship.
Unlike a human developer, AI is less dependent on how easy the code is to read, how strictly naming conventions are followed, or how elegantly files are organized. That doesn’t make code quality irrelevant, but it changes the balance between code quality and process quality.
At the same time, there is another question that is rarely discussed. What happens if AI is no longer available? Who will understand and maintain large amounts of AI-generated code then? That is one reason why code quality still matters, even as the development process changes.
Our experiment reflects this shift. Instead of asking whether a change is “good,” we increasingly ask whether it is verifiable.
That means moving the discussion away from subjective judgments and toward measurable quality gates.
A quality gate is more than a successful CI pipeline. It should answer four questions:
- Who owns this validation?
- What evidence demonstrates that it passed?
- What is its current status?
- Does it block the change from moving forward?
The exact gates depend on the nature of the change. A security-sensitive feature may require a security review. An infrastructure change may place greater emphasis on observability. Another feature may rely primarily on automated test evidence or traceability to the original requirements.
The important part is consistency.
Every significant change should leave behind evidence explaining how it was validated, rather than relying on the assumption that “the code looks good.”
This doesn’t mean that code quality no longer matters.
Quite the opposite.
Readable code still makes systems easier to understand, maintain, and extend. Those benefits haven’t disappeared simply because AI can generate implementations more quickly.
The question is one of emphasis.
In an AI-first development process, trust is built less through the appearance of the code itself and more through the chain of evidence surrounding the change. A reviewer should be able to understand what problem was solved, why this solution was chosen, how it was validated, and what guarantees exist before approving it.
In other words, the conversation shifts from “Is this good code?” to “Can we trust this change?”
We believe that distinction will become increasingly important as AI-generated code becomes commonplace. If implementation becomes faster and cheaper, confidence in the result will depend less on inspecting individual lines of code and more on understanding the process that produced them.
Adoption is harder than technology
If there is one part of this experiment that has nothing to do with AI models, prompts, or tooling, it is adoption.
The technical layer is the easiest to reason about. The organizational layer is not.
Even in a controlled pilot with motivated participants, adoption is uneven. Some teams start writing specifications immediately and treat them as a natural part of the workflow. Others simply continue watching rather than actively participating.
This distribution is expected, but it matters more than it looks like at first glance.
Because the shift here is not about learning a new tool. It is about changing where responsibility sits in the development process. That is always harder than introducing new software.
One of the most consistent signals from the pilot is skepticism, and it is not purely technical skepticism. It is structural. People understand how to write code. They understand how to reason about systems. But they are less sure what it means to formalize understanding before implementation, especially when that step used to happen implicitly.
There is also a quieter factor that shows up in conversations but rarely gets written down: fear.
Not fear of AI failing. Fear of AI working.
Some engineers and managers openly question what their role becomes in a workflow where an agent can generate large parts of the implementation. Even when the answer is “you still define the problem,” that answer does not immediately resolve the uncertainty. It just shifts the shape of it.
This is one reason why the pilot deliberately avoids turning spec-driven development into a rigid mandate. The goal is not compliance. The goal is learning loops.
The most valuable output from early adoption is not the specification itself, but what the organization learns from writing it. When teams review specs consistently, patterns start to emerge. The same types of mistakes repeat:
- unclear boundaries of scope;
- hidden assumptions in the “Understanding” step;
- acceptance criteria that sound precise but are not testable;
- decisions that are left implicit and later reappear as implementation bugs;
- AI filling in gaps that should have been explicitly resolved by humans.
Over time, these observations become more important than any individual document.
Instead of collecting “good prompts,” the team starts collecting recurring failure modes in thinking.
And that is a different kind of maturity. It is no longer about making AI better at guessing what is needed. It is about making the team better at expressing what it actually wants.
The long-term value of this loop is not in standardizing templates. It is in making invisible reasoning visible, so it can be improved.
What success actually looks like
In most AI transformation narratives, success is described in very similar terms: more usage, more automation, more generated code, faster delivery.
None of these are sufficient definitions.
In this experiment, those metrics are explicitly not considered success criteria.
In fact, focusing on them too early would be misleading. It is entirely possible to increase code generation speed while degrading system quality, introducing hidden complexity, or amplifying misunderstandings between business and engineering.
So the team evaluates success differently.
Success is not more AI usage. Success is not more generated code. Success is when the underlying structure of work becomes more consistent, not more automated.
There are a few concrete signals that matter more than throughput:
Specifications become a normal part of everyday engineering work, not a special artifact created for the pilot. Engineers, analysts, and managers naturally begin to express intent before implementation, regardless of whether AI is involved.
Artifacts become consistent across teams. A specification written in one project is understandable in another. The structure of “Understanding → Specification → Evidence” does not depend on personal preference or tool choice.
Implementations become traceable. Every change can be connected back to its original intent, the assumptions made along the way, and the evidence used to validate it.
Evidence becomes a default expectation rather than an exception. Changes are not considered complete when code is merged, but when the outcome is demonstrably verified.
And perhaps most importantly, teams stop treating this as a separate “AI workflow.” It becomes the default way of working, regardless of whether AI participates in implementation or not.
At that point, AI stops being the center of the transformation. It becomes just another actor in a system that is already structured enough to absorb it.
Conclusion
There is a common intuition that AI will simplify software development by removing steps, reducing process overhead, and collapsing complexity into a single interaction.
The early reality of this experiment suggests something different. AI does not remove the process. It exposes where process was missing, implicit, or assumed.
When code generation becomes cheap, the real constraint shifts upward in the system.
Ambiguity becomes more expensive than implementation. Misunderstanding becomes more expensive than rewriting. And weak definitions of intent become more costly than technical complexity.
In that environment, software engineering discipline does not disappear. It becomes more important, not less. But its focus changes.
The center of gravity moves away from writing code and toward defining what “correct” actually means before code exists. It moves toward making understanding explicit, validating assumptions early, and ensuring that every implementation can be traced back to a clearly articulated decision.
The teams most likely to benefit from AI will not necessarily be the ones with the most advanced models or the most aggressive adoption of tools.
They will be the ones capable of redesigning how work flows from idea to production.
Because once AI is able to generate almost anything, the differentiator is no longer the ability to produce output.
It is the ability to define, structure, and verify what should be produced in the first place.
That’s the approach we’re developing at Setronica. Our AI-powered software development process is designed to deliver software faster while keeping specifications, validation, and engineering quality at the center. If you’re looking for a team taking this approach in real projects, contact us, and we’ll be happy to help.
