Engineering judgment in the age of AI

AI makes code cheap.
Engineers keep it valuable.

Your team ships more code than it can properly review. Knowing what that code will cost you is what I teach.

A codebase assessment · a workshop · or both

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. How much it costs 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, and teams accumulate code nobody understands.

Nothing on any dashboard shows this. You find out months later. A change that should take a day takes three weeks.

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.

The answer isn't to use AI less. It's to keep reviewing the design, not just the code.

How this works

An assessment, a workshop, or both

Assessment

On its own

I read your codebase and identify what's making it expensive to change. You get a findings report you can act on. No workshop required.

Workshop

On its own

Six sessions on engineering judgment, taught using examples I bring. Available as a single talk, a one-day workshop, or the full six-week programme. Want it taught against your own code? Combine it with the assessment.

Strongest version

Both

Assessment, then workshop

The assessment findings become the session material, so every example is your code. This version ends with a backlog.

The programme

Six sessions on engineering judgment

Ninety minutes each. Roughly a third framing, a third discussion, a third hands-on work, and every session ends with something written down. In a tailored engagement, we do the hands-on work on your own systems. Otherwise, I bring the examples.

1

Why our tools exist, and what they cost us

Spotting decisions that made sense years ago and no longer do.
2

What actually happens when a customer clicks something

So problems get found in minutes instead of days.
3

Who is responsible for what

Where ownership boundaries sit, and why they decide what a change costs.
4

Keeping customer data safe

Why security problems are almost always someone trusting the wrong thing. Includes 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 modes, and why complexity compounds faster than anyone plans for.
6

Working with AI without losing control of your product

What the tools are genuinely good at, where they fail, and why the review still has to be yours.

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. Paired with an assessment, this is the one that ends with a backlog.

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, but on-site travel is charged at cost. Ask for a quote →

The assessment

What I examine, and what you get

I go through your codebase and identify what's making it expensive to change, with measurements rather than opinions. Reading a system properly turns up things that were never on anyone's roadmap. The recurring ones:

Code that outlived its assumptions

Something written correctly for how the system used to run but quietly wrong now that it runs differently. Code like this produces 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, and you can act on it whether or not you ever run a workshop. NDA as standard.

Both together

Why combine them

An assessment tells you what is expensive. A workshop teaches your team to spot it without me. The assessment findings shape the workshop, so the exercises work on your team's own decisions, assumptions and failure modes rather than textbook examples.

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.

Why it works

Three questions, asked without being prompted

Six sessions in service of three questions your people end up asking on their own about any change in front of them, theirs or a machine's.

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.

Three outcomes of a full engagement

Primary outcome

Your engineers develop better judgment. The three questions above, asked without anyone prompting them. This is the part that transfers to the next framework, the next system and the next model.

Mechanism

They build it on their own system. Judgment does not transfer from textbook examples. A tailored engagement works on your code, so the practice and the product are the same thing.

Business result

You keep a prioritised backlog of what is expensive. The most costly problems in your product, ranked, with the reasoning attached. This is the outcome that needs an assessment first.

A list I hand you is a consultant's opinion that expires. The same list, written by your own people, comes with a team that can see the next one without me.

The book explains the principles.
The workshop puts them to work.

Web Engineering Fundamentals is thirty years of engineering judgment written down. The workshop is that book taught by the person who wrote it, and a tailored one teaches it against your own code.

Request a sample chapter

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, and it is the reason this workshop exists.

I teach this with a mistake 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