AI and engineering
No shit this thing is real
Of course, only a lazy person would not write about AI. And it is obvious - it is everywhere. I am trying to use AI in almost all parts of my life, just because I strongly believe that we are already on the hook of AI progress, and even if it stops evolving that fast, we will be using it in any “late stage“ of AI development.
And again, AI is changing the way we code and develop systems. Even more, the way we see how people need to code. Here are a couple of reflections I've had so far.
The flow
A couple of years ago, people were talking a lot about “the flow“. An extremely focused state of mind, where you are working on some tasks and forget about time, environment, etc. It was extremely important for engineers to be in this state so they could do their work with a clear understanding of all edge cases, implementation details, etc.
Many years ago, I was reading a book called “Managing Humans“written by Michael Lopp. In one of the chapters, he mentioned Web DHD (like ADHD), but when we have a browser open with multiple tabs and are doing many tasks at once, like listening, musing, checking our code, replying on messenger, and checking the news. Michael called this “requirements for today's engineers,” not a neurodivergent state of mind. And I tended to agree with him. Imagine an engineer who reads documentation and, while reading, never replies to messages, letters, or even on-calls. Now, I feel that we are ready to take the next step of Web DHD → AI DHD. Yes. Previously, we expected an engineer to work on only one task but to be fully committed to it. Now it sounds lame and not effective at all. We expect engineers to operate with multiple agents: one is coding, another is researching, another is preparing an execution plan, and one more is writing the side project you have always wanted to complete.
You remember when “switching context“ was an anti-pattern. Well, now single-threading is an anti-pattern, and we wish more people could do multi-threading, because true parallelism does not exist with the outdated human brain on high-level cognitive functions. So now we are in the world of “effective switching context“ → more like a JavaScript event queue: you are fully focused on one task, get it to some milestone, give additional instructions, and the switching agent brings full focus there.
It is really hard and, at first, unproductive, but with time and experience, you kind of get used to it.
Writing code
When I worked at Affirm, one of our engineering culture values sounded like: “Code is more read, rather than written“. Meaning that you need to write code in a way that other human beings can read, maintain, and update it.
Now, in high-AI-penetrated companies, humans are less and less involved in writing code but more and more in reading it. GenAI can now do exceptionally good work on writing code, especially with technologies where more code is available as training material. But the quality of the code still highly depends on factors like:
How well you’ve configured rules for AI in your project/repo
How well are you providing specs to AI
And finally: how well you read what AI wrote, how well you understand what is happening, and how many lessons and actions you are taking to make AI generate code better next time ( meaning providing additional info to your .md configurations )
In the end, code quality still depends on humans, even though we are not writing it anymore. GenAI made it extremely easy to become a YOLO developer. Though your YOLO is a problem for the next engineer (or AI) who will work with your code.
To be frank, I don’t believe we can maintain current code quality standards for much longer. In most cases, they were low on average in the industry. But with a speed AI giving to us → mostly we will be selecting speed over quality.
Will it become worse? In the beginning, yes. But in the long run, AI will evolve. And AI doesn’t care about the quality of the code. I feel that, over many years, producing high-quality, human-readable code will become a premium craft like making knives. You can buy a bunch of knives in Ikea for a couple of bucks, or you can buy a knife made by a Japanese blacksmith for a couple of hundred.
Tho we are not there. So humans should still own the generated code as it was written by them. Good engineers will still produce better code than bad engineers. But bad engineers will produce WAY MORE code now.
Full-stack
For years, we were talking about full-stack engineers - those who can do frontend and backend with the same effectiveness and great quality. I am not saying that it is not possible. I think almost all engineers can be considered full-stack engineers. But a great frontend engineer can be quite a lame full-stack, and an amazing backend engineer can create a really ugly frontend and still be considered as full stack engineer.
Now, and going forward, I don’t think we'll require full-stack anymore and would consider this the default. Stack by itself is getting irrelevant for a job. Previously, you were able to onboard an engineer to a new technology stack in a couple of weeks, and within a couple of months, an experienced engineer could deliver good results with high performance. Now timelines are getting tighter:
AI will generate code
AI will help to understand code
AI will help to answer questions about the code or technology
So understanding of the engineering in core and design concepts is getting more important than proficiency in a particular technology. We have plenty of neofits in the industry because AI code-generation tools are so accessible, but once we reach a Plateau of Productivity, we will need engineers who understand CS more than ever.
Tho, yes, tech stack for most of the industry becomes irrelevant.
Price of mistake
Code is getting cheaper and cheaper. Just because it is way easier to generate it. Migrations and refactoring can be completed in hours rather than weeks. The price of making a coding mistake (not a business mistake) is inflated. You’ve done a bad structure in your module - work with Claude to rewrite it. Used the wrong lib - rewrite it. You need to update the flow - write a good spec on what a good flow needs to look like.
Tho communication between systems is still a bottleneck. Interfaces are more important than ever. The services you use can change internally as often as every day. Investments in contract testing seem to be a great way to sleep well during the night. Until we replace all systems with those that operate by AI (either via MCP), A2A, or God knows what will be next, AMAZING INNOVATIVE PERFECT Protocol ), we still have and will have tons of systems that expect your system to operate by strict rules. AI gives you the possibility to change them, but your clients won’t give you that luxury.
Do the right things right
AI is amazing. It is like opening Pandora’s box on unlimited possibilities.
But as Uncle Ben told us-"With Great Power Comes Great Responsibility"-we need to use AI carefully. Meaning that we still need to check what AI generated, discuss why it is done that way, and still have ownership of our codebase. Have rules, rituals, and workflows that prevent AI from getting into something that will be used by other people. At least for now.
I do see a future where fully AI-operated companies produce either other Agents or Software for other AI agents, which will be used by humans. And I think we will eventually be there. Recently, I asked my OpenClaw bot to turn on my Govee lights on the same local network via Telegram. And it found them, checked how to access them, and … turned them on. No instructions on how to do so were provided. I played with it and asked it to turn on and off on a schedule. And in the end, deleted the Govee application.
This little incident made me believe there is a good chance we'll eventually be in a future where AI writes code for another AI. And we, as humans, will just need to politely ask for what we need. Hopefully, that means that we will have more time for other human beings.