DEV Community: GlockOClock

AI prompting course - the worst AI ad I ever saw

GlockOClock — Wed, 17 Jun 2026 12:50:36 +0000

I decided to try a prompting course. Maybe it's me who doesn't understand something. I need to learn this something, and I will also become a multi-millionaire with just a team lead and AI agents

I don't want to make black ads, so let's say the course is authored by a world-top-5-IT-corporation, which sells its AI (and who doesn't?). So, it's top-notch. The course itself, however, is the worst AI ad ever!

New language
Fair indeed - AI+LLM is a new way to communicate with a computer. Previously there were only programmers and mortals who use rigidly developed functionality. But now, you can bend a computer to your will by talking to it in human language and get results which were not exactly programmed. I never thought about it, but in tech-philosophical meaning it's a strong point.

Evaluate and iterate
The optimistic introduction ends in 10 min, and we're getting to the main item: AI makes mistakes. It makes mistakes. It can be wrong. You need to check, because it can give you false info. AI is not a one-shot tool. You need to iterate. Don't hesitate to iterate 3-5 times.

Oh, I don't have problems with that. Those $50 000 are anyway lying on my bank account without use, I can spend tokens generously.

You read that right! Talking about AI problems takes 7 times more space than about its use (I counted minutes estimated for the course reading and videos length). The course classically conditioned me like Pavlov's dog to never use AI, because it's always wrong.

Practice and multi modal prompting
Not bad, good examples of how to mix pictures, documents and text in prompting to get better results. But AI makes mistakes! You need to evaluate and iterate.

Responsible use
At the end, there goes another verse of the "mistakes" song, where they introduce you hallucinations. Hallucinations, it's when AI proposes you to sweeten your tea with a spoon of salt. Or skin your neighbor with a plastic fork from doshirak. Yeah, it can propose a lot of things, you have to consult with another AI to make sure the first one is aligned with common sense, or just keep a human in the loop to verify the generated stuff. Verify it always, because AI makes mistakes!

Racism, ageism and biases
The most unexpected item for me was a warning that I have to write my prompts in a tolerant and inclusive way! Because AI may not understand correctly and start teaching me how to decapitate infidels or something. Ye-e-e-eah, that sounds like a great friend for the young generations to discover the world and learn...

At this note the course ends. Nothing else! While it may give so-o-ome slight prompting skill, you'll mostly spend time listening to complaints about AI. Champ, I recommend you against it! A prompting course is nearly useless, artificially prolongated and without any really good info. I'm not even saying how discouraging it is.

Imperative and declarative prompts
To my surprise, the course doesn't talk about request formulation styles (which I guess any engineer learned on university AI lectures):

Imperative (how to achieve the result): you step by step describe to AI what to do. For example, "I'll ask you several questions about life situations. Explain me how a true samurai would solve them. Then turn the result into antonym - instead of courageous actions propose cowardly ones, turn loyalty into betrayal and so on." Imperative approach is good when you need precise results, a complex chain of actions or you just want to force AI to do something it's programmed not to do.
Declarative (what result to return): you describe only the form of the result, and AI decides how to achieve it by itself. For example, "I'll ask you several question about life situations. Tell me how a samurai would solve them. Give me the result in the form of a haiku of 5-7-5 size." Declarative style fits better when you're preparing formal things: meeting notes, follow-ups, agenda, etc. If you have an example of the result format, it's a good idea to give it to AI, it'll improve understanding.

But AI makes mistakes! Don't use it! Don't buy it! Yes, it's a revolutionary tool and our future, but keep your hands off it, and especially don't give it to your children! God knows it'll teach them how to mast...

AI life coach that teaches selfishness and dishonor... in rhymes

GlockOClock — Sun, 05 Apr 2026 14:04:22 +0000

This is a submission for the DEV April Fools Challenge

What I Built

That's a tiny black-humor chat bot, which gives you negative advice (to be a coward, lie, rat on others, etc.) in rhymed haikues (Japanese poems). This is strictly a joke project with all the necessary disclaimers.

Demo

Code

https://github.com/IlyaFaer/life_coach_joke_ai_chat_bot/

How I Built It

Python for programming language
FastAPI for web framework
Google Gemini API for AI cloud model
A precisely formulated context for the AI model to generate responses correctly

[Boost]

GlockOClock — Mon, 02 Mar 2026 10:13:05 +0000

Kaizen Master - Solution for Technical Debt (and Legacy Code)

GlockOClock ・ Feb 26

#agile #programming #productivity #development

Kaizen Master - Solution for Technical Debt (and Legacy Code)

GlockOClock — Thu, 26 Feb 2026 09:23:05 +0000

(a short cookbook is at the bottom of the page)

~70% of developers call technical debt the main obstacle in their job. The problem scale estimates ~$2.4 trillion/year loss only in the US (e.g. CISQ report, AEIdeas Post). The first 1-2 years a product is usually fine, but then you see 30-60% time being spent on fixing.

Business wants high speed, and devs often don’t have time to study a case deeper, find a better solution. Instead, we commit a fast one, which causes na-a-asty accumulative quality decline.

While both speed and quality are needed, they are rarely achieved together. As an engineering manager, I thought about it and during the last 1.5 years tried an approach based on Kaizen. Its goal is to gradually reduce technical debt without rewiring much resources. And, chief, it gave results!

Kaizen

Though Kaizen is popular in IT, it’s mostly used in the “continuous improvement” meaning, which is not exactly correct. Short history lesson: during WWII, resources and specialists in the US were tight, so as time, while the rival’s Blitzkrieg strategy had high speed. American industry had to keep up, improvements were needed, but large modernizations were no go. So, the idea of small periodic zero-investment improvements came in. On long distance, little steps gave strategic level impact. A bit later the approach came to Japan, where due to cultural features (Bushido, Shinto, Buddhism), it grew into Kaizen.

Kaizen is a methodology of small, prolonged over time improvements of simplification, cleaning and ordering nature. Fixing bugs and adding new features is not a simplification, nor a zero-investment. Code refactor, process reorganization and algorithm shortening - this is Kaizen (philosophical objections possible). Thus, it’s a bit more than just “continuous improvement”.

Transactional Kaizen

Kaizen is often criticized for stopping work when a chance to improve is found. Indeed, it can disrupt development, especially in cross-functional teams and matrix organizations, where resources are on-demand. Plus, improvements can spin other improvements, which leads to even bigger disruption. Here comes a less chaotic Transactional Kaizen.

In my current collective, we work in 6-week-long transactions (projects/epics). During a transaction, we stay on planned features and bugs. If we see an opportunity, we don’t improve immediately. Instead, we leave a TODO comment in code (faster than opening a backlog, creating a task).

As a transaction ends, we run Kaizen “blitz” - a week of improvements. No bugs fixed, no functionality added, only TODOs and refactor. But that's not all!

Zero-Investment Improvement

Say we read an object from a database and update it. Under the hood, it does 2 DB requests, SELECT and UPDATE:

attr = Attraction.objects.get(pk=1)
attr.name = "new name"
attr.save()

Though it’s a common way to update an object, it can be done with just one request:

Attraction.objects.filter(pk=1).update(name="new name")

This small modification saves some processor time and look at it! We don’t even need a new test case, as we change the existing code.

Say we have tests that need test objects. E.g. to test a vacation plan, we need attractions (museums, beaches, etc.). Such tests quickly grow boilerplates. On a Kaizen blitz, we write an attraction init function with default values and flags for multi-step operations, so we reduce boilerplates as well as speed up writing the future tests.

Say we have a Docker container based on image. During a blitz, we change it to image-slim to reduce the container size, hence speed up its building.

These are "small zero-investment improvements". I guess, champ, you agree that one doesn’t take much of your time, 10-30 min maybe. Do it on a periodic basis, and code can become art, though it’ll take some time.

Kaizen Master

A step away from Kaizen is that we have only one person for Kaizen blitz. Why? Imagine you put a team of 5 devs on it. Will the department stop for a week? Isn’t it a big resource rewire in terms of business? We probably can use a shorter blitz, say 1 day, but then we need to choose a day and sync devs, or make them choose a day each for themselves… And how to prevent them from grabbing the same TODOs? A lot of “if”.

So, in each team we install a Kaizen Master (KM), who after every transaction (project/epic) does blitz. As you might have guessed, it’s the technical team lead. Here is why:

Lead reviews all pull requests and projects, thus, aware of what’s going on in code. Others will spend more time studying what they didn’t see yet.
Lead tracks all code, thus, has an eye on global inconveniences and patterns, like lack of testing utilities and boilerplates.
Lead is usually the top experienced employee with architectural skills and strategic vision. These items and Kaizen complement each other.
After a transaction is finished, our leads usually spend time with managers, deciding what’s next, who to delegate, etc. A blitz with a comparatively low load and free roaming time (there is no plan for blitz) seems a good time for meetings, brainstorming and chaotic calls.

With this in mind, tech lead seems the most effective person for blitz. They’ll improve fast, accurately and considering long-term consequences.

When to Apply

Kaizen Master is for fast growing SaaS/PaaS projects, such as fin tech, web services, cloud products, etc. They are long-term, have large multi-tenant codebases, require to often work on already implemented functionality (add new features to it). And project resources are limited. Huge amounts of work on tight deadlines happen in rich corporations all the time, so don’t take “limited resources” too straight.

KM fits well with Shape-Up, Scrum, Rapid Development and Extremal Programming methodologies. Basically, any transactional/iterative approach fits.

If a team has time for improvement sessions, Kaizen doesn’t make much sense. Short-term (<1 year), contract development and projects with generic logic (e.g. REST API limited to CRUD and filtering) will not benefit.

Profits

It causes systematic code and product quality to rise, though it may take ~8-10 months before impact becomes significant (which isn’t much in terms of business).
Resources are not drastically rewired - the team keeps working, while KM is on blitz alone. Depending on transaction size, KM will spend 10-15% of their time for improvements, which isn’t a lot.
No planning, tools or bureaucracy - improvements are small, spontaneous and informal.
Gives the KM time to review the codebase (not just out-of-context pull requests), which improves their knowledge of project and team, which helps in architecture and strategy.
KM helps to avoid scope creep, as improvements are separated into blitz.

In Anuran (where I work), we have a ~4 years old codebase. 1.5 years ago, our technical debt was ~40% of work time. It’s because we started the project with prototyping - developing pieces, keeping successful ones and then merging them into a system. Today, we spend only ~6% of time on technical debt. Sounds like success?!

Cookbook

So, the finalized recipe of KM:

Transactions:
Split the work into large periods - transactions. In most teams, 6-8 weeks is enough for code to grow significantly and obtain problems. Fit transactions to your sprints if applicable.

Kaizen blitz:
1 week is enough to review a lot of code and improve it. There is no work planned for the KM during blitz, and it must not be considered as spare time. It’s reserved for quality control, only urgent problems should be attended to by KM.

(It’s why we do blitz periodically instead of event-driven - there is always something else to do urgently, so improvement is delayed indefinitely. When time is reserved, even though it’s not much, it’s used efficiently.)

Simplify:
Only simplifications are done on blitz. Bug fixing and features (even tiny) are not. Most activity should go around refactoring, erasing unneeded code, reducing dependencies, writing reusable utilities, lowering cyclomatic and time complexity.

Point improvements:
If an improvement takes more than a day, split it into smaller pieces. It’s fine to do a part and continue on the next blitz.

Choose KM:
It’s recommended to choose tech lead as a KM due to their architectural, strategical skills, best practices and actual codebase knowledge.

Write TODOs:
To make KM work, devs should write TODOs when they find a potential improvement/inconvenience.

Do not:

Use complex tools for TODO tracking. KM is a lightweight methodology, not a new form of bureaucracy.
Consider KM as an excuse to write badly, because there is time to fix it later. Technical debt piles up exactly because of this logic.
Make it complicated. 3 days instead of a week, transactions of different sizes - it causes frustration. Keep blitz 1 week long and choose transaction length according to the speed of development.