Petri Hänninen

AI tools are everywhere now. They write our emails, generate our code, draft our documentation, and summarize our meetings. There is productivity gains are real. But so is the flood of half-baked, unreviewed garbage that's clogging up our inboxes and pull requests.

Let me state the obvious: No matter if you write the thing yourself, use AI, copypaste from Stack Overflow or use a Ouija board to generate your output, YOU are the one responsible for the quality. For every single paragraph, word and em dash.

You Own It, Full Stop

The tool doesn't take responsibility. ChatGPT won't apologize to your colleague for the confusing Slack message. Claude won't be the one losing sleep when your piece of crap code breaks prod in the middle of the night. You are. Or even worse, somebody else has to clean up after your neglicence.

This should be obvious, but apparently it isn't. I've seen pull requests with AI-generated descriptions that don't match what the code actually does. Messages that are technically grammatical but communicate nothing. Documentation that sounds authoritative but is plain wrong.

You need to own your output. You need to review it. You need to make it yours.

The Hidden Cost of Slop

Here's where the productivity math breaks down completely.

Say you save 5 minutes by having AI generate a PR description instead of writing it yourself. Great. But if that description is vague or inaccurate, your reviewer now spends 15 minutes trying to decipher what it is you were actually trying to accomplish. Maybe they leave comments asking for clarification.

You saved 5 minutes. You cost someone else 15. Multiply this across a team and those individual shortcuts turn into hours of wasted time.

Pull requests inheretntly invite such back and forth. But by not making the best attempt at producing the best quality you can, you significantly increase the amount of work a PR generates for the reviewer.

And it gets worse. When people consistently receive low-quality communication from you, they stop trusting it. They start skimming your messages. They assume your documentation is probably wrong. Your credibility erodes, and that's much harder to rebuild than the few minutes you saved.

The productivity gains turn into a loss of both productivity and credibility.

How to Actually Capture the Gains

The solution isn't to stop using AI. The solution is to own your output.

AI can be genuinely great for things you struggle with. No matter if your biggest struggle is staring at a blank page, fixing grammatical issues in the final product or anything in between, these tools can give a big boost.

But you need to ensure your work is the best quality YOU can produce. Not just the best quality the latest LLM can produce.

The Bottom Line

Using AI responsibly means you understand your tools, you put in the necessary effort to produce quality and you respect the people who have to read your output.

Wheter or not you're using AI to produce something, own it. Review it. Make it yours. Otherwise, you're not being more productive. You're just a shitty UI for ChatGPT.

Think back to when you started writing code. What actually got you interested and motivated to spend all the time and effort to learn to code? Was it the quality of code, or test coverage, or some performance metric? For me at least, the answer quite obviously is no. What instead truly got me going was the idea that I was able to make the computer do something it wasn't doing before.

This feeling, these moments and these results are, in fact, the reason why developers are needed and valued.

Big Bad Business?

Business requirements often get a bad rap for not valuing quality code, for incentivising dark patterns or for being plain stupid. This, though sometimes an understandable sentiment is somewhat lacking in perspective.

What business actually wants is to create a product that solves a problem for a specific group of people (users). A problem that is annoying enough that the users are actually willing to pay more for the solution than the cost of solving the problem is for the business. This idea captures everything from market fit to revenue to profitability.

Developers Focusing on Wrong Stuff?

Developers, on the other hand, get a bad rap for not seeing the big picture. Devs might argue for improving test coverage, maintainability, or God forbid try to speak business and talk about tech debt.

What is often missed in these requests is the reason why such things matter. I do not care about the test coverage number or performance metric itself. What I want is to create a piece of software that is able to do its thing now and in the future, and that does it without incurring unnecessary strain and thus cost for our infrastructure.

Common Ground After All

It might be obvious at this point that there is plenty of common ground here to build upon. Both the business and technical requirements strive for a solution that works, that solves problems and keeps solving them without the price of doing that becoming unbearable.

And this problem solving even is the very reason I fell in love with writing code in the first place!

So Why the Juxtaposition?

I think the clashes pretty much always come down to lack of communication skills on both sides of the table. We developers have a lot to improve on when it comes to explaining why some issues and metrics are better be dealt with before they really backfire. At the same time, the business need easily gets represetend as some vanity metrics or even cold hard cash.

If you're struggling to communicate, my suggestion is simple. First, take a big breath. Second, define the problem and suggested solution. Third, define what is the highest impact to effort improvement that you can do to make the solution even bigger, better or less costly to provide. Fourth, execute.

Note that especially step #2 is extremely easy to gloss over. "We all know what we're here for we've been doing this for 15 years" is not an acceptable answer. Every individual has their own answer to these, and even though a consensus and alignment may have existed at some point, these definitions have a tendency to drift apart unless explicitly managed. This driftage needs to be undone periodically.

After aligning yourselves towards the same target, step three should be quite painless. Even though the estimates on what's important can vary quite a lot, those differences can only arise from people not having the same information available or understandable for them. At this point the competing ideas are not "dev vs biz" but a concrete initiative against another, and those can be more easily scrutinized without the us vs them mindset coming in the way.

Having such a clear goal setting and structured approach to priorization is, in my opinion, the fastest and most efficient way for getting cool shit done together, as a team. If you find step three to cause trouble, take a look at for example the ICE scoring model, which in its simplicity is quite efficient.

This is just a note to self.

If you need captcha, rewatch Theo's video. Probably use hCaptcha for at least anything that's not absolutely huge or otherwise valuable/critical. Maybe could look into Radar by WorkOs.

Hi you! I'm Petri and I am a Software Developer among other things. I currently work at Duunitori, where I try to build the best experience for those who look for a job and those who are in a need of somebody to do something as well as enable our whole software engineer team to do the same.

I figured that I'd start writing and publishing some notes of mine. I will definitely not be keeping a strict schedule nor otherwise guarantee anything on this site. You could expect something interesting and I might deliver, or you could not, or I might not. Either way, we'll both be suprised.

The general idea is for the posts to be less like complete, coherent write-ups and more like living documents that get appended, edited, changed or otherwise modified at any time. So something like a digital garden.