Software Development

Claude Code и технические инструкции

graker — Tue, 13 Oct 2026 08:50:00 +0000

After the «redesign for 600» updating Docturist has become much easier. Yesterday we shipped the integration with the Ferma fiscal data operator, which had been ready even before the redesign, but we did not get to switch it on. Now we have, and even the merge went almost without conflicts. Life is getting better :hat:

By the way, during integrations and deployments like these it has turned out to be very useful to involve neural networks in preparing the accompanying materials. I would never trust an AI to write my own articles: robot ears stick out of every sentence afterwards. But preparing an article like «How to use the feature from this commit» is a piece of cake. The text is technical, written precisely, and needs no literary flourishes. Here, for example, is a manual on issuing receipts: I hardly edited it by hand.

What is more, monsieur Claude can connect to Chrome and Playwright, so making screenshots can be handed over to the robots completely too.

As for the manual, Claude did not just make all the screenshots (although he did). When we finished and rolled out the new design, it suddenly™ turned out that screenshots of the service and even videos are elements of the design itself. Except the design is new now, while the screenshots and videos are old. Besides, the project blog already had several manuals from before the redesign. And of course they all became outdated overnight too.

I really did not want to reshoot all of that by hand, so I dumped it on Claude right away. And here is what he did:

Wrote a manifest listing the screenshots from different sections of the site: which pages to take them from and under which accounts.
Wrote a script that takes all or some of the screenshots from the manifest, logging in with the right account and opening the right pages.
He even wrote a script for the video, which records several pieces from different sections separately and then glues them into a complete intro.
If a screenshot needs an error that is hard to reproduce (say, a rare error from the fiscal data operator), he simply draws it by manipulating the DOM, about ten times faster than I would have figured out how. And if there is not enough test data, he generates it on the fly, or also inserts it into the DOM.
Now, if I decide to change the look of some page a little, or rearrange blocks, I just rerun the script* and immediately have a set of updated screenshots.
And if I add a new section or feature, Claude takes the screenshots and adds them to the manifest as well.

Highly recommended, if you are not doing this yet.

*actually I do not rerun the script, I am too lazy. I tell Claude to reshoot the pages I need, and he reruns it himself.

PR на шиссот!

graker — Wed, 07 Oct 2026 18:30:00 +0000

The other day a PR of 610 files was finally defeated and merged! The result is a complete redesign of Docturist. The public part (the landing page and the blog) got a bit of it too, but first of all it is the whole inside: all the pages, forms and dialogs of the CRM itself.

This is one more example of how you can get carried away solving tasks with a neural network. Initially the idea was much more modest. The dashboard, also known as the desktop, also known as the home page inside the system, was made rather simple. This is what it looked like:

Of course, the travel agents reported that they did not use the widgets on this desktop at all. Only the links, to jump straight to the section they need. And I wanted it to be rather a quick access to important sections and information. So that some things could be done without leaving the dashboard at all.

That is what Claude Design and I took on. We rethought the contents of the dashboard to make it convenient and actually used, not just a place for links like the desktop in Win95. And the «before» above turned into a new «after»:

Now there are all kinds of metrics, and most importantly a smarter bookings feed. You can look at the latest bookings by date, or at the ones that need particular attention.

I did not hold back Claude's design impulses, so on top of that I got a new style at once. The previous style was built on the Color Admin theme, which I bought specially back in 2018. The theme has of course aged somewhat since then and lost some of its relevance.

Anyway, once there is a new look, you do not want to leave the other pages in the old one. And so, page by page, component by component, first with Claude Design and then with Claude Code, we brought the whole service to the new styles. And since just redrawing things is boring, we also rethought, improved and remade the components on the pages along the way.

That is how we got a PR of 610 files. Which of course wore me out with reviewing and testing. In the nutshell, the points of my talk (in Russian) on this topic still hold. You have to test, structure, decompose. But not looking at the generated code, as Robert Martin advises, does not work out for me just yet: I checked every screen, inspected the changes, the tests, the front end, and in each part I found something that was not done quite right, or did not work, or caused some new problems.

But in the end I checked everything, tried it by hand and shipped it. So now Docturist has not only a new, rethought, modern design, but also all kinds of usability bits, including:

— Docturist remembers and shows right away the set of tour operators the agent works with most often, no need to search through autocomplete every time.
— / or Ctrl+F immediately starts a search across all data (pressing Ctrl+F again starts the browser's native search).
— Booking documents can be generated and signed right from a popup on the desktop, without having to open the booking.
— The calendar works better on mobile devices (the mobile calendar is simply made anew).
— The profile page is finally split into 5 sections by the topics of the settings.

I am happy with the result, and now updates can be rolled out more often again, without reviewing such huge PRs. Overall the redesign took about a month and a half. Next up are the integration with an online cash register service (already done) and a dark theme (also done). Let's go!

Docturist, a smart planner for travel agents

Антропики всех забанят?

graker — Fri, 02 Oct 2026 05:14:00 +0000

For the last few days, reports of fierce bans from Anthropic have been popping up everywhere. Some authors report annoying bans in their channels. In several themed communities many people share how they got banned alive. On Habr they write that the whole of Hong Kong is being banned for using VPNs, and we in Russia are getting caught too. Someone from Yandex even complained they had to switch to ~~GigaChat~~ Codex.

Numerous reviews also say that a new claude.ai account now requires showing your passport and social security number and handing in biomaterials. So, dear friends, maybe neural networks will not replace us after all: we will not pass on skull shape.

On the one hand, take that, robots! I have not forgotten how to code by myself yet. On the other hand, I would like another month of vibe coding my little new video game at night…

I am holding on so far, though: since August I have been hearing from different people that they are getting banned. And I myself forget to turn on the VPN every other time, keep discussing Russia's traffic filtering boxes with Claude, make it install the Ministry of Digital Development certificates and parse resources that do not work from abroad. But apparently the robots will start suspecting something soon.

By the way, my current subscription runs out on Monday, so I will be squeezing every last drop out of it all weekend!

P.S. So how is everyone coping, colleagues? Codex, Cursor? GigaChat? 一个鲜为人知的中国神经网络? Human-hand-coding?

Нейроотладка

graker — Mon, 07 Sep 2026 22:05:00 +0000

Neural networks keep mercilessly replacing us. This time, in investigations and debugging.

Given: an editor lost a bit of content. Clicked something and everything was gone. Never happened before, and here we go again.

— Hey Claude, here are cleaned-up database dumps from several sites, an editor was doing something on the master, and content disappeared on several sites. Find where it went and figure out what the editor clicked. Just be careful, it is three gigs.
— Avec plaisir. And I will not parse the dumps, don't you worry.

He looks at the content synchronization logic. Spins up mysql containers in Docker on his own, loads the dumps. Unwinds the page revisions across the tables. 15 minutes later he writes a report: right here, on such-and-such date and time, the editor unsubscribed from the content and everything was gone. Here he restored the subscriptions, but it was too late, ha-ha-ha. And here is what to configure so that it is never too late again. But that is for another time, for now, sorry, the content cannot be brought back. Thank you, you are welcome, write again.

And how could this be automated even further? Let him into production, perhaps, and into Jira, so that he explains it to the editor himself? Some people, I know, already do, but we are still scared to let him into production. And not every project allows it anyway.

And what comes next at all? What did they do in Frank Herbert's books to completely ban all these computers?

upd: Humans in leather are still needed after all.

A thorough study of the report revealed several problems that the AI decided not to explain and that, in principle, cannot be explained by the report's findings. I dug deeper myself into places the neural network could not reach and found a bug in a third-party SaaS service used in the project.

I think Claude would have found it too, but who would let him in there.

I feel mighty. Take that, robots!

Доктурист разжился курсами валют туроператоров

graker — Tue, 18 Aug 2026 11:45:00 +0000

There's a new update in Docturist: we've added support for tour operators' exchange rates. What does it mean? Tour operators settle foreign bookings in a currency, dollars or euros. Which makes sense: they have to settle with foreign counterparties while the exchange rate keeps changing.

So the price of a tour is usually given in a currency, while the operator accepts payments in rubles, converting them into the tour price at some rate. Not at the Central Bank rate, of course, but at the operator's own rate, which each operator sets on its own (usually a few rubles above the Central Bank rate).

In Docturist you can keep bookings either in rubles — manually converting everything you need — or in a currency. And if you keep them in a currency, questions usually come up: roughly how much is the tour in rubles today? How much is left to pay? How many dollars of the tour price should be counted if the tourist paid $1000?

Until today, Docturist showed calculations at the Central Bank rate, purely for illustration, which is only good for a rough estimate. For an exact figure, you could enter the conversion rate manually and see the amount.

But why do it manually when you can take the rate from the operator's website and use it to get exact amounts? So we got busy and added support for operators' rates. Now, if exchange rates are supported for the tour operator the booking is made with, they take priority over the Central Bank rates and the user gets exact calculations (manual input is still possible and takes precedence).

From a technical point of view, writing dozens of parsers is, of course, not my favorite pastime. Somewhere there's an SPA with hydration after load, so plain requests don't see the rates and you have to hunt for an API. Somewhere foreign IP addresses are banned, so you have to hand the AI fixtures manually to test the parser. One site went and banned well-known hosting address ranges, so you can't just parse it from a live server. And somewhere there's even a bot protection script, and you can't get the page HTML at all without playwright/puppeteer.

It's unpleasant to wade through these thickets: you're not stealing anything, it's all purely for the convenience of users who bring money to these very operators. But there are so many restrictions, as if it were some terrible secret and not a USD/EUR block displayed right on the home page.

Anyway, the first dozen operators have been conquered and added to the service — both as an automatic per-operator parser in the queue and as a fallback to manual input. Plus plans B and C in case everything breaks or someone bans our IP.

We keep working!

P.S. And if you're interested in the Central Bank exchange rates, check out the Currencypotamus bot.

RTS Дачники против слизней

graker — Tue, 04 Aug 2026 09:20:00 +0000

As part of preparing for my talk, here's an example of vibe code, so to speak. I came up with a few small ideas and tossed them not even into Claude Code, but just into a Claude chat to discuss — and it went ahead and built a game demo in 15 minutes. We polished it just a tiny bit, and here I am sharing the result.

It's an RTS/base defense game: gardeners (played by my usual characters) have to defend a greenhouse from slugs attacking in waves. Stock up on cucumbers, buy units, squash slugs while the greenhouse is still standing. Of course, it's only a prototype, Claude made the characters out of emoji, and there isn't much variety either. But — tweak the balance a little, add map generation, buildings, art, sounds, and…

Even so, here's what you can do with an agent in, I repeat, just 15 minutes.

It's all written in JavaScript, Claude demoed it to me right in the chat. A little over 800 lines of code — and that's including all the texts and lines, HTML and styles. Plus the game logic, and even a pathfinding algorithm that leads the slugs to the greenhouse (flow field).

You can play it right below the fold.

Unleash my inner speaker

graker — Mon, 03 Aug 2026 10:40:00 +0000

Time to unleash my inner speaker. I'll be giving a talk at the https://zeldev.ru/agentikus meetup in a week. The talk is based on my April theses, so to speak — almost half a year has passed, and I have things to add.

The last time I gave a public talk was probably around 2015. So I'll have to prepare: I'll be drawing the slides with pebbles in my mouth like Demosthenes. Hopefully it'll turn out interesting.

Обновления в Ботопотамах

graker — Tue, 28 Jul 2026 22:20:00 +0000

The other day I managed to do some solid work on Botopotamus.

First, I've added a new public bot: meet Currencypotamus. It takes the XML with exchange rates from the Central Bank, parses it and shows it to you. There are plenty of such bots, but ~~this one's mine~~ the trick is that during the window when the Central Bank usually publishes new rates, this one keeps knocking on its door. And if you subscribe, it'll notify you right away when the rates are out.

This can be useful for making decisions, for example, in the travel business. Rush to pay for bookings now or put it off till tomorrow? Currencypotamus will tell you in Telegram or in Max.

Second, I've thoroughly reworked the platform itself. I made a modular architecture — now each botopotamus is added as a separate directory with all its logic isolated inside. With access to shared features: cron, cache, queues, events, statistics and so on. A module is a bot feature, while the bots themselves are added from the admin panel: enter the Telegram and Max credentials, click the features you need — and the bot is ready.

I've added localization: the language is detected from the user's message, and if a bot has several languages, you can switch manually.

I've slightly improved the monitoring bot: now if a site goes down, the bot pings it more often for a while — to detect sooner when the site is back up.

For these changes, I've put together a new Botopotamus landing page. The old one was purely about the monitoring bot, the new one is about bot development. And the public bots each got a mini landing page. I think Claude Design did a pretty good job, personally I keep getting mesmerized by the flying elephant.

We keep working, a couple more useful bots are in the pipeline.

Нейросети и анализ кода

graker — Wed, 22 Jul 2026 09:15:00 +0000

Yesterday I was estimating a group of ~40 tickets. All of them were created from an AI code analysis report on a large Drupal project. The project is about 10 years old, the codebase has evolved all this time, 20 subdomains, integrations, APIs, content synchronization — all in all, a cool project.

The report is structured, the neural network checked the project for all four horsemen of the apocalypse: Vulnerabilities, Bugs, Slowness and Dirty Code. Originally the report produced many more tasks, but I slapped won't fix on about 30% of them right away. There were glitches and misunderstandings of the context. But 40 tickets still remained.

Most of them are also tasks of the very lowest priority, like

a custom module doesn't declare a dependency on something like paragraphs;
somewhere in the code a brazen programmer called \Drupal::service() instead of using dependency injection;
somewhere deprecated Drupal versions haven't been removed from the supported versions, and so on.

There were also a few more serious issues:

a couple of N+1 problems;
several XSS vulnerabilities (only accessible to admins, but still);
several places lacking checks for whether a key exists in an array (spamming the log with warnings);
and even one timing oracle vulnerability.

Yes, dirty code is a sign of dirty thoughts :) Yes, it would be nice to clean it all up. But apart from 3–4 issues, it adds up to more than a hundred hours of work in total, and the payoff is slightly cleaner code, tidied-up legacy, a bit less tech debt and fewer warning/debug entries in the log. It's nice, of course, when the client doesn't mind such a spring cleaning. And all honor and glory to the account managers who can convince the client of the need for such cleaning when its value to the end user is roughly zero.

And these reports still leave a strange feeling. They do find something. But so far these reports bring much more fuss than benefit.

Смена Max API URL и сертификаты Минцифры

graker — Sat, 18 Jul 2026 10:40:00 +0000

Colleagues, if you develop bots for Max or just have some running there, a reminder: starting tomorrow you have to use the new API URL: https://platform-api2.max.ru.

You'll also need to add the Russian Ministry of Digital Development certificates to the host's trusted ones, since the new API URL works with exactly these certificates.

How to update the certificates

In these examples I download the certificates into build/certs/ because I then add them to docker containers from there, but you can download them wherever you like.

Download the current files (the official source is gu-st.ru; its own certificate is signed by the same CA, so you have to disable verification with the -k flag):

curl -k -o build/certs/russian_trusted_root_ca.cer \
   "https://gu-st.ru/content/Other/doc/russian_trusted_root_ca.cer"
curl -k -o build/certs/russian_trusted_sub_ca.cer \
   "https://gu-st.ru/content/Other/doc/russian_trusted_sub_ca.cer"

Check that you got something meaningful (a valid certificate with the expected subject/issuer):
```
openssl x509 -in build/certs/russian_trusted_root_ca.cer -noout -subject -issuer -enddate
openssl x509 -in build/certs/russian_trusted_sub_ca.cer  -noout -subject -issuer -enddate
```
Expected subject/issuer:
- root: subject = issuer = C=RU, O=The Ministry of Digital Development and Communications, CN=Russian Trusted Root CA
- sub: subject = C=RU, ... CN=Russian Trusted Sub CA, issuer = ... CN=Russian Trusted Root CA

In the Dockerfile I add

COPY ./build/certs/russian_trusted_root_ca.cer /usr/local/share/ca-certificates/russian_trusted_root_ca.crt
COPY ./build/certs/russian_trusted_sub_ca.cer /usr/local/share/ca-certificates/russian_trusted_sub_ca.crt
RUN update-ca-certificates

and the certificates get installed in the containers that need them.

You can also download the certificates from the Gosuslugi page.

Уведомления в Доктуристе

graker — Thu, 16 Jul 2026 13:05:00 +0000

We've rolled out in-app notifications in Docturist. First of all they work within agencies: if someone adds, changes or deletes a booking, a payment, a deadline, or changes a status, the other agents (who have access) get a notification. But solo agents will find them useful too — if they use the bank or document-signing integrations.

Notifications land on the bell icon, accompanied by an animation, a semi-transparent popup for 5 seconds, and a gentle unobtrusive "boop" from the speaker. The popup and the "boop" can be turned off if you like.

Generative neural networks and coding agents do let you juggle much bigger chunks of meaning when developing software. The first implementation proposed was an even more massive shotgun surgery than the previous feature — dozens of changes of 3–4 identical lines each, implementation details leaking into controllers. 60+ changed files (tests included). I suggested a more elegant solution to Claude, with practically no repetition, DI and event-driven, all just like in the finest houses of Rio de Janeiro. The result came out prettier, clean as Robert Martin's tear — but at 100+ changed files.

It works well; now I should hook push notifications up to it. And find some time to write it up as a few small case studies.

Виртуализация локальной разработки, docker-compose и traefik

graker — Thu, 25 Jun 2026 15:20:00 +0000

A long time ago I described a fairly simple way to virtualize the projects I work on, so it's easy to switch between them and they don't get in each other's way. 7 years have passed and of course the approach has evolved. Back then, using separate containers started with `docker run` was faster and more convenient, so I didn't write Dockerfiles and docker-compose files. But progress did catch up with me on this one and won. Now I use docker compose for local development too.

Still, I try not to use tools with all sorts of presets like lando or ddev. Mostly because when I ran into them, they worked fine — until I needed to change something in them or do something non-standard. After that the brain-melting began, sometimes so bad that it was easier to rebuild everything myself right away.
Besides, if you build "clean" environments, you have a chance to better understand how it all works, and if you use lando, forge, ddev and the like — the opposite.

So, why docker compose is better.

Доктурист добавлен в интеграции Qui-Quo

graker — Sun, 14 Jun 2026 22:25:00 +0000

The kind people from the Qui-Quo team — a plugin hardly any self-respecting travel agent can do without — have added our Docturist to their list of integrations.

Now Docturist users don't need to copy mysterious redirect addresses into the integration settings, they just tick a checkbox and the integration starts working. We keep developing the service!

Интеграция Доктуриста с Точкой

graker — Mon, 08 Jun 2026 22:30:00 +0000

Travel agents may handle dozens of bookings at once. Every day there are new payments from tourists, every day you have to manually open the bank, find the payment, mark the tour payment in the CRM (otherwise how do you keep track that nothing's been forgotten?) Sounds like a trifle — but it piles up daily, breaks your rhythm and sometimes causes mistakes. And overall it's pretty tedious — copying things by hand from one place to another. And what's tedious, we don't really feel like doing.

That's why we added the ability to import payments from banks to Docturist and started with an integration with the Tochka bank API. Here's a case study of how we connected Tochka to Docturist: we built automatic payment notifications, smart linking to bookings, and creating payment links right from the booking page. And about a few non-trivial things we had to figure out along the way. Technical and not so technical.

Given

Travel agents work with money all the time, and there are two main operations: accept a (pre)payment from a tourist, send a payment to the tour operator. Docturist already keeps a payment history and shows it in a nice timeline:

Task: build something more automated than diligently copying incoming payments from the bank client. That is, receive incoming payments in Docturist.

Besides, agents often accept payment via links: in the banking app they create a link to pay a certain amount by card and/or SBP (Faster Payments System) and send it to the tourist. It's a kind of lightweight acquiring, where you don't have to build a full-fledged payment form. And the bank doesn't mind (if certain rules are followed). Task 2: why not let users create payment links right from the Docturist interface. So they could copy them and send them to clients without having to open the banking app.

Here's what exactly we taught Docturist to do:

— receive notifications from the bank about every incoming payment;
— automatically link a payment to a booking (when possible);
— let the user link a payment to a booking manually (if the automatic linking didn't work out);
— create links for payment by card and/or SBP.

What we ran into along the way

For incoming payments Tochka sends notifications to registered webhooks, and webhooks can be registered programmatically. The user just needs to add an integration token and set a few permissions in the bank client. Webhook notifications arrive almost instantly.

Webhooks as a signed JWT

The first thing we had to figure out was the format of incoming notifications from the bank. Unlike services that send plain JSON with a signature in a header, Tochka sends the entire webhook body as a signed JWT. This means you can't just read the JSON — you first need to verify the signature with the bank's public key.

The controller reads the raw request body and decodes the JWT using the firebase/php-jwt library:

$token = $request->getContent();
$pem   = config('services.tochka.jwt_public_key_pem');
$data  = JWT::decode($token, new Key($pem, 'RS256'));

On any decoding error we log it and still respond with http 200. This is important: Tochka interprets any non-200 as a failure and will redeliver the notification. This way the business logic doesn't run, but the bank doesn't go into a resending loop either.

Testing this mechanism required separate infrastructure setup: an RSA pair is generated right in the test class, the public key is put into the config, and then we sign a test payload the same way Tochka does and decrypt it like the live application.

Smart auto-linking

When a payment comes from the bank, the system tries to find the booking automatically — by the payment purpose text (e.g. "Payment for booking DEM-001"). Here a classic string search problem arises: if the agency has bookings DEM-10 and DEM-100, searching for DEM-10 will find both. But we don't want to make mistakes linking bookings to payments, so we only link automatically if exactly 1 result is found.

If there's at least one more booking whose number starts with the found one, linking doesn't happen and the payment stays unlinked. The user will see it in the feed and link it manually. To make linking easier, the search filters out old, completed, paid and cancelled bookings.

Very smart auto-linking

So that users don't forget to include the booking number in the payment purpose, we made the default text for a generated payment link already include the number. But real-world use showed that almost all payments slip past and don't get linked to anything.

After some investigation it turned out that although payments are shown in the bank client with a proper purpose like Tour payment Full Name, booking number, as we intended, the webhook for some reason receives Payment by QR code ID QRABCD12345678 … instead. We had to implement an additional API method that, on receiving a payment with such a description, calls Tochka once more to get info about that QR code. In that info the payment purpose is already shown correctly, and the payment can be linked to the booking by it.

Currency conversion when linking

Tochka naturally sends amounts in rubles, since payments in Russia can only be made in rubles. But bookings in Docturist can be entered in USD and EUR too, since tour operators may work in these units and accept payments at their exchange rate. When a user manually links a ruble payment to a booking in EUR, the system has to calculate the amount in EUR to record it in the right currency. And each tour operator has its own conversion rate.

For these cases we made two scenarios:

Foreign currency booking + override → the user manually enters how many USD/EUR the payment amounts to (e.g. "150 EUR"), we use this value in the saved booking payment and store the calculated exchange rate along with it.
Foreign currency booking, no override → we take the latest Central Bank rate (it's updated daily). In this case we flag the linked payment as needing attention, since an automatic calculation at the Central Bank rate is an approximate calculation, and operators' rates are always higher.

Default values when creating payment links

While using the integration, it turned out that in many cases users want to create payment links with the same preset, e.g. "Card off, SBP on". A mistake in choosing the payment method can lead to financial losses (bank fees for acquiring and SBP are very different), which of course is unacceptable.

We had to implement a default setting for users specifying which payment methods are on and which are off by default, to reduce the chance of a mistake.

Sandbox

At the very start of development, the Tochka API documentation revealed that they don't have a full-fledged sandbox for making "toy" payments, only a fixed set of test requests that, if made correctly, return fixed responses. Test requests are of course not useless, but without a sandbox it's impossible, for example, to run a full test cycle: generating a payment link → paying it → receiving the payment → parsing and linking it to a booking. Only piece by piece.

In fact, link creation mostly had to be tested live, since it only works on accounts that already have acquiring activated, and for other accounts it throws a 403 "Forbidden by consent" error.

But on the plus side, the bank has an API integration support line that actually answers by email and even gives detailed information that couldn't be found in the documentation.

Results

100+ tests for all sorts of cases. We built JWT signature verification, deduplication, auto-linking with edge cases, currency conversion, access permissions. The API integration works with Laravel Horizon, meaning all incoming and outgoing processes (payment notifications, payment link creation, user registration in the system, webhook registration) run asynchronously in queues. And to notify waiting users we use websockets via Reverb.

The implementation let us build and test the logic for importing payments and creating payment links, which doesn't have to be tied to one bank. Now we need to add a layer of abstraction between payments/links and the bank API, and other banks can be connected to the system with less effort. The next integration candidate is Alfa.

The integration is already running in production. Agents create payment links right from the booking page and send them to tourists — without switching to the banking app. Incoming payments appear in the system automatically and in most cases link themselves to the right booking. Only what the system couldn't recognize unambiguously has to be sorted out by hand.

Код пишут роботы, но отвечать за него нам

graker — Wed, 08 Apr 2026 08:20:00 +0000

Lately I've been using generative neural networks in agent mode more and more in development; for simplicity, let's call it vibe coding, like everyone does. Why not? These days every toaster and its grandmother is vibe coding and telling everyone how great it has become. And in terms of opening up development to those who couldn't develop before, it really is great, by the way.

But those who could develop on their own before still look at the subject from a slightly different angle. So I decided to let my thoughts wander a bit, grumble, be a bit of a bore and reflect not on how to set up Codex or an MCP server, or how to unleash Claude Code on KWork. But on the effects, on the inevitable changes that neural networks have brought, are bringing and will bring into our daily work — into software development by living human people.

First, let's briefly define our place in space and time relative to the very phenomenon of neural networks (here and below — in software development). It's too late to discuss whether they are needed, whether they help, whether we should use them. That question is off the table. If you somehow haven't started yet, you should. The cat looks at the clock and says: it's time!

Как двигать проекты и не двинуться кукухой

graker — Fri, 17 Oct 2025 13:45:00 +0000

On a recent random coffee call (a form of networking I happily indulge in once a week) the following question came up. How do you take part in (run, team-lead, handle, manage and even code) 10+, 15+ projects without going cuckoo? And I was like: right, how?

I mean, there I am in my channel singing songs about time tracking. So it's probably not all sunshine and rainbows. But I'm holding on somehow.

As I see it, the main difficulties are three things:

— context switching,
— the constant stream of messages,
— and the general lack of time, of course.

Obviously, we're talking about projects that don't take 30 hours a week of involvement each. Otherwise it's all pointless, and the cuckoo flies off to warmer climes without us. Still, they do take quite a lot.

Long story short, over the years of all this parallelism I've developed some habits, and that's what I'm going to write about. Hard to say how critical they are, but without them my cuckoo and I would have a hard time fighting these difficulties.

Про софт-скиллы на работе

graker — Thu, 18 Sep 2025 17:25:00 +0000

Over my years of work I've heard all sorts of things about so-called soft skills, from people in charge, from HR, and from those who are (not) expected to have these very skills. During this time I've done some managing myself: as the head of my own studio, as a hired team lead, and as the head of a laboratory.

So here's what I have to say about the most important soft skills, especially for an inexperienced developer or one who has recently joined a team. So important, in fact, that if you master them, you'll be head and shoulders above many others — even if they code better. And if you're a novice team lead, they're an absolute must.

Always add value
If you're given the floor at a meeting, if a ticket is assigned to you, if someone asks you something in a chat — never leave the discussion in the same state it was in before you. Always add at least a little value to it. Don't play ping-pong with tickets…

Про звонки и совещания, часть 2

graker — Mon, 19 May 2025 18:20:00 +0000

Part one

At the same time, I joined another international team that practiced SCRUM and other agile stuff. And there were a lot of meetings/calls, given my team lead role. But you know what? It was almost the perfect example of "how it should be done" (and not only when it comes to meetings and calls).

The team had German roots, so order and punctuality reigned in all processes. You're expected to come to meetings on time; being three minutes late is a reason to apologize (although I never heard anyone being told off for it). At the same time, though, everything is strictly to the point. If you're needed, you have to come. If you're not needed, you won't be invited, no need to sit there warming a chair. If there's no agenda, there either won't be a meeting, or it will take 2 minutes (which isn't so bad, once a week).

Meetings related to the iterative development process (sprints, reviews, etc.) are usually agreed upon with everyone and scheduled at a fixed time on a fixed day of the week, for a long time ahead. Only the end of the project, World War III, or the switch to summer/winter time, which unfortunately is still alive in Germany, can interrupt that schedule.

If an unscheduled meeting is needed, the participants agree on a time among themselves based on free slots, and once agreed, everyone connects when needed. No "I'll give you a call sometime tomorrow afternoon" (meaning, sit and wait), no "we gathered at five, but the important participants can't make it, so let's wait till seven", and not even "quickly drop everything and answer the question I wrote three minutes ago".

Working on the home market in parallel was a bit wild in the light of such organization. Here we had to deal with unreliability, and demands to answer instantly at any time of day or night, and funny situations where rank-and-file employees switch to ferocious boss mode and demand everything at once. But fortunately, such situations are becoming rarer lately, and a professional approach prevails.

Про звонки и совещания, часть 1

graker — Tue, 08 Apr 2025 11:15:00 +0000

Every action or activity presumably has a purpose. We walk to get somewhere, run to get there faster, rest to regain strength, and click all the crosswalks in pictures to prove we're human. But there is one activity that many developers will confidently call pointless, meaningless and useless, and those who make others do it should be ~~shot~~ punished. I'm talking, of course, about meetings.

But is it really that bad? Actually, no. You can get something useful even out of "bad" meetings, just maybe not what you were hoping for. Besides, the fact that you or I personally didn't find anything useful in a meeting doesn't mean nobody else did. Say, the boss who needs to decide who won't get a bonus this month has already made a note of a couple of sour, uninterested faces.

Over 20 years of work I've of course taken part in all kinds of meetings. And at first many of them followed the same script. The team got together and had a heated discussion of the current project. Lots of ideas and opinions were voiced, it went on for two hours. And then what? Right, then at the next meeting it turned out that almost nobody had done a damn thing of what was said.

However, ten-something years ago I ended up in a working group collaborating with some Brits in the microelectronics industry. And one thing struck me right away. Every meeting call had a moderator, or a secretary, so to speak. He didn't know the answers to most questions himself, but he had the agenda (of his own side, at least), he owned the schedule, he shared his screen and took notes right there in SharePoint. And in these notes he didn't just briefly record what was discussed. But — most importantly — he immediately wrote down the actionables. That is, what action had to be taken as a result of the discussion. And — again, most importantly — who! had to take it.

After the meeting, all participants got access to the notes and the list of actions. And this had a dramatic effect on the results. Just try not reporting on the great successes you've achieved when, a couple of weeks later, you and all your colleagues are called upon to report on what was written down earlier!

This practice stuck with me forever, and I came across it many times later in other projects, mostly international ones. I recommend it to everyone: do it, appoint a secretary, or appoint yourself, keep at least basic minutes, and the output of all that talk will be noticeable. Especially if it wasn't before.

Especially since nowadays there are tools for recording a meeting, if taking notes on the go is inconvenient, and even for transcribing it afterwards.

The process in that group, however, also had a serious drawback, in my opinion. The thing is, when a call had an agenda only from our side, our foreign colleagues sent just the secretary. We voiced our questions, and the answer to them was always the same: I'll check with my colleagues and get back to you. That was very annoying, of course: why on earth did ten of us show up, when the whole session could have been replaced with one email with questions, and the meeting could have been scheduled when the answers were ready.

This also stuck with me, and in my dealings with clients I always stress: there will be no broken telephone with managers on my side. Only a discussion with the person who has first-hand information. That is, with me.

Then for several years I freelanced for an American team, on a highly automated e-commerce project. Which ran on Drupal 6 even when Drupal 9 was already out. I built online accounting automation for them, Stripe and lots of other stuff. The team was remarkable in that it held exactly zero meetings. Everything that needed discussing could be discussed in Slack.

And this had two main perks. First, of course, it's paradise for those who don't like calls. No need to spend time, get interrupted, synchronize. Finished a task — wrote up a thorough report. Second, written communication is always more to the point. If you can't put a thought in writing, it isn't ready yet, think some more. And write it so that the other person understands you. And they write back something you understand. Which, again, saves everyone time.

To be continued.

Про Notion, Obsidian и управление делишками

graker — Fri, 06 Sep 2024 16:45:00 +0000

Since sanctions made me urgently look for a Notion replacement, and I managed to find a wonderful little app called Obsidian, it's a good occasion to tell how I take notes, why I take them, how to migrate to Obsidian, why it's good, and whether it's good at all.

The note has a lot of letters, a few pictures and links, and mentions words like GTD and the swear words that come with them.