AI 시대의 소프트웨어 엔지니어링

Software Engineering in the Age of AI June 28, 2026 For those of you who don’t know, when I’m not writing novels, I spend my days as a software engineer, writing code. The software industry these days relies heavily on artificial intelligence. Because it has studied trillions of lines of publicly accessible source code, because code solves problems with testable right and wrong solutions, and because code is structured specifically to be understood by computers, AI has gotten very good at writing code. Before programmers started using AI, a typical workflow looked like this: Someone asks you to add a feature to an existing program. You write up a formal definition of that feature describing what it should (and should not) do, how users can access it and how to test that it’s working correctly. You spend time researching which data structures, algorithms, code libraries and external services might serve best to implement this feature. You write the code to build the new feature, the tests to make sure it works as expected, and the documentation telling users how to use it and telling other engineers what they’ll need to know to maintain and debug it. You create a “pull request,” asking other engineers in your organization to review and comment on your new code, and ultimately to approve it for use in the product. Now that AI can consistently produce pretty good code, the software developer’s workflow looks like this: You write a prompt asking AI to create the new feature. You review what the AI wrote, making changes as you see fit or asking the AI agent to make those changes for you. You either merge the new code into the existing codebase yourself, or you create a pull request for someone else to review and merge it. In the old workflow, the creative process happened mostly in your mind. In the new process, you supervise the creative process that unfolds inside the AI’s internal machinations. You’ve put some effort into creating a concise, thoughtful, accurate prompt to get the AI started on its work, but you haven’t done any of the hard thinking you would normally do in writing the code yourself. When you get code back from the AI, you’re essentially acting as an editor because, while AI can write code, it cannot always see the big picture of your project the way you can, and you need to make sure this new code won’t cause problems. AI does not know whether the code it just added violates some legal requirement to which your product is subject. It does not know if the request it makes to an external system is going to take ten milliseconds or ten minutes to fulfill. It does not know whether the actions of its code will conflict with some new feature that you know your teammates will be adding three weeks from now. It does not know whether the function it just wrote might introduce a new security problem when interacting with another function you wrote last month that handles sensitive information. A senior developer does know these things, and this is why he or she needs to vet and often correct the AI code that appears to “just work.” To a senior developer, AI is a competent, fast-working junior or mid-level developer that, when properly directed, produces mostly solid work but lacks the institutional knowledge and the deep and broad systems-level knowledge that you have developed over the past twenty years. Now, let’s back up for a second and make an analogy. Let’s say you’re a writer of historical novels. What does your workflow look like? Probably something like this: You picture a scene in which two statesmen are arguing outside St. Paul’s Cathedral in London in 1760. You consider what you need to know to write this scene accurately, including clothing, the atmosphere on the street and the political situation. You crack open a number of books and start taking notes on the following, among other things: Based on their socioeconomic positions and their roles in society, what would your characters be wearing? Who else is on the street with them? Vendors? Cabbies in horse-drawn carriages? What did those look like? Were the chimney sweeps out at that time of day? What about prostitutes and law officers? Who are the primary political figures about whom your characters argue, and what are their positions at the moment? What historical events from recent weeks or months are relevant, and how will they influence your characters’ argument? You go back to your writing, weaving the historical facts into a scene that you spin from imagination. The novelist and the software developer have a lot in common here. In reality, the novelist will have done much of her historical research before she begins writing, just as the software developer already knows from years of prior work which data structures and algorithms and which types of caches and databases will be suitable for the new feature he’s about to write. What both workers have in common is a deep feeling of engagement with the material they’re creating. They are entirely immersed in their work, to the point where they often lose track of time. In both novel writing and software development, it’s common for me and many of my peers to check the clock, dive into a problem, and then look at the clock ten minutes later to discover that four hours have passed. This is the state of “optimal experience” that psychologist Mihaly Csikszentmihalyi described in his bestselling 1990 book, Flow . Writers, software developers, painters, musicians and all other creative types enter this state when time and circumstances permit. Many software engineers work after hours at home precisely because the lack of meetings and other interruptions outside normal business hours permit them to enter this state. Now, let’s put the historical novelist in the position of the software developer. She gets a call from her publisher saying they’ve found a way for her to bring four books to market each year instead of one book every two years. They’ve recruited a bunch of top-notch high school and college students who can each crank out five pages a day of competent writing for dirt cheap. The publisher wants the historical novels to maintain the original writer’s level of excellence, or to at least be close, so they’re retaining her services as an editor. The novelist’s job is now to edit the work of the students, each of whom has been carefully prompted to write pages that should, with a little work, be stitched together into coherent chapters. Anyone who has ever graded the work of high school and college kids knows that this is generally not rewarding work. If you’ve ever had to grade a hundred papers in a week, you know what a grind that is. The novelist, like the software engineer, is no longer deeply engaged in her work. Editing is not creating. You do not give yourself over to your imagination. You do not immerse your mind and feelings in the process of invention. Instead, you’re rooting out problems, trying to clean up clumsy wording and redundant descriptions instead. The flow state is gone. You are now a cog in a larger process that doesn’t really value your creativity or your need to exercise it. Worse still–and I have felt this personally after months of reviewing AI-generated code–your skills drop off sharply. When a new issue arises–a feature to be implemented, or a tricky bug to fix–the idea of wasting several hours on it feels insulting. Why should I dig through all that code when Claude can locate the bug in five minutes and start drafting a fix? Why indeed? Why should you or I invest mental energy in something we used to actually like doing, something that now feels like a chore, when the bot can do it for us? Months of working with AI have made me noticeably lazier and stupider, at least when it come