devs group

Renaming one API field can break an old app. Before changing it, find every consumer. Keep compatibility until those clients can move. Test both versions.

Launch day is one day. Your software has work to do every day after it. That is the job we take on at devs group: turning a business requirement into software people can use, maintain and build on. We build new products, modernise existing systems and work alongside engineering teams. Architecture, implementation, integrations and production belong in the same conversation. AI helps us develop. Engineers remain responsible for the decisions, reviews, tests and releases. The document shows how we approach the work. If you are planning a build or untangling an existing system, start with the requirement: what needs to work, for whom, and under which constraints? https://lnkd.in/eqH87HhX

Your dashboard is fast. Is the number still current? A cache can make repeated reads cheaper and quicker. It also means deciding how long yesterday’s answer is acceptable. Before caching a value, ask: • How old can it be before a user makes the wrong decision? • What should invalidate it? • What happens when the cache is empty or unavailable? A product description and available stock may need very different rules. Useful exercise: choose one important number in your product. Trace where it comes from, when it refreshes and what the user sees while waiting. Speed is useful when people can trust what they’re looking at. #SoftwareArchitecture #WebDevelopment

That odd check in your code might be the only thing preventing an old bug from coming back. Before asking a coding agent to remove it, open the commit that added it. What went wrong? Does that condition still exist? Which test would catch the problem if you removed the check? Sometimes the old constraint is gone and the cleanup is overdue. Sometimes the extra line is doing useful work. If nobody knows why it exists, investigate the behaviour before inventing an explanation. Once you understand it, leave a short note about the reason. The next person will need that context, too. A thought from our article on engineering judgment with coding agents: https://lnkd.in/exdSHepm #SoftwareEngineering #CodeReview

“The prompt says it must not delete anything.” Good. Now check whether the tool actually allows deletion. An AI instruction describes the desired behaviour. The permission check decides what can happen. For a new workflow, separate three levels: • Read information • Prepare a proposed change • Apply the change Start with the access the task needs. Require approval for consequential actions, and enforce that approval where the action runs. Try one negative test: ask the agent to do something outside its role. Does the system block the action, or does it merely hope the model declines? That difference matters when a helpful assistant gets connected to real systems. #AIEngineering #Security

A timeout doesn’t mean nothing happened. Your app sends a request. The server completes the action. The response gets lost. Now your app retries. Without duplicate protection, one action can become two. This matters when AI agents call tools, too. For APIs that support it, reuse the same idempotency key when retrying the same operation. Check the provider’s rules, including how long it remembers that key. A useful test for your next integration: interrupt the response after the action succeeds. Does the retry create a duplicate? We explain the pattern here: https://lnkd.in/e_z345_6 #BackendEngineering

Pick one task your team keeps putting off. Now finish this sentence: “When ___ arrives, prepare ___, so someone can ___.” For example: “When a support ticket arrives, prepare a summary and a draft reply, so a colleague can review and send it.” That gives you a useful starting point for an AI workflow. Next, decide: • Which information can it read? • Which actions can it take? • Where must a person approve? Enforce those permissions in the tools, too. A written instruction alone isn’t an access control. Then test real examples. Count how often the result is useful without correction, and measure the review time. Which recurring task would you start with? #AIEngineering #WorkflowAutomation

Pick one task your team keeps putting off. Now finish this sentence: “When ___ arrives, prepare ___, so someone can ___.” For example: “When a support ticket arrives, prepare a summary and a draft reply, so a colleague can review and send it.” That gives you a useful starting point for an AI workflow. Next, decide: • Which information can it read? • Which actions can it take? • Where must a person approve? Enforce those permissions in the tools, too. A written instruction alone isn’t an access control. Then test real examples. Count how often the result is useful without correction, and measure the review time. Which recurring task would you start with? #AIEngineering #WorkflowAutomation

“Please review” is a lot to ask when the change contains three unrelated ideas. A useful pull request gives the reviewer a clear path: What problem triggered it? What behaviour changes? How was that checked? Where is the risk? Keep cleanup separate when it hides the important change. Show an example when the behaviour is hard to explain in prose. With coding agents, producing a large diff can be quick. Understanding it still takes attention. Before opening the next PR, ask whether a teammate could explain the change after reading the description and the relevant code. If not, split the work or improve the explanation. #CodeReview #AIEngineering

Something breaks. Which dashboard do you open first? We like to organise the first view around three questions: 1. Are users affected? Look at failed requests, slow responses and whether key actions still work. 2. Is the system under pressure? Check queues, connections and the resources most likely to run out. 3. What changed? Put deployments, config updates and feature flags on the same timeline. Here’s a useful exercise for your next team meeting: open your dashboards and see how quickly you can answer those questions. If the answer needs ten tabs, you’ve found something to improve before the next incident. The longer version: https://lnkd.in/eA6DpetB #DevOps #Observability