How to code today and still have some fun

Every single day I read about code quality, AI danger, AI excitement, losing jobs, getting jobs, spending tokens and free tokens. Regardless of the tone, it looks like the AI approach is still not defined yet in many minds. And I get it. You may like it because you can quickly do things that took you days a few years ago. You may hate it, because you can quickly do things that took you days a few years ago. Let's try just to live with this and make it something valuable, without losing control, fun, and your job.

Why today's coding drains engineers

Fun is lost

Simply, because it's not fun anymore. If you coded for years, you worked with functions, arguments, console debugs and multiple browser tabs offering to help you. Today, you are more of a manager, telling somebody else what to do and most developers didn't want to become managers. Ever. We didn't like them, they told us what to do, they were not precise. Just like us now, asking Cursor for help 🙂 We just wanted to build things and solve problems! The best part of it is taken from us. Will AI steal your job? Man, it already did, you're not coding anymore.

Layoffs and career risk

It's more difficult to find joy in working when your job is at risk. Programming was always a solid job, no risks, good money, fame, respect, with a little personality weirdness in the background. This changed significantly, admit it. Engineering knowledge, experience and critical thinking are still needed, but not the ability to code itself. It hits most seasoned engineers, as we can compare how it was and how it is, and are probably aware of the struggle and consequences of losing or finding a new job.

The hard part of code review

If you still want to know what is going on, you are mostly reviewing the code. Either the code created by your agents in your IDE, or code created by others' agents in the traditional GitHub way. Now the real pain - reviewing is totally not fun, and when we speak about AI-generated code, it's even worse.

• generated code introduces slop - complex workarounds for simple solutions, unnecessary edge case checks (I know, I know, but really), code grows, you shrink
• reviewing others' AI code requires getting context, knowledge and a huge mental switch - from generation to validation
• by approving something, you take part of the responsibility for the feature, which is not what you'd like to do
• we like to code, not watch someone or something else code and check if it's correct

Need for speed

This is the most frustrating part. Even to read an article like this, you need time. And wherever you open news, Slack, you feel the race. Companies are pushing with new model releases, SaaS products are competing with each other, there is a feeling that you need to do things quickly, otherwise somebody will do it sooner. Imagine that every day around 1000 new products are released on Product Hunt.

Even at work, you can sometimes feel that "others are shipping more". In such an environment, it's hard to care about code quality. You (usually) want to keep the job, shine a bit, deliver things that people request, so you sacrifice code quality as the least important victim. You know you ship it not the way you should, but "yeah, that works, let's ship it".

What can we do about that

Enough about problems - we all know what they are. Fortunately, we are known for problem-solving, so let's try to do this in this area as well. I worked with AI tools in a few different ways, from building whole plans and features with Opus / Fable, through Cursor for daily coding tasks, up to a locally set-up Qwen 3.8 to slowly solve some non-urgent issues. I tried to create an environment that puts me back in charge, brings me some fun and control, but also avoids winning a prize for slowest employee of the month.

Sometimes code manually

Tiny chunks keep you in control

I used "tiny", not "small", on purpose. In these times, it's hard to focus even on small chunks of code like 7 files edited. Do it in tinier parts. Create a plan of work and ask your agent to create a plan of work based on your bullets. Execute the plan chunk by chunk and check after each change if you're still in the game. If you understand the code, it's good to move on, if not - check it, or undo. With such small requests, your token waste won't be that big. Let's get a sample:

Feature: We never tracked where users come from to our app. Please do so and allow filtering by origin in the dashboard.

You can just paste it to the agent and it probably will come up with something pretty solid. But you can also use a prompt like:

Hey man! I need a feature that lets us know where users come from to our app, and allows dashboard filtering. Please build the plan for:

1. Add a column `origin` to the `users` table. Write a migration and set default to null if not provided. Origins should be limited to (`google`, `newsletter`, `friend`, null).
2. Add a form to registration (optional) that allows entering this field.
3. For newsletter, maybe we can detect it automatically and pre-fill.
4. Add a dropdown in the dashboard to allow filtering users by origin.

The plan should be done step by step. After each step I want to review the outcome before going further.

That gives you a lot. You're still not coding, but:

• you know what's going on
• you may expect a result and have a reference to compare the generated code
• you can review (or even run your friend BugBot) after every part - that will avoid a long and unhealthy iteration at the end
• when somebody asks you in a meeting "how it's done", you will know without asking your agent! A bit of fun is back 🙂

What a discovery! Tiny chunks are easier to review

You are still not coding, but the above gave you a bit of control, taste and ownership of what you are actually doing. But it gives a few more things! Imagine sending this code for review to somebody else - you know it doesn't include any shitty artifacts and overengineered things that could be done more easily. You can answer comments and go through the review smoothly.

But hey, there is more! In this example, you can split all 4 points into separate pull requests without losing anything - they don't need to be merged together. Hidden backend change, adding form input, newsletter fix, dashboard filter. They need to be done in order, but not together. Your code is simple, changes isolated, reviewer is happy, +10 points to fame and glory. But really, it is super helpful to see such a thing, instead of one 30-file PR with multiple Bugbot fixes and comments.

Hire a stupid friend

Like an older model that is cheaper and less powerful than all these modern gazillion-token-context ones. You don't need to switch to the latest one, unless you want to be first to humble brag about "Fable created whole app overnight" on social media. Old models are fine - they make mistakes, but are cheap and not so powerful so you'd need to consciously set better context, switch chats, and set requirements more precisely. You can also think: "OMG, you little silly agent, let me show you how this should be done", which is a bit of fun too.

Not all engineers will be needed, but try to be the one

Unless you are buying a farm, moving to gardening or running a food truck, you probably would like to stay in your engineering role. Seeing news that a company receives 1500 CVs for a single job posting doesn't motivate, but there's always something you can do, even while you are still safe, like:

• build some project you always wanted to build, or two, or seven
• post a few not-too-stupid things on social media if you are ok with that
• talk to people, join some events, get more connections
• learn something new, get a certificate
• create a personal website (like I did!)
• train that tiny local model to rate how beautiful you look today on webcam

These things will help you stand out when the time comes, they help with SEO, and make it easier to socialize when you have things to talk about. It's hard to peacefully do these once you are in need of a new job, but it's perfectly fine to improve these constantly, even if you are just hired. Best of all, you can do them at your own pace, using AI or not, playing with technologies (I'd like to try Elixir Phoenix soon) and keeping your brain busy while Bugbot is reviewing the PR for the 10th time.

Summary

If you feel like you've read a coaching article, apologies for that, that was not my intention 🙂 I shared it because this approach worked for me. I usually work on complex projects, with many layers, with multiple people and a large codebase, which becomes larger every single day. Things described above helped me with my daily work, and also keep my brain busy, which is important at a certain age!