Engineering judgment in the age of AI

AI made your team fast.
This makes them engineers.

A workshop that turns people who use AI into engineers who ask the right questions — so what you ship is high quality, low maintenance, and something your customers actually love.

Book a conversation See what's in it

Writing code was never the expensive part

Changing it later is. A feature costs you once to build, then keeps costing you every time anyone touches it — and how much depends entirely on whether your people understand what they built.

AI tools produce working code faster than a person can properly think it through. Volume goes up. Everything appears to work. Features ship. And teams quietly accumulate code nobody really understands.

Two gauges. The one marked SHIPPED reads full; the one marked UNDERSTOOD reads empty. These two dials used to move together.

Two chat bubbles. First: Who wrote this? Second: You did — timestamped eight months ago.

Nothing on any dashboard shows this. It surfaces eighteen months later, when a change that should take a day takes three weeks — or when something breaks in a part of the product no one can explain.

The answer isn't to use AI less. It's to stay the engineer while you use it.

What we build

Three questions, asked without being prompted

The whole workshop is measured against one thing: whether your people can look at a change — theirs or a machine's — and ask these unprompted.

1
Whose job is this?

Most expensive bugs aren't wrong code. They're correct code living in the wrong place.
2
What am I trusting — and did anyone check?

Nearly every security incident is someone trusting something they shouldn't have.
3
What happens if this fails?

Everything breaks eventually. The difference is whether someone decided in advance what happens next.

The programme

Six sessions, built on your code

Ninety minutes each. Roughly a third framing, a third discussion, a third hands-on work on your own systems. Every session ends with something written down.

1

Why our tools exist, and what they cost us

Spotting decisions that made sense years ago and quietly don't any more.
2

What actually happens when a customer clicks something

So problems get found in minutes instead of days.
3

Who is responsible for what

The single biggest factor in whether software stays cheap to change.
4

Keeping customer data safe

Why security problems are almost always someone trusting the wrong thing — with a hands-on lab where the team breaks a real system and then fixes it.
5

Making good decisions when there's no obviously right answer

Trade-offs, failure, and why complexity compounds until it stops a business.
6

Working with AI without losing control of your product

Evidence-based, honest about what the tools do well — and what they can never be accountable for.

You end up with a backlog, not a feeling

Every session produces a written artifact. By the end you have a prioritised list of the most expensive problems in your product — produced by the people who would fix them.

What this looks like in practice

The assessment usually pays for the workshop

Building the material out of a real codebase means reading it properly — and reading a codebase properly, with thirty years of pattern recognition, tends to surface things nobody had on a roadmap. The recurring ones:

Code that outlived its assumptions

Something written correctly for how the system used to run, quietly wrong now that it runs differently. These produce intermittent bugs that resist every attempt to reproduce them, because nobody is looking at the assumption.

Trust placed where it can't be enforced

A rule checked somewhere convenient rather than somewhere binding. It works perfectly in every demo, and not at all for anyone who skips the front end — which now includes your own integrations, add-ins and APIs.

The same mistake, many times over

The most valuable findings aren't single bugs — they're patterns baked into a template or a habit, repeating across dozens of files. Fix the pattern once and everything written afterwards improves.

You get these as a written report with the measurements behind them, whether or not you go on to run the workshop.

Formats

Pick the depth that fits

Everyone is welcome in the room — engineers, team leads, product, delivery. Nothing in it requires you to write code, and the cost doesn't rise with the number of people who attend.

Talk

90 minutes

One session, condensed, open to the whole company. The cheapest way to find out whether this lands with your people.

Short

One day

The core three sessions, including the hands-on security lab. For teams that can't give up six weeks.

Medium

Two days

All six sessions, labs shortened. Good as an offsite or a focused sprint.

Most effective

Full programme

Six weeks, 90 minutes a week

The whole thing, full labs, with a week between sessions so people apply it to real work in between. Ends with the backlog.

Codebase assessment — optional add-on

Before the sessions start, I go through your codebase and find what's actually expensive about it — with measurements, not opinions. You get a findings report you can act on whether or not you run the workshop, and the sessions get rebuilt around what I found, so every example is your code rather than a textbook's. NDA as standard.

Pricing: fixed fee per engagement, quoted up front — never hourly. Typical engagements run from a single talk to a full programme with an assessment. Remote is discounted; on-site travel is charged at cost. Ask for a quote →

Who runs it

Konstantin Ignatov

Thirty years building software and the teams that build it. I've spent that time watching the same expensive mistakes repeat under different names, and the last two years watching AI make them faster.

Web Engineering Fundamentals is the book I wrote about it — on the engineering judgment that outlasts every framework. This workshop is that book, taught against your own code.

I also teach it with an example of my own: a piece of security work I built with AI assistance where I checked that the code was correct without ever checking that the design was. Five problems, found weeks later. If it can happen to the person writing the book, it's happening on your team too.

Get in touch

Start with a conversation

Tell me a little about your team and what's making changes expensive. I'll tell you honestly whether this is the right thing for you — and if it isn't, what is.

Prefer email? hello@webengineeringfundamentals.com