An AI agent builds your subscription system. Everything works. The demo is clean.

Then one customer gets charged twice. Another keeps access after cancelling. Your webhook processes the same event three times.

The code may have been generated perfectly according to the prompt. But the customer will not call the AI model.

They will call your company.

Cursor, Lovable, Bolt.new, v0, Claude Code, Replit Agent, Base44, Windsurf, Devin and Rork have made generating software remarkably cheap. (Part one of this series covers what each of them does.) What they haven't done — what they can't do — is take responsibility for the result.

That gap is where product engineering lives, and it is getting wider, not narrower.

AI Is Creating New Engineering Roles

As the tools change, the people building software change with them. Five roles that would have sounded strange a few years ago are now recognisable job descriptions.

1. The AI-Assisted Product Engineer

This person doesn't simply "use AI to code." They own a feature or a product outcome end to end: requirements, architecture, implementation, testing, deployment, monitoring and iteration.

AI accelerates the work. The engineer owns the result.

2. The Agentic Engineer

As coding agents become more autonomous, companies need people who can design the workflows those agents operate inside — deciding what an agent may do independently, what context it receives, which tools it can access, how its work gets verified, when another agent should review it, and when a human must intervene.

This matters most when several agents are working at once. And the skill is closer to systems design than to prompting, because an agent with vague boundaries and vague success criteria doesn't fail loudly. It succeeds at the wrong thing, convincingly.

3. The AI Systems Architect

Someone still has to design the system: security, permissions, data architecture, infrastructure, model selection, APIs, reliability, observability, cost and scalability.

Agents may implement enormous portions of that architecture. But architecture is fundamentally about trade-offs, and trade-offs require context — about the business, the customers, the budget, the timeline, the regulatory environment, and the team who'll maintain this in two years.

That context does not live in the repository.

4. The Design Engineer

The line between design and frontend development keeps thinning. A Design Engineer moves fluidly between design systems, interaction design, prototypes, frontend components, responsive behaviour and AI-generated interfaces.

They don't stop at "here's the Figma file." They help turn the product experience into working software.

5. The GTM Engineer

A role forming in the space between engineering, marketing and operations. A GTM Engineer builds lead-generation systems, internal sales tools, CRM automations, analytics pipelines, AI workflows, experiments, landing pages, data enrichment and sales infrastructure.

Instead of marketing filing tickets with engineering, technically capable growth teams increasingly build and automate their own systems.

Does This Mean We Need Fewer Engineers?

Possibly fewer for certain kinds of implementation. But that's half the story.

If creating software becomes dramatically cheaper, companies create far more of it.

Think about what happened when website development got easier. The world didn't stop building websites — almost every company built one.

AI is likely to produce the same effect for software. Businesses that would never have considered an internal operations platform, a customer portal, a niche SaaS product, a mobile app or an AI workflow may now find building one economically obvious.

The volume of software goes up. The engineer's role simply moves higher up the value chain.

There's a second-order effect worth naming too: more software means more systems to secure, integrate, monitor, migrate and eventually replace. Cheap creation does not make maintenance cheap.

The Skill That Stops Being Differentiating

One skill is losing its edge: typing code quickly.

If an agent can generate hundreds of lines in seconds, your advantage cannot be I write React faster than the next developer.

What becomes valuable instead:

• understanding the problem

• designing the architecture

• choosing the trade-offs

• reviewing the implementation

• understanding security

• knowing when the model is wrong

• thinking about edge cases

• communicating with customers

• making product decisions

• taking ownership when something fails

Notice what those have in common: none of them can be verified by someone who doesn't have them. You cannot review an agent's architectural decision unless you could have made that decision yourself.

Which is also why "AI replaces junior engineers" is the wrong conclusion. The industry still has to produce people capable of judging the output.

AI Can Build the Feature. Who Owns the Consequence?

Back to the subscription system charging a customer twice.

This is why one word becomes decisive in AI-assisted software development: ownership.

• Who owns the architecture?

• Who owns security?

• Who owns releases?

• Who defines acceptance criteria?

• Who decides the product is safe to deploy?

• Who investigates the incident?

• Who protects customer data?

An agent can be accountable for a diff. It cannot be accountable for an outcome. Someone must remain responsible for the system.

The TYBWORK Approach: AI-Accelerated, Human-Led

We don't think engineering teams should ignore these tools. That would be a mistake.

We use AI to compress work across research, implementation, prototyping, code exploration, testing, debugging, documentation and repetitive development. If a machine helps our engineers finish something faster, we want that leverage.

But five areas stay human-led:

Architecture — someone has to understand the whole system and make the trade-offs.

Security — access, permissions and sensitive data are not an afterthought.

Acceptance criteria — someone has to define what "working" actually means.

Production readiness — a successful demo is not a dependable product.

Release ownership — someone must be accountable for what reaches customers.

That is the difference between using AI to generate software and using AI to engineer products.

From Vibe Coding to Product Engineering

The software journey now looks something like:

Idea → Prompt → Prototype → Demo → Product → Platform

Lovable, Bolt, Replit and the rest are dramatically accelerating the first half of that path. That's valuable, and founders should take full advantage of it.

But somewhere between Demo and Product, the questions change. Instead of can we build this?, you start asking:

Is it secure? Can customers depend on it? Can we maintain it? What happens when something fails? Can it support 10x more customers? Can our team keep developing it? Can we confidently sell this to an enterprise?

Those are engineering questions. And they tend to arrive at the worst possible moment — during a security questionnaire, a funding round, or an outage.

The Developer of the Future Won't Compete With AI

Trying to beat a coding agent at typing code is the wrong competition entirely.

The developer who wins gets better at thinking, architecture, communication, review, prioritisation, testing, understanding users, managing systems, directing agents — and taking responsibility for outcomes.

AI makes implementation cheaper. That makes judgment more valuable.