Where different perspectives matter more than the prompt
We live in interesting and challenging times. With the introduction of AI and Large Language Models into everyone’s lives, we are experiencing a great shift in how work gets done across all industries.
As a software developer with over 20 years experience, this is by far the most significant disruption I’ve experienced. Many of the skills I’ve practiced daily — things that makes me feel proud about my work and that makes me feel professional — suddenly appears to have less value. Skills like clean code and TDD are still valuable, but they no longer have the same leverage.
I realize that I need to adapt to this reality. We all do. But my purpose of this article is not just to express personal reflections; it’s also about a concern I have related to what’s happening to the way we work and collaborate. I see patterns emerging that makes me worried.
The Mexican Standoff
I’m a firm believer of the Agile principles — not as a set of rituals and ceremonies, but as a commitment to human relations and communication. For me the magic happens when everyone; product owners, developers , designers and other stakeholders; come together and collaborate. We all bring different backgrounds and experiences to the table and together I believe we bring the best value to our customers. And this is not easy.
I also know that far from everyone works like this today and I think that is sad. I’ve had my fair share of experiences in “the desert” but I’ve always strived to work in “a forest”, and even trying to plant one if it does not exist.
As Marc Andreessen has suggested, it looks like we are currently seeing a “Mexican standoff” happening between three roles in the software development: product owner, UX:er and developer. And this is happening because of AI.
The Product Owners believe they can “vibe code” a fully working, and decent looking application with a few prompts and without the involvement of developers and UX:ers.
The UX:ers can talk directly to the end-user to understand requirements, and develop a similar application without the need of developers or product owners.
The Developers can bypass the product owners and UX designers (and even other developers), figure out requirements, generating design and create the application on their own.
The scariest part? It works. It’s fast. You can go from idea to something that appears “customer-ready” in a fraction of time.
Does that mean that these three roles are now the same and capable of producing the same value? No, I don’t think so.
Does it mean that we should stick to the old barriers and silos between roles? Absolutely not.
Does this mean that the roles will change? Yes, most certainly.
Instead of waiting for the answers on how it will change, I think that all of us should embrace the tools, to learn and play with them as much as possible. But even more important, I also think we should challenge and experiment with the way we work together. Instead of continuing in the same rituals and processes as before, try to collaborate in different ways. And in doing this, recognize that our unique professional perspectives may now matter more than ever.
Cutting corners because our processes are broken is like painting over rust. Bypassing existing quality gates and challenges and leaning into “Vibe coding” might remove the immediate frustration of a handover, a conflict and disappointment, but the underlying structural issues remain. If we ignore human interaction to gain speed, we aren’t actually solving the problem of slow, incorrect deliveries — we’re just accelerating the path to a failed product.
Instead of using new technology to route around each other, let’s use it to tear down the walls. Gather around the tools and try to solve actual problems. I strongly believe that this is a recipe for success.
The Danger of “Vibe Coding”
Are we underestimating the value of the team? If a product owner vibe-codes a solution without anchoring ideas and requirements with a developer, or validating the behavior and design with a UX expert, are we not missing the very essence and value of collaboration with other humans?
Speed is attractive, but we should’ve learned the hard way by now that Agile is not about speed. Vibe coding can make you addicted to the features. It is so easy and cheap to generate one new feature after another that we don’t stop to seek feedback from the users of the features. How do you ensure that you are providing value or learn from your mistakes when you can ship 30 features in a couple of vibe prompts?
I argue we should embrace a feature-by-feature approach. Keeping changes small and controlled allows us to test our assumptions with real users and learn, even if the code itself is written by AI.
Introducing the AEGIS model
I’ve been experimenting with a mental model. I call it the AEGIS model. It’s an idea to ensure that we don’t drown in a flood of AI output and presumptions. The aim is instead to produce only what provides true value while encouraging close collaboration, ensuring that everyone has a place at the table.
**AEGIS **is a commitment to resolving our different perspectives into a high-density specification before an agent writes a single line of code. Whether applied to a solo project — where you rotate different “professional hats” — or within a full team, the principle remains the same: we should not underestimate the unique value that different domains and people bring to the table. By forcing this alignment up front it naturally encourages smaller, controlled features and a a continuous loop of testing and feedback.
The model is derived from the idea of Spec-Driven Development. By capturing multiple professional perspectives and storing them as part of the repository, we create a “Living Specification” that lives close to the code. This serves two critical purposes:
For the Agent: It provides high-resolution requirements for the current task as well as access to a historical record of decisions taken. The AI can see the evolution and reasoning of the product, not just its current state and prompt.
For the Team: It acts as professional guardrails. It reminds us to not ignore the architectural, design, or business implications that we take for granted today, and that has been built up by individuals years of experience building software. By centering our work around this shared specification, my hope is that we can break down barriers between the professions and work closer than before.
If we want to break the silos we need a new way to shake hands. AEGIS provides that structure by making sure that all features are filtered through multiple professional lenses before the actual code is generated:
A — Architecture: We utilize Architectural Decision Records (ADRs) to anchor the feature. This is not about what we are building, but why we have chosen a specific path, what alternatives we have discussed and what the consequences of the implementation will be.
E — Engineering: This is where the developer’s current craft remains essential. We provide the rules for the agent: how we want the code to be written and structured, the expected interface between modules, and strict separation of concerns. I’ve experimented with **EARS (Easy Approach to Requirements Syntax) **and have found it invaluable as a lightweight syntax for defining system logic and library preferences.
G — Goal: All changes needs to be justified. This is where we capture the business problem and the Value Hypothesis — what we think we’ll achieve and how we will measure success.
I — Interaction: This is the domain of the designer/UX:er. It can be anything from high-fidelity prototypes and wireframes to the specific color schemes, fonts, and interaction flows to ensure the product feels like ours and not something generic that the AI infers from prediction.
S — Specification: These are the behavioral requirements. We can use structured formats like Gherkin (Given/When/Then) or User Stories to define the functional requirements. The idea is that this becomes the source of truth that the agent must fulfill and we need a testing harness to be able to verify the behavior.
The power of traceability
I have experimented with a tagging system where every feature is assigned a unique, permanent ID. This is not just for organization; it is about creating a Traceable Thread through the life of the product.
By indexing specifications this way, we transform the collection of documents into a Relational Knowledge Base. This allows both humans and agents to navigate the “Why” behind the “What”. The idea is to get the agent to stop guessing and start operating with good context of the product’s evolution.
The Verification Loop
I think that one of the greatest risk with “Vibe Coding” is a false sense of completion. An agent might generate a beautiful UI or a complex function in seconds, but without a testing harness, that speed can be an illusion.
I believe that each feature requires a non-negotiable layer of verification. Whether the test itself is created by an agent or a human is secondary to the integrity of the proof. We should ensure that the result produced by the agent isn’t just “working code”, but a perfect match for the behavior we have specified.
This is where the human remains the ultimate judge. We can’t just “accept” the output; we need to verify it. By combining unit tests with automated test suites and acceptance testing, the hope is to turn the probabilistic nature of AI into a more deterministic professional outcome.
From Hype to Handshake
I am still experimenting with this model. Testing how AEGIS performs in the wild — not just on new “greenfield” projects, but also in the complex reality of “brownfield” legacy systems where the historical context is often missing or broken and refactoring is required.
Right now, the industry is strapped onto the hype train. I feel that we are so fascinated by the magic of the tools that we’ve stopped reflecting on how to use them together. We are treating AI as a replacement for labor, when I think we should be using it as a catalyst for closer human collaboration.
The promise of AI isn’t that it replaces the human handshake; it’s that it enables us to reach the user sooner and learn from our mistakes faster. It gives us bandwidth to stop worrying about the “how” and start obsessing over the “why”.
Why Cutting People Now is a Structural Risk
Another troubling trend that starts to appear are corporations demanding justification for their AI investments. It fells like a growing expectation that “less people can do more” now, leading to layoffs. And this before we have managed to identify and incorporate new ways of working using these tools.
Doing this while we are still in the experimentation phase is harmful. We are currently finding new ways to utilize this technology and this is changing by the minute; we must let that process take its time. If we are so stressed by the need for immediate ROI that we cut the very people who provide the “Anchor”, I think we have to question if that investment made sense in the first place.
Leaning into “Vibe Coding” as a way to justify a smaller headcount is a trap. It prioritizes the appearance of productivity over the reality of a sustainable product. If we lose our diverse professional perspectives where we seek to deliver value by balancing needs and costs, we aren’t becoming more efficient — we are just becoming more fragile.
I really want to stress that this is my opinion today. In an era where things change by the hour, my views might shift. But I strongly believe that the value right now is not in the “vibe” — it’s in the anchoring.
I would love to hear your reflections on this. Don’t hesitate to reach out to me — let’s make sure that all of us cultivate this forest together!
Top comments (0)