How a productive engineer uses AI at work (18 practical tips)
Most engineers use AI randomly and stay slow. This article shows how to design AI-first workflows to eliminate busywork, learn just in time, and multiply impact (18 practical tips)
Get the free AI Agent Building Blocks ebook when you subscribe:
For the last week, I’ve been thinking about how to get more output per hour of work. More impact from the same effort.
I realized we are all clear that coding with AI in our IDE is a huge boost. We also know that AI does not replace judgment. It magnifies whatever judgment you already have. When the thinking is sloppy, AI makes mistakes faster. When the thinking is clear, AI compresses weeks of work into days.
But it’s not only about coding and IDEs. There are more things in our software engineering jobs besides writing code.
In this post, I cover all the ways I could think of for an engineer to become more productive in their day-to-day work. Let’s start!
In this post, you’ll learn
How to use AI to increase output without lowering quality
Where AI actually saves time in day-to-day engineering work
How to turn invisible work into visible career leverage
Why workflow design matters more than raw technical skill
Technical work. Ship faster while keeping high quality
Scaffolding and boilerplate generation
Generate services, endpoints, and infra skeletons to get a happy path running fast. This avoids the brain fatigue of having to search for the syntax of things specific to a framework and work that you’ll only do once.
It’s also useful to test an idea before committing more resources. A small session to build and try out a POC will prevent the frustration of throwing away weeks of work if the idea isn’t what leaders expected.Legacy code understanding and translation
Use AI to explain code, regexps or the architecture of a project. I have found it useful to reduce onboarding time by asking AI what a module does before reading it line by line.
Testing as a default, not a chore
Generate unit and integration tests early. AI is great at boring edge cases. The point of unit and integration tests is to make sure you can make changes later without worrying about breaking existing functionality. You’ll know if you break something unintended thanks to those tests.
Keep in mind AI will optimize to fulfill a goal, and if the goal is just to make tests pass, it may delete the tests or update the code’s behavior just to make tests pass. Green does not mean correct.Refactoring
I remember an “ahá” moment when I started using refactoring functionalities of IDEs. It was trivial to extract something into a constant, function, or class. It was safer to do it with the IDE’s built-in functionality than to do it myself.
The same with AI, but for more complex refactoring. AI can make the complex refactoring to follow certain design pattern that an IDE just can’t by itself. Keep in mind that you’ll benefit from tests to ensure the refactoring doesn’t change the behavior!Debugging and rubber ducking
Pasting logs, stack traces, and failing tests is much faster than reading them yourself. More than once, AI spotted the issue in a few seconds after I spent a few minutes reading the stack trace of trying to find the right log that indicates the issue.
Command line, SQL, and complex syntax generation
Translate intent from natural language into commands and queries. This removes friction from tools you use rarely but still need to get right. I’ll be honest, I don’t know how to pipe multiple terminal commands like
awkorsedand make them work properly, but AI usually nails the command that I need.
Also, new database client applications are emerging to use natural language to obtain the data you need and visualize it. You don’t need to subscribe to any fancy SaaS, just use IA to craft the SQL queries for you.Documentation automation
Generate docstrings, READMEs, and diagrams from code itself. With AI, there’s no excuse not to write a good readme for a project.
Something to keep in mind is that AI can be overly verbose, and that the order in which you prompt AI will change your output document. So make sure that you are still driving the AI, that you know what you want as an output, and just delegate the tedious part of writing or finding the right referencesCode review acceleration
Summarize diffs and highlight risky changes. This lets you focus on what feels wrong instead of parsing noise.
I just read a note from Franco Fernando last week about code being harder to review than to write. In his words: “Reading is so slow because you have to piece together the thought process in reverse, and that feels hard.”
Imagine you’re a famous podcast host. You’d have a team of researchers that provides you with a report for each guest, and you’d have that structure because it’s faster for you and it scales. The same when reviewing code. With AI, there’s more code written, and you don’t have the luxury to take your time to read 3 or 4 times the PR to understand its purpose.Scripting and automation
Create scripts for migrations, data generation, and reports. If you have done it twice, you should invest the time to automate it. For many things, AI is not good by itself. For example, if I have to generate synthetic data for 5 rows, I may use AI directly, but if I need to do it for a million rows, my only solution is for AI to write a script and run the script.
Red-teaming and pre-mortems
Ask AI to break your design before a reviewer does. In software security, red-teaming is about a team in your company trying to break your systems before a malicious hacker does. You can do that as well for all the code you write, and not only about security.
It’s good to use AI to soundboard ideas so the first output you show to others is at a higher level.