The “New Era of Software Engineering” is a three-part series exploring how AI is redefining software delivery. As code becomes automated, the real challenge shifts to clearly defining the right intent. We introduce the role of the Intent Engineer, share our Intent Engineering methodology, and provide hands-on insights from SQUER’s first dedicated Intent Engineer — outlining how engineering intent becomes the key capability in the age of AI.
When we introduced the Intent Engineer role and published our methodology, the reaction from the industry was immediate.
CTOs reached out to ask how the role works in practice. Engineers wanted to know what an Intent Engineer actually does all day. Recruiters asked what profile to look for.
The honest answer: we've been developing this role for months, testing it across customer engagements, refining the methodology, and building the playbook. But we hadn't yet had someone carry the title full-time.
That changed this week. Pauline Chajecka joined SQUER as our first dedicated Intent Engineer. We sat down with her to talk about the role — not the theory, but the reality.
You're stepping into a role that barely existed a year ago. What made you want to do this?
I've always been drawn to the space between business and technology. I've seen enough projects where technically excellent teams built the wrong thing — not because they were bad engineers, but because the translation from "what the business needs" to "what gets built" was lossy. Information gets lost at every handoff. By the time a requirement reaches a developer, half the context is gone.
When I first heard about Intent Engineering, what clicked for me was this idea that we're not trying to write better requirements. We're fundamentally rethinking what the input to software development should look like. That's a much more interesting problem.
How would you explain your job to someone outside of tech?
I'm a translator — but not between languages. Between worlds. I spend time with people in the business department, understanding how they actually work, what frustrates them, where they lose time. Then I capture that understanding in a format that AI agents can use to build software.
The key difference to what came before: I'm not writing a specification that tells a developer "build this button here." I'm capturing the why behind what needs to change, with enough context that an AI agent can figure out the best solution on its own. It's more like writing a really good brief for an incredibly talented but very literal colleague.
What does a typical day look like?
There's no typical day yet — and I think that's the point. But I can describe the rhythm I'm settling into.
Mornings are usually with the business department. That might be an intent interview — a structured conversation where I'm asking things like "What are you trying to achieve?", "How do you do it today?", "What frustrates you most?". Or it might be process shadowing, where I literally sit next to someone and watch them work. I take notes on every system switch, every manual workaround, every time they copy-paste something between applications.
Afternoons shift to structuring what I've learned. Turning observations into intents — filling in the eleven fields of our intent template, quantifying the current state, defining success criteria. Then reviewing those intents with the Systems Engineer to make sure they're rich enough for the AI agents to work with.
Late afternoon is often demo time. Looking at what the agents built based on yesterday's intents, validating with the business department, feeding back into the next iteration.
What surprised you most so far?
How much of the value comes from the "current state" field in the intent template. Everyone focuses on what they want — the target state, the features, the solution. But the real gold is in understanding how things work today. When you discover that a claims adjuster spends 18 minutes per follow-up because 38% of incoming claims are incomplete, and you put that into an intent — the AI agent does something remarkable with it. It doesn't just build a validation form. It builds a system that understands why completeness matters and optimises for the right thing.
I thought I'd spend most of my time writing intents. Turns out I spend most of my time listening.
Which skills matter most for this role?
Three things, in this order.
First: curiosity about how businesses actually work. Not how the org chart says they work. How they actually work. The workarounds, the sticky notes, the "we've always done it this way" processes. You need to genuinely enjoy understanding operations.
Second: the ability to ask the right questions. The business department will tell you what they want — "we need a dashboard." Your job is to ask why they need a dashboard. What decision can't they make today? What information is missing? Usually, the real problem is three questions behind the first answer.
Third: structured thinking. You need to take messy, contradictory, incomplete information from conversations and observations, and turn it into something structured enough for an AI agent to work with. That means you need to be comfortable with ambiguity, but also disciplined about documenting with precision.
What's notably not on the list: deep technical knowledge. I understand software development concepts, and that helps. But my value isn't in knowing how to build a REST API. It's in knowing why a claims adjuster needs information in a specific sequence, and capturing that context so that an AI agent can make the right technical decisions.
That's interesting — you don't need to be a developer?
Not at all. In fact, I'd argue too much technical background can be a handicap. If you think in terms of endpoints and databases, you're already solving the problem in your head. You're already constraining the solution space. The whole point of Intent Engineering is to stay in the problem space as long as possible and let the AI agents — together with the Systems Engineer — figure out the best technical approach.
That said, you need to understand how AI agents work at a conceptual level. Not how to write prompts, but how context affects output quality. The richer the context in your intent, the better the agent performs. That's not intuition — it's something you learn by seeing the difference between a vague intent and a well-written one in the agent's output.
What's the biggest misconception about the role?
That it's "just" requirements engineering with a new name. I hear this a lot. And I get it — from the outside, it looks similar. Someone talks to the business, writes something down, hands it to the technical team.
But the difference is fundamental. A requirements engineer writes "The system shall validate that all mandatory fields are present before submission." An Intent Engineer writes "38% of incoming claims arrive incomplete. Each incomplete claim causes an average 2.4-day delay, 1.3 rounds of follow-up, and 18 minutes of adjuster time per round. A complete claim in auto insurance requires police report number and vehicle registration; in property insurance, damage photos and building year."
The first tells the agent what to build. The second gives the agent the context to figure out what to build. The output quality is dramatically different — because the agent can make hundreds of micro-decisions informed by business context instead of blindly implementing a specification.
How do you work with the Systems Engineer?
We're a Focused Impact Pair — two people plus AI agents, replacing what used to be a team of eight or ten. The split is clean: I own the what and why, they own the how.
In practice, there's a lot of conversation between us. When I hand over an intent, we go through it together. The Systems Engineer might ask: "This constraint about data residency — does it apply to processing or just storage?" And I'll either know the answer or I'll go back to the business department and find out. That back-and-forth sharpens the intent before the agents even start working.
The beautiful part: once the intent and the agent context are set, the AI agents can work for hours autonomously. By end of day, we have something to demo. That feedback loop — intent in the morning, working software by afternoon — is something traditional teams can only dream of.
What advice would you give to someone considering this career path?
Start by retraining your instincts. If you come from a technical background, resist the urge to solve. If you come from a business background, resist the urge to specify. Your job is to understand deeply and document precisely — but to leave the solution space wide open.
Practice asking "why" five times in a row. Seriously. When someone tells you they need something, ask why. When they answer, ask why again. By the third or fourth "why," you're past the surface-level request and into the real business problem. That's where the valuable intents live.
And spend time with the AI agents. Not coding — just observing. Give an agent a vague intent and see what it produces. Then give it a rich intent with domain context, success metrics, and constraints. The difference in output quality will teach you more about Intent Engineering than any methodology document.
Last question: why do you think this is the most interesting job in software delivery right now?
Because we're at the exact inflection point where the rules are being rewritten. Every previous era of software engineering was about optimising the how — better frameworks, better processes, better tools. For the first time, we're optimising the what. The quality of the input has become more important than the speed of the output.
And the Intent Engineer sits at the exact centre of that shift. You're the person who decides what gets built and why — not by writing code, but by understanding problems deeply enough that AI agents can solve them. That's an incredibly powerful position.
Plus, honestly? There's no playbook from someone else to follow. We're writing the playbook as we go. That's terrifying and exciting in equal measure.
Pauline Chajecka is Intent Engineer at SQUER. She works as part of a Focused Impact Pair, translating business needs into structured intents for AI-driven software delivery.
This is Part 3 of the "New Era of Software Engineering" series. Part 1: Why We Created the Intent Engineer. Part 2: The Intent Engineering Playbook. Next: From Intent to Production — a whitepaper walking through the complete journey from business need to deployed product.
