Your job on ADD (AI-Driven-Development)

Your job on ADD (AI-Driven-Development)

In a recent article I mused about how AI will impact our jobs as software engineers. I was realizing things were changing much more than I expected, and I was expressing my concerns about what it meant for all of us.

After a couple of weeks of prototyping and talking to others about this, I'm getting a better idea, and I wanted to share my thoughts.

"Senior" engineer tells another "I remember when" story...

I got my Computer Science degree at UC Berkeley. I started in 1986. As I was told by those who had been there, two years before I arrived, the basement of Evans Hall hosted a massive card-reading machine and an array of card-punching systems.

Computer science students would write the code for their projects by painstakingly punching out little holes in rectangular cards.

A single simple homework assignment could contain hundreds of cards. You would then take your cards to the counter, and an operator would put your batch on a stack and run it when a machine was ready. The output was printed out, and you could then evaluate the output, find the bugs, and likely replace whole sections of your card set.

By the time I was there, we were using vt100 terminals to centralized computers and writing code in text files. We each had our own computer account and could compile and run our code at will. We used vi and make and an actual version control system (CVS). The productivity increase was massive.

I'm still standing

When that transition happened, it's not like a ton of computer programmers were fired.

Nor did this happen when we got machines with windows and a mouse, or IDEs, or web-based apps (actually in some ways that was a step backwards for a while), or Google, or object-oriented languages or an actualy garbage collector or Stack Overflow.

What did happen is we had to learn new ways of doing things. I have spent my entire career having to teach myself new things over and over and over again.

I have seen the backlog of ideas from every company I've worked for, and in pretty much every case the vision is huge and the backlog is effectively infinite.

Re-training on the job

So unless they're not making money, companies will not fire developers. But in order to compete and make that money, they will need to deliver value faster by leveraging AI. I have been using these tools, and they are game changers.

So the demand for developers will continue to be high, but what it means to be a developer is changing quickly. Your technical and analytical skills will still be needed, but you will be doing more direction and guidance and less actual implementation. It's like you'll be a team lead rather than just a coder.

If we want to be in demand for that world, we have to sit up straight, take a deep breath, and dive into learning.

What won't work is saying "I'm too busy to dig into this, I have features to ship" or "there's so much hype, and most of this will be a waste of time." That may keep you valuable in the short-term, but it's a dangerous game to play long-term.

If nothing else, prove to yourself that it is all just hype by at least trying it.

Drinking from a firehose

There is so much to learn. And although vast majority of it is irrelevant, useless or temporary, there are also solid gems that are essential to learn.

This is so much more the case when it comes to making use of AI for developing software. How do you even begin, and how do you keep up? I mean, we all have a day job...

Here are some techniques that have helped me

  • Focus on solving a problem. Identify a problem that is relevant to your work and to your company, and experiment with using these new AI workflows and tools to solve that problem. This approach helps me go deep and keep my learning grounded in the nitty gritty of actually getting something to work.
  • Curate a list of thought leaders. Find a channel that allows you to "listen in" and discover themes and new ideas without being flattened by the hype machine. These days the best platform for that seems to be LinkedIn, but you can pick what works for you. Maybe you prefer podcasts, that works great too. I also like following people on YouTube. YouTube is particularly good at suggesting similar topics. I don't mind going down the rabbit hole, but I try to keep my feet on the ground.
  • Six impossible things before breakfast. Someone I know who is incredibly fluent and productive with AI development spends an hour each morning catching up. See if you can build a habit of spending a little time each day learning. A journey of a thousand miles starts with teaching yourself to fish. Something like that :)
  • Talk to others. See if you can find others who are also trying to learn, particularly if they're ahead of you on the journey. Talk to them, have them show you what they're doing. Maybe form an interest group at work and you all can meet regularly and share stuff on Slack. There's no need to do this alone.

Cool tools and practices I have found

It has only been two weeks, but here are some pointers to things I have used and experimented with that I find particularly useful and promising.

Many of these tips come from Jarad DeLorenzo so I want to call him out here and thank him for all his help.

  • You are hiring a subcontractor - Great perspective from Jarad: the most effective way to interact with AI, particularly for larger projects, is to talk to it like a subcontractor. Give it a problem statement, and have it give you a project plan, a design document, implementation plan, track status, write acceptance criteria and tests, write code, review its code and document the feature when it's done. Do each step one at a time, review its work, give it feedback and refine before going to the next step.
  • Give it focused context - An LLM doesn't do well just working with its vast compendium of general knowledge. You get much higher quality results if you give it focused context. If you want it to work with a particular library or tool, refer to it either by providing the docs page for the tool or pointing it to the URL. AIs apparently do better with well-structured text focused on the content rather than raw HTML, but sometimes the docs are too big for the context and you run out of tokens
  • Maintain a document folder - This is also a gem of a tip from Jarad. Create a docs folder for your project. Keep all the artifacts you create from above (project plan, design doc, implementation plan and status) in a docs folder that the AI maintains. You can also provide a list of rules to follow when writing code: best practices, formatting rules, whatever is important to you. When you want to do the next step, make sure to add these documents to its context before asking it to do the next step.
  • Have it update status - Thanks to Jara for this one again. As your AI subcontractor make progress, have it update status in the execution plan doc (I like to format it as a bulleted list with check boxes). This is so effective at being able to pick up where you left off later and it knows exactly what the next step is.
  • Try out Cursor - if you haven't downloaded and tried this, it's definitely table stakes. With it's ability to provide AI support inline as well as in your terminal, smart suggestions, a fast chat window, the fact that it indexes your whole codebase into a vector db, and its Composer conversational tool for building something as a conversation, it really does add some serious nitro to your engine.
  • Try out Cline - Cursor sometimes gets stuck when something doesn't work. It also doesn't do a good job of being able to run things on the command-line, see the output, and then read the errors to decide what to do next. Cline, a VS Code extension, is really good at this. So when it's time to refine and fix bugs and iterate, I find myself using Cline over Cursor's native AI chat interface. Since Cursor is build on VS Code, you can add Cline as an extension.
  • Learn what models are good at what - there are an amazing number of models out there. Some are good at reasoning. Some are good at codegen. Some are good at writing. Pick the right tool for the job. But to be honest, this changes almost daily, so good luck! I would say, try something, if it doesn't work, try something else.
  • Use Perplexity to ask general questions - I find Perplexity really useful for doing research, such as "which models are the best at codegen?" or "what are the best tools for building agent workflows?"
  • Compose solutions using agent workflows - As always, composition of focused components to solve a problem is such a great way to build things. In the AI world, you can compose components of AI agents. Each agent is given a specialized role, it is given tools it can use, and a set of instructions. Then you chain them together to get a job done. In this way you are acting like a general contractor or engineering manager, handing out jobs to various minions. The tool I have found works best for this is langgraph.
  • Don't limit what you think you can do with AI - I have been astonished. With a good context, the AI has generated rich, useful code, excellent design docs, debugged issues, and done effective refactors. I haven't done this, but others have shown me how it can build web-based UIs and take on subtle personas. Pretend you are working with a professional, with that level of analytical and creative skills.
  • Watch out for security concerns - If you are at a company that has strict security policies, be sure you abide by them. Cursor, for example, indexes your code and drops it in a vector db in the cloud. That could easily be a no-no. You may not even be allowed to work with an AI model in your IDE, since it's reading your code to give you answers. I personally have had to do all my learning on my own computer using open source code bases.
  • Demonstrate impact to your leaders - I am also meeting with leaders to show them the impact of this stuff and to come up with a plan to not let security be a risk to our ability to compete in this brave new world. You might want to do the same. Have a good demo focused on problems they want to solve (trust me, it won't be hard).

I'm still learning, so probably some of this is wrong, and there is so much more to learn. But hopefully this is useful for you and your journey. Best of luck and have fun!


Nimesh Desai

Software Engineer | Storyteller | Explorer

3 个月
回复
Andrew Wooldridge

Engineering Manager at eBay

3 个月

Thanks for this comprehensive and insightful article. It definitely adds to my own learnings and gives me areas to build my own knowledge from.

回复
Nimesh Desai

Software Engineer | Storyteller | Explorer

4 个月

This is very much I was thinking (and was going to write about) about how software engineering has evolved over the years and will continuing evolving, with the addition of AI now.

Willy John VanSickle III

AI @ Justworks | Transforming business with AI | ???? |*| Multi-agent LLMs |*| Product |*| Human-first solutions |*| Open Source |*| Measurable results |*|

4 个月

Langgraph slaps tho

Willy John VanSickle III

AI @ Justworks | Transforming business with AI | ???? |*| Multi-agent LLMs |*| Product |*| Human-first solutions |*| Open Source |*| Measurable results |*|

4 个月

Jarad DeLorenzo seems like a real expert on this AI stuff ??

要查看或添加评论,请登录

David Van Couvering的更多文章

  • Simplifying technical designs

    Simplifying technical designs

    Someone recently shared with me that they really appreciate my ability to take a massive, complex problem or design and…

    3 条评论
  • Choosing a backend language, choosing a culture

    Choosing a backend language, choosing a culture

    Somebody was talking to me about choosing a backend programming language for their startup. I was realizing that in…

    2 条评论
  • A set of coding standards

    A set of coding standards

    We have decided to focus on improving coding practices within my team, and I wanted to provide a digestible summary of…

    7 条评论
  • How big should a service be? The age-old problem

    How big should a service be? The age-old problem

    It happened again. I was in a conversation with a colleague, and they were trying to decide whether to make something a…

    8 条评论
  • Crossing the distributed systems chasm

    Crossing the distributed systems chasm

    A large part of my career has been helping an engineering organization evolve from a single monolithic system that…

    3 条评论
  • Deciding how frequently to deploy

    Deciding how frequently to deploy

    I was talking with a colleague last week about whether they should increase or decrease their deploy frequency. They…

    4 条评论
  • Turn out the lights when you leave...

    Turn out the lights when you leave...

    I have been having some interesting conversations with my developer colleagues as they are starting to see how well the…

    3 条评论
  • Politics and sales as a software engineer

    Politics and sales as a software engineer

    Politics and sales can definitely be a dirty business. Some people will say anything if it is to their advantage.

    1 条评论
  • Changing coding habits

    Changing coding habits

    Over the last few years, I have been working with teams trying to help them change their design and coding habits. I am…

    1 条评论
  • So busy but nothing gets done

    So busy but nothing gets done

    In my last post I talked about value streams and how we can use this concept to change how we think about building…

    2 条评论

社区洞察

其他会员也浏览了