How I learned to stop worrying and love ChatGPT

I've been actively using ChatGPT in my work for a couple of weeks now, and can say that it was a good decision for two reasons - not only it made me more productive and allowed me to focus on stuff I really care about, but unexpectedly it also relieved me from the anxiety I was getting when trying to 'play' with the robot before and being intimidated by its capabilities.

Regularly using it as a tool helps to stop seeing a competitor in it, and even if does indeed end up this way, it still allows you to spend the time you still have in a more fun and productive way.

I have tried to put together a few patterns of where I found the robot to be the most helpful - in no particular order, along with some general advice in the end.


  • Say you've got a bunch of inconveniently long legacy shell scripts that were originally short and self-explanatory, but gradually grew into an unreadable mess. That mess, however, works, so it is difficult to justify the effort of rewriting them, and you make a promise to yourself to do it later - until you have to urgently change them and renew that promise again.

    Just feed that code to the robot and ask to re-write it in a more readable language of your choice with tests, and make that switch.
  • Speaking of unit tests - you probably have a lot of them where you don't follow through the chain of calls and just mock everything outside of the specific piece of code tested. While quite often this is a sensible thing to do, sometimes it is not - but who can be bothered with spending a lot of extra time doing something like, e.g. automating a creation of a git repository with test commits and branches to test some of your git-dependent logic (a real situation for me)? Again, now you can ask the robot to do that.
  • Splitting a longer function into logically separated shorter ones along with its corresponding tests? "Purifying" your functions? Optimising some data operation for memory use or for performance? Also easy.


  • There are often multiple ways to solve a problem, and as an experienced engineer you probably have your favourite way of dealing with it every time that problem arises. Sometimes you think that maybe it's worth trying other approaches, but your historical approach works, and you aren't sure time spent on learning the details of the new one would result in a better (faster, cheaper, clearer) implementation, so keep repeating the same pattern.

    Show your solution to the robot and ask it to re-write it using the technology/language/service X you always want to try. Even if you don't like and decide not to adopt the new approach, learning from very practical examples like this is very efficient!
  • Looking at two (or more) seemingly identical libraries for something you're about to integrate? Let the robot present a quick summary of their key differences before (or instead of) diving into documentation, boilerplate code and public discussions.
  • Ask it to criticise or advise on your ideas before making a decision. It's a free second (third, fourth) opinion that is always available.


  • Decoding complex regular expressions into a set of human readable rules and vice versa.
  • Validating syntax where it isn't natively recognised in your editor (e.g. shell commands wrapped in YAML).
  • Standard error messages from various services - just copy and paste them for the robot while you're investigating, sometimes it's something standard it'll crack quickly while you're still reading your first Google link (that is not a SEO spam or is from 2015).

General rules

  • When prompting the robot, try to explain the problem the way it doesn't require additional context ("chisel away everything that is irrelevant"). It is not a very difficult skill to master, but being able to neatly extract a problem so that you can explain it without having to run through the lore first is a very useful communication skill going far beyond prompting the robot.
  • When robot's solution didn't work from the first attempt, tell it that - like when working with a human, it often takes a few iterations to narrow it down. It remembers its previous replies in the same chat so you don't have to repeat yourself, just tell what has changed (or hasn't against your expectations).
  • In general, structure your work as if you have been suddenly assigned a smart intern who you can delegate your tasks to. That intern doesn't know a lot about how your specific business functions (yet), but it had mastered the technical skills at school and is ready to crack a problem that was properly defined.

    There is probably a lot of boring stuff you have to do every day - think about how to consolidate and delegate it, and see if you can achieve more with that extra capacity!
Yuriy Akopov

Yuriy Akopov

London, UK
comments powered by Disqus