The title is a compound I came up with instead of a boring one — TaskCraft — which happily echoes the cult game titles Warcraft and StarCraft: warm childhood memories. TaskCraft is short for task crafting: reshaping a task, the craft of a task, or inventing a task. Hard to pin down with a single word.
Funny thing: craft literally means handicraft — something involving manual labor. Yet "craftsmanlike" in art is often derogatory: template work, zero creativity — which flies in the face of everything I'm about to write below. But let's take it one step at a time.
You know that feeling when you've been doing the same thing for a long time and it starts to wear on you: you want something new — new challenges, new changes, new scenery. It feels like living in Groundhog Day. The vast majority of people know this feeling. In searches like these, some go as far as radically changing their field or profession altogether. They change locations, cities, countries, families, hobbies. It's called finding yourself.
This year marks my 16th year of commercial programming experience — last year's milestone was round by human standards, this year's is round in binary. Unprofessionally, I started much earlier. This time I decided to write far more text than a year ago.
I still write code with my own hands rather than pushing tasks down to subordinates (less than before, of course — "thanks" to AI agents; they say soon they'll take this wonderful occupation away from me altogether, but anyway). I never became a full-time manager, never became a CTO, never left employment, never changed professions. No — to this day I'm on projects "painting buttons" and "assembling forms" with program code. And although my level of involvement, my influence on the product, and the "big picture" I saw from above kept changing, at my core I keep doing the same thing I started doing many years ago.
Job crafting
I reflected on what lets me do the same thing for so long without losing interest, and came to the conclusion that I've long been using a technique — or even better, an approach, — that psychologists call task crafting. I'd been using it unconsciously the whole time; for a long while I didn't know it had a name, and I couldn't see the pattern at all until I landed in a seminar at one of my former companies. That's when the puzzle came together for me.
Task crafting is one of the terms under the broader concept of job crafting: the process of designing your own activity, usually initiated bottom-up by the employee — a kind of proactive strategy for changing the characteristics of your work so it better fits your personal needs, goals, values, and preferences.
The term traces its roots to the work of two scholars, professors Amy Wrzesniewski and Jane Dutton, in the early 2000s. They studied why some employees perceive their job as "drudgery" while others find meaning and inspiration in it, even doing similar tasks day after day.
And the smart folks single out three main approaches to making work bring joy and happiness:
- Task crafting — changing the type, scope, sequence, and number of tasks that make up the job. Employees can take initiative by altering the tasks they perform, the way they work, or even task deadlines. In doing so, workers exercise a certain level of control over their work to minimize negative feelings (say, alienation from the hands-on work itself) or the overall time, in order to meet a deadline.
- Relational crafting — changing the nature of interactions with other people in the workplace. For example, employees can choose to what extent and how they interact with colleagues, or how much they take part in group social events (meetups, team-building events, corporate parties, small talk and coffee talks, etc.).
- Cognitive crafting — changing how you perceive your work in order to give it more meaning. For example, an employee may continually reevaluate how the work affects them and how connected to it they are. This can include reflecting on observations made at work and assessing how well those observations match personal goals, ideals, and passions.
I want to talk specifically about changing tasks. Relational and cognitive crafting are an interesting topic, and they have their place, but I find it hard to reflect on them just yet and fold them into this product of my graphomania. I'll definitely do that later — but for now…
To be honest, I'm not strong on the theory of the whole concept — I never went beyond one seminar and Wikipedia — but, as it turned out, I'm a good practitioner. So it's easier for me to just go ahead and tell very concrete stories of my personal task crafting that, in my view, kept me from "cooling off" toward the craft and the profession, kept me from being a "grasshopper" hopping between employers for a raise of a few hundred dollars — and in places directly or indirectly shaped my entire career.
I apologize in advance: the text below will be dense with nostalgic and historical digressions and very specific personal details of my career and professional curve, but for the full picture and the mood, I need to record all of it.
My task-crafting examples
Testing and tests
In 2010, looking for an internship during my college years in a major called "software for information technologies" (locally abbreviated POIT), I landed at a local IT company — and, lucky me, beyond the usual internship paperwork they offered me a proper full-time job: the company happened to have an opening. My joy knew no bounds: I would work at a real IT company, not as a sysadmin at a clinic or a school (with all due respect to sysadmins), but where they build real software — it was a straight-up dream. True, the opening was not about development but about testing. They offered me to become a tester, and I agreed without a second thought.
And I'll be honest: at that point I knew absolutely squat about what software testing was or what testers were supposed to do. No — at a high conceptual level I sort of understood, from the computer-game industry, beta testers and all that, but there was zero specifics or detail in my head.
When you're young, everything is interesting: the environment itself, and the fact that you're in it. I settled in quickly enough. Like many at the time, I speed-read Roman Savin's "Testing Dot Com" — the Russian QA bible of that era — and even wrote myself some desktop utility in Borland C++ that helped me file nicely formatted bug reports into a hideous tracking system of KROC, a big systems integrator — at the time, one of the main clients of that IT company.
As you've probably guessed, 99% of my working time went to manual testing. These were electronic document management systems with convoluted lifecycles of various document types, written back then in Java 6 and on the little-known EMC Documentum platform with DQL — a dialect of SQL.
Everything was great, except that I had always seen myself as a developer, not a tester — but it is what it is. I felt a mild pang of envy toward the departments where the guys wrote code. I felt second-tier, not first — again, with all due respect to testers. But I always did my job honestly and responsibly.
And still, had things kept going that way, I would definitely have gotten bored. Would I have changed companies or gone somewhere else? Hard to say. But the thing that held me was automated tests. That was my way of changing the work — my task crafting.
As a regular of software-testing.ru at the time, I quickly caught the trend: everyone was looking toward automation. And there it was — Java, Selenium RC (the first implementation of that tool), and real programming with its own patterns like Page Object.
I started slowly learning the subject and writing automated tests at work, while continuing manual testing on my immediate projects. The tester's profession took on new colors and no longer seemed boring or "second-tier". It should be noted that inside the company itself, automated tests were a very distant thing: at that point not a single project had any; it was something new and unexplored, from trendy forum articles, not from real life out in the provinces.
At some point I decided to run a small meetup for the managers and the team on my project — by then it was already a system for corporate documentation based on the DITA standard for the SAP corporation. I showed the end-to-end tests I had written in Selenium RC (back then they were all built on XPath out of endless chains of div containers) and sold the idea that manual regression could be burned down with automation. The manager gave the go-ahead for me to officially take on covering the main scenarios — and so programming and automation became my official job instead of invisible task crafting.
They even allocated me a spot in SVN next to the project's code. So effectively I was the pioneer and innovator of automated testing in that company.
Later, automation became a staple of all large projects, and testers got their own career track named SDET.
At some point my department of combined sysadmins (back then there was no such term as DevOps engineers: the people who configured Oracle and wrote Ant configs were called sysadmins, on par with those who reinstalled your OS and brought you a mouse and keyboard when you joined) and testers matured enough to split into two — QA and SA.
That was roughly the moment Steve Jobs died. I remember that day well: we all kept going out for tea with colleagues and discussing what would become of the Apple corporation and of our department.
We faced a choice: go into one — QA — or the other — SA, but I wanted a third. I applied to transfer to the Java development department. Yes, yes: that first tier wouldn't let me sleep peacefully. By then, thanks to programming Selenium tests, I was already confident enough in Java and had defended a thesis where I customized Eclipse RCP into a bug accounting and tracking system.
But, I must say, the head of the development department was in no hurry to take me just like that: I was made to go through a full interview with a test assignment. Just like that — no free passes.
As a developer I ended up on the project I had previously tested, and my first task was to bolt BIRT reporting onto it.
But very quickly I was moved to a project for the Daimler concern — a user management system. I remember the domain poorly: it wasn't my focus at the time, but it was tables inside tables and editing them. As it turned out, I was the perfect candidate for that project. And here's why.
It was real full-stack (the word didn't exist then, at least not in our latitudes). And I don't mean backend + frontend, although the distinctive trait of the client side was the stack popular at the time — jQuery: jQuery UI, jQuery Mobile, and QUnit.
Once you dive into browser automation, there's no walking past JavaScript: many things had to be supported with JS code specifically, inserted right into the Java code so that the latter would execute it in the browser environment as part of the test. In other words, I was in the know.
And among other things, the project had suites of e2e tests on Selenium and load tests on JMeter. In other words, they needed a Java developer with test-automation skills and client-side JavaScript. And thanks to my task crafting, I turned out to be the perfect candidate for the position.
Although automated tests were not my job to begin with — they were purely my own redesign of tasks, and JavaScript was altogether a side effect, a way not to get bored and to fill the routine with meaning, — later they transformed into my direct, explicit tasks, the ones I got from the client or from a manager at work.
The gestalt of a would-be artist
Until 2015, before the release of HTML5 and the era of SPA applications with full-fledged frontend frameworks, client-server applications were written with tools like Eclipse RAP, GWT, or JSF-based libraries that encapsulated all the logic of working with browser technologies — JS, CSS, and HTML. You write business logic and data handling in Java, and the UI is the smart libraries' business.
This bred a very second-rate attitude toward markup and GUIs among engineers: mostly all corporate application interfaces looked the same — dry and tasteless — and the layout was assembled with HTML table tags.
In a way, it was an approach that had migrated from desktop development on Borland VCL, Eclipse SWT, and Java AWT.
I was already a couple of years in as a Java developer on another large project for a well-known oil holding, and again it was electronic document management. The framework we wrote the UI in was a JSF library that had wrapped ExtJS 3 inside itself. Since this was a fairly raw homegrown contraption, and without coherent documentation to boot, this layer constantly produced various bugs and problems, and the UI kept falling apart across different browsers.
I keep recalling a quote from Alan Cooper's book "The Inmates Are Running the Asylum":
Engineers find it hard to grasp how C code that interacts with a database differs in any significant way from C code that interacts with a human being.
— Alan Cooper, "The Inmates Are Running the Asylum"
It seems to me that that's exactly when I became that engineer who realized that frontend and backend are about different things.
Perhaps it was the gestalt of a would-be artist: before computers, I was destined to become an illustrator, but I dropped out of art school and generally gave up on that direction. The magic box of resistors took all of my attention. Yet the love for art, visuals, and graphics stayed in my heart forever.
I became the person always called in to fix something in the UI, to figure out that unruly JSF library, to debug ExtJS code and understand how it all worked. My task crafting at the time became CSS and the desire to figure out layout — how to position elements properly with float and clear — and to stop wrapping everything in endless table/tr/td inside JSP code.
We had a percentage-based bonus system back then, and the full 100% could only be earned for something outstanding — which was rare. I remember my team lead throwing down a challenge: if I figured out how to build form and panel layouts in that JSF contraption in a sane and predictable way, he'd write me out those 100%. I did it. Even under Internet Explorer 8 and 9. No joke: how many frontend engineers can boast of doing layout for IE and writing jQuery?
Since then, the reputation of a JavaScript and UI developer stuck to me. I was the first to volunteer for projects with the first JS frameworks, when the line between frontend and backend had already started to show. First came the first SPAs on ExtJS 4 — a system for the German notary chamber — and even then I understood that frontend is not simple. Only, the complexity here is of a different kind. For instance, localization is not just bluntly translating text from English into German. German is an unusual language, with its own habit of fusing words into enormous tokens — which, of course, awkwardly popped out of containers and buttons or caused unexpected content wrapping. Localization is adapting the entire UI to a specific locale.
Then came Backbone.js, Ember.js, and next the industry demanded AngularJS specialists with Bootstrap CSS in the same clip. My task crafting in full-stack Java development — where I endlessly cursed at failing Maven dependencies and poorly understood why building that war file for Tomcat was forever so hard — led me to programming user interfaces in browsers.
I remember some Java folks leaving for big data and starting to write Scala, some going into mobile (Android ran the same Java), and some staying in the enterprise and evolving with the language and frameworks like Spring. Thanks to my crafting of markup, CSS, HTML, and JS, my path of growth was obvious.
It felt organic, as if going with the current, and I liked the outcome: I felt in my right place. The human-computer interaction layer has always interested me more than the layer of pumping data out of a database.
I never became an artist, but I started "painting with code", and that partially closed the gestalt.
Programming and tests
I had been a manual tester who programmed e2e tests. I had been a server-side Java programmer who understood CSS and JS. Now I needed to find what would set me apart among JavaScript/Frontend programmers. I needed a new task crafting.
I kept my role as a full-stack engineer, now heavily tilted toward frontend: Node.js replaced Java in my stack, and somewhere along the way my own team grew, plus the role of a team lead who mentored and taught others.
At that time I was surrounded by projects and engineers who didn't write unit tests. There simply weren't any anywhere. Although the industry itself wrote and talked about it a lot, in reality I ran into something entirely different. In the war for client tenders, with deadlines forever burning and development speed racing ahead, tests were always seen as something that would slow things down, add no value compared to QA, and eat up resources. Perhaps it was a question of the maturity of those projects and clients, or of engineering quality in one particular company. But that's how it was.
The hunger for the topic and the attempt to convert my past experience grew into a new task crafting — unit tests. Mike Cohn's popular concept, the test pyramid, explained very clearly why the emphasis should fall precisely on unit test suites — and those are written by programmers, not testers.
I became a test evangelist. On every project I joined, I'd wire in Jasmine, Mocha, Chai, Supertest, and Protractor. And to make it more fun, I started aggressively pushing the approach formulated by Kent Beck: TDD (Test Driven Development) — development driven by tests.
I wrote about tests, talked about tests, ran internal workshops and pairing sessions in the team, trying to show how to build code starting from tests. You write a test — your expectations live there — and then the solution and the implementation.
TDD and unit tests, and "extreme programming" practices in general, became my task crafting of that period. Many people came to associate me with exactly that. Some colleagues would say: "Look, that's the developer who works by TDD."
Did tests make our solutions better quality? Did the bug count drop? Was regression testing automated and saving money on manual testing? Those are all questions for the business and the corporations. I didn't need the answers, because tests were my crafting: I didn't tell the client I was writing them, didn't sell them as mandatory tasks — and still we always tried to hit the deadlines. One thing I can say for sure: nobody in the other departments did this. Only if a client arrived with a codebase that already had tests. But they were definitely not part of the engineering culture of that company.
Time passes, you grow, and along with you your thoughts change — and the things you use to dilute the routine of work.
The old infatuation with the generation that shaped Agile's postulates evaporated. TDD was hype, but, in my view, overrated — people talked about it more than they adopted and used it. I had already read many books by then, all the cult classics: TDD by Example, Refactoring, Clean Code, Clean Coder, Clean Architecture, and so on. I often spoke in quotes and other people's phrases, trying to look smarter as an engineer. But that wasn't my own opinion. Growing up, I suppose, is when your idols disappear: you start seeing ordinary people in them — imperfect, sometimes wrong, sometimes simply mistaken.
Martin Fowler became, to me, a PR man for his own company — and I did cross paths with ThoughtWorks engineers on a project for a large business-consulting company, and the quality of their work and service left much to be desired. Uncle Bob became, to me, an info-gypsy of the IT world, skillfully monetizing his trainings and talks while not doing real corporate programming; and Ken Schwaber and Jeff Sutherland, good salesmen whose product is Scrum certificates and badges. Perhaps all of this is ad hominem, but my fire for the topic of tests — the one all the authors above so eloquently wrote and spoke about for years — had cooled down, because reality diverged from the bookish picture.
And no, it's not disillusionment — it's growing up. There are plenty of brilliant, talented engineers with approaches of their own; not all of them have the means and the environment to publish books and shape minds. Good code isn't the kind where all the Gang of Four patterns and SOLID principles live — it's the kind that works for people and brings value.
TDD is just another approach, nothing more. It's neither worse nor better than anything else. Tests are the norm for any large, real project with a user base, if we don't want regressions and want to ship proper quality. It's part of quality gates, on a par with other quality checks.
Robert Martin used to appeal to the story of doctors washing their hands: sure, nobody writes tests today, but then doctors didn't used to wash their hands either. A good metaphor. And yes — when nobody around me wrote tests, it was great crafting. Now all doctors wash their hands before surgery and all engineers write tests, so this too has become routine and is no longer as interesting. No longer the thing that sets you apart.
Task crafting through diving deep into tests brought me a wampeter — around which I built my projects and teams, my engineering culture, and — I'm not afraid of the word — my reputation inside my IT company.
Accessibility
The new fascination that could change my work and influence it didn't take long to arrive. If you're a frontend engineer, what do you want to be different from all the other frontend engineers? I would be the one who builds screens and components not only to match the design in Zeplin, but who also makes them accessible to people with limitations: users with low vision, blind users, users with motor impairments or cognitive differences.
At the time, it was an incredibly niche topic. In 2018 I taught a web technologies course at IT Academy and told students about the W3C ARIA standard, clearly understanding that nobody did this on their real commercial projects.
You can't sell this to a client: most startups merely need to gather at least a sighted audience, attract some investment, or monetize their product somehow. WHO reports about 15% of people with disabilities look like solid supporting material, but a real, quality service for developing and testing an accessible product is a colossal expense. Only huge fines after lawsuits can push companies to think about accessibility — which is exactly what happened in 2025 after the EAA act was adopted.
But back then, in 2018, I decided this would be my crafting. I would be the frontend developer who speaks about accessibility and puts it into practice. I started digging into the subject, working with screen readers, immersing myself in WAI guides, and baking ARIA patterns into code and markup.
It wasn't a project requirement: the client didn't order it and didn't ask for it — he wouldn't even want it done 100% and would say to focus on something more profitable and important. Which is exactly why it was never presented or highlighted to him in any way. Accessibility shouldn't be a separate line item in development; it should become part of the natural path, something taken for granted. There is no "we build the project with tests or without" option, just as there is no "accessible product or not" option. It's part of the craft. Part of a quality service.
Alan Cooper has a foundational work — a doorstop of a book, "About Face: The Essentials of Interaction Design". Guess how many chapters are devoted to accessibility? Exactly one, with 2–3 sentences saying that it exists, that it matters, and that, if needed, one should support assistive technologies. I might be wrong, but as far as I remember it's the smallest chapter in the book. Truly first-class UX straight from Silicon Valley.
The first project I managed to make more or less readable for a screen reader was the German platform Lition — where sellers of green energy could find their buyer and sign a smart contract with them on the blockchain.
From there, accessibility walked hand in hand with me. And only now, perhaps, is it turning into routine. The tools have matured beautifully: Lighthouse CI and Deque axe close up to 30% of problems; simply following markup hygiene — semantics, text instead of images, a bit of ARIA — closes another 40–50% by feel. The remaining 20% is the extra Pareto-principle effort, which must be closed together with a team of testers who have real limitations, not artificial ones.
Nothing about us without us. You need to involve people with low vision or the fully blind, people with situational and permanent limitations — that's the only way to bring a product to real usability. WCAG Level AA is a very real, achievable thing, but a product that simply works for all categories of people matters more than numbers in reports and checked-off criteria in guides.
Accessibility is not only a crafting of tasks but also a powerful crafting of meaning and cognition. Supporting accessibility benefits regular users too: they call it the curb cut effect — by analogy with curb cuts that were originally built for wheelchairs and are now used by everyone. Even AI agents benefit from accessible markup.
When you fix a div with onclick into a button, add an aria-label to an icon button, or write a meaningful alt on an img, you feel like a real hero saving the world and restoring justice. Well, there it is — I lied at the beginning of the essay when I said I wouldn't reflect on cognitive changes at work.
Generally speaking, it's not that hard, engineering-wise — not like fundamental algorithms with binary tree rotations — but the effect they have on the mind is big.
After a while, having changed several companies and projects, I found myself on a government project of a Middle Eastern country. The task was to develop a design system for the products of various ministries and departments. They all wrote in different stacks and used different UI libraries; the point was to bring them all to a unified visual look and standard.
As you can guess, if anywhere has strict accessibility requirements, it's government digital products. And once again my task crafting proved useful.
We were developing the design system in Lit and Web Components, adapting ports to the modern Angular and React ecosystems. Initially I was to own the implementation and the technical side, while the Ernst & Young team was to shape the requirements for the design-system components. But they bailed out successfully right at the start, and I had to take the specifications under my own responsibility.
I had constant meetings with the Deloitte team responsible for component design in Figma — and that's where I got to shine with my accessibility knowledge, commenting heavily on the designs and giving advice and recommendations on fixes. It felt like all the accessibility knowledge accumulated over the recent years was needed for exactly this.
A pity, though, that the design system as a project was never adopted: it was frozen when the funding stopped, and the budget was redirected elsewhere.
Animation
The last task crafting of mine I could name is animation on the web. Once a colleague of mine said that in 2024 it's simply not done anymore to ship static interfaces and design-system components. Micro-animations should be a given. I agree.
Simple CSS transitions of 200–300 milliseconds make an interface far more alive. I like to bring, as arguments, weighty evidence from big products plus a few numbers:
- Google Material Design: recommends 200–500 ms animations for text
- Apple HIG: prefers ease-out curves for content appearing, and ease-in curves are reserved for content exiting or disappearing
- Nielsen Norman Group: microinteractions can improve a product's user experience
- Shopify: delicate animations increase engagement by up to 15% to 20%
These points are enough to convince anyone to start adopting animations. Most often, designers themselves deliver static designs. Some describe in text which animation should live where, but that's extremely rare. It leaves a large field for creativity and crafting.
I started with tiny, almost imperceptible transitions and keyframes from 0% to 100% — things like fade in/out or animated content appearing with a slide from the bottom. Colleagues started saying the product was coming alive, and I started feeling more confident.
That's how I got to GSAP, Motion, and Lottie. Many of those ideas were warmly received by my product team and the designers and made it into the product. I was among the first in the division to adopt the View Transition API, trying to mimic native platforms. Once I showed the app to a former colleague of mine, and he said: "It looks as if it's not web — it's native." That was the highest praise.
Animations were never my direct task and were pure crafting, but they transformed into a kind of default, where the product's UI is now hard to imagine static.
Recently I sat updating the visuals in our product. My son comes up from behind and watches how nimbly "hats" and "crowns" jump onto the little characters (user avatars) generated with diffusion AI models.
He stood there, watched, and said: "Oh, now that's what I call programming! And the AI drew that?" 😁 And that's when you understand it was all worth it.
The key with all this is not to overdo it, so the interface doesn't turn into a rollercoaster or a traveling carnival and start causing cognitive load.
And be sure to respect the Reduce Motion accessibility option — suddenly, two of my craftings intertwine!
The downsides
On the other hand, it would be dishonest not to mention the downsides of constantly changing your work and tasks.
The truth is, you will not be paid more for starting to put e2e code next to manual test cases, for laying everything out beautifully with CSS flexbox or grid instead of tables, for writing unit tests and keeping code coverage at 80%, or for making the product accessible to people with disabilities.
You might earn respect from colleagues and a good reputation, but more rarely a promotion or a raise. Getting an improved version of something for the same money is any employer's dream. You can ask for more money or a promotion only if you helped optimize the business, saved it money, or earned it some — or, at the very least (which is a weak case altogether), you want to catch up with a salary market that has moved ahead.
To change tasks, you must be ready for shifts in time and deadlines, for acceleration, or for consciously stepping away from priorities. Sometimes those are risks and costs for you to bear. Blown deadlines or overwork drive you into stress faster than you'd think. Burnout is not a myth but a reality — of the modern IT industry, and of society as a whole.
People who put far less effort into their tasks can climb the career ladder next to you much faster — simply because they don't busy themselves with perfectionism, don't tread water changing their tasks for the sake of variety, but move forward understanding the business's needs and the clients' requests.
What I'm saying is that task crafting is not about professional success. At Google and Amazon interviews, nobody asked me about tests, accessibility, or animations: there, I had to guide a mouse through a maze to the cheese, away from the evil cat, and do it as optimally as possible, in absolutely any programming language. And I, apparently, did not do it optimally. In other words, my free time would logically have gone into a LeetCode profile and yet another re-read of Robert Sedgewick's "Algorithms" — though in a month it would all have fallen out of my head anyway, because it's not the routine of every day.
But that's no longer crafting: activities like courses, books, side projects, etc., are a competing activity. Changing tasks is about your current, concrete work — the routine — not something on the side. And specifically, the routine inside the very same role, and often the same company.
People who change their roles, move into management, become architects and team leads, grow their income faster. The truth is, income grows even faster when you change companies: growth within a single organization is always a very long and hard road. Selling yourself to a stranger is much easier than to someone who has known you for many years: you can't make a first impression twice, and your failures stay with you forever.
If success in a profession is money and a career hierarchy, then task crafting is not about that.
The main thought is this: longevity in a profession (give or take one role) is sustained not by changing employers but by reinventing your own tasks inside the very same profession. That's exactly the path I took. It's a path that, in my view, makes you happier.
What's next?
This longread needs some kind of closing — it's downright incredible that you read it to the end!
Being a futurist is hard, so it's extremely difficult to guess what will be relevant in the future, which crafting comes next, and where it will lead.
Definitely, the biggest crafting for everyone right now is the mastery of writing prompts in natural language, composing plans in MD files for AI agents, and automating in every possible way the work engineers used to do by hand.
Some go full Breaking Bad and boldly start running a ralph loop with review and continuous improvement through simultaneous editing of both requirements and code. Some still dose their AI involvement and act as the reviewer — the human in the middle of the loop who, for now, controls everything, understands what's written, and reads the logic in the code. Some boldly declare they no longer read code.
This is, by the way, an interesting direction of development. If code and programming languages become secondary in software creation, we won't need human-readable programming languages. We'll need to create something like very low-level, optimized languages — compact and clear to machines but barely comprehensible to humans — something like assemblers for AI, only worse in syntax. Generating code and making sense of it will be the prerogative of machines, while the human controls the process at the highest level of engineering abstraction. Possibly even without typing on a keyboard — just by voice, as many already practice.
This is both crafting and not: everyone is doing it en masse right now. So it's hard to guess what's next. But it seems to me that even in this brave new world of AI, the concept and approach of task and job crafting will still be relevant!